andrethemac / l76glnsv4 Goto Github PK

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

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!

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

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.

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,

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.

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

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:

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.

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.