Add BLHeli_32 ESC telemetry support

Steini63 commented 5 months ago

Hello!

I would be very happy if BlHeli_32 telemetry could be implemented. Even if this would make my own converter ( https://www.franksteinberg.de/BLHeliTelemetryFeeder.html ) more or less superfluous. BlHeli_32 ESCs are cheap and widely available. In the meantime, the first models with BEC for fixed-wing airplanes are also on the market.

The protocol is very simple and documented here: http://ultraesc.de/downloads/KISS_telemetry_protocol.pdf

Other than described there, the ESCs can be configured to auto-telemetry since version 32.6, so that only reception via one line is necessary. Since firmware 32.8 BlHeli can also output FrSky S.Port directly, but S.Port only and not for all ESCs (not every cpu used, can output the inverted signal). Auto-telemetry (Kiss) in uninverted and works always.

Regards Frank

mstrens commented 5 months ago

I added some code in version 2.11.8 (in test branch on github) in order to process blHeli frames (based on the doc you provided). The ESC has to be configured to provide the frames automatically.

I did not tested the code. If you find some bugs, let me know.

Steini63 commented 5 months ago

WOW that was fast!

Ok, I tested with EdgeTx 2.10 - FrSky X8R S.Port. After a sensor search i got:

Sensor "5123" with data for capacity (mAh); values are plausible
Sensor "Tmp1" with data for temperature in °C; values are inplausible (-64°C)
Sensor "VFAS" with data for voltage in V; values are plausible
Sensor "Curr" with data for current in A; values are plausible
Sensor "RPM" with data for rpm; values are inplausible (much too low)

SPort_Sensors

On terminal I got permanent reports about crc errors: crcerror

Thanks Frank

Steini63 commented 5 months ago

For S.Port I suggest the sensor IDs that BLHeli itself uses. The advantage is that two 16bit values can be transmitted in one data frame (except for temperature). SPort_IDs_for_ESC

If i.e. sensor ID is 0x0B50:

byte of payload is voltage LSB
byte of payload is voltage MSB
byte of payload is current LSB
byte of payload is current MSB

If i.e. sensor ID is 0x0B60:

byte of payload is rpm LSB
byte of payload is rpm MSB
byte of payload is consumption LSB
byte of payload is consumption MSB

If i.e. sensor ID is 0x0B70: All 4 bytes payload is temperature (LSB first).

So does it look on EdgeTX: SPort_native-Sensors

Frank

mstrens commented 5 months ago

I put 2.11.10 on github. I fixed a bug for Temp. Temp will now be 96 more. I do not find a bug for RPM. I assume that ESC provides a value in 100rpm. So I multiply the value with 100 and I divide it by 60 (to convert from rpm to Hz). I changed the error message about wrong crc. I added the number of wrong frame / total number of frame and I display the 10 bytes from the frame. This should give an idea of the % of rejected frames. Note: did you have pullup resistors on scl and sda. I read that this help reducing the frame errors.

At this stage, I do not plan to combine 2 data into one telemetry fields. It is a quite big change and should not be valid for other protocols.

Steini63 commented 5 months ago

I fixed a bug for Temp. Temp will now be 96 more.

That did it - thanks.

I do not find a bug for RPM. I assume that ESC provides a value in 100rpm. So I multiply the value with 100 and I divide it by 60 (to convert from rpm to Hz).

You are right, the ESC sends 100rpm values. I assume EdgeTx multiplies the values internally when the sensor IDs I mentioned above are used. I get plausible values when I enter "7" for Blades/Poles for a 14-pole motor and a multiplier of "60" (although I don't understand the "60" because I want to stick with minutes as the basis).

At this stage, I do not plan to combine 2 data into one telemetry fields. It is a quite big change and should not be valid for other protocols.

I understand, thanks for clarifying.

I changed the error message about wrong crc. I added the number of wrong frame / total number of frame and I display the 10 bytes from the frame. This should give an idea of the % of rejected frames.

The % seem to be 100 :-(

Error in CRC from Blheli frame: 2000 / 5683 ff 21 5 3 0 24 0 2c
Error in CRC from Blheli frame: 2001 / 5685 ff 21 4 c5 0 24 0 2c
Error in CRC from Blheli frame: 2002 / 5687 ff 21 4 ee 0 24 0 2c
Error in CRC from Blheli frame: 2003 / 5688 ff 21 4 cd 0 24 0 2c
Error in CRC from Blheli frame: 2004 / 5702 ff 21 4 db 0 23 0 2c
Error in CRC from Blheli frame: 2005 / 5703 ff 21 4 fb 0 23 0 2c
Error in CRC from Blheli frame: 2006 / 5704 ff 21 4 d9 0 24 0 2c
Error in CRC from Blheli frame: 2007 / 5709 ff 21 4 f8 0 23 0 2c
Error in CRC from Blheli frame: 2008 / 5711 ff 21 4 cf 0 24 0 2c
Error in CRC from Blheli frame: 2009 / 5719 ff 21 5 2 0 23 0 2c
Error in CRC from Blheli frame: 2010 / 5723 ff 21 4 f0 0 23 0 2c

This is a real data logging from BLHeli (HTerm), last byte per line is the checksum:

BLHeli-log

Frank

mstrens commented 5 months ago

It seems that there are quite many frame errors. When it occurs, the first byte is 0xFF. I suspect it is related to some noise on the UART wire. I suggest that you add a 1K resistor between the UART wire and 3.3V. There was a bug (that I fixed in version 2.11.11) in the number of bytes being displayed (8 instead of 10). I also now display the content of valid frames (only one on 100).

Steini63 commented 5 months ago

Ok, I got it! I had 1k in series with BlHeli Tx from the beginning, that causes the problem.

Reducing that to 220ohm fixes the crc errors.
470ohm and a 2.2k pullup ist working also.
Direct connection is also ok.

valid Blheli frame: 46100 21 4 fc 0 4 0 1a 0 0 b0 valid Blheli frame: 46200 21 4 df 0 4 0 1a 0 0 77 valid Blheli frame: 46300 21 4 d9 0 4 0 1a 0 0 bb valid Blheli frame: 46400 21 4 ea 0 4 0 1a 0 0 af valid Blheli frame: 46500 21 4 fd 0 4 0 1a 0 0 6f valid Blheli frame: 46600 21 4 b8 0 4 0 1a 0 0 80 valid Blheli frame: 46700 21 4 fc 0 4 0 1a 0 0 b0 valid Blheli frame: 46800 21 4 e0 0 4 0 1a 0 0 fc valid Blheli frame: 46900 21 5 4 0 4 0 1a 0 0 f4 valid Blheli frame: 47000 21 4 ce 0 4 0 1a 0 0 7b valid Blheli frame: 47100 21 4 d4 0 4 0 1a 0 0 fb valid Blheli frame: 47200 21 4 fc 0 4 0 1a 0 0 b0 valid Blheli frame: 47300 21 4 fd 0 4 0 1a 0 0 6f valid Blheli frame: 47400 21 4 ec 0 4 0 1a 0 0 63 valid Blheli frame: 47500 21 4 c9 0 4 0 1a 0 0 68 valid Blheli frame: 47600 21 4 d9 0 e 0 1a 1 42 ba valid Blheli frame: 47700 21 4 d9 0 e 0 1a 1 3d c0 valid Blheli frame: 47800 21 4 da 0 e 0 1a 1 31 82 valid Blheli frame: 47900 21 4 fb 0 4 0 1a 0 0 a3 valid Blheli frame: 48000 21 4 f4 0 4 0 1b 0 0 31 valid Blheli frame: 48100 21 4 fa 0 4 0 1b 0 0 17

Thank you very much for your efforts. Tomorrow I want to test with iBus.

Good night Frank

mstrens commented 5 months ago

Thanks for the feedback. In principe it should work with all protocols because sending the data does not depend on the way the data are collected.

Steini63 commented 5 months ago

Hi again!

iBus Test is positive as expected, except the surplus temperature sensor:

iBus_Sensors

Frank

mstrens commented 5 months ago

I hope it is now fixed in 2.11.12 version. FYI, in this version, I also disabled the messages giving the content of the BlHeli frame.

Steini63 commented 5 months ago

I hope it is now fixed in 2.11.12 version.

It is! Thank you.

mstrens / oXs_on_RP2040

Add BLHeli_32 ESC telemetry support #122