ESC HW Platinum V5 supported?

[ParkerEde]

Hello mstrens, many thanks for this great project. I have successfully used it with GPS, Vario and Hobbywing Platinum pro 130A V4 and Hobbywing Flyfun 80A V5. I use the current TEST branch. Now I have a Hobbywing Platinum 80A V5 and get no telemetry values at all. Is it possible that the Hobbywing Platinum V5 is also supported?
Many thanks and best regards
Ralf

[mstrens]

To implement telemetry for an Esc, I have to know the detail of the protocol or to find on internet another project that implement it.
If you can provide this, I can try to implement it.

[ParkerEde]

I tried the project from dgatf. There I only get data when I select VBAR. If I select Hobbywing Platinum 80A V4 as normal, I get the sensors but no values.
I think there may be a VBAR firmware in the ESC. Unfortunately, no other firmware is offered in the Hobbywing USB Link tool. Only the 4.1.00, but there is no mention of VBAR.
I can make test outputs with special versions of yours and provide them if that is helpful. I would be happy to assist with the implementation.

[mstrens]

I just found this

/*

• Hobbywing V5 Telemetry
• • Serial protocol 115200,8N1
• • Frame rate running:50Hz idle:2.5Hz
• • Little-Endian fields
• • Frame length over data (23)
• • CRC16-MODBUS (poly 0x8005, init 0xffff)
• • Fault code bits:

•     0:  Motor locked protection
  

•     1:  Over-temp protection
  

•     2:  Input throttle error at startup
  

•     3:  Throttle signal lost
  

•     4:  Over-current error
  

•     5:  Low-voltage error
  

•     6:  Input-voltage error
  

•     7:  Motor connection error
  

• Frame Format
• ――――――――――――――――――――――――――――――――――――――――――――――――――――――――
• 0-5: Sync header (0xFE 0x01 0x00 0x03 0x30 0x5C)

•  6:      Data frame length (23)
  

• 7-8: Data type 0x06 0x00

•  9:      Throttle value in %
  

• 10-11: Unknown

• 12:      Fault code
  

• 13-14: RPM in 10rpm steps
• 15-16: Voltage in 0.1V
• 17-18: Current in 0.1A

• 19:      ESC Temperature in °C
  

• 20:      BEC Temperature in °C
  

• 21:      Motor Temperature in °C
  

• 22:      BEC Voltage in 0.1V
  

• 23:      BEC Current in 0.1A
  

• 24-29: Unused 0xFF
• 30-31: CRC16 MODBUS

*/

It was in this link
https://github.com/rotorflight/rotorflight-firmware/blob/master/src/main/sensors/esc_sensor.c

Do you have a logic analyser to capture the data provided by the ESC and see if it matches this doc?

[ParkerEde]

Yes,I have alogic analyser. I will have a look.

[ParkerEde]

Here is a Sigrok PulseView sample:
HW-Platinum-80A-V5.zip

[ParkerEde]

I thinks this matches
Frame Format
――――――――――――――――――――――――――――――――――――――――――――――――――――――
0-5: Sync header (0xFE 0x01 0x00 0x03 0x30 0x5C)
6: Data frame length (23)
7-8: Data type 0x06 0x00
9: Throttle value in %
10-11: Unknown
12: Fault code
13-14: RPM in 10rpm steps
15-16: Voltage in 0.1V
17-18: Current in 0.1A
19: ESC Temperature in °C
20: BEC Temperature in °C
21: Motor Temperature in °C
22: BEC Voltage in 0.1V
23: BEC Current in 0.1A
24-29: Unused 0xFF
30-31: CRC16 MODBUS

[mstrens]

I tried to implement it in version 3.0.7 (in test branch on github).

I did not tested it.
Let me know if it is OK

[ParkerEde]

These are now my settings:

09:35:44.274 -> Version = 3.0.7
09:35:44.274 -> Function GPIO Change entering XXX=yyy (yyy=255 to disable)
09:35:44.274 -> Primary channels input = 255 (PRI = 5, 9, 21, 25)
09:35:44.274 -> Secondary channels input = 255 (SEC = 1, 13, 17, 29)
09:35:44.274 -> Telemetry . . . . . . . . = 0 (TLM = 0, 1, 2, ..., 29)
09:35:44.274 -> GPS Rx . . . . . . . . . = 1 (GPS_RX = 0, 1, 2, ..., 29)
09:35:44.274 -> GPS Tx . . . . . . . . . = 2 (GPS_TX = 0, 1, 2, ..., 29)
09:35:44.274 -> Sbus OUT . . . . . . . . = 255 (SBUS_OUT= 0, 1, 2, ..., 29)
09:35:44.274 -> RPM . . . . . . . . . . = 255 (RPM = 0, 1, 2, ..., 29)
09:35:44.274 -> SDA (I2C sensors) . . . . = 255 (SDA = 2, 6, 10, 14, 18, 22, 26)
09:35:44.274 -> SCL (I2C sensors) . . . . = 255 (SCL = 3, 7, 11, 15, 19, 23, 27)
09:35:44.274 -> PWM Channels 1, 2, 3 ,4 = 255 255 255 255 (C1 / C16= 0, 1, 2, ..., 15)
09:35:44.274 -> PWM Channels 5, 6, 7 ,8 = 255 255 255 255
09:35:44.274 -> PWM Channels 9,10,11,12 = 255 255 255 255
09:35:44.274 -> PWM Channels 13,14,15,16 = 255 255 255 255
09:35:44.274 -> Voltage 1, 2, 3, 4 = 255 255 255 255 (V1 / V4 = 26, 27, 28, 29)
09:35:44.274 -> RGB led . . . . . . . . . = 16 (RGB = 0, 1, 2, ..., 29)
09:35:44.274 -> Logger . . . . . . . . . = 255 (LOG = 0, 1, 2, ..., 29)
09:35:44.274 -> ESC . . . . . . . . . . . = 8 (ESC_PIN= 0, 1, 2, ..., 29)
09:35:44.274 -> Locator CS . . . . . . . = 255 (SPI_CS = 0, 1, 2, ..., 29)
09:35:44.274 -> SCK . . . . . . . = 255 (SPI_SCK= 10, 14, 26)
09:35:44.274 -> MOSI . . . . . . = 255 (SPI_MOSI=11, 15, 27)
09:35:44.274 -> MISO . . . . . . = 255 (SPI_MISO=8, 12, 24, 28)
09:35:44.274 -> BUSY . . . . . . = 255 (SPI_BUSY=0, 1, 2, ..., 29)
09:35:44.274 -> Output level High . . . . = 255 (HIGH = 0, 1, 2, ..., 29)
09:35:44.274 -> Output level Low . . . . = 255 (LOW = 0, 1, 2, ..., 29)
09:35:44.274 ->
09:35:44.274 -> Esc type is HW5 (Hobbywing V5)
09:35:44.274 ->
09:35:44.274 -> Protocol is Sport (Frsky)
09:35:44.274 -> CRSF baudrate = 420000
09:35:44.274 -> Logger baudrate = 115200
09:35:44.274 -> PWM is generated at = 50 Hz
09:35:44.274 -> Voltage parameters:
09:35:44.274 -> Scales : 1.000000 , 1.000000 , 1.000000 , 1.000000
09:35:44.274 -> Offsets: 0.000000 , 0.000000 , 0.000000 , 0.000000
09:35:44.274 -> No temperature sensors are connected on V3 and V4
09:35:44.274 -> RPM multiplier = 1.000000
09:35:44.274 -> Baro sensor is not detected
09:35:44.274 -> Airspeed sensor is not detected
09:35:44.274 -> No Vspeed compensation channel defined; oXs uses default settings
09:35:44.274 -> First analog to digital sensor is not detected
09:35:44.274 -> Second analog to digital sensor is not detected
09:35:44.274 -> Foreseen GPS type is Ublox (configured by oXs) :GPS is detected but has not (yet) a fix
09:35:44.274 -> Led color is normal (not inverted)
09:35:44.274 -> Failsafe type is HOLD
09:35:44.274 -> Acc/Gyro (MP6050) is not detected
09:35:44.274 ->
09:35:44.274 -> Gyro is not configured (Rc channel used to select the gyro mode/gain is not defined)
09:35:44.274 ->
09:35:44.274 -> No sequencers are defined
09:35:44.274 ->
09:35:44.274 -> Config parameters are OK
09:35:44.274 ->
09:35:44.274 -> Attention: some config parameters are not saved; use SAVE command
09:35:44.274 -> Press ? + Enter to get help about the commands

Unfortunately, I am not yet receiving any sensors from the ESC

[ParkerEde]

I have now made further attempts.
As soon as I add the Logicanalyser with a Y-cable between the ESC and RP2040, the sensors are transmitted
A little irregular, but they do come

13:13:02.811 -> processing cmd
13:13:02.811 ->
13:13:02.811 -> Cmd to execute: FV
13:13:02.811 ->
13:13:02.811 -> GPS Num sat. = 0
13:13:02.811 -> Volt 1 = 37121051 mVolt
13:13:02.811 -> Current (Volt 2) = 0 mA
13:13:02.811 -> Capacity (using current) = 0 mAh
13:13:02.811 -> Temp 1 (Volt 3) = 28 degree
13:13:02.811 -> Temp 2 (Volt 4) = 255 degree
13:13:02.811 -> RPM = 0 Hertz
13:13:02.811 -> pwmTop= 20000

But as soon as I step on the throttle, the transmission stops. I use an RM TX16S with EdgeTx. There I can see this at the points near the sensors.
If I connect the ESC directly to the RP20240, no data is transmitted at first. If I now step on the throttle, all sensors are transmitted once.

[ParkerEde]

As soon as the throttle is greater than -100%, the data is transferred at a different interval. If you go back to -100% with the throttle, the data is transferred more slowly again....I recorded this here with PulseView
HW-Platinum-80A-V5-with idle-running Motor-idle.zip

[mstrens]

I found a bug that could explain strange value for the voltage.
The bug had also an impact on RPM and current.

I put a new version 3.0.8 on github.
In this version, I also print to the PC (via usb) the content of each frame being received.
I also increase the checks on the bytes having fixed values.
I hope this help to reject false frames.
Currently I do not check the check digits.

I could not look at your capture in siglog format because I get an error when I try to use pulseviewer.
Perhaps can you make the capture in salea format(?).

If you get values only when you connect the logic analyser, it could be that you have to add a pull up resistor (e.g. 1K) between 3.3V and the ESC pin.

[ParkerEde]

Wow. Here you find the SerialMonitorDump
SerialMonitorDump.txt

A 1k pull-up resistor between 3.3V and the ESC pin does not change anything.

[mstrens]

Thanks.

• it shows that not all frames are correctly decoded (wrong begin)
• it happens (once at least) that a byte is not correctly capture (0xF0 instead of 0xFF).

Are you able to provide a capture in a salea logic analyser format? This could help to understand why some frames are not correctly decoded

[ParkerEde]

I have just tried it. But Salae doesn't recognise my logicanalyser. Sigrok cannot export it in .sal format either. I have tried the recording on several PCs and was able to open it directly. Strange
Did you try this one?:
https://sigrok.org/download/binary/pulseview/pulseview-NIGHTLY-x86_64-release-installer.exe

[ParkerEde]

This was captured with the version from above.
Its a new capture. Can you open this?
HW-Platinum-80A-V5-with idle-throttle-idle#2.zip

[mstrens]

My issue is that I installed the same version of pulseview as you. It succeeded but when I run it it says that a dll is missing.
I tried to upload it but it still did not succeed.
Still, it could be that I have to restart the PC. I will try now.

In fact I am looking if the ESC frames with the data we are looking for are always the first byte after the line stays HIGH for at least 8 msec. This is the criteria I use to detect the begin of a frame. Perhaps you can loot at this in your views.

[mstrens]

I installed the missing dll and now I can see your capture.

In one of them, I can see that the uart line is not always HIGH when there is no signal.
I think that adding a pullup resistor could solve the issue.
Can you try adding such a resistor (e.g. 1k ) between 3.3V and the ESC pin.
It could be that this create a new issues because in hobbywing V4 the line was not allowed to be high in the first (3?) seconds.
to be checked with the logic analyser if the ESC is still sending data with this pullup always present.

[ParkerEde]

If I insert a pull-up resistor of 1K between 3.3V and the ESC pin, the signal is permanently at 3.3V. No more signals get through

[ParkerEde]

Okay. I made the recording from this afternoon without the signal being connected to the RP2040 input (screenshot).
Now I will create another trace while the RP2040 is also connected. It will look completely different....

[mstrens]

It is perhaps like hobbywing V4 where the pullup is needed but can't be activated just after power on.

I put on github a version 3.0.9 where I activate automatically a pull up (from RP2040) 3 sec after power on.

Can you try to remove the external resistor and use 3.0.9. Pehaps, this will solve the issue.

[ParkerEde]

okay, I will try now.
Here you find a new trace while the RP2040 is connected with 3.0.8.
HW-Platinum-80A-V5-with idle-throttle-idlewith connected RP2040#4.zip

[ParkerEde]

Here is a PulseView Trace and the serial Monitor Hex dump
HW-Platinum-80A-V5-idle-throttle-idle-with connected RP2040-v3.0.9#5.zip

It looks good now. I will go on checking

[mstrens]

You last trace confirm that:

• line is usually LOW when there is no signal
• it goes HIGH nearly just before ESC is sending his frame
• it goes low some small time after the last byte of the frame.

In fact the line is bidirectionnal and the question is who is the master and when must the line have a pull up activated.

I do not have the specification.

I saw a link to a pdf on a german forum (RC-Heli I think) but it requires to be a member and when I try I do not get the email that I have to use to confirm that it is me.

Let see if last version (3.0.9) is OK

[mstrens]

Indeed it looks good.

Now look if the values reported by oXs (e.g. with FV command) are good.

[ParkerEde]

Yes, the values look quite good now. However, the value for Tmp2 always returns 255 degrees Celsius. Unfortunately, there is no correct temperature value for the BEC (field 20 only shows FF).

Could the HEX output in the serial monitor now be deactivated again? Or do we still need data?

[mstrens]

Now 3.0.10 where debug msg are disabled.

I could also avoid to send the second temp but perhaps that another device using V5 protocol could transmit it.
I can also discard it only when it is 0xFF. This is probably the best solution.

[ParkerEde]

Yes thats the best solution 👍
Many thanks

[ParkerEde]

Now I have started to calibrate the Platinum 80A V5. However, the Excel file shows a minus value for Offset2 (-1641.442308). The values displayed for Throttle are also correct so far. Unfortunately, I already get 1.6A displayed in idle mode. Is it possible that if the offset has a negative sign, this is not being converted correctly?

[mstrens]

The current is calculated like this where

• current is the value provided by the ESC in 0.1A (and is an integer)
• currentf is the value in float (so with decimals) taking count of the corrections scales and offsets (which are float too

So the sign must be correcly handled.

currentf = ((float)current) * 100.0 * config.scaleVolt2 - config.offset2;
if (currentf<0) currentf = 0;

What is the value of "current" (so in the frame) when throttle is at -100 (so I expect = 0 in the frame)?

[ParkerEde]

yes. In frame is 0 0 (field 17 and 18)
I think the problem is 0 * 100 * scale2-offset2 (in my case for offset2 - * - = + so currentf is positive in idle)

my values
scale2=0.948708791
offset2=-1641.442308

[ParkerEde]

Is there still a chance that the case of a negative offset2 value will be treated separately?