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.
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
a company doing such an excelent marketing should at least be able to design a hardware that can do gnss. otherwise i suspect they do bigger efforts in sales than in producing their products. while that is normal in todays usual companies i wouldnt expect that from an open source company
1 Like
I regard this an unfair statement. Even with thorough design and testing of prototypes you still can be unlucky in exception cases. Still remember the “dead grip” of some Iphones. In production batches this type of incidental cases reveals itself in bigger samples. It can than be solved for next generations and manual repair in individual cases.
9 Likes
which is apple which for sure has the marketing problem i describe: much more effort is put into convincing people than developing the product. apple produced alot of failures that easily could have been avoided by putting more efforts in.
Are you willing to share the content of the mails you got back from Purism? This will help me to determine if I have to contact them as well or not. I prefer to keep the load of the Purism support as low as possible, so maybe if you share their replies, it will not be necessary for me to contact them.
1 Like
i can tell the flow but can’t paste the text without senders permission. 11/25 i told them about the problem, 11/27 they answered which kind of debugging i did (while i pointed them to this thread where this question was already answered), 11/27 i answered what i did, 11/29 they asked for my script i used, 11/30 i answered i used cat /dev/gnss0 | awk '/G.GSV/{print $0}', 11/30 they told its forwarded to the dev and asked for the order number (which should be clear from my email adress already), 11/30 i send the number, 12/1 i asked what the devs say, 12/1 they asked me for patience, 12/13 they came up with a test flow that i already did (written here in the thread), 12/14 i told them so, 12/23 i asked for any updates, 12/25 they told ‘not yet’.
1 Like
where? can you give a link?
What exaclty is the fix?
I have consulted Librem 5 design with Marek Peca, long term expert for satellite two way time synchronization and microelectronic and optronics systems designs and reserach. His modulators and receivers are used in space and CZ company Eltvor.cz/ works on new modems delivery to ESA now. Time modems use similar but more advanced TDM and correlation techniques as GNSS. He works at ESA on next satellites etc.
We have analyzed Librem 5 Evergreen schematics diagram. It is shame that components placement is not provided. But we moved forward a little anyway. There seems to be multiple alternatives how to assemble the board. Actual design and assembly clamps U20 BGA725L6 Low Noise GNSS Amplifier (LNA) input to the screw TS3 SC-M1.4. The resistor R256 and inductor L3 are shortcut. Rest of adaptation/resonator is not assembled. Location of the ANT3 ECT818000500 connector is not clean, visible or is under LNA shielding. I have not disassembled my Librem 5 yet, I wait for Purism confirmation about warranty in such case. It seems that signal is sourced from the TS3 screw which is connected to some antenna on the other board side. May be on heat spreader or somewhere??? Has somebody a photo?
Colleague considers problematic about 20 mm narrow path against the board (probably FR4 prepreg) to LNA which can cause significant signal loses. He considers as strange relatively high distance between antenna input (screw) and grounding point marked in Purism’s note. He suggest to add another connection between frame and PCB ground near to the screw path. The design of the line through screw is suspicious to me, how is controlled line impedance computed through that point? It can be source of many reflections probably.
He suggest to bring signal by coax to the LNA input. He thinks that he have some antennas to test that. I can imagine that building Librem 5 remix with external connector and bigger GNSS antenna can result in high quality positioning device. External antenna can be outside of car or boat then. Simple quarter-wave antenna for 1575.42 MHz (wavelength 0.19 m) should be around 48 mm. In the case of need and probably some funding, I can ask people who develop systems for antenna design simulations at our university or may it be some would provide input on base of their enthusiasm. In the fact Marek experiments with antennas design for satellites now.
The Librem 5 photo and components analysis by Marek Peca
BlackBerry back cover GNSS antenna
Generally I understand that design in the constrained space is demanding, but there the seems to be some problem. I have never seen S/N above 27% of full scale on my Librem 5. Mostly around 10% which is miracle that STM TESEO-LIV3F even gets fix/lock sometimes. So all available design data should be provided to help with analysis and looking for solutions.
15 Likes
Most of your post is over my head (which is fine, I don’t pretend to design any electronics for a living, let alone specifically GNSS units) but maybe you should bring it to the attention of Purism or even get Purism directly in touch with your associate.
This is a fairly confusing way of quoting signal strength if you are actually just quoting the number that comes out of the GSV message.
OK, I really do not know what is expected GSV range and my adding percentage character is misleading. The Quote from the Teseo-LIV3 GNSS Module - Software manual:
SatxCN0 Decimal, 2 digits, from 00 till 99 Carrier to Noise Ratio for satellite x in dB,
So the maximal value which can be shown (full scale) is 99. Yes it is quite possible that such value cannot be reached and or can even mean signal level which can over-saturate receiver. But the Teseo-LIV3 manual specifies that it starts to compute position and attempt to reach position fix only when it is in sync with four satellites with S/N ratio above 20, i.e. 20 dB. Use of percentage is my mistake, but I was not looking into manual at that moment and considered 20 as percentage of whole scale to 99. Yes it is logarithmic…
Important is what are usual values S/N obtained on different Librem 5 pieces and what is expected range from Teseo-LIV3 designers. And I consider my typical read values about 20 or even less even for strongest satellites outdoor as really out of nominal expected range of the GNSS module designer.
I wait for response from Purism support and I have pointed them to this discussion. In the fact I did not plan to respond there until receive a reply. But Marek has gone through analysis further and attempted to locate components etc. so I have decided to pass his observations into public knowledge pool.
6 Likes
OK, thanks for the clarification. So my peak reading of 37 is actually, as it happens, ten times better signal than your reading of 27.
Yes, it is.
Or in the fact 10 dBHz difference is 10 times higher power of the signal which means that actual measured Voltage is about 3 times higher (sqrt 10).
Can you confirm that you observe reasonable performance?
I have gone through manual again, may it be I have remembered threshold 20 from some discussion. I have found that manual states
GNSS positioning CN0 (signal to noise ratio) Threshold from 9 till 40 default 15 dB
But may it be, I have spotted somewhere else that four satellites at more than 20 are required to start algorithm…
There are more commands which can tune parameters $PSTMSETTHTRK (minimal angle and CN0 for tracking), $PSTMSETTHPOS (minimal angle and CN0 for positioning), $PSTMCFGGNSS (complete configuration), $PSTMCFGTHGNSS combined set of the thresholds only.
So it is chance that by tuning these values we can reach fix earlier. But on the other hand position fluctuation was about 20 to 50 meters when I have reached the fix (after paying and long time during walk around and on the top of the hill there) and recorded and processed NMEA message later. So I think that S/N ratio is under level for solid position computation on my Librem 5 piece so lowering the thresholds does not help too much.
I have not found some Teseo-LIV3 specific values but random papers speaks about 40 to 50 dB max for the satellite in zenith. Marek reports list with maximum at 42 from Xiaomi Mi8 phone under the roof of his home. But he expect that roof is light, so it would not be much better outdoor and he report that this phone has extraordinary good GPS block.
So it is question what is the expected range and performance on Librem 5 and what can be tuned etc… But at least, it is necessary to get some clue what is typical what can be easily solved etc…
1 Like
Marek send more clarification, I try to translate his description of the noise.
We can consider for 20 dBHz carrier to noise ratio that for signal sampling at 2*100Hz of the correlation process output there is not any correlation peak observable above the noise (signal to noise ratio is 100 times lower at 100 Hz so noise level is same as signal). For GPS where 10 Hz sampling and output is usually/probably expected, the value of 20 dBHz means that there is already detectable correlation peak but it is weak and does not allow good fix. So his interpretation of the theory matches observation and default Teseo-LIV3 threshold 15 dBHz for satellite masking out.
3 Likes
GNSS isn’t a major priority for me, so I have done only limited testing, but the few times I have rushed outside running a grep on /dev/gnss0 I have got reasonable results (a sample of SNR values is given above) and I have got a (correct) location fix fairly quickly.
I have no idea what factors other than the phone itself determine success (assuming that the phone is outside and with an uninterrupted skyview) e.g. latitude, altitude, weather conditions, space weather conditions??
(One of the main reasons why I want GNSS is so that my photos get geotagged correctly - and that needs a fair bit more work on the camera software to be able to get decent photos at all i.e. the geotagging will be the cherry on top.)