search

sparkfun / SparkFun_RTK_Everywhere_Firmware

Centimeter precision GPS/GNSS using L1/L2/L5 signals broadcast over Bluetooth, WiFi, and Ethernet.
http://docs.sparkfun.com/SparkFun_RTK_Everywhere_Firmware/
Other
17 stars 11 forks source link

Radio Corrections Priority #407

Open PaulZC opened 4 months ago

PaulZC commented 4 months ago

This is a note-to-self, so this doesn't get forgotten...

We still need to include the radios (CORR_RADIO_EXT and CORR_RADIO_LORA) in the corrections priority handling.

We discussed that the best way to handle CORR_RADIO_EXT would be to enable/disable RTCM3 via the UART2 port protocol.

CORR_RADIO_LORA will be important once we get the Torch LoRa running.

nseidle commented 3 months ago

LoRa has been added. Is CORR_RADIO_EXT correctly handled on the EVK?

PaulZC commented 4 weeks ago

This needs a bit more work...

We have settings.enableExtCorrRadio. When that is enabled this code fakes the connection. So, once settings.enableExtCorrRadio has been enabled, it usually 'wins' as it has the highest default priority. This prevents L-Band or IP from being pushed, unless their priority has been set higher.

We're not using settings.enableExtCorrRadio to disable / enable RTCM input on UART2. Right now, RTCM3 is always enabled. Corrections will always get through, even if settings.enableExtCorrRadio is disabled.

Is this what we want? Nope. Simultaneous L-Band/IP and RTCM3 will confuse the module and almost certainly cause float lock.

If I've thought this through correctly, a better solution is:

I need to think about this more, but I think this covers all the options...

If UART2 is receiving data, RTCM3 will only be enabled if settings.enableExtCorrRadio is true and correctionLastSeen(CORR_RADIO_EXT) is also true

If UART2 is not receiving data, correctionLastSeen(CORR_RADIO_EXT) won't be called, allowing other sources to provide corrections

But, maybe we don't need settings.enableExtCorrRadio at all. I think this works too:

If UART2 is receiving data, RTCM3 will only be enabled if correctionLastSeen(CORR_RADIO_EXT) is also true

If UART2 is not receiving data, correctionLastSeen(CORR_RADIO_EXT) won't be called, allowing other sources to provide corrections

It needs a proper state machine with nice state change debug messages... I'll give it a go!

PaulZC commented 4 weeks ago

Ah. Except you have to have at least one protocol enabled for the skipped bytes to increase. If you set INPROT to None, it just ignores everything and skipped doesn't increase.

More thought needed, but there's probably still a solution in there. With INPROT set to NMEA (only), skipped increases. So maybe we'll use that?

PaulZC commented 4 weeks ago

Thinking this through:

We can extend this to UBX-PMP, SPARTN and RTCM3 corrections on the ZED. There may be users who would want to: feed in UBX-PMP from an external NEO-D9; feed in SPARTN from an L-Band or IP source.

Does the same apply on the mosaic? On the Facet mosaic, users have access to COM2 via the RADIO connector, and COM3 via the DATA port and multiplexer. We don't yet know if the mosaic can be confused by multiple simultaneous corrections; I suspect not. But perhaps it would be wise to assume that the user may want to prioritise PPL L-Band RTCM over RTCM on COM2 - or vice versa. The mosaic has the InputLink SBF message which provides similar stats to UBX-MON-COMMS. There's enough similarity to warrant a common solution with the ZED.

We don't need to worry about Torch as it doesn't have a DATA port.

What about LG290P? TXD3/RXD3 is equivalent to the RADIO port. Does it provide COMM reports? PQTMCFGPROT lets you select RTCM input / output on individual ports. But I'm not seeing an equivalent of MON-COMMS...

Do we know if the LG290P can be confused by multiple simultaneous corrections? Maybe we should assume it can be?

OK. Where does that leave us.

I think we need to keep settings.enableExtCorrRadio. On LG290P, default to false. On ZED/mosaic, default to true. On LG290P, it can be used to enable / disable RTCM on RXD3. On LG290P, we'll use the 'fake' 'keep alive' code to prioritise RXD3 corrections over (say) BT or USB. On ZED and mosaic, it can enable the port monitoring RTCM-enable/disable functionality - even though that's probably redundant.

Stand back! Here we go...

nseidle commented 4 weeks ago

LG290P will be a problem. I don't have a good way currently to tell if RTCM is coming in over various ports but I will ask.

PQTMCFGPROT lets you select RTCM input / output on individual ports.

This command only allows modification of the port currently connected to. You can't (yet) modify COM2 from COM1. Quectel is aware of the issue and a fix is in the next firmware release, but no ETA (Q1 2025 is my guess).

While we are limited in our detection and blocking of RTCM at the port level, I'm glad we have the ability to curb corrections at the transport layer. The LG290P performs badly when given multiple correction sources.

nseidle commented 4 weeks ago

My fault. PQTMCFGPROT is port specific. PQTMCFGMSGRATE is the command I was thinking of. So we can block RTCM on a given port. I will ask if detection is possible.

PaulZC commented 3 weeks ago

I'm using the Better_CORR_RADIO_EXT branch for this. I've just pushed some changes, but these are untested and very Work In Progress...

https://github.com/sparkfun/SparkFun_RTK_Everywhere_Firmware/tree/Better_CORR_RADIO_EXT

PaulZC commented 3 weeks ago

Added / resolved in PR #500