Librem 5 GPS/Location Tracking

There’s an almanac and ephemeris. They descrbe the current satellite locations, they are valid for relatively short periods of time, and if not received otherwise, they are received from the satellites.

I can’t say anything about your problem, but my work unit doesn’t do GPS very well either.

Hmm ok,
This does make me wonder… Do we know if this is a hardware or software issue that makes it not work so well? I’m wondering if the librem 5 is capable of reliable navigation.

I know there’s a gps tuning section of the fund your app page. Does the gps just need more tuning to be reliable?

Is this was a real measurement (I doubt), then the signal is not usable (as in random noise). In real live you seldom find 0.0 for S/N, even when no signal available. Most probably a software error. (if unconnected antenna no satellite would be detected)

1 Like

Thanks, the required python package is python3-nmea2.

cgps starts fine now, but is this the expected output before a fix or at least some info like “Time” should be fileld in?

┌───────────────────────────────────────────┐┌──────────────────Seen  0/Used  0┐
│ Time:          n/a (0)                    ││GNSS   PRN  Elev   Azim   SNR Use│
│ Latitude:        n/a                      ││                                 │
│ Longitude:       n/a                      ││                                 │
│ Alt (HAE, MSL):        n/a,       n/a     ││                                 │
│ Speed:           n/a                      ││                                 │
│ Track (true, var):                n/a deg ││                                 │
│ Climb:           n/a                      ││                                 │
│ Status:         NO FIX (1914 secs)        ││                                 │
│ Long Err  (XDOP, EPX):  n/a ,  n/a        ││                                 │
│ Lat Err   (YDOP, EPY):  n/a ,  n/a        ││                                 │
│ Alt Err   (VDOP, EPV):  n/a ,  n/a        ││                                 │
│ 2D Err    (HDOP, CEP):  n/a ,  n/a        ││                                 │
│ 3D Err    (PDOP, SEP):  n/a ,  n/a        ││                                 │
│ Time Err  (TDOP):       n/a               ││                                 │
│ Geo Err   (GDOP):       n/a               ││                                 │
│ ECEF X, VX:              n/a    n/a       ││                                 │
│ ECEF Y, VY:              n/a    n/a       ││                                 │
│ ECEF Z, VZ:              n/a    n/a       ││                                 │
│ Speed Err (EPS):        n/a               ││                                 │
│ Track Err (EPD):        n/a               ││                                 │
│ Time offset:            n/a               ││                                 │
│ Grid Square:            n/a               ││                                 │
└───────────────────────────────────────────┘└─────────────────────────────────┘
{"class":"TPV","device":"/dev/gnss0","mode":1}
{"class":"TPV","device":"/dev/gnss0","mode":1}
{"class":"TPV","device":"/dev/gnss0","mode":1}
{"class":"TPV","device":"/dev/gnss0","mode":1}

Someone reported GPS positioning kind of working in February, via sudo cat /dev/gnss0:

When I just tried sudo cat /dev/gnss0 myself (on a Librem 5 Evergreen running byzantium), it does give NMEA-style output (including GPRMC and GPGGA NMEA sentences) which looks promising. I have not tried the gpsbabel conversion yet.

Edit: after looking more carefully at the NMEA output, maybe it is not that promising, it says there is no fix and the time that is supposed to be UTC time looks way off.

To get a fix with a GNSS receiver you need to have a good antenna connection and the GNSS module must have downloaded an almanac and the ephemerides for the satellites it is tracking. To speed up the process you can upload the almanac and ephmerides to the module , this is know as AGPS.

gnss_share can handle the AGPS portion and it also will share data with geoclue which is used by most L5 navigation software for geolocation.

You can copy the almanac and ephemeris from a phone that has a 3D fix to one that doesn’t and then have gnss_share upload it to the GNSS module.

If you don’t use AGPS the almanac and ephemeris will automatically get downloaded from the satellites. This takes at least 12 minutes and must have a clear view of the sky, preferably a window sill or outside. Once the initial navigation messages ( almanac and ephemeris https://en.wikipedia.org/wiki/GPS_signals#Navigation_message ) is downloaded it gets saved to battery backed RAM. If you are using gnss_share it will also get saved to the filesystem.

The second part of this is how well the antenna is receiving the satellites. As others have stated you can directly dump the output of the GNSS module using cat /dev/gnss0. You need to find the GSV sentences as these show the number and strength of the satellites being received ( section 11.4.4 https://www.st.com/resource/en/user_manual/dm00398983-teseoliv3-gnss-module--software-manual-stmicroelectronics.pdf ).

Initially you need to see a single satellite with a SNR of > 20 for the navigation messages to be downloaded and it must be active for more than 12 minutes. You’ll slowly see more and more satellites in the GSV messages. Once the module starts tracking satellites you will see a GSA message with satellites in it and that shows the current satellites being used for your location solution. After that you should see a GGA message that indicates a fix.

If you never see a GSV message with a SNR above 20 or a GSA message tracking satellites then it could either be a hardware problem or not enough of a view of the sky problem. The view of the sky problem can be cause by tall trees , tall buildings, metal or concrete roofs and the eaiest way is to take the L5 out into a field or some area with a full view of the sky.

If all the above fails then it may be a hardware problem. A common issue is the ground on the GNSS antenna https://puri.sm/wp-content/uploads/2021/03/22_v2.png. This part is both delicate and also must be touching the frame of the phone. On visual inspection if it is not touching the frame it can be GENTLY bent to touch it, see the dis-assembly instructions here https://puri.sm/posts/disassemble-librem-5/

11 Likes

How do I know whether I should be expecting Rev 3.1 messages or Rev 4.10 messages?

Either way though

I think I need to spend some time out in a field because I don’t seem to be getting any satellite signals sitting inside.

See how the Signal to Noise ratio is zero for all satellites listed? I believe that means that although the ephemeris says those satellites are in view, the signal is absent or NFG.

1 Like

That would explain why when I was testing this the number of satellites “in view” according to GPGSV sentences did not change when I moved the phone from the window to somewhere far away from the window. I was expecting to see fewer satellites in view, but there was no change. Probably I had never any satellite at all truly in view, the info shown was just what should be in view in theory based on the saved position and time info which are very far off.

Looks like it thinks I am in China, then I get to know which satellites would be in view it I was in China (and if the time was correct which it is not). :slight_smile:

I’ll try taking it into a field.

1 Like

Watching it for awhile it does sometimes get 2 satellites that it will say yes and have a SNR of 20-27 for me. Going to try taking it into a field. Sadly my hikes don’t seem to give it what it needs being outside.

edit: even with those two it doesn’t get a fix. I think it needs 3.

It needs six, no, seven points
No, four on earth (1,2,3 etc.)

Now I got GPS working! Seems like it needed to be outdoors, putting it in a window was not enough to get a fix. I used sudo cat /dev/gnss0 while walking around the house and put the result of that in a file tmp.nmea, then convert the nmea to gpx format like this:

gpsbabel -i nmea -f tmp.nmea -o gpx -F tmp.gpx

then it works to show the resulting track in GNOME Maps like this:

gnome-maps tmp.gpx

Then GNOME Maps opens and shows it, it even centers on it and zooms in:

18 Likes

This is so unixy :heart:

Spent some time out in a field and I have now managed to get a valid latitude and longitude out of /dev/gnss0 and it agrees well enough with an iPhone at the same location.

5 Likes

I got GPS location working in Pure Maps (on the L5)!
I had to

  1. Have clear sky
  2. wait ~10 minutes for the first fix (but then the fix is acquired fast, even after a reboot)
  3. Build gps-share and run it (quite simple, build it with cargo build. I just had to sudo apt install libudev*)
  4. fix .local domain name resolution
    4b. try where-am-i and verify it works
  5. to debug problems, check status of geoclue service
  6. run pure maps :slight_smile:

Updates are a bit laggish but navigation is finally usable!

11 Likes

This is probably because of the almanac and ephemeris getting downloaded the first time and then being saved, as Angus wrote about above.

Could you explain what that means?

Is “where-am-i” some command-line tool, or a function inside the Pure Maps app?

1 Like

It’s a command line tool in the geoclue-2-demo package which lives under /usr/libexec/geoclue-2.0/demos/where-am-i. It just prints out the location from geoclue. Since it connects to geoclue, if there are problems in getting the position, systemctl status geoclue prints out errors in the setup, if any.

When I started gps-share the first time, it found the gps device and said

Attempting to autodetect GPS device...
Attempting to autodetect GNSS device...
Detected /dev/gnss0 as a GPS device
TCP server bound on all interfaces
Port: 10110
group: /Client4/EntryGroup1

I also started cgps, which had 3D FIX, but where-am-i reported the location with 20000m accuracy (so it was definitely not using gps). systemctl status geoclue showed an error in domain name resolution of pureos.local. I just added pureos.local to the 127.0.0.1 line in the hosts file (I really needed gps because I was lost, that’s the most quick fix I found).

(gps-share cpu usage is 0 when nothing is connected to it, and jumps to 12-15% when there’s a client. Also, I’m running it with --network-interface lo to prevent other devices from accessing its location remotely)

5 Likes

cgps uses gpsd which will likely break gps-share or gnss-share.

Only one of gpsd or g*-share should be given access to the /dev/gnss0 device at a time.

If you want to spoof gpsd on a system using gnss-share use something like this

#!/bin/bash

PORT=2947
SOCK=/var/run/gnss_share.sock

socat -d -d -d -lf /tmp/socat.log TCP-LISTEN:${PORT},reuseaddr,fork UNIX-CLIENT:${SOCK} &
2 Likes

My experience with librem 5 in italy. Using, with Librem 5, gnome maps or in the browser with openstreetmap, my position is reported further south of about 140 m. On the other hand, with a phone with android the position is exact with a maximum error of 5 m.

1 Like

I’m in italy too, and it works ok, sometimes with reported error less than 5m. Did you try xgps?

1 Like