✨FEATURE: Allow to get 16-bit ibus channel data

[gandy92]

Is your feature request related to a problem? Please describe.
The FlySky receiver FS-IA6B outputs 16-bit channel data on the IBUS, which are available through ibus::getChannel(rc_channels_t *channelData). This being 11-bit data works fine as long as the data stays in the usual range of values from 1000 through to 2000.

However, an RC control can be tuned to output a larger range of values, e.g. 906 to 1058, which leads to an overflow in the rc_channel_t channel values, resulting values above 1047 to be wrapped to values starting with 0.

Describe the solution you'd like
One way to solve the issue would be to add a second getChannel() method, allowing the user to alternatively get the 16-bit channel data:

void ibus::getChannel(ibus_channels_t *channelData) {
  memcpy(channelData, (uint8_t *)&_channelData, sizeof(ibus_channels_t));
}

Describe alternatives you've considered
A workaround exists on the application level where each channel value 0..499 is wrapped to values 1048..1547, expecting that no receiver outputs values below 500.

[Witty-Wizard]

@gandy92 ,
My understanding is 11-bits give a range of 0-2048, which should be enough for standard packets, but having 16-bits of data packets is a more robust solution.

[gandy92]

@Witty-Wizard , definitely an edge case - until I've seen those values wrapping around, I had assumed the same.

[Witty-Wizard]

@gandy92, I have created a new branch, for this issue

[Witty-Wizard]

@gandy92, I have created a PR #32 for this issue, please check that and share your thoughts, also I have made the method available from the SerialIO class, not the best solution but it should work

[gandy92]

I've compiled and run my example sketch with that branch and everything seems to work fine. I agree with your mild concerns about this function being a member of the SerialIO base class. For debugging purposes I had added the member function only to the ibus class (without the override) which worked fine and my thoughts at the time were to maybe change the rc_channels_t to allow for more bits. I'd put aside that thought because I did not want to risk side effects just to output some debugging info. Maybe, if this does not break the existing API, it is worth considering using 16 bit in the rc_channels_t in the first place (if there are no other requirements than saving a few bytes of memory). That said, I don't really feel too strongly about this.

[Witty-Wizard]

@gandy92, The reason to use 11bit channels in the first place was because protocols like Sbus and crsf transmit in 11 bits so it is easier to decode by just memcpying the buffer to the target structure

As shown in here

[gandy92]

@Witty-Wizard , I see - and makes perfect sense, too. I'm afraid I don't see an obvious solution to this, other than what you have implemented already.

[Witty-Wizard]

@gandy92, Well if the solution works i think it is good enough. I am going to merge it into the main branch