Librem 5 GPS/Location Tracking

i just found

The GNSS module is unable to reliably receive broadcasts from satellites, making it difficult to fix the location of the phone. This problem will be addressed in later revisions of the hardware, from Dogwood onwards.

in https://docs.puri.sm/Librem_5/Known_Issues/Chestnut.html - no hint about the exact problem.

I covered the table (70x95cm) with aluminum folio (see photo) and the results are:

display up (after 30 minutes):

fix            None
View sats
S13:20.0 S24:19.0 S15:22.0 S05:10.0 S23:14.0 S10:18.0 S14:17.0 S66:19.0
Solution sats
S13:20.0 S24:19.0 S15:22.0
timestamp      2021-12-11 14:15:28.17
Fix time       1639228528.000
TTFF           0.0


display down:

fix            3D
View sats
S23:26.0 S15:29.0 S13:24.0 S24:27.0 S10:29.0 S14:23.0
Solution sats
S23:26.0 S15:29.0 S13:24.0 S24:27.0 S10:29.0
timestamp      2021-12-11 14:19:54.35
Fix time       1639228794.000
TTFF           145.4

rotating the device to display up again does not loose the fix

3 Likes

Thank you. Are you able to tell how much of a difference the presence of the aluminum foil made, when comparing your current test results with the test results you posted 3 days ago (the L5 face-down test without the foil)? The time-to-first-fix 3 days ago was 68 seconds without the foil but 145.4 seconds with the foil. Can we infer that the foil was actually a hindrance to fixing?

Better compare it with the tests in posting #105 in this tread:

  1. without the folio and display down it gets a fix in less than 10 secs; with display up it does not see any satellite
  2. with the folio and display down it gets a fix after some 145 secs; with display up it sees at least some satellites and almost got a fix;

Any experts here to explain this?

The antenna amplifying effect works (but not much). Actually the distance between antenna and reflector is very critical with Ghz frequencies. A few mm more or less can make a big difference.
Due to the results as reported:

  • GPS module works
  • Antenna not effective (loose or bad connection to GPS module)
  • Antenna (partly) obscured (this gives even less signal, but should not be a problem with a well connected antenna)
2 Likes

Here my test results: My L5 has difficulties finding a GPS fix.
But in this setup it can easily get a fix (at the moment within ~ 15 seconds): The L5 is screen down in a this plastic container, I put this container on the metal baking plate of my oven. The metal plate with the plastic container is on top of a table which also has a stair on it, so that it is relative high on my terrace outside. The weather conditions are: a constant drizzle, so the plastic container and the baking plate from the oven are wet. The sky is completely covered with a light drizzle cloud layer.


When the oven baking plate is not there, I will not get a fix, when the oven plate is there, the L5 will get a fix.

I use these two commands to follow the progress of the fix via ssh, warm and dry from the inside of my house:

NOTE: running multiple socat commands in parallel on the unix-client:/var/run/gnss_share.sock seems to break things, so do NOT do that!

First I do:
sudo socat unix-client:/var/run/gnss_share.sock - | grep -aE --line-buffered '^\$G[P,L]GSV,.*'

This command shows all GPGSV and GLGSV sentences. From these sentences I can see if there are any satellites that have a signal/noise (s/n) value.
This is a typical example of these lines without s/n values (recognizable as the ,, values)

$GPGSV,3,1,11,13,77,298,,14,52,119,,05,49,215,,30,47,068,*71
$GPGSV,3,2,11,15,45,293,,20,25,190,,07,18,065,,18,16,299,*79
$GPGSV,3,3,11,23,10,325,,08,10,029,,24,06,248,,,,,*41
$GLGSV,3,1,09,76,75,065,,66,66,139,,67,56,316,,77,46,208,*6B
$GLGSV,3,2,09,75,20,038,,84,13,005,,83,09,309,,68,06,318,*67
$GLGSV,3,3,09,65,06,139,,,,,,,,,,,,,*52

With the oven baking plate under the plastic container, these lines change into lines that do contain an s/n value, like this:

$GPGSV,3,1,11,13,79,299,27,14,53,116,28,15,48,293,,05,48,213,*76
$GPGSV,3,2,11,30,45,068,28,20,23,189,,07,16,066,,18,15,297,*7C
$GPGSV,3,3,11,23,11,324,,08,09,027,,24,07,249,,,,,*47
$GLGSV,2,1,08,76,73,059,,66,63,141,,67,58,316,,77,49,209,*68
$GLGSV,2,2,08,75,18,039,,84,13,003,,68,08,319,,83,08,307,*6B

When I have lines with s/n values, I stop the command with CTRL-C and run:
sudo socat unix-client:/var/run/gnss_share.sock - | grep -aE --line-buffered '^\$GNGSA,[DANE],[1-3],[0-9]{2}'

This will then result in lines like:

$GNGSA,A,1,14,,,,,,,,,,,,99.0,99.0,99.0*1B
$GNGSA,A,1,14,,,,,,,,,,,,99.0,99.0,99.0*1B
$GNGSA,A,1,14,,,,,,,,,,,,99.0,99.0,99.0*1B
$GNGSA,A,1,14,,,,,,,,,,,,99.0,99.0,99.0*1B
$GNGSA,A,1,14,30,,,,,,,,,,,99.0,99.0,99.0*18
$GNGSA,A,1,14,30,,,,,,,,,,,99.0,99.0,99.0*18
$GNGSA,A,1,14,30,,,,,,,,,,,99.0,99.0,99.0*18
$GNGSA,A,1,14,30,,,,,,,,,,,99.0,99.0,99.0*18
$GNGSA,A,2,13,14,30,,,,,,,,,,4.3,4.1,1.0*2A
$GNGSA,A,2,13,14,30,,,,,,,,,,99.0,99.0,99.0*19
$GNGSA,A,2,13,14,30,,,,,,,,,,99.0,99.0,99.0*19
$GNGSA,A,2,13,14,30,,,,,,,,,,99.0,99.0,99.0*19
$GNGSA,A,2,13,14,30,,,,,,,,,,99.0,99.0,99.0*19
$GNGSA,A,2,13,14,30,,,,,,,,,,99.0,99.0,99.0*19
$GNGSA,A,3,13,14,15,30,,,,,,,,,9.2,5.6,7.4*27

The 3 in the above line indicates a 3D fix.

For details regarding the NMEA sentences, see this page.

Kudos to a close by other L5 owner who helped me with the commands and testing!

2 Likes

Do you get a fix in this assemble with display upside?

No, I explicitly tried that.

Just for a check (it solves nothing). Can you try with L5 upside, but with ~10cm distance from the baking plate as in this image


To verify if you get similar results as @guru

My assumption is that the antenna is not well connected and that the GPS module is receiving just by itself (which tells me that it’s a good quality module). A little bit extra ‘internal antenna’ amplification by a reflective surface on the right distance could than just be enough.

If I received my L5 (still waiting :cry:) I would try to fix the antenna connection (if reachable).

1 Like

@Jan2 Could you clarify what we are to understand from the images?

Is the idea that the solid line from e.g. S1 to L5 via the metal plate can (with luck) be very close to an integral number of wavelengths longer than the dashed line? Then, the signal strength can effectively be doubled for that particular satellite?

In that case, to get the best result, the metal surface (baking plate or whatever) should be as large as possible, and the L5 should be placed at least one wavelength (about 20 centimeters?) above the metal surface?

If the metal surface was infinitely large then it would not matter if the L5 was placed significantly higher, like several wavelengths above it, but given that the metal plate is of limited size it is probably best to place the L5 at about one wavelength above the metal, since moving it higher means satellites closer to the horizon cannot benefit from the metal surface?

A possible improvement could be to put a few (many!) more baking plates around the center one, effectively creating a larger metal surface?

Perhaps also put some of the plates at a slight angle as above, making it possible to get 3x signal strength for some very lucky satellite? :slight_smile:

Will we have to bring the entire contents of our kitchen along with us when we are navigating? lol.

4 Likes

Antenna design for mobile GPS is much more complex than the space available in this forum allows for explanation (and I don’t regard myself as an expert in this field). The antenna used in the GPS module is most probably a Planar Inverted-F antenna (PIFA), although other variations are possible.
What I tried to explain was the effect of a bad antenna connection. The differences between the receiving path, direct - indirect, is exaggerated and partly misleading …
For reflection of the back plane or earth it’s best to assume that both direct and indirect path are passing through the antenna. The next picture explains the amplifying effect of reflector at 1/2 wavelength.
antennaHalfLambda
The dotted line is the reflected wave, arriving at the antenna in the same phase as the direct signal. As such the reflector improves the GPS signal, hopefully just enough to increase signal/noise ratio above the threshold level.

To answer your question: the reflector is best placed on an integral number of half wavelengths.
The use of many baking plates leads ultimo to a parabolic reflector. It’s best to put the L5 in the focus-point :laughing:

1 Like

What I understand from this and other explanations in this tread and from own experiments, it seems to me that in the L5 something around the GNSS chip/antenna/earthing is bad or let’s say not optimal constructed, i.e. it is a hardware issue. While any software issue can relatively easy be fixed by installing an updated version, how Purism could address such a hardware issue?

And, why they didn’t detected this before in own tests, or in the versions before Evergreen?

I tested this. The L5 can get a fix in this configuration. But also when the with the screen down 10 cm above the baking plate.

It is quite difficult to exactly determine how all factors influence each other, but I think that the following statements are true:

  • Screen down works better than screen up;
  • With metal oven baking plate is better than without it;
  • 10 cm above metal oven baking plate is better than directly on top of it.

It seems that the best results are obtained by having the L5 screen down, 10 cm above the metal over baking place (and outside, obviously).

When I have the seemingly optimal configuration inside at the top level of my house, some satellites do show a s/n value, but I did not get a 3D fix.

Also note: when the L5 has a 3D fix, which I monitor with this line:

sudo socat unix-client:/var/run/gnss_share.sock - | grep -aE --line-buffered '^\$GNGSA,[DANE],[1-3],[0-9]{2}'

It looks like it can hold the fix when putting the L5 in less optimal positions. When I then stop the command with CTRL-C, but keep the phone in the less optimal position, the L5 cannot establish a 3D fix again. So, I think that somehow the L5 can sometimes maintain a 3D fix in a location where it cannot freshly establish a 3D fix.

Are there any L5 owners that can always easily get and maintain a 3D fix when outside, without applying special configurations?

4 Likes

Mine seems to get decent SNR values quickly and easily - and gets a fix.

I don’t know whether it’s a 3D fix. Would have to study the message spec.

I’m not using any special software. Just grep -a xxx /dev/gnss0

1 Like

As I mentioned before, antenna problems are per definition very complex. Taken into account that GPS signals are relatively weak, variations in mm of antenna placing can already have big effects. Especial the connection between antenna and module is critical. Even if the connection is soldered, the connection may deteriorate due to e.g. vibration during transport. Example: a hairline crack in the connection induces a wave-reflection point, resulting in a severe reduction of signal. If this, for the naked eye invisible, crack is on the right place then the result is a better reception… (see: Standing wave theory)

You can find a more in dept evaluation of mobile GPS antenna problems here: https://www.nxp.com/docs/en/brochure/75016740.pdf

If the percentage of bad GPS receiving L5’s is high, I strongly advice a re-engineering of the GPS antenna construction. A robust design is needed for large quantity production.

Purism confirms antenna possible problems on some pieces. It has been already mentioned in this thread and there is somewhere suggestion how to try fix ground connection between metal frame and board. I have not found time and courage to disassemble my Librem 5 and try to fix that. But I try that when I have less duties at the university and company

There is fix heading to mainline which can probably lower some interference between SDIO and GNSS receiver. I am not sure/not checked yet, if it is already included in stable kernel 5.13.0-1-librem5. If you have while, you can check if switching WiFi off enhances SNR

arm64: dts: imx8mq-librem5: Limit the max sdio frequency
This is needed for the 1LV Cyress WiFi module to probe correctly.
It also helps improve GNSS sensitivity.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=09d255f0beb5370440e75a6bf7872f56b26ab4c9

By the way, I have tested GPXsee for Garmin offline image maps. It could be usable. I have enhanced GPXsee to support zoom by pinch on the touchscreen

See branch zoom-by-pinch in my fork

and pull request

If there interest, I pud my Librem 5 build somewhere or even prepare deb package…

3 Likes

I tried to switch Wifi/BT off as the FAQ suggests in https://source.puri.sm/Librem5/community-wiki/-/wikis/Frequently%20Asked%20Questions#4-privacy-and-security
with

#Disable WiFi/Bluetooth
echo 0 | sudo tee /sys/class/leds/wifi_en/brightness

because you can not switch off all three HKS (which would shutdown the GNSS too). But the file /sys/class/leds/wifi_en/brightness does not exist in my OS Byzantium. Any idea?

But if you switch off mobile and WiFi off then interference from the sensors should be minimal. Cameras should be stopped (power down) as well when not used. So I think that test and comparison with modem and wifi on and off by switches should be enough.

Regarding GPXsee update with zoom by pinch gesture support on Librem 5 see