"ERROR: EPO in NVRAM doesnt match file" #15
Comments
|
Hmmm. I'm pretty sure it's not you. :)
|
|
It decided to behave while I tested again, so I had to force it to fail by using too many sets. The whole process fails if I try 57600. Interestingly, sending twelve sets fails the same as 28 sets (or most other counts). Force fail, too many sets: epoinfo out: Twelve sets: Port speed 57600: Weird issue! And thanks for looking into it. (Note, I modified my shell script to also use the ${SPEED} variable in the stty call, so no mismatch) |
|
OK, I think I may have a math problem that only shows up in certain circumstances. Give me a few days to iron it out. In the mean time, send 24 sets instead of 26. That seems to work reliably for me. |
|
Give version v1.2.0 a shot. I've updated the code to be more reliable but with my latest experimentation, the NVRAM on the device can only hold 23 sets so make sure you use |
|
Will try it out now. Thank you kindly for your efforts! |
|
No errors, worked fine - after pip installing pre_commit, which apparently wasn't a dependency previously. |
|
pre_commit? Hmmm. I wonder how that get in there. |
|
I'll check the new release, but for some reason I'm getting an assortment of odd errors now. I'll report back if the new update doesn't mitigate that. |
|
(posting this but see next post as I dug deeper) Nope, no change. running my script, unchanged from above except using 23 sets as recommended - and with debug turned on - the output now is: |
|
After the results above, I ran gpsinit -f /etc/gpsinit_time.conf. I forgot to add the speed, and got the following output: So I then ran it properly with correct speed, and of course it had to renogiate with the chip: I've gotten those failed ack's so often, even when things appeared to be working fine, i gradually just ignored them. I think that is still generally the case - they're spurious, but maybe I'm wrong. Here's the output from the update-epo script now - but first to be sure I didn't bork something, here's the script in its current state, which should be fine: And the output (and I know I left the coordinates in, even though I was eliding them previously. Paranoia can become annoying!) The telltale wtf should be obvious - sets to 2035. So, I tried sending just two sets. That got a successful 'verified'. Sent 22 sets; 'verified'. 23, failed. various iterations up to the full 120 sets, all failed. I ran a gpsinit -f /usr/local/bin/gpsinit_reset.conf -s 115200 /dev/gpsd0, (which still sends 26 sets by default, btw) - but that failed to fix it either, even after setting the default within epoloader to 23. I ran into this once before, with the way out-of-bounds sets in nvram. I have a feeling the only fix is for me to shut down the Pi, disassemble the case, and take out the backup battery so that it loses everything. Sigh. It's a beautiful clear case made of stacks of carefully cut acrylic, which is a massive pain to pull apart. At this point, I dont think it's anything at all to do with your code, it's just some sort of corruption the chip is prone to. Whee! |
|
Dang. Battery pulled, waited a bit, battery restored, boot and get system sorted out with a reasonable time, gpsinit_reset, run update-epo script with 23 sets - same failure, same bad ending date - I'm lost at this point. Very very minor typo run across in eporetrieve, next to last line: Although I kind of like checkdum. |
|
sigh. I'm just not sure where to go next. The MT3339 was not originally designed to use EPO-II files and I think the firmware update that allowed it to use them wasn't quite fully tested. You can see evidence of this in the PMTK707 response message... Anyway... I just downloaded a new EPO.DAT and it has the same start and end dates as the one you just tested. Guess what? It fails for me as well. However if I do 22 sets, it works fine. The one from 2 days ago that starts at 2023-01-20-23:59:49 works fine at 23. I'm going to have to collect a few days of files to see if I can find a pattern. I'll also see if there's some other source of EPO data I can use. |
|
This issue is almost comical! Yeah, wouldn't surprise me if it's a faulty firmware update that leaves potentially corrupt data behind sometimes. It's interesting that your downloaded EPO doesn't work either - it couldn't be a bad epo that MTK has generated?? Anyway - really appreciate your efforts. For now I've swapped in place my backup Pi which has a ublox hat. It keeps decent time, just not quite as good as the Adafruit board. While further poking around I noticed that Adafruit swapped the chip on their Ultimate GPS hat to one using the MT3333 - aparrently the MT3339 is discontinued. |
|
Just ran update, 22 sets, worked fine. Really makes me think maybe it's a problem with MTK's files... |
|
I'm surprised the ublox isn't better. I now use the F9Z which is expensive but even the Neo- M9 was better than the MTK device. The MT3333 (which works no better than the 3339 BTW) I thought was also discontinued. Maybe there's just more stock left Anyway, I've downloaded a bunch of sets, some from MT and some from Garmin and they have exactly the same data in them so I think Garmin gets them from MT. The interesting thing is that for the same file, I can get 22, 23, 24, 25 or 26 good sets loaded depending on where I start in the file. I'm wondering if it has to do with where the GPS week changes over in the sequence. When I've got a few more files, I'm going to let a test run with all the combinations of starting set and set count and see what happens. |
|
In my case it's a ublox Neo M8T, on a HAT built by...some tiny drone company on ebay that I bought a couple from a few years ago, and which no longer sells anything. It's not bad per se - But the time jitter on the Adafruit is in nanoseconds rather than microseconds. It's also entirely possible it's just something with that particular Raspberry Pi's host hardware. |
I keep getting this error, but I can't figure out why. Sometimes, just 'pushing' one or two fewer EPO sets will get it to go through cleanly. But run from cron daily, this happens frequently, and limits the utility of doing so in an automated fashion.
I call epoloader from a simple shell wrapper. The issue happens whether via cron or direct on command line. Here's the wrapper. I've also slightly modified eporetrieve to write to /var/tmp rather than /tmp.
#!/bin/bashLAT="xxxxx"LON="-xxxxx"ALT="41"SPEED="115200"DEV="/dev/gpsd0"FILE="/var/tmp/EPO.DAT"MAXSETS="26"nice /usr/local/bin/eporetrieve/bin/systemctl stop gpsdstty -F ${DEV} raw 115200 cs8 clocal -cstopbnice /usr/local/bin/gpssend clear_epo ${DEV}nice /usr/local/bin/epoloader -s ${SPEED} --no-init -k --max-sets=${MAXSETS} -l=${LAT},${LON},${ALT} -t- ${FILE} ${DEV}/bin/systemctl start gpsdI changed the '-l' instantiation to '-l=' having just read the other issue that's up here. No change. I used the 'gpssend clear_epo' as a separate command just for my own clarity; results are no different if I declare it on the epoloader command line.
I would entertain the idea that I'm doing something wrong - although the fact it works fine sometimes seems to suggest otherwise. Oh, and I run the job at 18:03 PST, which is 02:03 UTC, which I presume is early enough in the day to not be a problem.
Here's the full output of the script:
root@ B-NTPsec: ~ # update-epo
EPO data saved to /var/tmp/EPO.DAT
Opening EPO Type II file with 120 sets
GPS Version: ['PMTK705', 'AXN_2.31_3339_13101700', '5632', 'PA6H', '1.0']
Setting known values: xxxx,-xxxx,41 2023,01,17,02,56,50
Time set
Location set
Setting binary mode, speed: 115200
Sending 26 EPO sets of 120
Sending set 1. Valid from 2023-01-16 23:59:46 UTC
Sending set 2. Valid from 2023-01-17 05:59:46 UTC
Sending set 3. Valid from 2023-01-17 11:59:46 UTC
Sending set 4. Valid from 2023-01-17 17:59:46 UTC
Sending set 5. Valid from 2023-01-17 23:59:46 UTC
Sending set 6. Valid from 2023-01-18 05:59:46 UTC
Sending set 7. Valid from 2023-01-18 11:59:46 UTC
Sending set 8. Valid from 2023-01-18 17:59:46 UTC
Sending set 9. Valid from 2023-01-18 23:59:46 UTC
Sending set 10. Valid from 2023-01-19 05:59:46 UTC
Sending set 11. Valid from 2023-01-19 11:59:46 UTC
Sending set 12. Valid from 2023-01-19 17:59:46 UTC
Sending set 13. Valid from 2023-01-19 23:59:46 UTC
Sending set 14. Valid from 2023-01-20 05:59:46 UTC
Sending set 15. Valid from 2023-01-20 11:59:46 UTC
Sending set 16. Valid from 2023-01-20 17:59:46 UTC
Sending set 17. Valid from 2023-01-20 23:59:46 UTC
Sending set 18. Valid from 2023-01-21 05:59:46 UTC
Sending set 19. Valid from 2023-01-21 11:59:46 UTC
Sending set 20. Valid from 2023-01-21 17:59:46 UTC
Sending set 21. Valid from 2023-01-21 23:59:46 UTC
Sending set 22. Valid from 2023-01-22 05:59:46 UTC
Sending set 23. Valid from 2023-01-22 11:59:46 UTC
Sending set 24. Valid from 2023-01-22 17:59:46 UTC
Sending set 25. Valid from 2023-01-22 23:59:46 UTC
Sending set 26. Valid from 2023-01-23 05:59:46 UTC
26 sets sent. Valid from 2023-01-16 23:59:46 to 2023-01-23 11:59:46 UTC
ERROR: EPO in NVRAM doesnt match file
In NVRAM: 2023-01-16 23:59:46 to 2023-01-22 17:59:46 UTC
root@ B-NTPsec: ~ #
Any help would be appreciated, I'm stumped.
The text was updated successfully, but these errors were encountered: