MSP-RC Feature Extensions - Wishlist

[b14ckyy]

Since many game-pads and joysticks have many more buttons and axis than our 16 available channels, it would be nice to have the ability to also let multiple buttons set the same channel to a specific value.

2 variants:

• Sticky value
  • Button A sets channel X to value 1000
  • Button B sets channel X to value 1300
  • ...
• Push value
  • Button A sends channel X to 1500 for 200ms, then falls back to 1000
  • Button B sends channel X to 2000 for 200ms, then falls back to 1000

A set value could be used for direct Flight Mode selection. A Pulse value could be used for the Programming framework to have push buttons without wasting multiple RC channels.

[b14ckyy]

Toggle Button for RC Control while conencted.

When then RC Feature is enabled in settings, it would be nice to have a toggle when connected and in the map view to start/stop sending RC messages.
Especially when a Fallback RC link is used, it would be good to disable the GCS RC control without disconnecting the whole MSP link.

But this needs some discussion and brainstorming to not cause havoc if channels are entirely different between GCS channels and Radio channels.

Would it be possible to read the channels (5 and higher) from the FC first and mirror them to the hid-server when the toggle is switched on?
The radio would be in a state already, where the craft is configured for assisted flight so a fallback would be no problem but since we have mostly push buttons only on the GCS, it would be good if we could start with a mirror of the Radio channel positions first.

[stronnag]

Toggle Button for RC Control while conencted.

When then RC Feature is enabled in settings, it would be nice to have a toggle when connected and in the map view to start/stop sending RC messages. Especially when a Fallback RC link is used, it would be good to disable the GCS RC control without disconnecting the whole MSP link.

This sort of exists even if it is not exposed to the user (or used internally at the moment), so it could be exposed such that:

• Enabled means the HID server is started when the MSP channel is started
• Activated means that the RC data held by the HID server is sent to the FC.

But this needs some discussion and brainstorming to not cause havoc if channels are entirely different between GCS channels and Radio channels.

Would it be possible to read the channels (5 and higher) from the FC first and mirror them to the hid-server when the toggle is switched on? The radio would be in a state already, where the craft is configured for assisted flight so a fallback would be no problem but since we have mostly push buttons only on the GCS, it would be good if we could start with a mirror of the Radio channel positions first.

There is an obvious problem (regardless) for example where the radio has three position switches, and the controller only has latched buttons. But solvable by expanding the proposed two position latch to a 'N' position latch in the future.

[stronnag]

OK, as of now:

Enabled : In the MSPRC settings dialog means that the mwp-hid-server will start when an MSP port is started and stop when the MSP port is closed. This is a prerequisite for MSPRC.
Activated: This means that that mwp will use data from the mwp-hid-server to send MSP_SET_RAW_RC to the FC.

When MSPRC is Activated, then mwp will first interrogate the FC MSP_RC to set the current RC channels. At the moment we do nothing with this data, but it could in future to set the value for latch buttons.
After MSP_RC has been received, mwp will use data from the mwp-hid-server to send MSP_SET_RAW_RC to the FC.

The MSPRC function may be Activated / Deactivated as required while a MSP port is active.

Activate is controlled from the File > Edit menu.

At startup, the Activate menu option is set from Enabled setting (but can be changed on demand). It is not currently persisted.

Here's a log fragment showing this:
(Numbers in brackets) are explained below:

21:06:11.522260 :HID DBG: pid=255325 53 (1)
21:06:11.522296 Send HID Info (2)
...
21:06:11.550794 Raw RC: 22 No joystick connected (3)
21:06:11.581800 INAV v8.0.1  SITL (171d00bb) «BENCHYMCTESTY»
21:06:11.581900 Load FC safehomes
21:06:11.803174 :DBG: Clear poller state MWP_SERSTATE_NORMAL
21:06:11.803204 Save home d/l done
21:06:11.803222 Load FC Geozones
21:06:11.803630 :DBG: MSP_RC size 68 (4)
21:06:11.806114 :DBG: Read 4 geozones
21:06:11.813640 :DBG: Clear poller state MWP_SERSTATE_NORMAL
21:06:11.813690 Geozones validated
21:06:11.848278 Sensors: Acc Baro GPS  (00cb)
21:06:11.848310 INAV v8.0.1  SITL (171d00bb) «BENCHYMCTESTY»
21:06:11.848355 Poller cycle for  9 items, 81 / 226 bytes (INAV_STATUS,ANALOG2,NAV_STATUS,RAW_GPS,COMP_GPS,GPSSTATISTICS,WP,ATTITUDE,ALTITUDE)
21:06:11.848391 Start poller
21:06:11.854382 Request RTC pos: 54.355194 -4.523159 sats 16 hdop 100.0
21:06:11.855258 RTC local 2025-05-13T21:06:11.855, fc 2025-05-13T21:06:11.000
21:06:13.386745 Arming flags: Geozone (0060), load 0% MSP_CMDS_INAV_STATUS (5)
21:06:31.669714 :DBG: msprc action set to false, use_rc=1 (6)
21:06:32.576143 Arming flags: Geozone,RC Link (40060), load 0% MSP_CMDS_INAV_STATUS (7)
21:06:53.180132 :DBG: msprc action set to true, use_rc=53 (8)
21:06:53.185002 :DBG: MSP_RC size 68 (9)
21:06:54.080304 Arming flags: Geozone (0060), load 0% MSP_CMDS_INAV_STATUS (10);
...
21:07:00.456903 Serial closed replay 0 (11)
21:07:00.457042 48.952s, rx 192615b, tx 84171b, (3935b/s, 1719b/s) to 0 wait 0, avg poll loop 5 ms messages 8609 msg/s 175.9

1. MSPRC setting was enabled, so the mwp-hid-server is started
2. mwp asks the hid for controller info.
3. Fake was set via MWP_HIDOPT=-f; so no joystick is reported as expected. mwp will schedule MSP_RC to get current channel values.
4. The MSP_RC response is reported (not yet acted upon), this schedules MSP_SET_RAW_RC.
5. The next polled MSP2_INAV_STATUS reports that the only blocker is "Geozone" (expected for this scenario). In particular "RCLink" is NOT a blocker.
6. The user uses File > Edit > Activate MSP RC to Deactivate MSPRC.
7. The next polled MSP2_INAV_STATUS reports that the blockers are Geozone" and "RCLink", showiing mwp is no longer scheduling MSP_SET_RAW_RC.
8. The user uses File > Edit > Activate MSP RC to Activate MSPRC again.
9. The MSP_RC response is reported (not yet acted upon), this schedules MSP_SET_RAW_RC.
10. The next polled MSP2_INAV_STATUS reports that the only blocker is "Geozone" (expected for this scenario). In particular "RCLink" is NOT a blocker.
11. The user closed the MSP port, ending the experiment.

[stronnag]

• RC channels are longer limited to 16; the number supported by the FC is available. mwp will send the lesser of the number of channels supported by the FC / the number of channels defined in the RC mapping file (so if INAV reports 34 RC channels, but only 12 are defined in the mapping file, mwp will send 12 in order to conserve bandwidth).
• mwp reads MSP_RC when MSPRC is activated and sets its channels accordingly. However, until "latch" is implemented, this is somewhat pointless.

[stronnag]

In order to be able to make progress, and pending resolution of #218, there's a trivial / temporary implementation of "latch" (or at least what I understand as "latch" --- effectively momentary switches).

This adds a new keyword (and modifier) to the mapping file:

• "latch" implements the default 2-pole latching switch;
• "latch=N" implements an N-pole latching switch (N=2 - 6).

Pressing the latched switch toggles the channel value, so for:

Button 1 = Channel 10 latch=3 ; SF

Repeatedly pressing the button would result in channel values of (inital value)1000 => 1500, 2000, 1000, 1500, 2000, 1000, 1500, 2000 ....

And I appreciate it wraps rather than going up-down like a mechanical switch (n.b. trivial / temporary implementation ...)

[stronnag]

inverted latches are also valid.

Button 1 = Channel 10 latch=3 invert ; SF

[stronnag]

I suppose we need a channel monitor as well ....

[b14ckyy]

Thats a VERY good idea! Love it

[stronnag]

Particularly with latched channels, as there's no tactile feedback, you can only guess as to the position.

[stronnag]

Note: HID mode is no longer limited to 16 channels, rather the max supported by the FC (34 in INAV 8).

Let's continue with sticky / fixed. Intended for devices with many momentary buttons, such that you can have discrete buttons for functions like PH, WP, RTH, Cruise.

Pressing the button sets a distinct value on a channel
Pressing the button again reverts the value to 1000 if it's at the fixed value.

Button 1 = Channel 10 fixed=1250 ; PH
Button 2 = Channel 10 fixed=1500 ; RTH
Button 3 = Channel 10 fixed=1750 ; WP
Button 4 = Channel 10 fixed=2000 ; Cruise

• User presses Button 1, assert PH (Ch10 = 1250)
• User presses Button 2, assert RTH (Ch10 = 1500)
• User presses Button 2, RTH cancelled, channel set to 1000 (back to default (Acro) or some other lower precedent mode set by another channel)

...

• User presses Button 1, assert PH
• User presses Button 2, assert RTH
• User presses Button 1, assert PH again

Practical ?
Other implementation ideas?

[b14ckyy]

That sounds good and easy to understand. I am just unsure about the fallback to 1000 when the same button is pressed twice.
I see the use for some functions like a one button 2-pos toggle, so it makes sense to combine that in one function any maybe even for a single channel multi function, but it would be nice to have a parameter to have a "set only" button as well.

Based on your example:

Button 1 = Channel 10 fixed=1250 ; PH
Button 2 = Channel 10 fixed=1500 sticky ; RTH
Button 3 = Channel 10 fixed=1750 ; WP
Button 4 = Channel 10 fixed=2000 ; Cruise

• User presses Button 1, assert PH (Ch10 = 1250)
• User presses Button 1, fallback to default Mode (Ch10 = 1000)
• User loses Video due to range or fault
• User presses Button 2, assert RTH (Ch10 = 1500)
• User unsure and presses Button 2 again, (Ch10 stays at 1500)
• User presses Button 4 after Video returned, to continue flight

So I like the fallback idea but it should be optional. Button rows on radios (like the 6pos row on the boxer) also sticks by default when pushing the same button multiple times. This functionality should be consistent and the fallback optional.