Hi,
I have ZED-F9P-00B-02 integrated into our system.
I have observed that sporadically CARR_SOLN will drop from 2 to 0 and won’t go back to 2 for over an hour. Wi-Fi is stable and there are no packet lost. Happens on multiple machines and multiple locations. The sky is clear and GPS signal is fixed when that issue happens.
Did anyone else observe such behavior and has an idea what can cause that?
What version of firmware are you running? I for sure wouldn’t be running anything earlier than HPG 1.13. Ideally we’d be at HPG 1.32
.. for over an hour
This would kind of suggest the source of your data is not helpful. Start by making sure your base is providing solid data. Realistically around 8 satellites per constellation, measurements from both bands, probably 30 satellites total. Does it recover quickly if you reset the Rover? Do multiple Rovers fail at the same time?
Happens on multiple machines and multiple locations.
Perhaps consistency in process/methods? Can you manifest the issue with a wired serial connection? With RTCM3/NTRIP from reliable / authoritative sources?
.. no packet lost
This can be good and bad. Using TCP/IP can hide issues, there’s no value to moving old/stale data. Fresh data will always trump retrying old data. Examine more critically what you’re receiving.
Hi Clive,
Thank you for your response.
I’m running with HPG 1.13.
When this issue happens - other rovers in the same area not necessary show same behavior when connected to the same base station.
This issue happens with both our own base stations and geodnet service.
The rover is connecting to the internet over dedicated starlink with clear sky.
Another strange observation that sometimes it takes the rover 40 minutes to get carr_soln 2 after restart when in most cases it takes under 1 minute.
I hope it gives more information.
HPG 1.13 has occasional issues where it will go to/from RTK FIXED to NO FIX, for a couple of epochs. ie second or less, this was addressed in 1.32 and even more so in 1.51
From a cold-start I can get to RTK FIXED in about 50-55 seconds, taking many minutes, either the rover view of the satellites is bad/poor, if multiple rovers are impacted, I’d tend to worry more about the base.
If a rover gets bad timing, it can be very hard to break it of that, going backward in time being especially hard. There you might have to cold start clearing time, location, ephemeris data.
RTK uses satellites the base and rover have a common view of, so that can be limiting.
In uCenter Classic I might look at Sky View plot to understand what the Rover can see, and what portions of the sky.
Starlink probably has excessive latency, you really want the data within the current second or two. You might want to look at Point-Perfect / SPARTN data, as this is more of a model, which can give you minutes. Or more localized Base within the range of WiFi / LoRa or other sub-GHz short range radios.
I will try to upgrade to 1.51 unless you think that 1.32 is more stable.
Regarding a cold start - it is not a cold start per say. The rover is under clear skies and I get both gps and rkt fixed. I restart that process (same base station and rover is idle) and sometimes it now takes up to 40 minutes to get to carr_soln fixed but in 95% of the cases it takes, as you mentioned, 50-55 seconds. From my observation this behavior is not location, rover or base station dependent.
@clive1 Another question.
Is there a way to upgrade FW from Jetson Linux without taking the entire assembly apart?
Yeah, I’m not sure exactly what you’ve built, or the accessibility that provides you. Say access to a UART or USB, or if you can port-forward a serial connection over a network link.
uCenter Classic might be able to facilitate that as a connection method.
I did work with @PaulZC on some firmware update code, but that might be for the Facet rather than Linux.
It is connected via USB to UART. As result of that stm32flash can’t be used since it doesn’t go into boot loader mode without manual step on the module itself.
I will use u-center to manually upgrade FW and see if that resolves the issue.
With Clive’s help, we did write some Python code to upgrade the ZED-F9P. It works well on Mac / Linux. But unfortunately it contains information shared by u-blox under NDA. We asked u-blox for permission to share the code openly, but they went quiet on us. Hopefully you can do the upgrade using u-center.
Best wishes,
Paul