new message radio_status_extensions in development

[leonardosimovic]

The RADIO_STATUS message contains the RSSI, however digital radios often provide additional information on the link status such as:

• SNR: signal to noise ratio [dB]
• MCS index: which Modulation Coding Scheme is being used
• NSS: number of spatial streams
• Queue size: packets waiting to be sent
• Air time: percentage of the time the radio is transmitting [%]

which can be useful when performing e.g. range tests.

Example data:

[hamishwillee]

Thanks @leonardosimovic - is this abstract or do you have a particular radio and ground station in mind? I ask because we require a prototype before we push this into common.xml

@julianoes @auturgy You guys know much about radios?

[auturgy]

how do i know what radio?

[julianoes]

@LorenzMeier brought up the question whether this message should also include a radio_id in case there are multiple radios, as well as support for MIMO radio where you might need multiple of these fields.

[hamishwillee]

Apparently the RADIO_STATUS message is a bit weird. As I understand it the message is injected by a radio into the stream. It doesn't have an ID, and I am not sure how it is supposed to be used. @auturgy @julianoes Do you know the detail of how this part of the protocol is supposed to work - will better inform comments?

Either way though, an IP radio is probably quite different, and might need different semantics.

"generally" speaking if a system might have multiple radios and channels that we want to do something with, we're going to need to identify them individually.

This set of data in the message seems reasonable but might not be exhaustive:

• What other information is supplied by your radio native status API that you have chosen to omit for this?
• Do you know of other IP radios? What do they expose.
• What are your plans to prototype?

In summary, we don't know enough yet to assess this.

[olliw42]

great, I would have had to raise a related issue in the near future too (as I'm working on a lora mavlink link), so great :)

Apparently the RADIO_STATUS message is a bit weird. As I understand it the message is injected by a radio into the stream. It doesn't have an ID

yes, it is injected on both sides, that is, the tx side sends it to the GCS and the rx side to the FC

it does have an ID: https://mavlink.io/en/messages/common.html#MAV_COMP_ID_TELEMETRY_RADIO

it is weird in the sense that it has an id but is not supposed to send heartbeats

(that's at least how the SiK's work, and I would thus speculate that other's do too)

@LorenzMeier brought up the question whether this message should also include a radio_id in case there are multiple radios, as well as support for MIMO radio where you might need multiple of these fields.

yes, PLEASE !!

I do have in mind a true diversity system, so one would need the fields twice for each side, i.e., four times if one wants to stick with the xxx and remxxx pattern. I personally would have preferred one message, where the values for the 2nd could e.g. be extensions, and not all field values would really need to be doubled. But any solution is fine.

What other information

• LQ !!
• selected antenna

the cumulative fields like rxerrors or fixed etc are IMHO pretty useless

[leonardosimovic]

Thanks for the feedback everyone!

@hamishwillee The message was developed with a Silvus StreamCaster 4000 radio in mind but eventually it ought to be abstract.
Indeed, the Silvus API exposes many more parameters, a lot of which are mesh-networking related i.e. carrying statistics of neighboring nodes. Although interesting, we thought these to be too specialized. A more general and useful parameter would be the radio temperature.

We first considered to extend the existing RADIO_STATUS message. However as @olliw42 mentioned, it is a bit of a special case because the message is implemented in the radios themselves. E.g. the SiK radios inject the message directly into the message stream and updating would be cumbersome. Hence we decided to use a second message for now.

@olliw42 Could you explain what you mean by LQ?

I do have in mind a true diversity system, so one would need the fields twice for each side, i.e., four times if one wants to stick with the xxx and remxxx pattern. I personally would have preferred one message, where the values for the 2nd could e.g. be extensions, and not all field values would really need to be doubled. But any solution is fine.

Instead of repeating the fields we may also consider repeating the entire message. To do so we could define the local_radio_ID and remote_radio_ID to uniquely identify the stream.

Suggested fields atm:

• Radio ID
• Remote ID
• Selected Antenna
• LQ
• Temperature
• SNR
• MCS index
• NSS
• Queue size
• Air time

cc @mrivi

[olliw42]

LQ = link quality
that's a value which basically all "newer" rc systems such as TBS Crossfire&Tracer (I think TBS came up with it first), ImmersionRC Ghost, ExpressLRS, are using. google e.g. "LQ link quality"
I indeed think it's a better value than e.g. rssi and noise and such

RADIO_STATUS .. is a bit of a special case because the message is implemented in the radios themselves. E.g. the SiK radios inject the message directly into the message stream and updating would be cumbersome.

I actually do not agree, I like that concept. It's kind of the easiest to do for a tx or rx.

Instead of repeating the fields we may also consider repeating the entire message. To do so we could define the local_radio_ID and remote_radio_ID to uniquely identify the stream.

I understand the point, but I'm also not a fan of these super huge messages which carry all sorts of fields of which only at most a handful are used, and which in addition need to be send multiplied ... I "hate" that waste of bandwidth and spilling of the network.
It might be true that all of you only have 1Gbit ethernet network and 32-core multiprocessors and 100GHz-AI-FPGA's on your drones, but the majority of e.g. ArduPilot users won't ... they may still use 57600 bps wires...

IMHO

[hamishwillee]

Thanks all.

@olliw42 Interesting. I guess you don't need a heartbeat since you don't need the message routed. I think the only other case of that is the HIGH_LATENCY.

@leonardosimovic Thanks for the additional information. I think you're probably right not to extend the original RADIO_STATUS.

What sort of rate would this be sent at, and what are the typical data rates we can expect from Silvus, microhard, and any other radio systems that might need this?
i.e. do we need to worry about the size of this particular message if it is always going to occupy a very small fraction of the link it is sent on?

@julianoes is there anyone in the dev team or Auterion with a lot of radio experience we can drag in to help arbitrate? I expect Daniele will have played with both Silvus and Microhard, and probably others? @auturgy You've played with a few too right? I have zero expertise on this.

[julianoes]

@hamishwillee that would be @eyeam3

[olliw42]

Interesting. I guess you don't need a heartbeat since you don't need the message routed.

I don't want to dive deeply into the pro and cons, since it's just a fact that this how the SiK's work.

concerning the routing, that's actually some muddy territory, since not all routers appear to work the same. Some may route only when they have seen a respective heartbeat before, some others may route whenever they have seen an id in whatever message. (I think ardupilot is of the first kind, and mavlink-router of the second). The wording of the standard (https://mavlink.io/en/guide/routing.html) seems to imply the second kind.

That is, if it is a router of the second kind then the RADIO_STATUS messages would be routed, and if one wants to take the standard as reference then they should be routed. Routers of the first kind appear to have special handling for the RADIO_STATUS message, which however can actually be of the kind to never forwad radio messages ;) (see https://github.com/ArduPilot/ardupilot/blob/master/libraries/GCS_MAVLink/MAVLink_routing.cpp#L108-L112)

[hamishwillee]

@olliw42 Thanks, and fair enough. I do not know the original intent but I interpret the standard in the same way. I don't want to get into the detail either :-)

[auturgy]

@hamishwillee yes, played with a few. If we're looking at Streamcaster, should probably consider MPU5 and TrellisWare too, as equivalent datalinks. DoodleLabs is also gaining traction.
I'm not convinced that we're taking the right approach with this message. Might be time to look at a COMPONENT_STATUS?

[mrivi]

We are looking into how the message generalises with other radios and we'll update the pr accordingly

[hamishwillee]

Thanks @mrivi That would be great. Hopefully in the next week or so?

@auturgy Let's talk about whether COMPONENT_STATUS can be used for this tonight (I don't "get" this yet).

[hamishwillee]

@mrivi Any ETA on when you'll update this proposal?

[leonardosimovic]

Hey @hamishwillee, unfortunately we didn't have the time to look into it yet but you can expect to hear from us within the first two weeks of January. Until then, happy holidays!

[hamishwillee]

Thanks for letting me know @leonardosimovic. Hope you guys have a great holiday too.

[leonardosimovic]

Hey everybody! I wanted to share an update proposal for the message.

To recap, the new message ought to be abstract enough to be used with digital MIMO radios that are potentially taking part in MANET.

I suggest that the message payload is composed of three sections:

A) Fields representing radio settings:

• Frequency [MHz]
• Channel / Bandwidth [MHz]
• Max Link Distance [m]
• Transmit Antennas [ ]
• Receive Antennas [ ]

In a traditional setup consisting of just two radios, these values might very well be static while modern radio may auto adjust. For example, the TX/RX antenna configuration might be changed depending on the technology used to transmit data (Mode field in the next section).

B) Fields representing radio stats:

• Mode [ ]: The technology used to transmit i.e. beam-forming, spatial multiplexing, diversity coding.
• MCS Index [ ]: It implies various parameters such as number spatial streams, max data throughput, min SNR etc.
• Transmit power output [dBm]
• Device Temperature [C]
• RSSI [dB]: The standard for signal quality.
• SNR [dB]: Better estimate than RSSI as it includes background noise. Most modern radios implement this.
• LQI [%]: Quality analysis is based on the packets rather than received signals.
• Air Time [%]: Percentage of time the radio is transmitting
• Queue Size [ ]: Number of packets waiting to be transmitted.

These fields represent the momentary variables and give insight into radio health and performance. Note that we have three fields for the link quality: RSSI, SNR, LQI. Question: What are your thoughts on condensing these into a single field e.g. Signal Quality and let the user/radio decide which one to implement / how to interpret.

C) Network stats:

• Number Nodes [ ]
• Weakest Link SNR [dB]
• Weakest Link Queue Size [ ]

In MANET applications we also care about links that may have no means of injecting a message into the stream.
Consider this example:

Here the path from Ground Station (GS) to UAV would be bottlenecked by the link AB but it would not show if we only considered GS and UAV. Some radios are already able to provide information on the weakest link. For radios that do not provide it, one might perform a graph search e.g. on GS side.
For the weakest link I've chosen only the SNR the following reasoning:

• RSSI seems antiquated. The radios I looked at with MANET capabilities are all able provide SNR in addition to RSSI (if not execlusively).
• The LQI already considers the weakest link.

Please let me know what you think! :)

[olliw42]

reading this it occurs to me that one probably shouldn't consider such a message or message set to be "extensions" of the old radio_status message ... while certainly impressive and very cool, it appears that this is rather specialized and probably not of relevance to the larger userbase of older-style radio links
that is, what I'm suggesting is to rather use a quite new name or set of names for the messages in this application, a message named radio_status_XXX rather could/should be a modernized version of the old radio_status. just my 2 cents
:)

[hamishwillee]

@leonardosimovic Thanks for this. Just back from holidays. As previously, I personally don't have have domain knowledge to assess this. @auturgy @julianoes @lorenz - need technical assessment.

Generally

• you need to decide who and what the message is to be used for, and what information is therefore needed. You then provide the minimal information for that audience. In the case of "should I send Signal Quality" you'd be thinking who is this for - if it is to display in QGC that would probably be appropriate. I wouldn't send all the detailed information for a message that is streamed all the time but is only used for debugging once in a blue moon
• it is not uncommon to split messages based on how often the info updates, or who needs it. So if all these might reasonably change all the time you could combine them, but if some are likely to be static, or debug only, that could be a separate message.

Let's see what the information breakdown is before we decide on a final name(s).

[leonardosimovic]

Closing this due to inactivity