I have today received my RTK facet, to compliment my RTK Express that I have been testing recently. A couple of scenarios come to mind that I would like to try out with these receivers:
The first is to get heading output using a fixed baseline (with the two receivers). I believe reading the Moving Base App Note that this is easily configured by connecting up the UARTs, but can I do this with these kits (can I just connect up the USB-C ports to the UBlox together)?
Another scenario is relative GPS, as in the calculation of a range and bearing between the two (uncorrected) receiver positions. The usage case for this would be with the ‘base’ on a moving ship. and the ‘rover’ on a buoy towed behind the ship. I believe this also falls into the Moving Base parameters, though I’ve not seen any tutorials on how this can be done with two ZED-F9P’s (and radios).
Any help would be much appreciated.
Yes, if I’m understanding the scenario correctly you can transmit from one unit’s UART/serial to the other, and connect that one to U-blox via usb-c and pass whichever messages you’d like through to u-blox
Perhaps someone with experience using the Moving Base Mode can offer an example - I’ll also poke around and see what I can find
Thanks for getting back to me. I guess with these kits it would be easy to hook the ‘data’ port to the other ‘data’ port just flipping the RX/TX. I did find this link for heading output: https://docs.px4.io/master/en/gps_compa … ading.html
I did some research and after testing in normal RTK surveyed in base (Facet), and RTK rover (Surveyor) with RTCM over radios, after connecting to the latter with U-centre 2 could see UBX-NAV-RELPOSNED coming in without any additional changes required.
Of course this is in a static mode, so still need to work out how to get it into moving baseline mode. I’m assuming that the rover is taking the position from the broadcast RTCM and then calculating the relative position and heading. Not sure what would happen if base was ‘moving’ as presumably it wouldn’t broadcast RTCM if it had not completed the ‘survey in’.
I might just pick up two C099-F9P-1 boards as these work out of the box, and the configs for both rover and moving base are published online.
Hi, I have successfully programmed a set of 3 RTK Expresses to run as Static Base, Moving Base, and Rover, it’s a little bit fiddly because the firmware in the RTK Express fights your manual configuration of the desired sentences, but my process was the following:
-
I created a spliced connection on the Radio port of my moving base Express. I run the RX line to the TX line of a telemetry radio to receive RTCM correction from my static base. I then run my TX line from the radio port of to the RX line of the radio port on my rover. This enables me to use UART2 on the moving base to both receive RTCM correction from the static base, and send moving base RTCM correction to the rover.
-
On the moving base, I typically had the best luck powering it on as a rover instead of a base. I think this is because of the survey-in process it tried to do as a base, but I could be mistaken (I’m in the process of digging in to the firmware right now). I then used U-center 2 to manually program UART 2 to output the desired RTCM sentences 1074,1084,1094,1124, and 1230.
-
My rover I ran as a standard rover via the RTK Express firmware, but I configured UART 1 (via U-center 2) to output NAV_RELPOSNED and RXM_RTCM. RXM_RTCM is not required, but it provided a convenient way to monitor via U-center if I was actually getting all the desired correction sentences rom my moving base.
Hope this helps!
Many thanks for this, makes total sense. I will give it a try. My end game is to try and use two units on a fixed baseline and generate an accurate heading (I’m hoping better than 0.05 degrees). However, I do have a requirement for relative tracking as well.
In your example, how do you stop the real rover from being corrected by the radio RTCM from your static base? I would like to generate two relative distance/bearings from two sets of units (two bases and two rovers), but not sure how each rover would differentiate the unique radio RTCM? I did see in the NAV_RELPOSNED string that there is an ID field, but not sure if this can be defined…
Today I looked to see what the units were configured to in each mode:
Facet in Rover mode:
CFG-MSGOUT
NMEA_ID_GGA_UART1 1
NMEA_ID_GGA_USB 1
NMEA_ID_GLL_USB 1
NMEA_ID_GSA_UART1 1
NMEA_ID_GSA_USB 1
NMEA_ID_GST_UART1 1
NMEA_ID_GSV_UART1 4
NMEA_ID_GSV_USB 1
NMEA_ID_RMC_UART1 1
NMEA_ID_RMC_USB 1
NMEA_ID_VTG_USB 1
UBX_NAV_HPPOSLLH_I2C 1
UBX_NAV_PVT_I2C 1
UBX_TIM_TM2_I2C 1
Facet in Base mode:
CFG-MSGOUT
NMEA_ID_GGA_UART1 1
NMEA_ID_GGA_USB 1
NMEA_ID_GLL_USB 1
NMEA_ID_GSA_UART1 1
NMEA_ID_GSA_USB 1
NMEA_ID_GST_UART1 1
NMEA_ID_GSV_UART1 4
NMEA_ID_GSV_USB 1
NMEA_ID_RMC_UART1 1
NMEA_ID_RMC_USB 1
NMEA_ID_VTG_USB 1
RTCM_3X_TYPE1005_I2C 1
RTCM_3X_TYPE1005_UART1 1
RTCM_3X_TYPE1005_UART2 1
RTCM_3X_TYPE1005_USB 1
RTCM_3X_TYPE1074_I2C 1
RTCM_3X_TYPE1074_UART1 1
RTCM_3X_TYPE1074_UART2 1
RTCM_3X_TYPE1074_USB 1
RTCM_3X_TYPE1084_I2C 1
RTCM_3X_TYPE1084_UART1 1
RTCM_3X_TYPE1084_UART2 1
RTCM_3X_TYPE1084_USB 1
RTCM_3X_TYPE1094_I2C 1
RTCM_3X_TYPE1094_UART1 1
RTCM_3X_TYPE1094_UART2 1
RTCM_3X_TYPE1094_USB 1
RTCM_3X_TYPE1124_I2C 1
RTCM_3X_TYPE1124_UART1 1
RTCM_3X_TYPE1124_UART2 1
RTCM_3X_TYPE1124_USB 1
RTCM_3X_TYPE1230_I2C 10
RTCM_3X_TYPE1230_UART1 10
RTCM_3X_TYPE1230_UART2 10
RTCM_3X_TYPE1230_USB 10
UBX_NAV_HPPOSLLH_I2C 1
UBX_NAV_PVT_I2C 1
UBX_TIM_TM2_I2C 1
So basically, I put my RTK Facet in Rover mode and then turned on all the RTCM outputs that were enabled when in Base mode (using U-Center 2). Whilst I could see TX/RX on the radios, the RTK Express in Rover mode did not converge (and there was no indication it was receiving RTCM), and the RTK Facet didn’t at any time imply it was transmitting RTCM (but would it in Rover mode…?)
Reading the moving baseline application notes it states that no NMEA should be transmitted, so I turned all these off in the RTK Facet also (again in U-Centre 2). But that made no difference. I’m stabbing in the dark a bit now…