System time issues for uBlox 9 protocol (ZED-F9P)

I have some success using the ZED-F9P (Both ArduSimple and CSG shop module) for RTK navigation. However, I found that with ZED-F9P the ArduCopter no longer have the correct timestamp. Timestamp shows 1980 January for all the mission with the ZED-F9P module.

I found that, the time of the week is missing and cause this issue. Upon further investigation and some digging in the ArduCopter code, I found that in ardupilot/libraries/AP_GPS/AP_GPS_UBLOX.cpp the time_week get from the UBX-NAV-SOL message. Then, the time_week and time_week_ms was used to covert into the system time in AP_GPS. However, based on this document, the ZED-F9P is using UBX version 27.10 protocol (uBlox 9). In this new version of the protocol, the UBX-NAV-SOL is no longer generated with the module. I could not really find another source of week number in NAV group. Seems like uBlox finally did away with NAV-SOL message. Will uBlox 9 be supported for future version of the ArduPilot?

Currently, I am thinking about the work around. Since UBX-NAV-PVT provide UTC time in yyyy/mm/dd/h/m/s and time accuracy estimate in nano second, we can use the UTC time to calculate the week number and pass it to the time_week.

@WickedShell this one might be for you

@tommyma1617
Glad you have managed to get some results from this. Does this date issue prevent the use of the Zed for RTK nav?

Have you seen the Drotek module? Looks a bit more compact than the Ardu-simple. Tempted to try it but wanted to know if the Zed is actually supported in Ardupilot.

No at all. The navigation part works great. The navigation part of the ZED-F9P works great! ArduPilot is using the UBX-NAV-PVT for the navigation anyway. If you have the control system tune properly, the landing precision/position holding is pretty good. I have some operation depends on the high accuracy timestamp that provided by the GPS. Thus the system time is important to us. Just in term of the RTK navigation, ZED-F9P is pretty great.

I did not try the Drotek module myself. However, I would imagine it should not make any different. The ZED-F9P is very compact module. All the board does is bring out the interface for different form factor. ArduSimple is kinda big is due to they have build-in xBee interface. You can “saw” the board in half it would still work fine. It seems now that beside the not have UBX-NAV-SOL, uBlox 9 (the one ZED use) is pretty similar to the older version uBlox protocol (ArduPilot based on).

How’s your F9P configured for 5Hz RTK ? I couldn’t manage 5Hz using more then GPS + Glonass, and for 10 Hz I had to drop to GPS-only.
I had a pair of Ardusimples to test, and the more I looked at specs versus results, the more I started to question my driver. I tried a couple of driver changes but it only made matters worse

I have no problem using 5HZ RTK with GPS+Glonass+Galileo+Beidou when it is on the drone. I used the ArduCopter auto configure that has update rate 200 ms, Airborn4G navfilter. With in the GPS, I choose to use all constellation. What problem do you run into? When test on computer, I used the default windows driver. I also used it as Ntrip client/server using raspberry pi and it works fine with both USB and UART.

If someone is adding code to update to the newer uBlox protocol, is it possible they could looks at adding RELPOSNED message handling to get heading and baseline length? Really would love to see support for this setup https://www.ardusimple.com/product/simplertk2b-heading-basic-starter-kit-ip67/

Ardupilot master now supports F9P auto configuration. So plug-n-play is now possible.

There are so many interesting things in 3.7. Any idea on when a first beta will be out?

Awesome, great work!

Just posted this that might be pertinent : New uBlox F9 GPS test & quick comparison to M8 series