I am using the standard Unity Input Manager, not the new input system.
I am connecting a joystick controller to my app, but it is not a standard Xbox/PSx type controller - it is a (Taranis) radio control transmitter of the type used on model aircraft. These are very 'soft', that is to say depending on the transmitter type they support a number of channels, and you can map any physical switch/pot/joystick to any channel within the transmitter. Typically, the first four channels are mapped to the sticks for throttle, yaw, pitch and roll, and you map extras as necessary. I have two extra switches mapped to channels five and six, two way, so the channel values they put out just change between max positive and max negative (the control sticks obviously give a varying value depending on position).
The transmitter has a USB output for behaving like a PC game controller, and it does - all six channels arrive in Unity.
However there is another (wireless) way of doing this: the transmitter transmits to a model RC receiver/flight controller, which has a USB port, which in turn connects to a PC just as the transmitter did - doesn't need a transmitter to PC USB cable, that's all. The receiver connects to a flight controller running software called Betaflight, and it is that which supports the PC USB link. All this works just as for the direct USB link - except for the extra channels.
In Unity, I am trying to find out where the extra channels have got to. There is a possibility that in Betaflight only the basic four are handled, don't know yet, I am trying to investigate from the Unity end.
In Unity, I have mapped all 28 physical joystick axes (all that appear to be available in Input Manager) to 28 virtual axes, called JoyAxis1 to JoyAxis28. These I read with Input.getAxisRaw("<virtual_axis_name>"); Works fine for the basic four channels, and the other two when using the USB link, but not the other two when going via Betaflight.
I do notice that the next two virtual axes in the list (when logically I would expect my two extras to show up) are all stuck at value '1', whereas the working axes all report -1 to +1 as expected, and the totally unused axes report 0. Makes me think something is happening on these axes, but not the right thing.
My question, after a long description, is this: Is it the case that the assignable axes 1 to 28 is it in terms of what Unity can read? Could these channels be turning up in some other form I have not yet read? And the subsidiary question is, can I get at the true raw values coming from the input hardware (the hardware certainly does not produce a float -1 to +1, more likely an integer 0 to 1023, or -128 to +127, or similar, so there is input processing going on, I'd rather get behind that and do it myself.
