andrethemac / l76glnsv4

MicroPython library for quectel L76 glnss gps on pycom pytrack

L76GLNSV4

MicroPython library for quectel L76 glnss gps on pycom pytrack

2020-03-25 add new methods for quering the chip

• get_dt_release: get the software version of the chip
• get_chip_version: get the hardware version of the chip
• better handling of messages send by the chip

2020-03-20

• added fix for newer chips with longer messages (Kudos to askpatrickw for finding the issue)
• RMC -> added NavigationaalStatus
• GSA -> added GNSSSystemID
• GSV -> added SignalID
• new messages are added to newer versions of the chip (V4.10 and later). this should fix this.

2019-06-10 new version L76GLNSV5

https://github.com/andrethemac/L76GLNSV5

this is a rewrite, the messages are now read and parsed in a separed thread.

2019-06-08

• added new features
• enterStandBy: put gps off, needs powercycle to restart
• hotStart: restart the GPS with last found data in non volitale ram
• warmStart: restart the GPS with last known data not in ram
• coldStart: as powercycle
• fullColdStart: forget everything and start al over, takes long to get fix (same as powercycle)
• setPeriodicMode: Mode 2 preserves the most energy
• setAlwaysOn: same as setPeriodicMode(0), keeps the gps awake

improved fix speed

improved nmea message handling

example using the pycom pytrack and wipy3 or lopy4

this example uses the machine.deepsleep to put the wipy/lopy to sleep, but the pytrack board keeps powered. The L76 gps doesn't looses its rtc clock or the satelites in view, resulting in a very quick fix. powering down the pytrack means you need to look anew for satelites, this takes a long time. the Periodic StandBy mode seems to be the most enery efficient. (more test needs to be done) Don't use the pytrack sleep, if you want quick fixes. The pytrack sleep powers the whole board down.

pytrack has a parameter to keep the gps powered during deepsleep of the pytrack module py.go_to_sleep(gps=True)

from pytrack import Pytrack
from L76GNSV4 import L76GNSS
import machine, time
import pycom

print("up")
py = Pytrack()
L76 = L76GNSS(pytrack=py)
L76.setAlwaysOn()

print("print gsv")
# returns the info about sattelites in view at this moment
# even without the gps being fixed
print(L76.gps_message('GSV',debug=True))

print("gga")
# returns the number of sattelites in view at this moment
# even without the gps being fixed
print(L76.gps_message('GGA',debug=True)['NumberOfSV'])

L76.get_fix(debug=False)
pycom.heartbeat(0)
if L76.fixed():
    pycom.rgbled(0x000f00)
else:
    pycom.rgbled(0x0f0000)
print("coordinates")
# returns the coordinates
# with debug true you see the messages parsed by the
# library until you get a the gps is fixed
print(L76.coordinates(debug=False))
print(L76.getUTCDateTime(debug=True))

# example using the periodicmode of the gps
print("put gps in low power for 40 seconds after 20 seconds")
L76.setPeriodicMode(2,20000,40000,60000,60000)
print("wait 15 seconds")
for x in range(15,0,-1):
    pycom.rgbled(0x000f00+x)
    time.sleep(1)
print("put lopy to deepsleep for 1 minute ")
print("the gps schould be awake before the lopy")
machine.deepsleep(60000)

# example using the deepsleep mode of the pytrack
machine.idle()
py.setup_sleep(60) # sleep 1 minute
py.go_to_sleep(gps=True)

l76glnsv4's Issues

When Adding Additional Control Messages, Cannot capture PMTK001 Responses

I'm working to add sdditional control messages for:

• Querying Firmware Version (605 - PMTK_Q_RELEASE)
• Working with AlwaysLocate Flash Logs
  • Starting and Stopping Logging (185 PMTK_LOCUS_STOP_LOGGER)
  • Querying Log (622 PMTK_Q_LOCUS_DATA)
  • Erasing Log (184 PMTK_LOCUS_ERASE_FLASH)

But, as-is the library never seems to capture the response codes. These are all PMTK001 messages. Is this something you've observed before? I see you have commented out every place where you were trying to capture this before, ex:

    # return self._read_message(messagetype='001', debug=debug)

Any additional information you can share about that? I see in your new V5 version you switched to a threaded model. I am wondering if the _read was to slow in this model to catch all messages.

UnicodeError when creating the L76 object

Hello there,

I found a strange error (which I am not able to reproduce), when calling the constructor. It suddenly raised a UnicodeError exception. Currently I am working with a Lopy4 and Pytrack2 board.

As far as I can understand the line of code who produce the unexpected error is the following one:

L76GLNSV4/L76GNSV4.py

Line 229 in 4904f25

nmea_buffer = self._read().decode('utf-8')

Even if this is very strange, it seems that I received on the i2c a message that can not be decoded in UTF-8.

For the moment I wrap the initialization in a try/catch block to avoid the firmware to suddenly crash. Do you think it could be a good idea to detect the error inside the constructor? I could provide a PR but the change is very minimal I guess.

Thanks for your nice work.
Best regards.

Problem with Fipy 1.20.0.rc3

Hello,

First thanks for that alternative library, I'm using the following pytrack with Fipy.

(sysname='FiPy', nodename='FiPy', release='1.20.0.rc3', version='v1.9.4-c5b0b1d on 2018-12-17', machine='FiPy with ESP32', lorawan='1.0.2', sigfox='1.0.1');

Before I switched to your library when using 1.17.x.x, on the first connection after 2 minutes I could get connected to the GPS ( get fix if I can say like that).

Since I upgraded to 1.20.0.rc3 the first connection never happen and it seems to just loop/timeout in the get_fix function.

I have the same issue with the "offficial" library L76NGSS.py provided on the pycom github.

If you have any hint, thanks by advance.

Br,

Improving ColdStart Aquisition Times

I did a little research on this... the main thing seems to be if you had a reliable clock (RTC) and a known last good position. You could use PMTK 740 and PMTK 741 to inject time and position and improve the cold start performance.

I don't think your library can do this magically for the user, but it might be something the user could do when initializing L76GNSS if they had a battery powered RTC and a reliably cached last position. I'm not sure of the impact of loading a bad time or position.

Maybe not enough to start coding from, but good information to save here for future reference.

Helpful Quectel Information:

• Potential Hardware Board esign Issue
• With helper Location and Time you can Improve Cold_Start times using PMTK 740 and PMTK 741

PMTK_DT_UTC

Packet Type: 740
Format: $PMTK740,YYYY,MM,DD,hh,mm,ss*CS<CR><LF>
Example: $PMTK740,2010,2,10,9,0,58*05<CR><LF>
The packet indicates that the current UTC time is 2010/Feb/10 09:00:58.

PMTK_DT_ POS

Packet Type: 741
Format: $PMTK741,Lat,Long,Alt,YYYY,MM,DD,hh,mm,ss *CS<CR><LF>
Example: $PMTK741,24.772816,121.022636,160,2011,8,1,08,00,00
The packet indicates that the GNSS receiver is at:

• latitude 24.772816 degrees
• longitude 121.022636 degrees
• altitude 160 meters

Year and date transposed in getUTCDateTime()

When I call getUTCDateTime() and print the result, the current date appears behind the "20" and the year is displayed as the date. For instance, when it's 2018-5-27, that function returns 2027-5-18.

get_fix timeout does not work

The timeout does not work, because the chrono is continuously reset inside the while loop by _read_message.

L76GLNSV4/L76GNSV4.py

Line 323 in 1cf479b

nmea_message = self._read_message(('RMC', 'VTG', 'GLL', 'GGA', 'GSA'), debug=debug)

getUTCDateTime() without GPS connection

When i call getUTCDateTime() when i don't have a GPS connection and print the result i get 2080-01-06T00:04:42+00:00 instead of the None the comments in the code indicate.

Core Dump using Pytrack V2

I have been experiencing errors when using this version of L76GNSV4. I am using a pytrack V2, a LoPy 4, the pycoproc_2 library and your L76GNSV4 library. After receiving the coordinates in a certain time the LoPy 4 performs a Core Dump for no apparent reason. Have any bugs been reported in your library with that hardware combination?
Software Versions:

LoPy4: 1.20.2.r6
Pytrack V2: 16
L76GNSV4: 2020-03-25
pycoproc_2: 2021-04-09
Jumper and Active Antenna: Yes

Error:
Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled.
Core 0 register dump:
PC : 0x40152a0b PS : 0x00060f30 A0 : 0x8015356d A1 : 0x3ffb41f0
A2 : 0x3ffcdd40 A3 : 0x0000000000 A4 : 0xa0443030a0 A5 : 0x3ffcdd40
A6 : 0x000000000000 A7 : 0x00000000 A8 : 0xa04430e0 A9 : 0x3ffe3e64
A10 : 0x3ffe3e64 A11 : 0x00000001 A12 : 0x00060920 A13 : 0x3ffb42a8
A14 : 0x00000017 A15 : 0x0000000000 SAR : 0x00000020 EXCCAUSE: 0x0000001c
EXCVADDR: 0xa04430e0 LBEG : 0x40094230 LEND : 0x4009425e LCOUNT : 0xffffffffffffff

ELF file SHA256: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Backtrace: 0x40152a0b:0x3ffb41f0 0x4015356a:0x3ffb4230 0x401536ba:0x3ffb4260 0x40158468:0x3ffb4290

================= CORE DUMP START =================
fDkAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==

Missing NMEA 4.10 Keywords from RMC, GSA, GSV (Was: RMC Messages being skipped)

I'm learning the library and I may be making mistakes so please to point me in the right direction if I'm wrong. It seems as though no RMC based functionality is working, but I see RMC messages in the debug output.

See in this log stream that I ask for an RMC message and none is found, but there is one in the log.

>>>> L76.gps_message('RMC',debug=True)
RMC
messagetype RMC
nmea raw 255 22 b',W,070802.000,A,A*52\r\n$GNRMC,070803.000,A,4737.0000,N,12220.0000,W,0.00,87.63,190320,,,A,V*25\r\n$GPVTG,87.63,T,,M,0.00,N,0.00,K,A*07\r\n$GPGGA,070803.000,4737.0000,N,12220.0000,W,1,6,3.47,41.8,M,-17.3,M,,*53\r\n$GNGSA,A,3,26,27,16,10,,,,,,,,,3.61,3.47,0.98,1*\n'
nmea raw fix False 71 $GNRMC,070803.000,A,4737.0000,N,12220.0000,W,0.00,87.63,190320,,,A,V*25
RMC -> ['RMC', '070803.000', 'A', '4737.0000', 'N', '12220.0000', 'W', '0.00', '87.63', '190320', '', '', 'A', 'V']
nmea_message None

I spent a good hour looking at _RMC() in the library and couldn't see anything wrong.
When I take the message from the logs:
msg = ['RMC', '070803.000', 'A', '4737.0000', 'N', '12220.0000', 'W', '0.00', '87.63', '190320', '', '', 'A', 'V'] and the keywords in the function and run dict(zip(keywords, msg)) as in _mixhash(), I get a perfectly formatted DICT so I'm stumped.

This seems to be breaking the following functionality all of which simply run indefinitely:

• L76.gps_message('RMC')
• L76.getUTCDateTime()
• L76.getUTCDateTimeTuple()

If you can point the way, I'm happy to do a PR and test the fix. tx!