If you believe reporting your location as Montreal when you are 800km away is “working”, then yes, it’s fine.
GPS does not report any valid location when it doesn’t get a fix. You’re getting it from other sources in that case.
As noted many times above and in other threads, you need to upload assistance data to the module in order to expect getting a fix to be fast and reliable. You can also get it to work fully cold, but it requires plenty of time and a bit of special attention (and may not work at all in poor conditions - which is true for many other phones too, the only difference is that they download assistance data from the Internet automatically which L5 does not do yet).
3 Likes
the script stops at “getting approximate position …”: 30 minutes in open air, clear sky, without any progress. Should I wait more?
1 Like
How long does this data remain valid? I don’t use GPS very much (maybe once a month) and after starting Pure Maps or Maps, after such a long usage delay, these apps show me in the ocean, but after 10 minutes or so, I’m back on land where I belong 
2 Likes
Wikipedia says:
- ephemeris data is valid for 4 hours
- almanac data that is loaded will typically cover up to 60 days
Do you mean that you have the GNSS chip switched off (“lockdown mode”) or that the GNSS chip is switched on but you are just not using it?
Or that you don’t go outside enough?
Or the two combined?
Not lockdown mode, but the L5 is mostly inside, either in a car or home or office, and is powered on 24/7. So maybe I’m not walking around outside enough with the phone. I’m not sure where the L5 comes up with Pacific Ocean GPS coordinates. Why can’t the last (and best) land coordinates be saved in memory? I must add that after not using the mapping apps for a while, in order to get a new fix, I typically do have to go outside for a bit of time, which is sort of annoying.
I don’t see why you restrict that to “land” and I doubt that it is possible to determine what is “land” and what is “sea”. If you have any valid GNSS location then caching the most recent one could be reasonable.
The question would be: is any layer in the software stack capable of doing that? In my opinion though it should be possible to disable that by configuration i.e. if I don’t want a cached value, if I want a real fix or nothing.
Whereabouts? If it’s Atlantic Ocean, off the coast of West Africa, then it’s (0,0). If it’s Pacific Ocean, somewhere near China, then it’s probably some internal hardware default.
Is it at all close to your real location or is it out by hundreds or thousands of kilometres?
No. It should get something in a few seconds. Make sure you have location services enabled. Also make sure to run the script exactly as specified (via sudo, not as root).
Almanac is valid for a few weeks, ephemerides are valid for a few hours. The module is able to do autonomous prediction of future ephemerides, which extends the time you can get fast fixes to a day or two, but it relies on it having built an internal database of past ephemerides, so it will work better when used often.
For the record, GNSS module is powered off automatically when nothing is using it. You need to actively request it for it to do anything, regardless of kill switch state.
They are, but they’re useless. How do you know that a fresher WiFi/IP-based location is actually worse than the old cached GNSS location? You just don’t.
Well, I recommend checking it then 
/usr/libexec/geoclue-2.0/demos/where-am-i -a 8 tells you the source of location data in “description” field.
8 Likes
It’s off by about 200 km from my land location, in the ocean off of the Pacific Northwest. I think @dos explanation was good. I’ll try using the GPS much more frequently to see if that helps.
1 Like
It doesn’t work.
I’ve noticed that the output of sudo socat unix:///var/run/gnss-share.sock - gets interrupted when issuing the sudo ./agps.py /dev/gnss0 command on the second terminal. Here are the last lines:
$GPVTG,0.0,T,,M,0.0,N,0.0,K,N*02
$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0*1E
$GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0*1E
$GPGSV,2,1,08,30,85,182,,20,65,262,,07,60,056,,05,43,307,*74
$GPGSV,2,2,08,13,26,281,,14,25,157,,11,24,233,,09,23,091,*79
$GLGSV,2,1,08,70,72,039,,80,69,092,,71,36,316,,73,35,185,*63
$GLGSV,2,2,08,79,25,033,,69,19,109,,86,16,279,,87,13,333,*60
$GPGLL,4435.67687,N,01124.13954,E,152213.000,V,N*45
$PSTMCPU,26.25,-1,49*4C
$PSTMGPSSUSPENDED*15
$PSTMGPSSUSPEND
while the second terminal gets stuck on INFO: Checking approximate location... forever
Something’s wrong with your Geoclue then. Get it to work and the script should then continue.
Are there any current plans or efforts to use wifi triangulation in the future? I mean it would not only give more accurate results but also help getting a fix location, right?
Are there any current plans for more features to gnunet messenger? 
A lot actually… ^^
Next plan on my roadmap is to implement more privacy controls. For example revoking invitations to chats. Also client-side filtering of messages and blocking of users. After that I’ll probably work on profile pictures and similar customization features.
Last steps on my current roadmap are exciting if they should work but unclear whether they are feasible. So I don’t want to spoil anything. ^^’
3 Likes
Wow You Are a HERO!
Please, Please 
share your Paypal.
GNU | Purism | thejackimonster
4 Likes
Have you confirmed that this doesn’t happen now? It doesn’t seem as if such functionality would be specific to the Librem 5 (could work on any laptop) so the question might have to go upstream.
FWIW, for privacy reasons, I have disabled geoclue using WiFi at all so, for me, it wouldn’t help to get a more accurate result.
1 Like
Indeed, I have the strong impression that this already does work, I guess based on geoclue indeed.
1 Like
I see, my fault. But it seems not to use accelerometer data yet. I think that would make sense to use though. For example the WiFi gets used about every 5 minutes. But if you know that you have moved by integrating accelerometer output, you could decrease the delay.
5 Likes