LoPy4 w/ PyTrack: GPS does not show up!

[jlandercy]

Hi pycom-munity,

I started my first PoC with LoPy4 and PyTrack this morning.
I wrote a bunch of code, tested it, and it seems to work except for the GPS coordinates which are almost always (None, None). This is a bit frustrating as when you ship a PyTrack you expect to get some geo-localisation.

My code relies on pycom-libraries, required files are located in lib:

• L76GNSS.py
• LIS2HH12.py
• pytrack.py
• pycoproc.py

A MCVE would be:

import utime

from pytrack import Pytrack
from L76GNSS import L76GNSS
from LIS2HH12 import LIS2HH12

py = Pytrack()
acc = LIS2HH12(py)
gps = L76GNSS(py, timeout=60)

start = utime.ticks_ms()
while (True):
    now = utime.ticks_ms()
    if (now-start) >= 10000:
        c = gps.coordinates()
        print(c)
        start = utime.ticks_ms()

Current and original version is :
Pycom MicroPython 1.20.0.rc2 [v1.9.4-ecfa670] on 2018-12-17; LoPy4 with ESP32

I tried to upgrade to higher version, but it makes the assembly LoPy4/PyTrack not working (could not reach the terminal). I downgraded to legacy 1.20.0.rc2, then I could make it work again.

What puzzles me is that some assembly succeed to get the GPS but other simply don't, never (I have 20 of it). The problem is a bit random. Some assembly that do get coordinates may not succeed as well after a simple reset.

What could be done to fix this issue and makes the application reliable? Thank you for your help.

[jlandercy]

@jcaron Thank you for answering. My question is not about WPS which is also a very interesting topic anyway or smartphones applications.

My question is about GPS and L76 chipset as implemented on the PyTrack. Indeed WPS helps GPS to get quicker resolution.

I do agree with you the PyTrack library is very crude, thank you for the last link, this one is helpful.

[crumble]

@mnovella said in LoPy4 w/ PyTrack: GPS does not show up!:

Perhaps something to do with the GPS the Pytrack has (seems to be a Quectel L76-L), or the internal antenna of such?

PyTrack use an external Antenna. The small white bar on the pyTrack. Other L7n-m have bigger antennas soldered on top of the housing.

[jcaron]

@jlandercy Good summary, I'd just like to clarify this point:

This is why modern smartphones can get it quicker because they download the Almanac over the internet and can directly use the Ephemerides to localize. Additionally they can use NTP to assess time and other RF gateways to estimates position within the required tolerances. This why they get quick positioning with GPS.

When you need your position on your smartphone, in many (most) cases it does not even use GPS at all, it makes a list of neighbouring Wi-Fi networks, sends that to a server, and the server returns a position. Coupled with similar things for cell towers (much less precise), PDR (pedestrian dead reckoning), this allows the phone to maintain a relatively accurate position at all times without even switching the GPS chip on (so when you open Maps it actually already knows your location in the background).

The GPS chip in phones is usually only turned on when a running app requires a level of precision that is beyond what the other sources can provide (e.g. you want really precise position for navigation, or you're out in the middle of nowhere and you just have cell tower signals to give an estimate of the location -- in that last case you will usually see at first a very large light blue circle giving your estimated position, and then only after the GPS has acquired a position will it be able to give a more precise position).

The whole topic has been covered a number of times in this forum, including here recently.

Also, the pycom-provided GPS library is very basic. There are alternatives which could give better results in some situations. See here for a couple of examples.

[jlandercy]

@mnovella Thank for adding details. Yes I tried another PyTrack/LoPy4 boards and combo. The first one is still not acquiring while the two others got a fix and are acquiring. There might have an issue with one board. I will investigate it deeper. I have the feeling that we can get more from the PyTrack board if we update the library. But yes we are limited by the design and the antenna.

To be continued...

Additional informations

Yesterday I also read a bit about how GPS works under the hood and why does it delays in various situations. I leave here some additional informations to whom could be interested on it.

GPS requires Almanac and Ephemerides in order to localize:

• the almanac consists of coarse orbit and status information for each satellite (SV) in the constellation (valid from two weeks to few months depending on the required precision);
• the ephemerides consists of accurate orbit and status information of specific Space Vehicle (refreshed every two hours, valid from 30 minutes to 4 hours).

Those data are emitted by SV and must be accumulated. This is why when the receiver is:

• shutdown since a while (cold start, outdated almanac);
• moved across a long distance (greater than 1000 miles, mislocated almanac);

The GPS delays before getting a position because it needs to rebuild the Almanac and Sky Search for the constellation. We can help them be setting a rough estimate of the time (<20s) and position (within 100 miles) to switch from the Cold Start to the Warm Start status.

This is why modern smartphones can get it quicker because they download the Almanac over the internet and can directly use the Ephemerides to localize. Additionally they can use NTP to assess time and other RF gateways to estimates position within the required tolerances. This why they get quick positioning with GPS.

Further more, good localizations with GPS requires:

• to accurately measure time in order to properly resolve the trilateration problem;
• to mitigate the multiple path effect (canyon, tall buildings);
• to have a clear sky with few atmospheric interferences (weather).

The first is by design the latter are context dependent and we have few grip on it.

Useful references

• https://en.wikipedia.org/wiki/GPS_signals
• https://en.wikipedia.org/wiki/Time_to_first_fix
• https://gisgeography.com/trilateration-triangulation-gps/
• https://gisgeography.com/gps-accuracy-hdop-pdop-gdop-multipath/
• https://www.gpsworld.com/the-almanac/
• https://www.gpsinformation.org/dale/nmea.htm

[mnovella]

@mnovella Thank you for answering and sharing your experience. So you managed to improve performance by going under the hood of the GPS process and implementing your own logic. Am I getting it right?

Basically, but not using Pytrack.

Initially I pretended to use the Pytrack as the GPS module of the project I'm making. However, after struggling with these inconsistencies for several days I decided to not use Pytrack at all.

What I did was acquire another, external GPS (sorry, can't disclose the model, but there are several options to chose from), which I connected to the LoPy4 via UART. Then, I simply "read" the data transmitted by that GPS, after which I parse and find the NMEA sentences that contain the coordinates to obtain a location (when it gets a fix).

Don't know why but that other GPS worked way better than the GPS the Pytrack has. Perhaps something to do with the GPS the Pytrack has (seems to be a Quectel L76-L), or the internal antenna of such?

May I ask what were the most important milestones to overcome this issue?

Some pointers of what I did before giving up were: trying the Pytrack with different LoPy4's, going to the roof of my office, comparing time to get fix during the day versus the night (in case some Constellations were not present at my "3rd world" location :).

I eventually managed to get a fix, and get the Pytrack to give coordinates, but like I said it took a long time to get a fix, and the same time to obtain it again if lost.

Perhaps it's your Pytrack that is malfunctioning? (Perhaps try with another Pytrack if possible?)

And yes, a word from Pycom would be useful here. Hope I could help you :)

[jlandercy]

@mnovella Thank you for answering and sharing your experience. So you managed to improve performance by going under the hood of the GPS process and implementing your own logic. Am I getting it right?

May I ask what were the most important milestones to overcome this issue?

By now, 8 hours recording I have a node that never got a coordinate while the second recorded only 15% of the time. I was expecting something else, how disappointing...

It also might be worthy if someone at PyCom replies and gives us a consistent feedback on the technology they sell. Guidelines, tips and so on. Because when I read that peculiar spec sheet it sold me a dream. Now I am kind of mixed.

[mnovella]

@jlandercy I also have a PyTrack and LoPy4 setting, and after many tests I have perceived that it takes quite some time to get GPS fix (several minutes), even when outside and with clear sky view.

However, after getting a fix, I start getting coordinates without many problems (with some occasional fix loss).

I also use the L7GNSS library and a code similar to yours. So far, I still experience some inconsistencies and some (None, None) received as coordinates. I have also experienced exceptions when initializing the Pytrack by calling Pytrack(), case where I have to retry, reboot, or reseat the LoPy on the Pytrack.

Today, I still use the Pytrack as an easy way to connect the LoPy and program it, but for getting coordinates we decided to go for an external GPS and parse the NMEA sentences via UART... perhaps I am also missing something to make this work reliably.