Struggling with receiving RTCM messages!

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.

Thank you in advance.
Jay

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

Why? I have 1005 turned on.
Jay

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!!!

Jay

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.

It is working! Thank you clive1.

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).

jay

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

Apologies for not being more clear.

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.

Jay

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

I was able to get the 4072.0 corrections by adding UBX to my UART2 output on the base. I’m now getting a relative rtk fix pretty quickly.

=== DIRECT SERIAL GPS MONITOR === [Arrow keys to drive, Space to stop] 11:15:50

MOTORS: STOPPED at 0.00 - Turning: STRAIGHT
Left: 0.00 Right: 0.00
[Space=STOP] [c=Center] [p=Save Waypoint] [Arrow keys=Drive]

Front GPS: 113.9 msg/sec | Rear GPS: 267.4 msg/sec
Front GPS: FIX (Quality: 1) Rear GPS: FIX (Quality: 4) [RTK FIXED] :green_circle:

Front Position: 34.1519337, -77.8668625
Rear Position: 34.1519315, -77.8668552

Front GPS Heading: N/A
Rear GPS Heading: N/A
Calculated Heading: 289.6°

Distance between GPS devices: 0.72 meters

Front GPS: 0.1 seconds old
Rear GPS: 0.1 seconds old

WAYPOINT NAVIGATION:
No waypoints loaded

I can probably use this as-is but as a perfectionist I’ve been working on getting RELPOSNED working for a couple of days. Unfortunately, this is the best I’ve gotten so far:
11:16:58.484 - RELPOSNED v1
FLAGS: 0x1D0795F0
FIX: False, DIFF: False, VALID: False, CARR: 1
HEADING VALID: False, REF_MISS: True
POS: N=-0.24cm E=0.70cm D=0.21cm
BASELINE: 0.769m
HEADING: 0.00° (valid=False)
RAW PAYLOAD: 01 00 00 00 F0 95 07 1D E8 FF FF FF 46 00 00 00 15 00 00 00 4D 00 00 00 10 5C A6 00 00 00 00 00 E7 20 26 27 64 00 00 00
FLAGS details:
gnss_fix_ok: False
diff_soln: False
rel_pos_valid: False
carr_soln: 1 (FLOAT)
is_moving: True
ref_pos_miss: False
ref_obs_miss: True
rel_pos_heading_valid: False
HEADING: 0.00° (±0.00°)

Thoughts?

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)
-----------------------------------------------------------------------------

Thoughts?

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