I’ve tried most everything. I’ve tried the basic UART2 confirming the base prt was set to send and the rover to receive with the physical cable going from tx to rx. All the I2R, UART, USB are all checked for 1005-12xx. I’ve tried to send it from and to UART1. I’ve changed the rover and base. I’ve reset and reloaded all the variables (mind numbing). I even have a GPIO bridge where I can see all the messages coming in and I send them to the USB port… Nothing.
Is there some weird setting somewhere that doesn’t allow receive? What am I missing. I know it’s an easy fix but I cannot find it.
Something with a u-blox ZED-F9P, or something else? Which boards?
In your direct wired mode, common ground?
Reporting via UBX-MON-MSGPP, RXM-RTCM ?
Create a log (record button), on the ROVER allowing it to collect the configuration settings, attach.
Ok - I’ve got a bunch of meetings today. I’ll get it to you late or tomorrow. Yes Zed-F9P. Yes RXM-RTCM. The strange thing is it was working a couple of months ago. I went to work on different parts of the project and it quit. Baffled. Thank you and I’ll get more info quickly.
COM4___9600_250308_182109.txt (1.2 MB)
I had to change it to .txt to upload. This is the .ubx file of the rover. I use a saved rover file to start. Then I add all the RTCM messages (some are missed in the upload).
I also noticed today looking at the GPIO that yes I’m getting a lot of messages but I’m not getting any 1005 messages. That may be the primary issue:
— 10 seconds RTCM Statistics —
RTCM messages detected: 465
Message types:
Type 1074: 50 messages
Type 1077: 50 messages
Type 1084: 50 messages
Type 1087: 50 messages
Type 1094: 49 messages
Type 1097: 49 messages
Type 1124: 50 messages
Type 1127: 50 messages
Type 1230: 67 messages
1005 will only come out in TIME mode, where either Survey-In has completed or you’ve programmed in a static location.
It won’t report this mode via NMEA, so check UBX-NAV-PVT
Decide if using MSM 4 or MSM 7 messages, you don’t need both.
RTCM3 message output isn’t needed on the Rover. RTCM3 input should be enabled in all interfaces by default.
Thanks - that solved it. Kindof. I have a moving base but it thinks it is a fixed base. I think it is sending corrections that make it look like I’m not moving. How do I configure it as a moving base instead? I don’t see the configuration parameter in TMODE 3. Thanks all!!!
For Moving Base, you disable TMODE3, and instead output 4072.0 message, this replaces 1005, and provides a PVT / COV for the motion, or not, of the Base position
TMODE3=Fixed, locks the output position reporting, if the solution shows it’s moving you’ll get a NOFIX instead of TIME, and 1005 will be disabled/gated
ok - I’ve disabled TMODE3 and enabled 4027.0 messages. I expected to get an accurate dual-gps heading but instead I’m seeing swings from 275 - 335 when my rover is stationary. Is there something I’ve missed? When I was in RTK my heading was within a degree (or better).
Well I’m not intimately familiar with your implementation.
Is this distance between the antenna’s fixed? Greater than 1m?
What sort of antenna configuration, orientation, ground-planes?
Satellite counts?
Heading will come from the secondary unit.
The only caveat is that it doesn’t work at a refresh higher than once per second. If I set it to 5hz (rover and/or base) it quits working. Any thoughts?
Antenna’s are 1 m apart. they are magnetic and on a metal base. (flat, large).
You need to establish what specifically is “not working”
Losing messages? Bandwidth issues?
For Moving Base they want consistent settings between both units, ie both 5 Hz
Baud rates of 38400 should be ok, 115200 or 230400 might be better
When I’m in 1hz, you can see the rtx light blink (RTK Float) and go off (RTK Fixed). However, as soon as I change them to 5hz, no blinking. No RTK. Just stuck in DGNS mode. I’m using the 1074 groups not the 1077.
Ok, so the MSM4 ones, ie 1074, 1084, 1094…
along with 4072.0 and 1230
Check they are being received on the second device using UBX-RXM-RTCM/COR
Check the actual receiver state via UBX-NAV-PVT/RELPOSNED rather than rely on the LED
Which unit is the primary? And which the secondary?
The Secondary needs to be getting the 4072.0, and should be getting the UBX-NAV-RELPOSNED
The Secondary being feed just the RTCM3 data, no NMEA, no UBX
---UBX-----------------------------------------------------------------------
01 3C NAV-RELPOSNED - 66 D3 : 66 D3 48
NAV-RELPOSNED 487036400 1 0 0 1769406464 0
-24 70 21 77 10902544
-25 32 38 39
100 54118 0 4259840 2162688
Differential Corrections Applied
Relative Position Components Valid
Is Moving
Reference Position Missing
Float Solution
-24.2500 70.3200 21.3800 NED cm (ACC: 425.98 m)
Heading Invalid
77.3900 BASELINE cm
77.3955 109.026862 (calc) (ACC: 5.41 m)
-----------------------------------------------------------------------------
Diagram your system so I have some idea what you’ve built. Show the data / message flows that you’ve implemented, and where you’re taking the positioning data.
Here are some illustrations of my thoughts on this
I would NOT recommend 10 Hz operation. I’d suggest starting with 5 Hz for both units, in the solution rate, and RTCM3 message outputs.
You might be able to get 8 Hz, but you’re getting awfully close to the computational bandwidth of the ZED-F9P’s and it will just drop more epochs if it overloads. The two units will not fully synchronize, they will align close to top-of-second, but expect some ebb-n-flow as to which reports first.
You get first-order positioning solution from the Primary unit, and orientation from the Secondary wrt the Primary
