We are working with a base /moving base/rover configuration as follow:
- simpleRTK2B (using ZED-F9P, used as “heading” board) –> srtk2b+heading_rover_F9P_FW_HPG112.txt
- simpleRTK2Blite (using ZED-F9P, used as moving base and rover) –>srtk2b+heading_lite_movingbase_FW_HPG112.txt
- XBee Long-Range
We are observing a lot of jumps and we are debuging all the messages involved to try to figure out the reason:
- UBX-NAV-PVT, flags: carrSoln: to ckeck changes from fixed to float and to no carried phase resolution
- UBX-NAV-RELPOSNED, flags: refPosMiss (RTCM 4072 message), refObsMiss: to check if extrapolated reference are used to computed moving base solution
We observed some of these issues but, there are much more jumpings in the gps than the corresponding to the issues. We have observed how the accuracy of the gps gets worse without any of the occurences of these messages (from fixed to float or to no carried phase resolution and without missing of the 4072 messages).
The antennas have their corresponding ground plates.
We have review the documentation, but, are there any other messages that give more information about the potential problems?
Did you change anything on the default configuration files? E.g. navigation rate, baudrate of serial port, number of messages enabled, etc?
Yes we change the configuration (navigation rate and baudrate) in February when Ardusimple techniciams came to our faciltiyes. They validated these changes and there was not lost of message. We collected data last March and the accuracy of the gps data was very good, but withouth changing anything from that date, the gps data collected last 11th May showed a lot of jumps in the gps postion. We checked the configuration and everything seemed fine. For this reason we started to debug the messages mentioned in the previous post and the jumps not always correspond to the occurence of the issues. I could upload some images with plotted gps position if you need them.
Plots help identify there is an issue, don’t really convey enough detail to understand the interactions between the base, rover(s), comms links and antennas, etc.
UBX-RXM-RTCM would report on message integrity
Probably want to decompose issues here, starting with the quality of data generated at the Base, performance of the Primary Rover, and then of the Secondary Rover (Heading) unit. Identify what links in the chain are losing or corrupting data.
Would recommend 5 Hz operation
Hi, thanks for your answer. We use a 5Hz operation. I assume you are referring to the crcFailed bit on the flags field of UBX-RXM-RTCM. I am going to check it.
That, and quantifying how many messages were just completely missing, having missed the preamble/sync, etc.
I have checked that there was not any message missed nor crc fail.