Do Type II EPO files work with the MT3339?

[quantumaardvark]

First: Thank you for your excellent utilities... they are immensely helpful.

Second: There appears to be an ambiguity in the README, and it leads me to be unsure of how well the EPO assist is working. The text says the MT3339 requires original EPO files - not EPO-II. And yet the example given (indeed, the file fetched) is shown by epoinfo to be Type 2. I download the file in the way you show it and use -m 26 to restrict epoloader to use 26 sets. There is definitely an improvment, but is that simply because the current time is correct because it is set along along the way of using your tools?

After uploading 26 sets in this way, epoloader says it can't verify the uploaded sets and then leaves the MT3339 in a state where it no longer communicates at any baud rate unless I cycle the power to the MT3339 (in a GlobalTop u2p). Reset does not always recover it from this state. I'm using a Raspberry Pi and I've read the other issues posted about that, but I don't think that is what is going on here.

Thanks for your help.

[gtjoseph]

It is EPO II. I think I just forgot to update the README. Exactly what is the error message? If it's "ERROR: EPO in NVRAM couldn't be verified" it's because epoloader lost communications with the GPS. If it's "ERROR: EPO in NVRAM doesnt match file" then that's because there are too many epo sets. I suspect the former since you're using the -m 26 option.

If that's the case, it sounds like a baud rate mismatch or some other communications issue. Can you run gpsinit and gpsstatus reliably?

[quantumaardvark]

Thank you so for such a prompt reply. The error message is "ERROR: EPO in NVRAM couldn't be verified". Curious because it got as far as actually doing the transfers.

When it gets into this state, neither gpsinit nor gpsstatus work. After a reset, a clue may be in what gpsinit has to say sometimes:

Setting NMEA at 57600 baud. No response. Seeing if it's in binary mode. Apparently not. Failed. Setting NMEA at 115200 baud. Unit is currently in NMEA mode at 115200 baud. Found unit at 115200 baud. Attempting to set it to 9600 baud GPS and port are now synchronized at 9600 0 ['PMTK001', '314', '3'

Note how it says 'Found unit at 115200 baud. Attempting to set it to 9600 baud'. As 115200 was the target, that sounds odd! Most often though it runs through all the combinations and does not find any match unless the receiver is reset after a failed attempt, when it then (mostly) works. It can take more than one attempt, as above. Once it has synced, I never get a 'transfer failed' message. or a 'final transfer failed'. So it feels like this is the boundary between binary and NMEA modes.

[gtjoseph]

Try using fewer EPO sets, maybe just 13: -m 13. Also try setting -s to the speed you normally run at so the code doesn't have to go through the search.

[quantumaardvark]

Many thanks. I've tried your suggestions.

Setting 9600 makes no difference. Gpsstatus starts with 9600 and despite it being already in that state, can't find it, even after several attempts. However, after a hardware reset gpsinit works straight away and after that gpsstatus works as expected.

Using just 13 EPO sets does, I think make an improvment in performance, if not in serial comms! This would appear to solve the 'performance not being as good as expected' problem.

All said and done, a couple of resets and using 9600 baud seems to be the pragmatic recipe. Even then gpsstatus only starts after it assumes it's presently in binary mode. Judging by other people's experiences of the serial comms, there seems to be some 'secret sauce' we are collectively unaware of about the MT3339 serial port and mode switching.

Finally, the MT3339 still seems to be having problems: the attached screenshot shows sufficient satellites with a good SNR yet despite the EPO (2) file, 615 seconds after starting, still no fix!!! Can't blame that on the serial comms, though!

Again... many thanks!

[gtjoseph]

Sorry for the late reply, I missed the notification last week. The MT3339 was a great unit in its day but it's getting a little long in the tooth. Having said that, it's cheap and (usually) works well. I've got some time next week to do a retest on an RPi and refactor so maybe I can figure out what's going on.

What hat/carrier is the gps mounted on? How is it powered? Are you using an external antenna? Which pins on the Pi are used for the UART? Are you using the PPS signal? If so, what pin is it connected to? Does the Pi have an RTC connected?

[quantumaardvark]

Indeed, the MT3339 is a useful device. To answer your questions:

• It is mounted on a custom circuit board with a passive antenna and full ground plane. The ceramic patch feed point is within 2mm of the receiver antenna input. It is still engineered as a 50-ohm line.
• It is powered by a well-filtered 3.3V feed with decade-spaced capacitors.
• The connection is via a flat, flexible cable going via a break-out board to the RPi. VCC noise is in the order of 20 to 50mV.
• I'm not using the PPS signal.
• The GTOP u2p has an integral RTC. Its backup battery is fully charged and has the correct voltage. The RPi does not have an RTC but when powered (which it always is) gets standard NTP time.
• The RPi serial port is the 'mini' serial port which is at risk of transient baud rate inaccuracies. But with that said, I've never seen it fail during EPO upload.

If it helps, I've also seen it fail to set the default messages (PMTK314) - about 5% of attempts - despite having established the correct baud rate, but not after having done a hardware reset.

[cjmair]

I came across the same problem with epoloader. I found that it doesn't seem to be coming out of binary mode, after sending the EPO sets. I traced this to code in the set_nmea function. I found if I made the following change, it could come out of binary and the load completed ok.

144 fg.flushOutput() change to 144 fg.flush()

I used gpsinit to send the command PMTK253,1,9600 which created the fault seen and gpsinit didn't seem to be able to fix it. There was a similar fg.flushOuput() in it's set_nmea function and changing that to fg.flush() also allowed gpsinit to recover from binary mode.