Garbage NMEA output from GPS

[wibble]

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.
But, receiver is so weak that it get fix only on wide empty space. It seems even clouds are not welcome. 
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.
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.

[Dmytro]

At least I can try to boot from mmc
Another strange observation if I come close to a building on north or east side (<5m) fix is lost. South and west do not matter that much.

[wibble]

At least I can try to boot from mmc
Another strange observation if I come close to a building on north or east side (<5m) fix is lost. South and west do not matter that much.

If that's consistent (over hours/days not just minutes) that would be very strange. More likely it's just where the sats were in the sky at the time.

[Dmytro]

Without SD it doesn't perform any better
May be another distro will do better?
@wibble controls you've mentioned are ro and I didn't find any useful information in them.
Another strange thing is others are not interested or this thread is invisible?

[wibble]

I can't say I'm surprised - I was having trouble without SD, but it's good to have confirmation. SD was just an example of a digital interface that could cause interference, and might be configurable to reduce it. As it happens it looks like they are among the identified interfaces (is wifi/bluetooth on one of them?) It could be they're only configurable via devicetree. There may be other interfaces that have configurable drive strength at the hardware level, but don't expose it in the driver. This is why we need someone with hardware knowledge. If we're unlucky it's an inadequate antenna, poor signal routing, or something noisy that we can't adjust (or slug with caps)

Who knows...most people's eyes would glaze over if I mentioned NMEA ;-)

[wibble]

Preliminary result with AGPS seems promising - I have a fix most of the time with the phone indoors in a location I've not seen a fix in before. This is a sample of 1 though so it's possible I've just been extremely lucky. It's been experiments with the python3 cli so far, just to see if it would work. It'll need integrating into ModemManager or similar if it's going to be practical, and turning AGPS on/off requires a modem restart.

[wibble]

It looks like I was at least somewhat lucky the first few times - retrying a couple of hours later I'm not getting a fix indoors. More testing needed, but that'll have to wait for another time.

[wibble]

After more testing it seems quicker and more reliable at getting a fix with AGPS than without it. Proof of concept python script here:
https://gist.github.com/alastair-dm/2632...e555fa6628

Prerequisites in the comment after the script. I haven't bothered with the nicities like checking the responses as it's just proof of concept. A proper implementation needs including in ModemManager or similar.