Ibus telemetry support

[pacnsave]

Hi,

I understand that the Lua doesnt work with the flysky Ibus telemetry protocol. Is it possible to add this feature?

I have tried to rename the sensors on my radio to match the frsky naming system but that doesn't work maybe there's a workaround?

Thanks

[AWegner1]

I'm interested in getting this to a working state too. Would be awesome to use the FlySky-Receivers for this.

[teckel12]

@pacnsave It's possible for sure, but there's things missing in the ibus telemetry that would need to be added. There's also a possibility that some of the ibus telemetry would need to change, which is more challenging because it should really be extended not changed to keep any legacy support.

As far as what's needed, the first thing would be changing INAV to export the missing telemetry that's needed by INAV Lua Telemetry. The problem I have is that I don't fly ibus so I don't have the ability to develop or test.

With the case of FrSky D-series telemetry, someone who used that telemetry made the changes to INAV. That would also probably need to happen for ibus support.

Once INAV is modified, INAV Lua Telemetry may not need to change at all for ibus to work. Or, just a simple sensor remapping. It depends on what telemetry ibus currently includes (which I really don't know).

For a start, if someone with ibus could provide a listing of all the telemetry sensors on their transmitter. That would allow me to go through what would need to be added for it to work. Or, identify possible issues (like a sensor that would need to change rather than just be extended).

[teckel12]

Looking into ibus telemetry, it seems you can set the value ibus_telemetry_type and there's currently 8 different telemetry types. So, we could either piggyback off #8 or just create ibus_telemetry_type = 9 for INAV Lua Telemetry.

I have no idea of what the limitations are for ibus telemetry, but creating ibus_telemetry_type 9 and trying to duplicate the flight modes like in FrSky telemetry seems like the next logical step. But, I'll need someone flying ibus who wants to be a guinea pig.

[pacnsave]

I can do some testing if you need it.

[teckel12]

https://github.com/iNavFlight/inav/blob/master/docs/Telemetry.md#ibus-telemetry

[teckel12]

@pacnsave What do you use for ibus_telemetry_type? It seems most are just slight differences with imperial to metric differences. That's going to greatly complicate things (or we're simply going to need to support one type and deal with any conversions).

In addition to the ibus_telemetry_type I would also like to know what telemetry sensors you're showing on your transmitter. It seems INAV is possibly outputting most everything that INAV Lua Telemetry would need, but it also seems that maybe only certain receivers support certain telemetry which could cause a problem.

Seeing your telemetry sensors would absolutely help. Also, what receiver are you using?

[pacnsave]

@teckel12 i haven't changed the ibus_telemetry_type just left it as default which is 0 i assume. I'm using a flit 10 receiver with a jumper t16. Here are all the sensors I'm discovering note i haven't got a gps, baro, mag but will add this soon

[teckel12]

All the sensors with the same name is going to be a problem. If you delete all sensors and then rediscover do they all reappear like that? Also, we'll probably need to see all the sensor names with GPS/baro/compass as this could be why they're all labeled RPM with values of zero.

[pacnsave]

Yes that's how they appear I can change the name, id, unit etc in the radio and this doesn't effect the reading from the flight controller.

If I'm not mistaken the type of sensor inav send are as you see in the screenshot. https://github.com/iNavFlight/inav/blob/master/docs/Telemetry.md#ibus-telemetry I can get back to you when I install the compass/baro in the next few days

How does the Lua read the telemetry information is it take from the name of the sensors Id? Maybe it would be as simple as changing this information?

[teckel12]

@pacnsave The sensor names are the key, that's how lua works with telemetry in OpenTX. So sure, the sensor names can be changed, it just makes it a bit dicey to provide instructions, because the user would need to know which sensors were which. Like if acc_x, acc_y, and acc_z are all named RPM, it's kinda a challenge to know which to name what. And if multiple sensors have the same name OpenTX just sends one randomly, so bad things can happen.

[pacnsave]

I have tried to change telemetry type this is what it does. So it's possible to use these to rename each sensor to the correct name. (Telemetry type 3)

I also tried renaming the sensors to the correct name but that doesn't seem to work, maybe I'm missing a sensors it needs to function? The biggest problem I have found is the acc_x, acc_y,and acc_z are not showing data and compass has one to many numbers (0007)

[teckel12]

@pacnsave No idea what any of these sensors are. The problem with many of them named the same make it VERY challenging to the average user to know which one to change to what. Like how would you tell someone to change one of the RPM sensors to TMP2? Which RPM sensor?

If I were you...

Step 1, delete all sensors Step 2, discover sensors Step 3, don't change sensor types (like those named TMP are not temperatures and shouldn't be shown as a temp). Step 4, identify what each sensor represents, using the ibus telemetry code as a guide: https://github.com/iNavFlight/inav/blob/master/src/main/telemetry/ibus.c

I can do none of this as I don't have ibus. I also don't what you're referring to about acc_x, acc_y, acc_z. What are you talking about? I don't see these sensors in any of your pics. Are you seeing something you're not sharing? Confused.

In any case, someone using ibus will need to all the legwork on identifying all of the sensors, making documentation, and then extending the ibus telemetry to include anything missing. Basically, an ibus expert and probably a programmer will be required, which isn't me as I don't fly ibus. But at this point, there no way to add ibus support because the necessary information doesn't exist.

[qba667]

@teckel12 looking at the topic a lot of clean-up is needed on iNAV and on OpenTX. iNav Is using old implementation from hali9 - for some years I refactored it in Betaflight. Open tx is not implementing all types of sensors that are available - it just must be added. Most of definitions from https://github.com/iNavFlight/inav/blob/dbdd1656a84ee4f09ebc14b4c0b86a9476a48f46/src/main/telemetry/ibus_shared.h are valid - but it should be rewritten.

[teckel12]

@qba667 It also looks like because it's using old sensors, OpenTX is not labeling the sensors correctly, so it's near impossible to even know what sensors to name what. Also, it seems that there's several different IBUS telemetry options, with different sensors (making things even more complex).

It's really looking more like this is an INAV/OpenTX issue, and once good telemetry data is being sent to the transmitter, then Lua Telemetry could be adjusted to use that telemetry information.

If INAV needs to change, it would be nice if the telemetry is as close to SBUS as possible. Also, making the changes to INAV/OpenTX would need to be made by someone actually using IBUS as I have no way of testing and honestly have little interest in learning when I'm not going to use the protocol anyway.

[AWegner1]

I have IBUS and OpenTX hardware available, when there is the need to check or code something with it I am open for this.

[teckel12]

I now have an ibus receiver and a FLYSKY transmitter so I should be able to do some testing.

[qba667]

@teckel12 but we need to hack internal RF module so it will receive all telemetry. It seems there is also code in NV14 internal module to update receivers - but so far I have not figured it out how to trigger it. I can implement my IBUS telemetry from BetaFlight because there I made clean-up to be as close as possible to other protocols.

[j1r1]

I am interested and can do some testing with Taranis, Jumper, iA6B and various INAV FCs. Implementing work done in Betaflight sounds promising. But fixing of INAV IBUS telemetry should not focus on a particular receiver (like NV14, although hack of update procedure would be nice to have as well).

[j1r1]

The list of discovered sensors has changed probably since recent fix of IBUS protocol done by qba667. Especially I noticed valid GPS coordinates (OK, just two decimals and expressed in Volts :-) )at positions 13 and 14:

[teckel12]

@j1r1 Most sensors being named RPM or A3 make the possibility of using this next to impossible. Even if usable information would be provided (which I'm not sure of) the amount of user modification. Required would be a challenge to it it working for anyone. As the sensors are added in a different order each time you do a discovery, you can't instruct users as to which RPM or A3 sensor to change to what name.

This issue is being shelved till there's better telemetry data that can be identified in a logical way (which is outside thr scope of Lua Telemetry and maybe even INAV, as it may be an OpenTX and/or FlySky issue).

[j1r1]

@teckel12 I understand that this is not matter of Lua Telemetry only. But please be aware that while the order of the sensors varies, their IDs (very right column of my pictures) are unique and can be used to assign their names (although they do not correspond to Telemtry.md doc precisely). What I have found out so far using iA6B+OminbusF4v3+T16:

• first nine sensor data (IDs 0 or 250 or 255) are generated by the receiver alone and some of them have understandable meaning (RSSI, RNse, RSNR) but ID 0 Following IDs mean:
  1. Ubat
  2. baro sensor temperature
  3. status (mode?)
  4. course
  5. a voltage value derived from Ubat
  6. most probably current
  7. ? maybe direction to home?
  8. ? maybe distance to home?
  9. ? maybe GPS course?
  10. ? maybe GPS altitude?
  11. LAT second part
  12. LON second part
  13. LAT first part
  14. LON first part
  15. most probably GPS speed

[j1r1]

I looked into the ibus_shared.c source file (Cleanflight) and found it there. So let's take my previous observations as confirmation that it works (and sorry for incorrect recognition of 5 and 6) : 1 ,sensor 2, VBAT 2, sensor 3, Baro/Gyro Temp 3, sensor 4, Status AS RPM 4, sensor 5, MAG_COURSE in deg AS RPM 5, sensor 6, Current in A AS ExtV 6, sensor 7, Baro Alt in cm AS ExtV 7, sensor 8, HOME_DIR in deg AS RPM 8, sensor 9, HOME_DIST in m AS RPM 9, sensor 10,GPS_COURSE in deg AS RPM 10,sensor 11,GPS_ALT in m AS RPM (ALT m) 11,sensor 12,GPS_LAT2 AS RPM 5678 (-12.3456789 N) 12,sensor 13,GPS_LON2 AS RPM 6789 (-123.4567890 E) 13,sensor 14,GPS_LAT1 AS ExtV -12.45 (-12.3456789 N) 14,sensor 15,GPS_LON1 AS ExtV -123.45 (-123.4567890 E) 15,sensor 16,GPS_SPEED in km/h AS RPM (SPE km\h)

[teckel12]

The user would be required to change all of their sensor names EXACTLY correct, and on the X7 you can't see the IDs until you go into each sensor. So the names of each of these need to be changed to the SBUS telemetry names (case sensitive). Once that is done, Lua Telemetry will get most of the information it needs, see what happens!

[qba667]

@teckel12 it is outgoing right now - currently only for multi-protocol module. Should be ready until Monday. @j1r1 it is a little bit different than you think.

[pacnsave]

I would like to note that to get the Lua working the RSSI value should be above zero, Ibus RSSI shows a minus value so it doesn't work unless you change it in opentx

[teckel12]

@pacnsave In LuaTelemetry v1.7.2 and later, it doesn't get the RSSI directly from the sensor. It gets it from the same RSSI value that is sent to the transmitter. For example Crossfire telemetry has inverted RSSI values (neither of which are labeled RSSI) but LuaTelemetry doesn't use those. It takes what the protocol is sending to the transmitter for signal quality.

[qba667]

@pacnsave @teckel12 I was working with Pascal on this. Few small changes are needed in BF - because I never tested it before with GPS - and this was buggy. Here is the repository: https://github.com/pascallanger/opentx/tree/sweet-pascal And that is our actual telemetry list

const FlySkySensor flySkySensors[] = {
  {AFHDS2A_ID_VOLTAGE|0x100,    ZSTR_A1,                UNIT_VOLTS,                  2},  // RX Voltage (remapped, really 0x0)
  {AFHDS2A_ID_TEMPERATURE,      ZSTR_TEMP1,             UNIT_CELSIUS,                1},  // Temperature
  {AFHDS2A_ID_MOT,              ZSTR_RPM,               UNIT_RAW,                    0},  // RPM
  {AFHDS2A_ID_EXTV,             ZSTR_A3,                UNIT_VOLTS,                  2},  // External voltage
  {AFHDS2A_ID_CELL_VOLTAGE,     ZSTR_CELLS,             UNIT_VOLTS,                  2},  // Avg Cell voltage
  {AFHDS2A_ID_BAT_CURR,         ZSTR_CURR,              UNIT_AMPS,                   2},  // battery current A * 100
  {AFHDS2A_ID_FUEL,             ZSTR_CAPACITY,          UNIT_RAW,                    0},  // remaining battery percentage / mah drawn otherwise or fuel level no unit!
  {AFHDS2A_ID_RPM,              ZSTR_RPM,               UNIT_RAW,                    0},  // throttle value / battery capacity
  {AFHDS2A_ID_CMP_HEAD,         ZSTR_HDG,               UNIT_DEGREE,                 0},  // Heading  0..360 deg, 0=north 2bytes
  {AFHDS2A_ID_CLIMB_RATE,       ZSTR_VSPD,              UNIT_METERS_PER_SECOND,      2},  // 2 bytes m/s *100
  {AFHDS2A_ID_COG,              ZSTR_HDG,               UNIT_DEGREE,                 2},  // 2 bytes  Course over ground(NOT heading, but direction of movement) in degrees * 100, 0.0..359.99 degrees. unknown max uint
  {AFHDS2A_ID_GPS_STATUS,       ZSTR_SATELLITES,        UNIT_RAW,                    0},  // 2 bytes
  {AFHDS2A_ID_ACC_X,            ZSTR_ACCX,              UNIT_METERS_PER_SECOND,      2},  // 2 bytes m/s *100 signed
  {AFHDS2A_ID_ACC_Y,            ZSTR_ACCY,              UNIT_METERS_PER_SECOND,      2},  // 2 bytes m/s *100 signed
  {AFHDS2A_ID_ACC_Z,            ZSTR_ACCZ,              UNIT_METERS_PER_SECOND,      2},  // 2 bytes m/s *100 signed
  {AFHDS2A_ID_ROLL,             ZSTR_ROLL,              UNIT_DEGREE,                 2},  // 2 bytes deg *100 signed
  {AFHDS2A_ID_PITCH,            ZSTR_PITCH,             UNIT_DEGREE,                 2},  // 2 bytes deg *100 signed
  {AFHDS2A_ID_YAW,              ZSTR_YAW,               UNIT_DEGREE,                 2},  // 2 bytes deg *100 signed
  {AFHDS2A_ID_VERTICAL_SPEED,   ZSTR_VSPD,              UNIT_METERS_PER_SECOND,      2},  // 2 bytes m/s *100
  {AFHDS2A_ID_GROUND_SPEED,     ZSTR_GSPD,              UNIT_METERS_PER_SECOND,      2},  // 2 bytes m/s *100 different unit than build-in sensor
  {AFHDS2A_ID_GPS_DIST,         ZSTR_DIST,              UNIT_METERS,                 0},  // 2 bytes dist from home m unsigned
  {AFHDS2A_ID_ARMED,            ZSTR_ARM,               UNIT_RAW,                    0},  // 2 bytes
  {AFHDS2A_ID_FLIGHT_MODE,      ZSTR_FLIGHT_MODE,       UNIT_RAW,                    0},  // 2 bytes index
  {AFHDS2A_ID_PRES,             ZSTR_PRES,              UNIT_RAW,                    2},  // 4 bytes In fact Temperature + Pressure -> Altitude
  {AFHDS2A_ID_PRES|0x100,       ZSTR_TEMP2,             UNIT_CELSIUS,                1},  // 2 bytes Temperature
  {AFHDS2A_ID_ODO1,             ZSTR_ODO1,              UNIT_METERS,                 2},  // 2 bytes Odometer1 -- some magic with 330 needed
  {AFHDS2A_ID_ODO2,             ZSTR_ODO2,              UNIT_METERS,                 2},  // 2 bytes Odometer2 -- some magic with 330 needed
  {AFHDS2A_ID_SPE,              ZSTR_ASPD,              UNIT_KMH,                    2},  // 2 bytes Speed km/h -- some magic with 330 needed
  {AFHDS2A_ID_TX_V,             ZSTR_TXV,               UNIT_VOLTS,                  2},  // TX Voltage
  {AFHDS2A_ID_GPS_LAT,          ZSTR_GPS,               UNIT_RAW,                    7},  // 4 bytes signed WGS84 in degrees * 1E7
  {AFHDS2A_ID_GPS_LON,          ZSTR_GPS,               UNIT_RAW,                    7},  // 4 bytes signed WGS84 in degrees * 1E7
  {AFHDS2A_ID_GPS_ALT,          ZSTR_GPSALT,            UNIT_METERS,                 2},  // 4 bytes signed GPS alt m*100
  {AFHDS2A_ID_ALT,              ZSTR_ALT,               UNIT_METERS,                 2},  // 4 bytes signed Alt m*100

  {AFHDS2A_ID_RX_SNR,           ZSTR_RX_SNR,            UNIT_DB,                     0},  // RX SNR
  {AFHDS2A_ID_RX_NOISE,         ZSTR_RX_NOISE,          UNIT_DB,                     0},  // RX Noise
  {AFHDS2A_ID_RX_RSSI,          ZSTR_RSSI,              UNIT_DB,                     0},  // RX RSSI (0xfc)
  {AFHDS2A_ID_RX_ERR_RATE,      ZSTR_RX_QUALITY,        UNIT_RAW,                    0},  // RX error rate
  {TX_RSSI_ID,                  ZSTR_TX_RSSI,           UNIT_RAW,                    0},  // Pseudo sensor for TRSSI

  {0x00,                        NULL,                   UNIT_RAW,                    0},  // sentinel
};

As far as it is all name based it should work just fine. Now it is time to address iNav implementation itself, because it is a little obsolete.

[teckel12]

@qba667 If the sensors can't be named in OpenTX automatically like with FrSky and Crossfire, a lua script can be run to assign more appropriate sensor names using the setTelemetryValue function.

https://opentx.gitbooks.io/opentx-2-2-lua-reference-guide/general/setTelemetryValue.html

Much like there is a Crossfire lua script, an IBUS telemetry script could be created that would use the setTelemetryValue function to assign appropriate sensor names. It would be ideal if Betaflight and INAV both had the same IBUS telemetry sensors so a single script could be used for both. Even including this script in OpenTX would be possible as the Crossfire script is part of the standard SD card already.

I would suggest using sensor names defined with other telemetry protocols as much as possible to limit confusion. Here's some sample documentation:

https://github.com/teckel12/inav/blob/master/docs/Telemetry.md#available-smartport-sport-sensors https://github.com/teckel12/inav/blob/master/src/main/telemetry/smartport.c#L62 https://github.com/teckel12/inav/blob/master/src/main/telemetry/frsky.c#L19

This is very much still outside the scope of Lua Telemetry. But, once IBUS telemetry has been standardized and formatted in such a way that the information is all available, Lua Telemetry can be tweaked to support IBUS.

[teckel12]

I never tried using the setTelemetryValue function till today. Seems it can't be used to change sensor names if they already exist. So this would only work if the user would delete all sensors before running a script to set the sensors.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.