MSP Message for link stats of MSP-RC systems

[b14ckyy]

Current Behavior

Using a RC Link system like mLRS that support RC over MSP, there is currently no way to get receiver and link information to the OSD and for blackbox logging. mLRS is the first system to provide this feature with ELRS maybe following in the future.

Desired Behavior

Having a MSP message the Rx can use to send RC Link stats and information to the FC. This would allow them to be logged and used for the OSD.

Suggested Solution

A New MSP message in INAV so it can receive RC Link information from MSP-RC receivers.
The Link Statistics and Information should be send as a message string that can be extended in the future if necessary.
If more fields are added in the future, then older INAV versions should also work with the existing fields so a longer payload should just be cut off and additional fields ignored.

Basic Fields to be available and their length in bit MSP2_RCSTATS:

Sublink ID - 2 (This would be used in the future to receive dedicated RSSI, LQ and SNR and Power Level values from multiple transceivers. The Rx will rotate through the IDs and send the corresponding data individually to keep message size low, up to 4 transceivers possible)
RC-Link Valid - 1 (Failsafe trigger)
RSSI% - 7 (gives int value defined by the RC Link. Set to 127 if not used)
RSSIdBm - 7 (gives int value defined by the RC Link, will be inverted to negative value by INAV. Set to 127 if not used)
Rx LQ% - 7 (gives int value defined by the RC Link. Set to 127 if not used)
Tx LQ% - 7 (gives int value defined by the RC Link. Set to 127 if not used)
SNRdB - 5 (-20 to +11 dB, only shows in OSD when <10 or negative, -20dB shifted in INAV, Rx would send values 0-31, 31 would also be sent if not supported or not used)
Receiver Antenna - 2 (Not Used; Rx; Tx; RxTx)
Transmitter Antenna - 2 (Not Used; Rx; Tx; RxTx)

Total Payload: 40bit

RC Link Settings that don't usually change often or at all, just sent by the Rx on change or on link establish MSP2_RCINFO:

Sublink ID - 2
Band - 4 byte string (Example: 868M, 2.4G, DUAL)
Mode - 6 byte string (Example: 19Hz, 31Hz, 50Hz. FSK, FLRC // 150Hz, F333Hz 1000Hz)
Power Level Tx dBm - 6 (min power level = 0, Value of 63 for not used and show `--` in the OSD)
Power Level Rx dBm - 6 (min power level = 0, Value of 63 for not used and show `--` in the OSD)

Both messages do not need a reply from the FC to the Receiver. The rate these messages are sent to the FC is defined by the RC Link system. For MSP2_RCSTATS an update rate of 4-10Hz is recommended, depending on how much bandwidth on the MSP port can be sacrificed. MSP2_RCINFO should only be updated when necessary. usually when a value changes.

Who does this impact? Who is this for?

All pilots who want to use MSP capable receivers.

Additional context

A second MSP message could be added to provide an input for advanced link data like the currently used frequency fields. This would then be for logging only and needs a high update rate to be usable. So maybe it should be separated from standard link statistics for the OSD that can easily be at 4Hz update rate.

@olliw42
@Scavanger

[olliw42]

very desirable IMHO and suggestion looks highly reasonable to me

👍

[OptimusTi]

Quick note: SNR is dB, not dBm. Depending on rf chip, min may be lower.

[b14ckyy]

@OptimusTi thanks for the hint. you think any RF Chip can handle a Signal that is more than 15dB under the noise floor? I have seen mLRS in 31Hz mode to reach -8dB SNR without breakup and at -10 it was over. -15 will be a very long shot I guess. Even for LoRa. Sure we could add a bit more if that is really reasonable but I have doubts.

[OptimusTi]

Maybe in a perfect world. I'd use -20dB for sanity. Common in the LoRa world.

[olliw42]

this field is VERY specific to lora anyway ... other link systems may have very different measures/metrics for "noise"

[b14ckyy]

I think Crossfire was FSK only in the past and also had it but I could be mistaken.
Anyway. If you think more range for SNR makes sense we can add a bit and get -32 to 32. We still have 1 bit left to have at least the ability to have 2 Link stat frames for dual operation, without raising the payload size.

in the worst case if we do 4 Linkstat frames, we could steal a bit from the LQ. I think a 2% step precision for LQ would not hurt anyone :P Lets see what @MUSTARDTIGERFPV has in mind for the framing and what @Scavanger says about that implementation.

alternatively (in the end we transmit positive numbers only and shift them in inav afterwards) we could just do a -20 to 11dB range for SNR.

[olliw42]

my mistake, I probably should have said specific to semtech sx chips, not ruling out others do too but point is some others don't do ... so, doesn't invalidate the statement ;)

[OptimusTi]

How many sf used in mlrs? That should tell you how low you can go.

[MUSTARDTIGERFPV]

For SNR, anything beyond -20dB is unlikely to be valuable. Crossfire measures SNR differently than ELRS and mLRS, not using RegPktSNR but instead measuring RSSI during the dead time between packets - that's why it has SNR available even in its 150Hz FSK mode.

On the MAVLink RC channels discussion, a device manufacturer was arguing for 4 sublink values, so we might want to keep that flexibility. IMHO it's more valuable to have this than SNRs that LoRa chips can't decode anyway (and are likely near theoretical limit).

[b14ckyy]

@MUSTARDTIGERFPV I think you both have good points. In INAV's case and I would assume also in BF, the SNR on the OSD only shows up if it is <10dB. As we can only send integers anyway afaik, a 5 bit value for SNR should be fine and on the INAV side we shift that value by -20. This way we get a -20 to 11 range to use on the FC while the Rx sends a raw value from 0-31.

Additionally a value of 31 could then be just "SNR not supported/disabled" as well.

Edit: I have added the sub link ID and we are at nice round 5 byte payload. I guess it also makes sense to have the ID for MSP2_RCINFO as well, to have separate power levels for each transceiver?

[b14ckyy]

So far this looks pretty good but I have one question:

with the antenna Tx/Rx state, we would currently cover information about a dual-band or diversity setup with 2 transceivers.
But if we now use the option to have sub-link IDs to get data for each receiver, it makes not much sense to have every tx/rx combination for 2 antennas. I wonder how we could optimize that, especially as we also have receivers that have one transceiver with antenna switching diversity.

Would this make more sense then:
Receiver Antenna - 2 (Not Used; Rx; Tx; RxTx)

So we would use each sub-link ID also for each antenna or transceiver if there are multiple. Could even be used for antenna switching if you want that and we save 2 bit.

[olliw42]

I think you encounter here a situation which comes from not being logically/conceptually consistent but mish mash. I.e., here mix the concept of sending data in different messages with the concept of sending some combined data in one message.

this may point to few obvious appraches to resolve :

• one could take the ID concept serious, and only send the data for that antenna in that message. One would then only have the info for that antenna in the message (i..e. one bit). A diversity or dual band (two antenna system in general) would have to send two messages.
• one could make the id field such as to allow indicating that the message may also reflect two antenna. E.g a bit mask of four bits, there each bit is for one antenna. In one message only two bits could be set at most.
• one could reinterpret the ID to not mean one particular antenna but a cluster of antenna, like cluster 1 meaning antenna 1 and 2, cluster 2 meaning antenna 3 and 4.

not saying any is great, but just to indicate paths towards possible resolution

[olliw42]

I think the vaue for power needs more specification. The power can also be negative, as well as positive. Not clear to me this is intended to be represented currently.

[b14ckyy]

• one could take the ID concept serious, and only send the data for that antenna in that message. One would then only have the info for that antenna in the message (i..e. one bit). A diversity or dual band (two antenna system in general) would have to send two messages.

That's actually how I had that in mind. From a users perspective, it does not really matter how many transceivers are on their hardware, all they see from the outside are antennas. Additionally I highly doubt that we will ever see a 4 transceiver system with antenna diversity on each (8 antennas total). In the end the idea is to provide 4 slots to write 4 different datasets and its up to the RC Link Code to decide how its used and its on the FC Software side to decide how the information are provided to the user. The main goal is to have a way to provide separate link stats for up to 4 transceivers. If you wanna use it for antennas in a Antenna switching diversity setup and one transceiver, that's also possible, but the only difference between the ID 0 and ID 1 would be, what antenna is active. All other values would be identical.

• one could make the id field such as to allow indicating that the message may also reflect two antenna. E.g a bit mask of four bytes, there each bit is for one antenna. In one message only two bits could be set at most.

Theoretically we could say we use the ID for transceiver info only and an additional Antenna bitmask as you said but then we would end up with a full extra byte in the message with not much benefit. In a 4 Transceiver setup that would be 4 bytes more for a full cycle. But that would only make sense for that unlikely setup of more than 4 total antennas.

I hope I understood your point correctly.

• one could reinterpret the ID to not mean one particular antenna but a cluster of antenna, like cluster 1 meaning antenna 1 and 2, cluster 2 meaning antenna 3 and 4.

As above, that would be up to the RC link code.

####################

My idea basically is something like this, in a multi-transceiver setup:

To have one element for each transceiver that shows either RSSI or LQ as bars + Info if the transceiver is used for R/T/RT
But this has to be defined later. For now we just talk about the way to feed INAV with the data.

I think the value for power needs more specification. The power can also be negative, as well as positive. Not clear to me this is intended to be represented currently.

You think Transmission power levels and negative dB are actually practical and will be used? For some "min" low power mode I would have said we just show 0dB.
I mean sure if it makes sense we can shift the value by -20 like we did with SNR so you can reach -20dB transmit power if you think that makes sense. Gives us still ridiculous 43dB max.

[olliw42]

power levels: wasn't attempting a suggestion just trying to say that it needs to be specified. :)

looking forward to 63 dBm devices LOL

[b14ckyy]

got it, added that.

[olliw42]

any progress planned, or dead horse?