Problem providing NTRIP corrections from SW Maps via BlueSmirf to ZED-X20P

[Christian_Kohler]

I have a BlueSmirf v2 attached to the UART2 headers on a ZED-X20P breakout board. I’m using SW Maps on an iPhone 17 Pro. I can connect to the X20P through BlueSmirf using SW Maps. Because I’m on an iPhone, I can only use the BLE mode, not the SPP mode. This works fine, but when I try to provide NTRIP corrections from the phone in SW Maps, it has a couple of problems. (1) it doesn’t look like the X20P gets corrections, because the solution never changes to RTK, I do see data flowing on the NTRIP Client screen, but the status never changes. (2) it will disconnect the BlueSmirf after 30-45 seconds, and I don’t even see any GPS data anymore. I can reconnect, but when I add the NTRIP corrections, the BlueSmirf connection to SW Maps drops after a short while.

If I provide NTRIM corrections through USB connected to a Raspberry Pi, running PyGPSClient, I can see the status on SW Maps change to RTK. I can also provide NTRIP corrections through U-Center2 via UART1, and that also works. I just can’t get them working through SW Maps. I checked and CFG-UART2INPROT-RTCM3X=1 so that should allow RTCM corrections. I’m using an OpenLog Artemis running the GNSS firmware to log to SD via the I2C port.

Any idea what is going on here? Is there too much data flowing through the BlueSmirf? I have the problem with 1Hz and 5 Hz. I set the baudrate to 115200.

Thanks

[rftop]

In SW Maps, when you Edit the NTRIP Client - is “Send NMEA GGA to Caster” option selected ?

[Christian_Kohler]

Yes, good question. I have “Send NMEA GGA” selected (and my caster needs it). I also made sure that UART2 has GGA, so that SW Maps can send it back. When I connect the NTRIP client, it actually shows the correct baseline distance on the screen.

I have NTRIP Version as V1, I tried V2, but didn’t connect at all. This is the NY State RTN network.

[rftop]

Then my next guess would be the same as your assumption: " too much data flowing through the BlueSmirf".

A quick check could be to send commands to temporarily turn off some data from the X20 to confirm… like NMEA GSV, most constellations, etc.

[sparky]

Much head scratching!

If we attach the BlueSMiRF (configured for BLE) to the ZED-X20P UART1 RX pin, everything works as expected (note, the UART1 has to be config’d for 115200). If we move just the TX wire from BlueSMiRF to UART2 RX pin on the ZED (note, UART2 is config’d for 115200), we get nothing but skipped bytes.

We are using the latest HPG 2.02 on the X20P.

Above, we see UART2 is skipping the incoming data.

Above, UART2 is config’d for 115200bps.

Above, we used pyGPSClient to inspect the RTCM coming out of the BlueSMiRF, it eats it up (looks fine).

Above, if we scope the signal coming out of BlueSMiRF, it’s healthy 3.3V, looks good.

Above, other things of lesser note, BlueSMiRF SPP and BLE work fine with LG290P (we were trying to eliminate BLE from the issue which I believe we have).

Back to the X20P: Now if we connect Android phone + CH340 to the X20P UART2 RX pin, it works. Why does a wired connection work on UART2 of the ZED-X20P but not data coming from an ESP32?

Why does the data coming from an ESP32 work on UART1 but not on UART2?

Above, perhaps it’s serial timing tolerances? So we changed the ZED to 38400 (both UARTs) and the BlueSMiRF to 38400. The same: UART1 is happily connected to the BlueSMiRF over BLE and RTCM is received and RTK Fix occurs. Moving the wire to ZED-X20P UART2 RX pin, the ZED just skips all data coming out of the BlueSMiRF.

We’ll keep looking into this but right now we can’t say why ZED-X20P UART2 is being a lot more particular than UART1.

[sparky]

Ahah! There’s a high voltage limiting 1k resistor on that connector (BlueSMiRF and locking JST) that is causing the issue. If you jumper around that, BlueSMiRF works great (which also explains why the CH340 worked = bigger driver). So you can either jumper over the resistor, or connect the BlueSMiRF to the RX2/TX2 pins.

[Christian_Kohler]

Wow, thanks for digging into that. I’ll test it first by connecting on the other UART2 pins, and will considering jumping the resistor later.