Basic support for softRF

[error414]

Discusion: #11065 (comment)

The PR is adding basic support for softRF for Nano-Edition, see https://github.com/lyusupov/SoftRF/wiki/Nano-Edition

SoftRF supports FLARM and FANET protocols which are widely used by small planes in low altitudes. Good benefit for UAV to know about them.

Required by softRf

MAVLINK_MSG_ID_HEARTBEAT 
MAVLINK_MSG_ID_SYSTEM_TIME 
MAVLINK_MSG_ID_GPS_RAW_INT

Message which are not implemented

MAVLINK_MSG_ID_SYS_STATUS
MAVLINK_MSG_ID_VFR_HUD
MAVLINK_MSG_ID_ATTITUDE

The PR just add one new message MAVLINK_MSG_ID_SYSTEM_TIME. MAVLINK_MSG_ID_HEARTBEAT has been refactored, now MAVLINK_MSG_ID_HEARTBEAT is sent always, not only witgh HUD message as it was before.

ADSB.md is updated as well.

Testing:

• comminication softRF (FLARM ) <-> softRf (FLARM ) tested by SAMUD
• comminication softRF (ADSB-L) <-> softRf (ADSB-L) tested by SAMUD
• comminication softRF (FLARM ) <-> original FLARM defice on big plane

By tests results can be adjusted setting in ADSB.md file, mainly message rates.

[github-actions]

Test firmware build ready — commit 3b3545a

Download firmware for PR #11414

227 targets built. Find your board's .hex file by name on that page (e.g. MATEKF405SE.hex). Files are individually downloadable — no GitHub login required.

Development build for testing only. Use Full Chip Erase when flashing.

[sensei-hacker]

Thanks for this. I see this would add a new setting system_time_rate. What does that rate mean and why/how would users change it?

Does that mean number of times per second? Number of milliseconds between sends?

Also I see some other things added like ground speed, system type, etc. are those supposed to be part of this PR?

[error414]

system_time_rate settings follows INAV convention. Same a
mavlink_pos_rate, mavlink_extra1_rate

Maybe would be nice to add to all description in which unit it is.

The number means hz, see https://github.com/iNavFlight/inav/pull/11414/changes#diff-77281cb45441cdeab50dd4c2215dbe6693da397b8633f53566a19d84dbb9c5aaR175

Also I see some other things added like ground speed, system type, etc. are those supposed to be part of this PR?

It's not new, it's renamed function mavlinkSendHUDAndHeartbeat to mavlinkSendHUD. All addition what is under https://github.com/iNavFlight/inav/pull/11414/changes#diff-77281cb45441cdeab50dd4c2215dbe6693da397b8633f53566a19d84dbb9c5aaR811 already been in INav.

[sensei-hacker]

Ah cool it looks like ground speed and air speed just got moved within the file, just different line numbers. Not new.

Can we add "hz" in the description of the setting?

When would/ should a user change that? I ask because I'm looking through all of the settings we currently have an noticing some things that could be improved.

[error414]

Can we add "hz" in the description of the setting?

sure

When would/ should a user change that? I ask because I'm looking through all of the settings we currently have an noticing some things that could be improved.

I have no idea why is there that setting. I have never used it because ELRS can convert CSFR telemetry to mavlink telemetry and send via backpack. It's called mavling telemetry so parsonally I would say it was designed to adjust rates for diferent RC telemetry speed.

[sensei-hacker]

Part of the reason I was asking is because anything that adds a new setting alters the binary structure of the settings (the parameter group) in the EEPROM, so it has to wait until INAV 10. Things that don't add new settings may work for INAV 9.1.

From everything I'm finding, that should ways be sent at 1 Hz. There is a different message used when you need more precise time tracking. So maybe it doesn't need to be a setting and doesn't need to push this to INAV 10.

If it DOES need to be a setting, altering the parameter group and therefore the binary in the EEPROM requires incrementing the version number of the PG in telemetry.h. Otherwise, all of the settings would be read in off-by-one, with the value intended for MAVLINK_RADIO_TYPE being read as MAVLINK_MIN_TXBUFFER, MAVLINK_SYSID being used for MAVLINK_MIN_TXBUFFER, etc.

So we need to either get rid of the setting or increment the PG version.

[error414]

Part of the reason I was asking is because anything that adds a new setting alters the binary structure of the settings (the parameter group) in the EEPROM, so it has to wait until INAV 10. Things that don't add new settings may work for INAV 9.1.

From everything I'm finding, that should ways be sent at 1 Hz. There is a different message used when you need more precise time tracking. So maybe it doesn't need to be a setting and doesn't need to push this to INAV 10.

You are right, MAVLINK_MSG_ID_SYSTEM_TIME is ussually send in 1Hz, and mainly it is always sent by Ardupilot, it is not in any data stream you would have turn on in ardupilot. So probably we don't need to change rate.

So if I removed the settings, MAVLINK_MSG_ID_SYSTEM_TIME would always be sent, and it would not be possible to turn the message off if you wanted to minimize communication over the RC downlink.

If you are OK with removing settings for MAVLINK_MSG_ID_SYSTEM_TIME and send it always, I'm Ok with it.

So we need to either get rid of the setting or increment the PG version.
always forget, I'm glad you made check for that :)

[sensei-hacker]

Yeah I would think just send it at 1 Hz. Once per second is slow enough that it doesn't hurt anything if you aren't using it, right? That's what I would think, but I'm far from a Mavlink expert!

@xznhj8129 has been doing a lot of work with Mavlink and MSP control. He might have a different view.

[error414]

I removed settings for system time, hope it will be OK :).

[error414]

created change request (for softRf) to be softRf more compatible with INAV

lyusupov/SoftRF#195