FiPy + PyTrack = unable to get GPS coordinates

[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.

[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...

[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...

[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]

@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

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 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...

[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]

@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?

[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.

[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.

[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.