Garbage NMEA output from GPS
#11
(06-25-2020, 11:55 AM)Dmytro Wrote:
(06-24-2020, 07:06 PM)wibble Wrote: ttyUSB1 is correct for nmea output, and ttyUSB2 for enabling gps with AT+QGPS=1 and any configuration you care to do. I haven't tried gpsd on mobian, but I think it worked in PmOS. You can check it with picocom or similar.
I was able to propagate nmea data to application layer. Smile
But, receiver is so weak that it get fix only on wide empty space. It seems even clouds are not welcome.  Huh
And it takes time regardless assisted or not. I'll experiment tomorrow trying to refix on the same position.
I'm afraid it may be antenna issue or even worth. Sad
Anyone has different experience?
My experience is that a hot start (had a fix, lost with a few minutes indoors, gps still enabled, then back outdoors) gets a fix in <2 minutes while a warm start (same but a few hours indoors) may as well be a cold one. However the hot start probably has sats in an advantageous position while the 'warm' one may not. In comparison with the Garmin Geko 201 (2003 vintage cheap handheld gps) the cold start had similar difficulties due to sky view, but since then everything's effectively a warm start as it retains data from the last fix when powered down, and it generally gets a fix in <2 minutes while sitting next to the PinePhone that may not get one after 10 minutes. I haven't tried feeding it assistance data yet, and I haven't tried the old OpenMoko for comparison.

This situation feels very familiar - the OpenMoko GTA02 had very similar symptoms to begin with, and it was fixed with a driver change for a different part of the hardware entirely. It may give some hope, and some pointers on what to look for to fix it. The full story is probably still in the list archive somewhere, but here's the essence of it...

Short version: interference from SD clock and data lines made first fix slow to impossible without very good sat signal. Driver update to use reduced drive strength setting fixed it. Getting the assistance data upload working improved it further.

So...who would have the in-depth knowledge of the hardware to know which parts might be capable of being dialed back to reduce interference? I found these, but haven't investigated how they work:
    /sys/firmware/devicetree/base/soc/pinctrl@1c20800/rmii-pins/drive-strength
    /sys/firmware/devicetree/base/soc/pinctrl@1c20800/mmc2-pins/drive-strength
    /sys/firmware/devicetree/base/soc/pinctrl@1c20800/mmc1-pins/drive-strength
    /sys/firmware/devicetree/base/soc/pinctrl@1c20800/rgmii-pins/drive-strength
    /sys/firmware/devicetree/base/soc/pinctrl@1c20800/mmc0-pins/drive-strength
    /sys/firmware/devicetree/base/soc/pinctrl@1c20800/mmc2-ds-pin/drive-strength

Longer version if you want more details: When trying to get GPS going some were reporting that getting a fix was difficult or impossible, while others were seeing similar performance to other GPS devices. Working out whether this was down to environment (sky view etc.), expectations or luck (where the sats were) was tricky - cue scripts that would force a cold or warm start and collect stats on how long it took to get a fix etc. Finally someone spotted an appartently unrelated correlation - the people having most difficulty were using SD cards. Hypothesis - interference from the SD clock/data lines was causing problems for the GPS. Someone put capacitors across the lines at the SD socket and found first fix performance much improved - there was a fix but it needed a hardware mod. The developer of the SOC kernel drivers then realised that the hardware had configurable drive strength for that interface, but it had been hard-coded in the driver to use the maximum. A quick patch exposed it as a setting that could be changed in case specific SD cards needed the stronger setting - in the end I don't remember any needing this. A mod to the testing scripts let it cycle through drive strengths so the first fix time was compared with similar sat positions, and showed a clear link between SD drive strength and first fix time. The driver was then defaulted to minimum drive strength and everyone was happy(ish). You may or may not be amazed at how hard it was to convince some people that the driver change was a proper fix not a workaround, and that getting the soldering iron out wasn't just unnecessary but inferior.


Messages In This Thread
Garbage NMEA output from GPS - by Subsentient - 06-20-2020, 06:49 AM
RE: Garbage NMEA output from GPS - by wibble - 06-21-2020, 05:57 AM
RE: Garbage NMEA output from GPS - by wibble - 06-21-2020, 07:19 AM
RE: Garbage NMEA output from GPS - by Dmytro - 06-21-2020, 03:20 PM
RE: Garbage NMEA output from GPS - by wibble - 06-21-2020, 12:27 PM
RE: Garbage NMEA output from GPS - by wibble - 06-22-2020, 05:26 AM
RE: Garbage NMEA output from GPS - by Dmytro - 06-24-2020, 03:11 PM
RE: Garbage NMEA output from GPS - by wibble - 06-24-2020, 07:06 PM
RE: Garbage NMEA output from GPS - by Dmytro - 06-25-2020, 11:55 AM
RE: Garbage NMEA output from GPS - by wibble - 06-26-2020, 06:49 AM
RE: Garbage NMEA output from GPS - by Subsentient - 06-25-2020, 09:06 PM
RE: Garbage NMEA output from GPS - by Dmytro - 06-26-2020, 02:21 PM
RE: Garbage NMEA output from GPS - by wibble - 06-27-2020, 07:55 AM
RE: Garbage NMEA output from GPS - by Dmytro - 06-27-2020, 11:06 AM
RE: Garbage NMEA output from GPS - by wibble - 06-27-2020, 03:55 PM
RE: Garbage NMEA output from GPS - by wibble - 07-10-2020, 05:25 AM
RE: Garbage NMEA output from GPS - by wibble - 07-10-2020, 07:33 AM
RE: Garbage NMEA output from GPS - by wibble - 07-15-2020, 01:00 PM

Possibly Related Threads…
Thread Author Replies Views Last Post
  PinePhone Beta dead - no boot-related output on serial interface horalocal 1 1,359 02-15-2023, 11:21 AM
Last Post: fxc
  New PinePhone PostmarketOS CE -- No second display output audidiablo 3 4,438 09-22-2020, 05:11 AM
Last Post: Arehandoro

Forum Jump:


Users browsing this thread: 3 Guest(s)