Support for 4 Byte Sensor Data - Baro Altitude etc

[jc9aj]

I'm in the process of designing a consolidated sensor module to work with the FS-iA6B receiver and an OpenTX transmitter. I've got it working great with a Current and External Voltage setup. Next stage is to hook up a BMP180/280/388 sensor for Baro Pressure and Temperature. The Cleanflight/Betaflight/OpenTx code supports it (Sensor Type 0x41) however there are a few changes required to your library to make it work:

1. Pressure sensor is a 4 byte payload rather than a 2 byte payload
2. The 4th Byte in the PROTOCOL_COMMAND_TYPE (which you have commented as always 0x02) is in fact the payload size in bytes. So for Baro Sensor this would be 0x04
3. The PROTOCOL_COMMAND_VALUE response would need to include 0x08 for the first byte, and the two additional bytes of payload. This, I believe, is formatted with the 19 Least significant bits being Pressure (in Pascals) and the 13 most significant bits being Temperature (in 0.1 deg C, and 0=-40 deg C - Similar to IBUSS_TEMP format)

I'm just wondering if you might make the changes necessary? I'm sure I can do it but it wont be as elegant as your code, and it might be a useful addition for others - especially if it includes the other Cleanflight/Betaflight sensors (GPS payloads etc)

Many Thanks

[bmellink]

Hi jc9aj,

More than happy to add support for this to the code. But I would need your support in testing it as I do not have an OpenTX tranceiver.

I was only aware of the sensor types for internal and external voltage, temperature and RPM as those were the only one supported by my tranceiver. I suspect there are a lot more. Do you have a reference of other sensor types? It would make sense to implement all the ones that are predefined. Where did you get the information on the specs?

regards
Bart

[jc9aj]

Awesome! There is an official Flysky/Turnigy Sensor for Altitude which i own (TGY-CAT01) however I think its only supported by later FS-I6/I6X firmware. I'm hoping to grow to add GPS parameters in the future (I'm oving over to using a Jumper T16 which plays nicely with Flysky Receivers and Telemetry).

I'm more than happy to help with testing, I've got a logic analyzer which is helpful for debugging

Here are the links to the OpenTX and Cleanflight GitHubs which describe the extended sensor set (I think these are driven by flight controller telemetry outputs):

https://github.com/cleanflight/cleanflight/blob/7cd417959b3cb605aa574fc8c0f16759943527ef/src/main/telemetry/ibus_shared.h

https://github.com/opentx/opentx/blob/2.3/radio/src/telemetry/flysky_ibus.cpp#L52

[bmellink]

Hi Jc9aj,

I created a branch of the repository called "sensor32". See https://github.com/bmellink/IBusBM/tree/sensor32
I think this could work. Would you mind testing?
See the "Additional telemetry sensors" section in the readme how this works. It is very simple: I added a second argument to addSensor function to define the number of bytes (should be 2 or 4).

The setSensorMeasurement(uint8_t adr, int32_t value) now takes an int32_t value (4 bytes). In your code you still need to do the bit shifting to create the 32 bits number to be passed as sensor value.

[jc9aj]

Nice work bmellink.

I had to make one change to get it to work:

Line 246 was changed to "if (len!=2 && len!=4) len = 2;" (it forced the sensorLength to always be 2 using the 'or' logic operator)

Other than that my only suggestion is to Define the SensorIds in the header as hexadecimal rather than decimal to be consistent with the Cleanflight notation.

Here's a couple of images of the sensors working on by FS-i6X and T16 and my sensor setup currently. The FS-i6X doesn't support the current sensor conversion so its just displayed in raw decimal

ogic

[bmellink]

thanks. I modified the (stupid) error in the if statement, merged the branch into master and created a new release (1.1.3) which should show up soon in the Arduino library manager. Thanks for helping out. I will leave this issue open for a few days in case you have any more issues/ additions.