Ardupilot: Incorrect NMEA GPS time & week decoding

[yanivasy]

While using external GPS with NMEA messages (GGA& RMC), the time and date given by the GPS is correct.

However, by logging the data (using the cube black) and extracting it (using mission planner), it seems that both the week number is incorrect (2003 is of last week instead of 2004 which is the current week) and the in by the time since the beginning of the week (in millisecond) even the day number is incorrect (3 days difference).

On the same GPS, I've changed the GPS output to SBF (and of course the GPS type to '10') and now the cube recorder GPS week and time are correct.
I've tried another manufacture GPS which also output NMEA and the same incorrect week and time was given by analyzing the log file
I've even updated the firmware to 4.0.3 and the MP to the latest- but the same difference in week and time consisted when using NMEA GPSs.

Version 4.0.3
Platform [ ] Copter
Airframe type hex,
Hardware type Cube,.

[WickedShell]

I'll try and reproduce this some time soon, but it will be a bit before I get there. As a side note NMEA is the worst protocol to select because it doesn't provide us with some of the information we'd like to have for the EKF. If you have a GPS that speaks the SBF protocol, then you should be using that instead, as our driver for that is much better then the NMEA one.

[yanivasy]

Thanks @WickedShell

As far as I know, only Septentrio's GPS recivers have the ability to generate SBF protocols whereas all GPS receivers I came across have build in NMEA protocol and therefore NMEA is a much widely used protocol.
For example, in the case of a Novatel's GPS receivers, I haven't found any other supported protocol beside NMEA. Am I wrong?
For that reason I was pretty supersized that such error/bug wasn't reviled by now.

[WickedShell]

Yes, but the SBF protocol tells us more information then we are extracting from the NMEA protocol, and gives it to us faster (with less lag) and lets us ensure all the required fields are being sent to us. The net effect is a higher performance. We do actually support the Novatel protocol directly (it's the NOVA one in the list of GPS types).

As an example of a critical missing piece of data, we care about the horizontal, vertical, speed accuracy which we don't get out of the NMEA drivers, but we really care about getting the vertical velocity out of the GPS, which we don't have in the NMEA support (and I haven't found the field in the actual NMEA spec anywhere, just vendor specific extensions).

You will also find that while all GPS's may support NMEA, their support for their own protocol is almost always better, and in the ArduPilot use case I'd be surprised to see the NMEA protocol be more common then any of the binary protocols for a given brand of receiver. To reiterate: using NMEA is basically the worst choice you have, and is a last ditch fallback.

[yanivasy]

I think this issue came up because of the GPS week rollover that took place on April 6, 2019.

https://www.gps.gov/support/user/rollover/

Maybe this will help fixing the bug.

[yanivasy]

I'll try and reproduce this some time soon, but it will be a bit before I get there. As a side note NMEA is the worst protocol to select because it doesn't provide us with some of the information we'd like to have for the EKF. If you have a GPS that speaks the SBF protocol, then you should be using that instead, as our driver for that is much better then the NMEA one.
@WickedShell , have you found the time check to it?

[WickedShell]

@yanivasy no, sorry. As a note I missed earlier we do support novatel's proprietary protocol, it's type 15 (NOVA) in the ArduPilot docs.

[peterbarker]

I think e529d475d4c3377180789dc4fd43e7cf71f08b9f might have fixed this one on master.

@yanivasy are you able to test master to see if it suffers from the same problem you were seeing?