BLHeli32 ESC telemetry setup - how?

I’m not getting either. Nothing in MP and no ESCx lines in the log. BLH_DEBUG does nothing for me.

Yes, I have done the dataflash configuration and that works fine. Just not getting any esc telemetry.

@Paul_Atkin1 I take it that you have successfully used UART7 on a regular kakute then?

imho it might help to check if your BLH ESCs are setup, found and initialized correctly before trying to debug BLH telemetry.

if BLH_DEBUG does nothing for you i’d say there’s some settings that need to be adjusted and you’re not having BLH active at all, not only telemetry missing. even with no BLH ESC hardware connected and powered, by opting for BLH_DEBUG = 1 you should get some console prompt like:

ESC: ESC: 4 motors mask=0x000F
ESC: BLHeli installed on port 0

this requires setting BLH_AUTO to 1 for multirotor motors (or using BLH_MASK to specifically point to BLH ESCs used for non-multirotor throttle functions).
once your motor mask is set correctly and returns something different than 0, with your ESCs connected and powered you can test BLH response by setting BLH_TEST to either one of your motor output ports. if successful, this will return something like:

ESC: Test PASSED
ESC: Prot 1 Good 8898 Bad 0 0 0 0 x0
ESC: BL_ReadBuf 16 -> 19
ESC: BL_SendCMDSetAddress 0xEB00
ESC: BL_SendCMDSetAddress 0xEB00
ESC: BL_ReadBuf 256 -> 259
ESC: BL_SendCMDSetAddress 0x7C00
ESC: Interface type imARM_BLB
ESC: BL_ReadBuf 8 -> 9
ESC: BL_ConnectEx 2/4 at 2
ESC: Running test on channel 2
ESC: Change to BLHeli mode

there’ll likely be no BLH telemetry requests and responses unless these requirements are met.

yes, it worked fine. it is only difficult to see the actual presence of the telemetry data in the MP. one way to see it - the easiest way - it is to set voltage and current to be shown from the ESC telemtry. this way, if telemetry does not go - you will never see the voltage when you connect lipo to the ESC.

Pretty sure I am using mavlink 2

dunno then, try checking the firmware version on the ESCs, to bump it up to the current, but, it should work.

try connecting something else to the PE7 pin to see if it get anything at all. or set it to half duplex and feed radio telem out of it, to see if it is operational.

That’s tricky as this board has specific wiring of this pin to the ESC’s. Or do you mean do this in the hwdef.dat?

Ok I get

APM: ESC: Running test on channel 0
APM: ESC: BL_ConnectEx 0/4 at 0
APM: Initialising APM
APM: ESC: BL_ReadBuf 8 -> 9
APM: ESC: Interface type imARM_BLB
APM: ESC: BL_SendCMDSetAddress 0x7C00
APM: ESC: BL_ReadBuf 256 -> 259
APM: ESC: BL_SendCMDSetAddress 0xEB00
APM: ESC: BL_ReadBuf 16 -> 19
APM: ESC: Prot 5 Good 151338 Bad 0 0 0 0 x0

APM: ESC: Test PASSED
Critical failure

This is on 4.0 on which I also see Internal Errors when using pass through. This vehicle also flies.

ok, this looks kind of promising except for the critical failure prompt. could you upload your currently used params?

I think there is a bug in BLHeli support in 4.0. I see these “Internal Error” messages after having connected with blehli and they don’t go away until I reboot. I’m using 32.7. Parameters here:

Gecko3-Tune1.param (19.2 KB)

copter master, defaults with BLH enabled. working as expected except for BLH_DEBUG not giving any prompts as it does on plane (like you described). telemetry:
image

loaded your params then, just moved ESC tlmtry to SERIAL5 due to hardware requirements. still get ESC telemetry, but internal error too (0x8000) and can’t connect to BLH suite using passthrough anymore. couldn’t yet identify what exact setting breaks BLH here though.

ok, as i understand you‘re connecting ESC telemetry to hardware UART7RX. afaik from your hwdef PR this corresponds to SERIAL5 in ardupilot runtime though, not SERIAL7. there‘s only SERIAL0 - 6 defined in that hwdef. setting SERIAL5_PROTOCOL to 16 might get your ESC telemetry working, not sure about those int errors and passthrough though…

Ok, so break that down for me - because you are right! Configuring SERIAL5_PROTOCOL = 16 gives me ESC telemetry! So what is my mistake here? Is the hwdef wrong?

I notice that we are only on MSP version 37 and 42 introduced ESC telemetry - wonder whether that is connected as I have BLHeli set to always output telemetry.

it‘s ardupilot hwdef serial port mapping. see board readme for reference:

  • SERIAL0 -> USB
  • SERIAL1 -> UART1 (Telem1)
  • SERIAL2 -> UART2 (Telem2)
  • SERIAL3 -> UART3 (GPS)
  • SERIAL4 -> UART4
  • SERIAL5 -> UART7
  • SERIAL6 -> UART6 (Transmit only, FrSky)

UART7 is mapped to SERIAL5 by default, that‘s all there is. it would have made sense to make uart order match serial port mapping in the first place (like in matekf405-wing hwdef) as follows:

UART_ORDER OTG1 USART3 USART1 USART2 UART4 EMPTY UASRT6 UART7

i’m not 100% positive we support 8 ports here by default, that might have been the reason to squeeze them. i‘d rather not say the hwdef is wrong, it’s just not exactly intuitive imho. altering hwdefs post-primarily would break all existing setups though.

Ah thanks. The board hwdef hasn’t been merged yet so I am going to change it to be more sane. I also think this board has a UART5 anyway so the setup is wrong as it stands.

i’m trying to wrap my head around things right now.

1.: afaik the KakuteF7Mini’s pin defs exactly match the non-mini’s, except for using flash instead of SD for logging. imho you could relevantly reduce your hwdef by including the existing non-mini hwdef and just redefining relevant lines.
2.: your current mini hwdef PR copys the non-mini’s UART order that imho doesn’t seem too intuitive regarding mapping ports 5,6 and 7. is that correct?
3.: i just tried building with a UART order that matches hardware ports / silkscreen, it builds fine, just got no hardware to test on. can you do that?

cheers, basti

EDIT: no UART5 on KakuteF7(Mini) as far as i can read from manual and bf port.

EDIT2: could you check if this puts UART7 on SERIAL7 KakuteF7Mini_arducopter_UARTfix.apj (741.2 KB)

Can you post the change you made to hwdef?

check couple posts further up:

see ardupilot/libraries/AP_HAL_ChibiOS/hwdef/omnibusf4 at master · ArduPilot/ardupilot · GitHub as an example on how to reference from an existing hwdef with just minor changes.

Thanks, when I have this all working I will try that. The battery monitor defaults are way out of whack as well.