Servers by jDrones

BLHeli32 ESC telemetry setup - how?


(Paul Atkin) #7

so, there was a bad solder of a signal wire and rx line was on ground.

i re-soldered, and now i see a bunch of bad crc errors thrown:

ESC: Bad CRC on 3
ESC: Bad CRC on 2
ESC: Bad CRC on 2
ESC: Bad CRC on 3
ESC: Bad CRC on 2
ESC: Bad CRC on 0
ESC: Bad CRC on 3
ESC: Bad CRC on 2

GPS 1: detected as u-blox at 115200 baud
ESC: Bad CRC on 1
Barometer calibration complete
Initialising APM
Calibrating barometer
finished motor test
Initialising APM
starting motor test
PreArm: Throttle below Failsafe
PreArm: Throttle below Failsafe
Frame: QUAD
KakuteF7 00410023 34345117 39383339

i also noted that SERIAL5_BAUD for some reason was automatically altered to the value 115200.
it probably was supposed to be 115? go figure.

All signal wires are made from coax antennas, with a grounded shield, so signal should be clear.


(Evan Williams) #8

The other thing I can think of is whether the input needs to be inverted . . . The Kakute F7 supports hardware UART inversion, but I don’t know how to configure that from ArduPilot.


(Paul Atkin) #9

i am not sure. i did not think this esc stream was actually inverted. go figure. do you have it working on the chibios or nuttx?


(Paul Atkin) #10

hi, could anybody comment or explain how to use logic analyzer to troubleshoot this esc telemetry signal?
how is it supposed to look like? a screenshot would help.


(Evan Williams) #11

I had it working on the ChibiOS version.

As for the signal analysis, I’m not familiar enough with the encoding of telemetry to distinguish inverted from un-inverted (It would look visually like a subtle difference aside from any preambles).

What I would try is changing UARTs to one more mainstream. I would also try just one ESC on said UART, and disable UART7 while setting the function for the new one.


(Paul Atkin) #12

uart7 is not possible to alter due to the layout and all soldering done.
i tested it before this work was done with a gps unit on it. all worked. uart config and hardware is operational.


(wkf94025) #13

I experienced the bad CRC message months ago when I was on an older version of the blheli 32 firmware. Upgrading in July to the latest firmware eliminated that error message for me. I am using a single ESC on a Matek f405-wing. The only place I saw evidence of ESC telemetry was in DF logs and in the OSD.


(Paul Atkin) #14

that is what i see when i read the esc status. is it a last version? or same one you use?
hmm. bhheli suite i started says in its header - 32.6.0.4. should i try to flash it, or, is it even relevant, if current version in the ESCs is 32.4?


(Paul Atkin) #15

so, i tried to flash 32.6 into those esc. it went in ok. motors worked ok.
but, it is either a bug or who knows what it is - the leds on those escs stopped working - in the config utility it would light them up ok when you save settings, but after reboot leds would not light up anymore. as i got those ESCs specifically for those LEDs - it had to go, this 32.6 version.

also, CRC errors did not go away from MP and telemetry did not appear.
so, i for now disabled it onuart, i guess it is not something that may/will work reliably. tested uart again as well with gps just to prove my sanity.

so it is back to 32.4 with working leds and no telemetry. if anybody else will have those escs - pls let me know what the hell it wants in order to work ok.


(wkf94025) #16

Do you have a Matek FC (supported by ChibiOS) available as a bench test on one of those ESCs? On a low-numbered UART? That’s what I would try next.


(Rainer Walther) #17

I think I have a similar problem.
Got an “Omnibus F4 Nano V6” FC with a “Ori32 25A 4in1” ESC.
They are connected with the “4in1 socket” which also connects ESC telemetry TX-wire to UART4.

I activated UART4 in “OmnibusNanoV6/hwdef.h” and compiled Copter-3.6-RC12 branch.

UART_ORDER OTG1 USART6 USART1 UART4
PA1 UART4_RX UART4

Configuration in Mission Planner

SERVO_BLH_AUTO,1
SERVO_BLH_DEBUG,1
SERVO_BLH_MASK,15
SERVO_BLH_TRATE,10

UART4 seems to be mapped to Serial2:

SERIAL2_BAUD,115 (If I verify later parameter is changed automatically to “115200”! Is this correct?)
SERAIL2_PROTOCOL,16

Battery monitor set to BLHeli ESC

BAT_MONITOR,9

Then I get readings in Mission Planner Status-Tab for “battery_voltage” and “current”.
“battery_voltage” shows correct voltage.
“current” is way too low. I guess it shows only the current from one ESC.
The “esc*” readings are all zero!
There are no ESC messages in Mission Planner Messages-Tab.

The ESC are running version 32.4.

Any idea how to get the “esc*” readings and correct current?


(Paul Atkin) #18

if you have such a capability - can you pls try flashing betaflight to your omnibus to confirm if it will read correctly esc data in the power options tab?


(Michael Nunan) #19

I have BLHeli32 working with a PixHawk and a SPEDIX 4in1 40A. I am getting some bad CRC messages with latest BLHeli - no observble impact.

I only get telemetry from BLHeli when I am connected to the AP via the USB port, none over the serial TELEM1 interface.
I am uploading a digital scope capture of the signal out for 1 channel.

BLHeli32 on scope


(Paul Atkin) #20

i forgot to give an update here. whole thing was a case of a mistaken diagnosis. i have concluded that i had no working telemetry based on the fact that an MP ‘status’ screen was showing nothing for ‘esc_xxxx’ fields. i presumed if ESC telemetry works - MP will show it. it was wrong. CRC messages are only shown if debug option is on in the SERVO. removing it suppresses those CRC errors. it is a problem in blheli code.

MP shows nothing in status screen - it is a problem in MP code.

ESC telemetry worked all along - a dataflash log did show me ESC 1,2,3,4 sections populated. and it should work in OSD too, but i did not check yet. but, as log shows it - it works.


(wkf94025) #21

Yes, MP appears to know nothing about BLH telemetry.
Yes, DF logs are the place to look for evidence of working BLH telemetry.
Yes, new OSD code for F4-based ChibiOS-based flight controllers have option of showing BLH telemetery amps, temps, RPMs.
CRC error was fixed several months ago by BLH team. IMHO, if you are still seeing that, it’s not because you have a certain debug flag on, but because you’re running a version of BLH firmware that pre-dates the fix.

Kelly


(Rainer Walther) #22

As mjbunan said above, I also get the esc_* readings from “Omnibus F4 Nano V6” with “Ori32 25A 4in1” ESC, if I connect MP via USB port. With SIK-Radio Telemetry on serial port the readings are all “0”.

Current is still too low. This is also the case with Betaflight 3.5.1. Seems to be a problem of Ori32.

Thanks for your great work!


(S) #23

RainFly,
You should push your updated hwdef for the nano to master, or however we get it into the official release. It would be really helpful to have uart4 working for us non programmers!

thanks.


(Paul Atkin) #24

I second question about current readout from 4in1 esc. I got same problem now as FC only gets voltage. What is the way to setup - correctly - a current reading from esc?


(Michael Nunan) #25

The ESC I have SPEDIX 4in1 40A has an overall current sensor onboard with a 3.3 v analog output that is compatible with the PixHawk current sensor input. It also has a bat level signal - which would blow the PixHawk voltage sensor. I built a voltage divider (2 res and a cap) with values similar to the Attopilot sensor between the ESC and the PixHawk. To get voltage monitoring working (scale 25V to less than 3.3V)

https://photos.google.com/photo/AF1QipNDkCnG6CpjwcCNk0uChx4iv5QGOPHlz4Q4g8vH


(S) #26

That link requires a google login… Probably best to post photos directly to the forum.

Someone mentioned their ori32 current reading was wrong…
That is a known issue w/ those ESC’s… they aren’t calibrated. But apparently you can calibrate the current sensor per ESC in the blheli configuration program. There’s a thread on rcgroup where people are talking about that.