search

gtjoseph / mt3339-utils

MIT License
62 stars 21 forks source link

Transfer to GPS fails with result = -1 #11

Closed shaunmulligan closed 2 years ago

shaunmulligan commented 2 years ago

I am using an Adafruit PA1010D (based on MT3339) GPS https://www.adafruit.com/product/4415 with a raspberry pi. the epoloader script seems to fail with the transfer part but I don't know where to begin with debugging why. Would you be able to offer any insight to figure out why its failing? gpsstatus works perfectly, it seems to be some issue with the binary transfer.

pi@overkill:~/mt3339-utils $ ./epoloader -l=37.4537408,02.2577958,5 -t=2022,01,19,12,46,00 --max-sets 24 -c /tmp/EPO.DAT /dev/ttyACM0 -s 115200
Opening EPO Type II file with 120 sets
Current port speed: 115200
GPS and port are now synchronized at 115200
Setting known values: 41.4537408,2.2577958,5  2022,01,19,12,46,00
Clearing existing EPO data
Setting binary mode, speed: 115200
Sending 4 EPO sets of 120
Sending set    1.  Valid from 2022-01-18 23:59:46 UTC
result : -1
rseq : -1
Transfer failed
Resetting NMEA Speed: 115200
ERROR: EPO in NVRAM doesnt match file
  In NVRAM: 1980-01-05 23:59:46 to 1980-01-05 23:59:46 UTC
shaunmulligan commented 2 years ago

I tried the same thing with the Adafruit Ultimate GPS, which is also based on the MT3339 chipset and I get the same result :(

gtjoseph commented 2 years ago

I'll take a look this weekend.

shaunmulligan commented 2 years ago

Thanks @gtjoseph . It looks like it's due to python3 . I just ran the same setup with python2 and it seems to mostly work, besides the NVRAM validation not matching. see the output below:

pi@overkill:~/mt3339-utils $ python2 epoloader -l=41.4537408,2.2577958,5 -t=2022,01,19,15,23,00 --max-sets 24 -c /tmp/EPO.DAT /dev/ttyACM0 -s 115200
Opening EPO Type II file with 120 sets
Current port speed: 115200
GPS and port are now synchronized at 115200
Setting known values: 41.4537408,2.2577958,5  2022,01,19,15,23,00
Clearing existing EPO data
Setting binary mode, speed: 115200
Sending 24 EPO sets of 120
Sending set    1.  Valid from 2022-01-18 23:59:46 UTC
result : 1
rseq : 0
result : 1
rseq : 1
result : 1
rseq : 2
result : 1
rseq : 3
result : 1
rseq : 4
result : 1
rseq : 5
result : 1
rseq : 6
result : 1
rseq : 7
result : 1
rseq : 8
result : 1
rseq : 9
result : 1
rseq : 10
<snip>
result : 1
rseq : 260
result : 1
rseq : 261
result : 1
rseq : 262
result : 1
rseq : 263
  24 sets sent.  Valid from 2022-01-18 23:59:46 to 2022-01-24 23:59:46 UTC
Resetting NMEA Speed: 115200
ERROR: EPO in NVRAM doesnt match file
  In NVRAM: 2022-01-18 23:59:46 to 2031-07-31 09:59:46 UTC
gtjoseph commented 2 years ago

I think I've got it sorted for both python 2 and 3. I'll have something up to test tomorrow.

gtjoseph commented 2 years ago

@shaunmulligan I just pushed up v1.1.0-rc1. Give it a test with both python2 and 3.

shaunmulligan commented 2 years ago

thanks @gtjoseph this is awesome. I have verified both are working with the Adafruit Ultimate GPS (mt3333). thanks so much!

shaunmulligan commented 2 years ago

Weirdly enough I just tested this on the MT3339 based device and it doesn't work as well, there are two problems. 1.) if I provide the -t- command it fails with ERROR: Unable to set time. None 2.) If i provide the time manually, then it writes the epo data but the last lines of the output indicate its not written to NVRAM.

...
Sending set   24.  Valid from 2022-01-29 17:59:46 UTC
Sending set   25.  Valid from 2022-01-29 23:59:46 UTC
Sending set   26.  Valid from 2022-01-30 05:59:46 UTC
  26 sets sent.  Valid from 2022-01-23 23:59:46 to 2022-01-30 11:59:46 UTC
ERROR: EPO in NVRAM doesnt match file
  In NVRAM: 1980-01-05 23:59:46 to 1980-01-05 23:59:46 UTC

Maybe this chipset has a slightly different command set or something?

gtjoseph commented 2 years ago

That is weird. I tested with the 3339. Let me see what other devices I have to test with.

gtjoseph commented 2 years ago

@shaunmulligan Do a 'git pull' again. I just added some debugging options. First, get the firmware versions from both working and non-working devices: ./gpsinit -f ./gpsinit_info.conf <device> Second, on the device where epoloader fails, run it with the --debug option.

Paste the results here.

shaunmulligan commented 2 years ago

Thanks for adding those debug options, here is the output from the two devices:

PA1010D (MT3339) - Not working as expected

pi@testingpi:~/mt3339-utils $ python3 gpsinit -f gpsinit_info.conf /dev/ttyACM0 
Setting NMEA at 9600 baud.
   Unit is currently in NMEA mode at 9600 baud.
GPS and port are now synchronized at 9600
Processing commands...
get_version
['PMTK705', 'AXN_5.1.7_3333_19020118', '0027', 'PA1010D', '1.0']
get_epo
  EPO in NVRAM: 1980-01-05 23:59:46 to 1980-01-05 23:59:46 UTC
Done

With —debug

pi@testingpi:~/mt3339-utils $ python3 epoloader -s 115200 -l=41.4537716,2.2577526,0 --debug -t 2022,01,24,8,56,00 /tmp/EPO.DAT /dev/ttyACM0 
Opening EPO Type II file with 120 sets
Setting NMEA at 115200 baud.
>> $PMTK000*32
<< 
>> $PMTK000*32
<< 
   No response.  Seeing if it's in binary mode.
>> $PMTK000*32
<< 
>> $PMTK000*32
<< 
>> $PMTK000*32
<< 
>> $PMTK000*32
<< 
   Apparently not. Failed.
GPS isn't at the desired 115200 baud rate.  Trying the current port rate of 9600 baud.
Setting NMEA at 9600 baud.
>> $PMTK000*32
<< $GNGGA,205636.000,4127.2262,N,00215.4705,E,1,
>> $PMTK000*32
<< $PMTK001,0,3*30
   Unit is currently in NMEA mode at 9600 baud.
Attempting to set it to 115200 baud
>> $PMTK251,115200*1f
>> $PMTK000*32
<< $PMTK001,0,3*30
GPS and port are now synchronized at 115200
>> $PMTK605*31
<< $GNGGA,205639.000,4127.2259,N,00215.4700,E,1,7,1.93,3.9,M,51.2,M,,*40
>> $PMTK605*31
<< $PMTK705,AXN_5.1.7_3333_19020118,0027,PA1010D,1.0*76
GPS Version:  ['PMTK705', 'AXN_5.1.7_3333_19020118', '0027', 'PA1010D', '1.0']
Setting known values: 41.4537716,2.2577526,0  2022,01,24,8,56,00
>> $PMTK740,2022,01,24,8,56,00*0f
<< $PMTK001,740,3,2022,1,24,8,56,0*0D
Time set
>> $PMTK741,41.4537716,2.2577526,0,2022,01,24,8,56,00*26
<< $PMTK001,741,3,41.453772,2.257753,0.000000,2022,1,24,8,56,0*08
Location set
Setting binary mode, speed: 115200
>> $PMTK253,1,115200*00
Sending 26 EPO sets of 120
Sending set    1.  Valid from 2022-01-23 23:59:46 UTC
Sending set    2.  Valid from 2022-01-24 05:59:46 UTC
Sending set    3.  Valid from 2022-01-24 11:59:46 UTC
Sending set    4.  Valid from 2022-01-24 17:59:46 UTC
Sending set    5.  Valid from 2022-01-24 23:59:46 UTC
Sending set    6.  Valid from 2022-01-25 05:59:46 UTC
Sending set    7.  Valid from 2022-01-25 11:59:46 UTC
Sending set    8.  Valid from 2022-01-25 17:59:46 UTC
Sending set    9.  Valid from 2022-01-25 23:59:46 UTC
Sending set   10.  Valid from 2022-01-26 05:59:46 UTC
Sending set   11.  Valid from 2022-01-26 11:59:46 UTC
Sending set   12.  Valid from 2022-01-26 17:59:46 UTC
Sending set   13.  Valid from 2022-01-26 23:59:46 UTC
Sending set   14.  Valid from 2022-01-27 05:59:46 UTC
Sending set   15.  Valid from 2022-01-27 11:59:46 UTC
Sending set   16.  Valid from 2022-01-27 17:59:46 UTC
Sending set   17.  Valid from 2022-01-27 23:59:46 UTC
Sending set   18.  Valid from 2022-01-28 05:59:46 UTC
Sending set   19.  Valid from 2022-01-28 11:59:46 UTC
Sending set   20.  Valid from 2022-01-28 17:59:46 UTC
Sending set   21.  Valid from 2022-01-28 23:59:46 UTC
Sending set   22.  Valid from 2022-01-29 05:59:46 UTC
Sending set   23.  Valid from 2022-01-29 11:59:46 UTC
Sending set   24.  Valid from 2022-01-29 17:59:46 UTC
Sending set   25.  Valid from 2022-01-29 23:59:46 UTC
Sending set   26.  Valid from 2022-01-30 05:59:46 UTC
  26 sets sent.  Valid from 2022-01-23 23:59:46 to 2022-01-30 11:59:46 UTC
>> $PMTK000*32
>> $PMTK000*32
<< 
>> $PMTK000*32
<< $PMTK001,0,3*30
>> $PMTK607*33
<< $PMTK707,0,0,0,0,0,0,0,0,0*2E
>> $PMTK251,9600*17
>> $PMTK000*32
<< VTG,140.39,T,,M,3.05,N,5.65,K,A*2C
>> $PMTK000*32
<< $GNGGA,205654.000,4127.2227,N,00215.4
>> $PMTK251,9600*17
>> $PMTK000*32
<< GNVTG,148.58,T,,M,0.25,N,0.46,K,A*26
>> $PMTK000*32
<< $GNGGA,205657.000,4127.2221,N,00215.
>> $PMTK251,9600*17
>> $PMTK000*32
<< SV,3,2,10,26,41,168,,08,32,297,27,18,25,052,,21,15,242,*7D
>> $PMTK000*32
<< $GNGGA,205700.000,4127.2214,N,00215.4678,E,1,7,1.93,4.9,M,51.2,M,,*4B
ERROR: EPO in NVRAM doesnt match file
  In NVRAM: 1980-01-05 23:59:46 to 1980-01-05 23:59:46 UTC

Ultimate GPS (MT3333) - working as expected

pi@testingpi:~/mt3339-utils $ python3 gpsinit -f gpsinit_info.conf /dev/ttyACM0 
Setting NMEA at 9600 baud.
   Unit is currently in NMEA mode at 9600 baud.
GPS and port are now synchronized at 9600
Processing commands...
get_version
['PMTK705', 'AXN_2.31_3339_13101700', '5632', 'PA6H', '1.0']
get_epo
  EPO in NVRAM: 2022-01-23 23:59:46 to 2022-01-30 05:59:46 UTC
Done

With Debug:

pi@testingpi:~/mt3339-utils $ python3 epoloader -s 115200 -l=41.4537716,2.2577526,0 --debug -t- /tmp/EPO.DAT /dev/ttyACM0 
Opening EPO Type II file with 120 sets
Setting NMEA at 115200 baud.
>> $PMTK000*32
<< 
>> $PMTK000*32
<< 
   No response.  Seeing if it's in binary mode.
>> $PMTK000*32
<< 
>> $PMTK000*32
<< 
>> $PMTK000*32
<< 
>> $PMTK000*32
<< 
   Apparently not. Failed.
GPS isn't at the desired 115200 baud rate.  Trying the current port rate of 9600 baud.
Setting NMEA at 9600 baud.
>> $PMTK000*32
<< $PMTK001,0,3*30
   Unit is currently in NMEA mode at 9600 baud.
Attempting to set it to 115200 baud
>> $PMTK251,115200*1f
>> $PMTK000*32
<< $PMTK001,0,3*30
GPS and port are now synchronized at 115200
>> $PMTK605*31
<< $PMTK705,AXN_2.31_3339_13101700,5632,PA6H,1.0*6B
GPS Version:  ['PMTK705', 'AXN_2.31_3339_13101700', '5632', 'PA6H', '1.0']
Setting known values: 41.4537716,2.2577526,0  2022,01,25,15,19,02
>> $PMTK740,2022,01,25,15,19,02*3b
<< $PMTK001,740,3*33
Time set
>> $PMTK741,41.4537716,2.2577526,0,2022,01,25,15,19,02*12
<< $PMTK001,741,3*32
Location set
Setting binary mode, speed: 115200
>> $PMTK253,1,115200*00
Sending 26 EPO sets of 120
Sending set    1.  Valid from 2022-01-23 23:59:46 UTC
Sending set    2.  Valid from 2022-01-24 05:59:46 UTC
Sending set    3.  Valid from 2022-01-24 11:59:46 UTC
Sending set    4.  Valid from 2022-01-24 17:59:46 UTC
Sending set    5.  Valid from 2022-01-24 23:59:46 UTC
Sending set    6.  Valid from 2022-01-25 05:59:46 UTC
Sending set    7.  Valid from 2022-01-25 11:59:46 UTC
Sending set    8.  Valid from 2022-01-25 17:59:46 UTC
Sending set    9.  Valid from 2022-01-25 23:59:46 UTC
Sending set   10.  Valid from 2022-01-26 05:59:46 UTC
Sending set   11.  Valid from 2022-01-26 11:59:46 UTC
Sending set   12.  Valid from 2022-01-26 17:59:46 UTC
Sending set   13.  Valid from 2022-01-26 23:59:46 UTC
Sending set   14.  Valid from 2022-01-27 05:59:46 UTC
Sending set   15.  Valid from 2022-01-27 11:59:46 UTC
Sending set   16.  Valid from 2022-01-27 17:59:46 UTC
Sending set   17.  Valid from 2022-01-27 23:59:46 UTC
Sending set   18.  Valid from 2022-01-28 05:59:46 UTC
Sending set   19.  Valid from 2022-01-28 11:59:46 UTC
Sending set   20.  Valid from 2022-01-28 17:59:46 UTC
Sending set   21.  Valid from 2022-01-28 23:59:46 UTC
Sending set   22.  Valid from 2022-01-29 05:59:46 UTC
Sending set   23.  Valid from 2022-01-29 11:59:46 UTC
Sending set   24.  Valid from 2022-01-29 17:59:46 UTC
Sending set   25.  Valid from 2022-01-29 23:59:46 UTC
Sending set   26.  Valid from 2022-01-30 05:59:46 UTC
  26 sets sent.  Valid from 2022-01-23 23:59:46 to 2022-01-30 11:59:46 UTC
>> $PMTK000*32
<< 
>> $PMTK000*32
<< 
>> $PMTK000*32
<< $PMTK001,0,3*30
>> $PMTK607*33
<< $PMTK707,56,2194,89680,2195,23264,2194,217264,2194,217760*13
>> $PMTK251,9600*17
>> $PMTK000*32
<< $PMTK001,0,3*30
Verified EPO in NVRAM matches file
gtjoseph commented 2 years ago

Yep, OK. The first unit looks like it's sending periodic NMEA messages while the second one isn't. I think the periodic messages are confusing the parser. The best thing for me to do probably is to turn off the periodic messages at the start, then turn them back on again after the verification. Should have something to test again tomorrow.

shaunmulligan commented 2 years ago

awesome, thanks so much, your support has been awesome!

gtjoseph commented 2 years ago

OK, give it a shot again. epoloader suspends periodic NMEA message output before doing anything, then restores them when it's done.

shaunmulligan commented 2 years ago

I just gave it a run now but it still seems to fail in the same way unfortunately :(

pi@testingpi:~/mt3339-utils $ python3 epoloader -s 115200 -l=41.4537716,2.2577526,0 -t 2022,01,27,08,21,45 --debug /tmp/EPO.DAT /dev/ttyACM0
Opening EPO Type II file with 120 sets
Setting NMEA at 115200 baud.
>> $PMTK000*32
<< 
>> $PMTK000*32
<< 
   No response.  Seeing if it's in binary mode.
>> $PMTK000*32
<< 
>> $PMTK000*32
<< 
>> $PMTK000*32
<< 
>> $PMTK000*32
<< 
   Apparently not. Failed.
GPS isn't at the desired 115200 baud rate.  Trying the current port rate of 9600 baud.
Setting NMEA at 9600 baud.
>> $PMTK000*32
<< $GNGGA,082342.096,,,,,0,0,,,M,,M,,*56
>> $PMTK000*32
<< $PMTK001,0,3*30
   Unit is currently in NMEA mode at 9600 baud.
Attempting to set it to 115200 baud
>> $PMTK251,115200*1f
>> $PMTK000*32
<< $PMTK001,0,3*30
GPS and port are now synchronized at 115200
>> $PMTK414*33
<< $PMTK514,0,1,1,1,1,5,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*37
>> $PMTK314,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*28
<< $PMTK001,314,3*36
>> $PMTK605*31
<< $PMTK705,AXN_5.1.7_3333_19020118,0027,PA1010D,1.0*76
GPS Version:  ['PMTK705', 'AXN_5.1.7_3333_19020118', '0027', 'PA1010D', '1.0']
Setting known values: 41.4537716,2.2577526,0  2022,01,27,08,21,45
>> $PMTK740,2022,01,27,08,21,45*3d
<< $PMTK001,740,3,2022,1,27,8,21,45*3F
Time set
>> $PMTK741,41.4537716,2.2577526,0,2022,01,27,08,21,45*14
<< $PMTK001,741,3,41.453772,2.257753,0.000000,2022,1,27,8,21,45*3A
Location set
Setting binary mode, speed: 115200
>> $PMTK253,1,115200*00
Sending 26 EPO sets of 120
Sending set    1.  Valid from 2022-01-26 23:59:46 UTC
Sending set    2.  Valid from 2022-01-27 05:59:46 UTC
Sending set    3.  Valid from 2022-01-27 11:59:46 UTC
Sending set    4.  Valid from 2022-01-27 17:59:46 UTC
Sending set    5.  Valid from 2022-01-27 23:59:46 UTC
Sending set    6.  Valid from 2022-01-28 05:59:46 UTC
Sending set    7.  Valid from 2022-01-28 11:59:46 UTC
Sending set    8.  Valid from 2022-01-28 17:59:46 UTC
Sending set    9.  Valid from 2022-01-28 23:59:46 UTC
Sending set   10.  Valid from 2022-01-29 05:59:46 UTC
Sending set   11.  Valid from 2022-01-29 11:59:46 UTC
Sending set   12.  Valid from 2022-01-29 17:59:46 UTC
Sending set   13.  Valid from 2022-01-29 23:59:46 UTC
Sending set   14.  Valid from 2022-01-30 05:59:46 UTC
Sending set   15.  Valid from 2022-01-30 11:59:46 UTC
Sending set   16.  Valid from 2022-01-30 17:59:46 UTC
Sending set   17.  Valid from 2022-01-30 23:59:46 UTC
Sending set   18.  Valid from 2022-01-31 05:59:46 UTC
Sending set   19.  Valid from 2022-01-31 11:59:46 UTC
Sending set   20.  Valid from 2022-01-31 17:59:46 UTC
Sending set   21.  Valid from 2022-01-31 23:59:46 UTC
Sending set   22.  Valid from 2022-02-01 05:59:46 UTC
Sending set   23.  Valid from 2022-02-01 11:59:46 UTC
Sending set   24.  Valid from 2022-02-01 17:59:46 UTC
Sending set   25.  Valid from 2022-02-01 23:59:46 UTC
Sending set   26.  Valid from 2022-02-02 05:59:46 UTC
  26 sets sent.  Valid from 2022-01-26 23:59:46 to 2022-02-02 11:59:46 UTC
>> $PMTK000*32
>> $PMTK000*32
<< 
>> $PMTK000*32
<< $PMTK001,0,3*30
>> $PMTK607*33
<< $PMTK707,0,0,0,0,0,0,0,0,0*2E
>> $PMTK314,0,1,1,1,1,5,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*31
<< $PMTK001,314,3*36
>> $PMTK251,9600*17
>> $PMTK000*32
<< $PMTK001,0,3*30
ERROR: EPO in NVRAM doesnt match file
  In NVRAM: 1980-01-05 23:59:46 to 1980-01-05 23:59:46 UTC
gtjoseph commented 2 years ago

Weird. The unit accepted each of the sets without error but apparently didn't save them to the NVRAM. This says there are no sets in the device: $PMTK707,0,0,0,0,0,0,0,0,0*2E Is it possible you just have a bad unit.

Actually, are you sure that the 3333 even supports loading the EPO? I don't have a 3333 and never tested it. Do you have another 3333 to test?

shaunmulligan commented 2 years ago

It could be a bad unit, unfortunately I don't have another one to test against :( according to the data here https://labs.mediatek.com/en/chipset/MT3333 it should support EPO, so not sure why its not writing it to NVRAM

gtjoseph commented 2 years ago

Hmmm. Not sure what else I can do at this point. Have you tested the 3339 with the latest code?

shaunmulligan commented 2 years ago

yeah the 3339 still works. Perhaps the mt3333 I have doesn't have NVRam or something odd like that :( , I guess I will need to use the 3339 for my project for now. thanks for all the help!

gtjoseph commented 2 years ago

No problem!