FiPy + PyTrack = unable to get GPS coordinates

[securigy]

I am running the latest image from Andreas built by Rober_hh that fixes access to REPL over serial and AP on boot up.
I was able to connect to LTE and get local time.
However I am unable to get GPS coordinates, using the example code:

    from L76GNSS import L76GNSS
    from pytrack import Pytrack

    py = Pytrack()
    l76 = L76GNSS(py, timeout=30)

    while(True):
        coord = l76.coordinates()
        print("Coordinates: {}".format(coord))
        time.sleep(5)
except Exception:
    pass # do nothing on error

I am getting:

Coordinates: (None, None)

Any ideas? Should I user a different GPS library?
I am also not clear: is GPS data coming directly to PyTrack via its own radio channel, OR is it coming over CAT-M1 that I am connected to? (apologies for a newbie question)

EDIT: So I kept digging into this forum's postings and somewhere I read that this library L76GNSS supports only GNSS (not GPS in the US). Is it true?
So I tried micropyGPS - here I get error while trying to read:

Traceback (most recent call last):
  File "main.py", line 27, in read_receiver
  File "gnssl76l.py", line 35, in sentences
  File "gnssl76l.py", line 27, in read
OSError: I2C bus error

I tried initializing I2C in different way but that did not help:

i2c = I2C(0)
or
i2c = I2C(0, pins=('P26','P25')) // does not compile - invalid arguments
or
i2c = I2C(0, I2C.MASTER)

the 1st and 3rd way I am getting I2C Bus Error.
Any ideas? What am I doing wrong?

[securigy]

@psrebrny So I can't say that I predicted in detail the process you went through but my gut feeling told me that it won't be easy (although kudos to you for proving that it is possible). So I slept on the issue for couple of days and decided for another $50 to solve this problem by purchasing another dev board with Assist GPS and cutting my (TTFF) cold start to 26 sec. In fact just by reading its spec I was amazed and excited to avoid all this trouble - so I think that $50 is well spent. So if I were you I'd take a look at uBlox NEO-M8 series. I went for this one:
NEO-M8U-0-10CT-ND
Still waiting for delivery from Digi-Key.
I must say here that although Pycom deserves a good word for its innovation and rushing forward with its devices, IMO this rush is very hard on developers that either face unexpected problems with firmware (that sure does not go through any QA), or capabilities of devices or lack of them that never mentioned by Pycom. So, I'd recommend for Pycom to slow down and make their HW more capable that can be used in real commercial devices and their FW reliable.

[psrebrny]

@securigy I am struggling with the GPS fix too. I went through the effort of obtaining ephemeris data for the L76 chip and I wrote a piece of software to download this data to GNSS chip. However, I have not tried to obtain the GPS fix yet.

In order to get ephemeris data you have to contact Quectel that produces L76. They will give you access to servers from where you can download the data. A single data package for GPS system is 2304B long and it is valid for 6h. Then you have to implement a protocol specified in GNSS_Flash_EPO_Application_Note_V1.0 to upload the data to GNSS chip. The upload procedure is very unreliable over I2C. I manage to transfer data only once and it was some old sample data. That is why I did not test it yet. When I have some results I can share with you.

[jcaron]

@securigy The LTE-M antenna is for LTE-M, this is completely separate from GPS.

As stated previously, being indoors is not really the best option for reception of GPS signals.

Yes, you just keep looping receiving the data and feeding it to the library until you get a fix. As stated previously, on cold start, TTFF (time to first fix) can be minutes. It takes 12.5 minutes to transmit the complete almanacs over the GPS signal.

On subsequent starts, it can be quicker as long as the data saved is still valid, though the GPS chip still needs to acquire the position of several satellites.

[securigy]

@oligauc i am i suburbs and using standart lte-m antenna in the house. What about fog? Is that a factor? Where in the code I wait for a fix? Just trying to loop on attempt reading the sentences?

[oligauc]

@securigy The current PyTrack version comes without an external antenna. Trying to obtain a fix indoors might be difficult, especially if it is cloudy, living near high rise builds, etc.

[securigy]

@crumble May be I am wrong but based on what you said there is no real and reliable solution for that. If I supply power to it 24/7 and it gets the GPS quickly (5-10 sec) then I can do that - but if not then it seem that I need to look for another solution than PyTrack for GPS. Or any other GPS sensor will behave the same?

EDIT:
A quick search brought me to this solution that in short uses CAT-M1 to reach to AssistGPS servers and download all needed data for Time To First Fix (TTFF), that is, Almanac, ephemerides, etc...
http://ozzmaker.com/get-a-gps-fix-in-seconds-using-assisted-gps-on-a-raspberry-pi-with-a-berrygps-gsm/
Is anything like that exists for PyTrack (aGPS) in the form of 3rd party library, or special firmware? and if not, how difficult to do it? Are there any plans to do it? If the answer is No to all of the above then may be it is easier to use just their GPS module (uBlox CAM-M8) ? Still need to create PDP on FiPy side...

[crumble]

@securigy

It can take more than 5 minutes to get a fix. How long depends on the location and time.

You can set different start modes. By default the L76 is configured to store the almanac in its internal flash, so that it gets the fix faster. But the stored data must be younger than 3 hours.

Additionally GPS can be supplied with power when the ESP is in deepsleep. So you can get fixes fast,.

I place my pytrack next to the window, but I have only a short timeframe where I can get fixes. So I have not seen them for a long time.

To get around the init problem: use the pytrack deepsleep method. Catch the I2C exception and send the whole system, including the GPS, for 1 second to deepsleep. This will reboot the GPS. See my post somewhere in the 1.20.1 announcement for this. (I dom't know how to deep link a certain post.)

[securigy]

@crumble The 1st thing I did was upgrading new FiPy 1.2 to firmware 1.20.1.1r and that's what totally disabled my development. It took me enormous time and help from Robert and Andreas using Andreas version of the firmware to rectify these 2 problems: loss of AP on bootup and loss of serial connectivity to REPL. BUT it works for your LoPy then good for you...It also worked for my LoPy4, but not for FiPy...

I still do not understand how do I build device that with power up will get it's GPS - I mean not after minutes of waiting for a fix...Is it possible at all to get it in seconds? and what do I have to do to achieve it. May be "robust" is not the right word but I used micropyGPS since I liked all the features and info I can get from it. Now it runs without errors (it was my error using the wrong pin numbers that was causing the I2C Bus Error), but no coordinates either. Yes, maybe it is a bit more of lines of code but I am not perfectionist at this point - just trying everything I can to prove (to myself first) that thing can work as a practical device... So here is the output I get:

Raw data: b'\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n'
Raw data: b'\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n'
Raw data: b'\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n'
Raw data: b'\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n'
Raw data: b'\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n'
Raw data: b'\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n'
Raw data: b'\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n'
Raw data: b'\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n'
Raw data: b'\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n'
Raw data: b'\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n'
Raw data: b'\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n'
Raw data: b'\n$GPRMC,035245.0'
Raw data: b'93,V,,,,,0.00,0.'
Raw data: b'00,060180,,,N,V*'
Raw data: b'37\r\n$GPVTG,0.00,'
Raw data: b'T,,M,0.00,N,0.00'
Raw data: b',K,N*32\r\n$GPGGA,'
Raw data: b'035245.093,,,,,0'
Raw data: b',0,,,M,,M,,*47\r\n'
Raw data: b'$GPGSA,A,1,,,,,,'
Raw data: b',,,,,,,,,,1*03\r\n'
Raw data: b'$GPGSA,A,1,,,,,,'
Raw data: b',,,,,,,,,,2*00\r\n'
Raw data: b'$GPGSV,1,1,00,0*'
Finished.
No Date
No Coordinates
Timestamp: (3, 52, 45.093)
Satellites in use: 0
Configuring LTE .. OK
Attaching to LTE network .. OK
Connecting on LTE network 
Disconnecting LTE ... OK
Detaching LTE ... OK

Obviously, the raw data is way more than that...I just printed a little piece...And obviously there are no visible satellites...
As I mentioned before this is California homes construction with no concrete or bricks and I am located near a corner window...As suggested my last resort is to go outside and try...What does it mean "will take a long time to get a fix" - in my script I am trying to get and parse sentences for 10 seconds. Do I need to increase the length of the loop to 5 minutes ? (when I try outside).
...and what do I do for this:
The GPS is sometimes not reachable durint init. But you can work arounf this problem.

[crumble]

@securigy

the micropyGPS is not more robust, the library has more features.

In a nut shell:

• On power up the GPS tries to get a fix.
  • it uses data von its internal flash from data configured or collected previously.
• The GPS chip sends continously data about its status in an endless stream of so called NMEA sentences.
• You have to configure the ESP, so that it can read this stream via I2C.
• You have to read and parse this stream for the NMEA sentences and theire contence.

Depending on the library it will do only the last part for you. And may have method to calculated distences between two waypoints and other general stuff.

The pycom "example" will do the connection out of the box therefore it provides only the actual coordinate.

MicropyGPS can parse more sentences and has a lot of features like distance calculation with different earth-models and so on. But therefore you have set up the connection to the GPS and data reading by your own. I never used this one, because RAM on a LoPy is precious.

Both libraries are not the cause for the I2C Bus errors. Most of them are caused by the hardware (ESP 32) and the IDF (c framework/environment of the SoC developer). As far as I can tell this by now, the majority regarding the pytrack problems are fixed with firmware version 1.20.1.r1 using IDF 3.2. There is only one problem left. The GPS is sometimes not reachable durint init. But you can work arounf this problem.

It is your decision if the 2 lines of code for WiFi setup in boot.py are the stopper for dealing with less I2C errors. REPL over serial (USB) works fine on my Win 10 system. IDF 3.2 used in 1.20.1.r1 fixed a bunch of other timing and memory problems as well. I recommend to update, if does not break your FiPy modem.

[securigy]

@jcaron hmmm...thats "deep".
So how do you solve this big problem if you want to create for example a car tracker where location is constantly changing and the tracker is either in the trunk or under the hood...sort of inside...or is it done some other way...

[securigy]

@crumble updating Fipy to official 1.20.1.1r is a very bad thing - it disables default AP behavior ar boot up and screws up REPL access over serial making Fipy useless...
As I figured out last night I was getting i2c buses error due to incorrect i2c initialization - wrong pins as also pointed by Robert.
I switched to micropyGPS library as I understand is more robust and have no errors but no coordinates either... Apparently according to extensive GPS explanation using GPS by Pytrack or any other sensor does not seem practical...

[jcaron]

@securigy just to be clear, when a phone shows a position, in the majority of cases this does not come from GPS, but a combination of:

• knowing the cellular tower the phone is connected to (possibly the several towers it “hears”), and converting that to rough coordinates using a server
• listening for available WiFi networks and Converting that to coordinates using a server
• Assisted GPS, where the GPS receiver gets a lot of the data (almanac, ephemeris...) from a server rather than having to listen for it — it takes a long time to receive all that data over the very very slow GPS signal.
• pedestrian dead reckoning (PDR) with the phone using an IMU to try to track the current position from the last known with any precision.

The GPS chip is power-hungry, takes time to provide an accurate result (especially without A-GPS or recently saved data), and has a hard time working indoors, in tunnels, or even in narrow streets flanked by tall buildings (“urban canyons”), so it is most definitely not the primary source for location information. When you open a Maps application on your phone, remember that your phone has been monitoring cell and WiFi networks in the background, so it already knows where it is (at least roughly).

Also note that most of those techniques require the use of a server. A stand-alone GPS receiver is in a very different situation.

[robert-hh]

@securigy There is no Pin called "P25" or "P26". The notation Pin(25) and Pin(26) addresses GPIO25 and GPIO26, which in turn is "P22" and "P21".
"P22" is GPIO25, "P21" is GPIO26. Since the "Pxx" number count along the egdes of the development modules, "P25", and "P26" would be GND and Vin.
Beside that, the notation Pin(25) is invalid for the Pycom dialect of MicroPython. It is used by the Micropython.org variant.
Confused?

[securigy]

@crumble Well, this is kinda bad news - still hard to believe that PyTrack's GPS does not work inside. I live in Southern California where all houses made with thin drywall and thin stacco on the outside (thin layer of concrete-like mix), so it does not sound like a true obstacle...and there are plenty of satellites...besides, my desk is at the corner window. How come the phone GPS works OK and PyTracks does not... If it does not work in my place it probably does not work anywhere and then why to buy PyTrack vs. less expensive Expansion Board 3.0 ?

Anyway, I hope somebody has a practical answer what to do in this case as I cannot imagine dragging my computer and all the goodies to the backyard... Is there anyway to determine the reason for I2C Bus Error? This error comes from gnssl76l.py line 27, which is the second line in the code below (readfrom functions call):

def read(self, chunksize=255):
        data = self.i2c.readfrom(self.address, chunksize)
        while data[-2:] != b"\x0a\x0a":
            utime.sleep_ms(2)
            data = data + self.i2c.readfrom(self.address, chunksize)

        return data.replace(b"\x0a", b"").replace(b"\x0d", b"\x0d\x0a")

By default, it seems that when I2C passed to the library is None - it uses pins 25 and 26, and I wonder what pins I should use:

class GNSSL76L:
    def __init__(self, i2c=None, address=0x10):
        if i2c is None:
            self.i2c = I2C(scl=Pin(26), sda=Pin(25))
        else:
            self.i2c = i2c

        self.address = address

So far i used the following. Is it correct?

i2c = I2C(0, I2C.MASTER)
receiver = GNSSL76L(i2c)
gps = MicropyGPS()

The I2C constructor refused to use pins 25 and 26 in its other constructor form, but would accept 10 and 11.

i2c = I2C(0, pins=('P26','P25')) # refused
i2c = I2C(0, pins=('P10','P11')) # accepted, but still threw I2C Bus Error

Any ideas are welcome.

EDIT: Nov 4, 2019
I also tried the changes to Pycom standard GPS library and it did not work either...
https://forum.pycom.io/topic/1626/pytrack-gps-api/9

How come Pycom releases the product (PyTrack) with either functionality or standard libraries that do not work?
Do they really think I have more time to find the solution than they are? I am talking basics here...
My experience with FiPy brings me to give them friendly advise: stop rushing the products out - focus on quality and reliability, otherwise it is a really sure way to lose the developers...(to Qualcomm)

[crumble]

@securigy

Update the firmware *Py to 1.20.1.r1 and pytrack 0.0.8.

This will solve a lot of I2C errors.

At least one is still there. The GPS may get into a state where the *Py cannot talk to it. You have to catch the I2C error in init and send the pytrack to deepsleep with gps=True. This forces the GPS chip to reboot and you have a very high chance that the ESP32 and the L76 can communicate again. (and a low chance that they stuck somewhere before deepsleep)

[jcaron]

@securigy Note that "GNSS" is a generic term for the various navigation systems, including GPS, Galileo, GLONASS, Beidou, etc.

All of those systems have global coverage, it's not like you only have GPS in the US, Galileo in Europe, etc.

However, when the chip detects satellites, it may "pick" one or more of the systems, and the reporting changes slightly depending on the system(s) the chip locked on.

Early versions of the Pycom library only listened to GNGLL reports from the chip, which mean each GLONASS only or GLONASS+GPS. The library was fixed about a year ago to support both GNGLL and GPGLL (so also if it has only GPS lock and a number of other cases).

Make sure you have the latest version of the library.

[crumble]

The pycom library is really basic, but are OK for reading the coordinates.

GPS chip get its own signals. You need clear sky,. It may work sometimes inside, if you have really thin walls or your window is located in the right direction.

It may need some time to get the first fix (it sees multiple sats to triangulate the coordinates). Depending on the settings, it may be faster the next time. It may need some minutes for the first fix. Your phone is able to guess its position from other sources. This will speed up the GPS triangulation a lot.

The antenna of the pytrack is really small and you cannot plugin an external antenna. Don't put it into a metal case. place it under clear skies, wait and do not catch exceptions. The i2C communication between the ESP and the GPS may fail. You want to see this.

The GPS has its own flash to store settings and data. If you are not the first owner, someone may have missconfigured the GPS and you have to reset it. Best practice is to let the settings untouched and be patient.