when using puremaps on wifi, my locatiion is always the same place, 100 km away. When I switch to mobile, it puts me 35 km away. When I have it follow me, it rarely puts me in the same neighbourhood, then jumps to the magic place 35 km away. I’ve done the whole “sit in a park and wait” bit, but behaviour is consistent. Next steps?
GPS always work, GNSS not much. 
It works, if the data has been downloaded from the satellites. This can take a while, depending upon your reception. There is a purism repository that can speed things up, ‘git clone https://source.puri.sm/snippets/1207.git’.
I did that and ran the agps.py script, then I started Maps and let my phone sit outside for ~15 minutes. Then I was able to get an (highly) accurate fix.
You can do the latter part without the repository (i.e., run Maps and let phone sit), but in my case that always seemed to take too long for my patience.
NOTE: When you lose satellite signal, your location will go back to whatever it relied upon before.
1 Like
One of these mystery locations probably is associated with your internet access provider. Do a check on your IP address. See what real world address comes up.
See this thread for more.
1 Like
The only thing I seem to see from various threads is that NO, gps does not work. Editing your geoclue.conf file is supposed to help, but if I pull mine up in nano, it tells me it can’t be saved.
and then there is this:
Is this likely to need a software/firmware fix alone? Or is the issue in hardware (relatively not fixable)?
… which generally means that you need to use sudo in front of the nano command.
That screen shot needs to be a little wider to be maximally helpful. If geoclue is interested in WiFi then geoclue probably has what in my opinion is a misconfiguration i.e. using WiFi for location services is in my opinion misconfiguration (poor privacy and muddies the waters). So once you get to reconfigure geoclue, those WiFi messages should go away.
GNSS works for me. To be clear … interacting directly with the device works.
If interacting directly with the device gets a correct location fix (it did for me) but using applications that layer on top of that does not work then it sounds like software issues that will eventually get resolved.
the error that got cut was:
failed to open /etc/geoclue/conf.d
there is no conf.d, there is only geoclue.conf
there is no Dana either, there is only Zuul
Then I believe the file that you want to edit is /etc/geoclue/geoclue.conf
In the thread I mentioned above, I desctibe how my gps made the same sort of error as you describe. Imswitched off the wifi as a source for a location in geoclue, which got rid of the mystery spot.
At first my localization was terrible, mainly because it was very, very slow at getting a first fix. This got better over time. I presume because of updates, and maybe also because I trained the GPS by using it outdoors with no overhead obstructions, and giving it lots of time to find its bearings.
Now, outdoors, my GPS is really fast and really accurate (within a meter of my actual position). Indoors it still struggles. But I hardly need my L5 for indoor navigation anyway.
This holiday I was able to use my L5 for navigating on walks through the woods and the countryside in Czechia, and on the road in the car. It never failed me.
So, yes, GPS is supposed to work.
Oh, and when I run the geoclue status command, I do get the cof.d warning, but not the ones about the wifi. Must be because I disabled that, I guess.
There’s no need to edit geoclue.conf or disable any location sources, so please don’t unless you know exactly what you’re doing. Geoclue will use GNSS whenever it’s available and will only fallback to less precise sources if it’s not, so you’re not gaining anything this way.
As expected. Show me a mobile phone that gets a reliable GNSS fix indoors 
1 Like
Every android phone I’ve had for the last 10+ years has had no problems with this (and no I’m not talking about with wifi assistance).
I get accuracy within 10ft (most software reports as within 30ft but the reported location is actually within 10) in my home with the android phone. The Librem5 is bounding around between reporting 1 house over and 1 street over (off by 50-500 ft, most of the time closer to being off by 300-500 ft). The longer I leave the librem 5 alone it will go from having a blue circle indicating the low confidence in the location to being confidently wrong about the location and bouncing around at impossible speeds so it should be able to calculate that the confidence must be unwarranted.
There are only a handful of commercial, steel reinforced concrete, buildings I’ve had issues getting a GNSS fix in over the years with multiple brands of android phones. Most residential and high rise buildings have no issue.
1 Like
So how many satellites are being used for the solution and with what kind of SNR then?
I have tested many different phones during the last few months and while it’s possible to get an unassisted fix by placing the phone near a window for 10 minutes or so, there’s basically no chance to get a fix in the middle of a regular house I’m living in. Some buildings may make it harder than others, but it’s not even supposed to be reliable without external antenna, especially when you have to download almanac from the sky.
1 Like
12-16 satellites, so far with the tools used SNR ranges between 10 and 20 on the android phone I checked just now. If you point me toward a preferred tool I’ll use that one, same for pointing me to how to gather the data on the Librem5 to compare.
And which constellations are that? (it’s impossible to see 16 GPS satellites at once, so you must be using other systems as well)
To make an apples-to-apples comparison on the Librem 5, you’d have to first run the script from Assisted GNSS ($1207) · Snippets · Snippets · GitLab to upload up-to-date almanac and ephemerides to the module and to configure the constellations (we don’t have assistance data for GLONASS available so far; there’s GPS, BeiDou and Galileo; the module doesn’t support GLONASS and BeiDou running at once anyway though), and then watch NMEA GSA and GSV messages via socat.
1 Like
Should be at least GPS + GLONASS since that’s been standard for a while. Not quite sure how to check if others are included.
I mean, yes that would be a closer comparison of the hardware, but respectfully. People compare the combination of hardware and software and having to run a script that is in the source repository is not the same as happens in the background. Is there an ETA on this being background functionality for the Librem5?
I’m sorry, what? I don’t understand this. (I can look it up after going through the script process but if you can elaborate to save time that would be a bonus).
Well, things that are WIP tend to require a bit more attention from the user that those that are already integrated. An alternative would be to get outside, ensure perfect conditions and line-of-sight to the satellites, wait for the module to download all almanac and ephemerides from the sky and only then go inside to perform a test.
Or to compare with another phone that doesn’t use online assistance, but then I can already tell you that the result will be “both of them take very long and perform poorly”
As mentioned in the linked instructions: sudo socat unix:///var/run/gnss-share.sock -
When I ran this the command took a moment to complete and there was no returned data so I’m not sure what I would be watching for if I just get returned to the prompt after?
It should start showing a stream of NMEA data coming from the GNSS module. Is your system up-to-date? Is gnss-share running? Are the killswitches set to a position where GNSS module can be enabled?