Here4 LED piloting from DroneCAN

Here GPS
1

Hello,
we’re working on an application that pilots Here4 LEDs manually via DroneCAN bus.
We are not using a flight control, but a custom board; a Orange Cube is connected for SLCAN access from PC only, and has the NTF LEDs disabled to avoid interefering.

We see that in order to properly pilot the LEDs with the LightsCommand, we need to force writing 0 then 1 again to Here4 parameter NTF_LED_OVERRIDE at every power cycle of the Here4.
If we don’t do so, the LEDs stay white.

Do you have any clue why this is necessary?

Thanks!

2

@HeliEngadin which version of firmware are you on, please ensure that you are running the latest firmware installed through mission planner. Or manually update through Releases · CubePilot/GNSSPeriph-release · GitHub

3

Software version is updated by Mission Planner to 1.13.FB50B077
Also there is an error present in the logs, IERR 0x800 277

Any clue?

4

@HeliEngadin is that error in the Cube or from Here4?

5

@HeliEngadin regarding the LED control, after you have updated firmware. Set FLASH_BOOTLOADER parameter as well, this way the latest bootloader will be flashed, and have the LEDs shutdown at boot rather than solid white.

Regarding the LED control it is the LightsCommand to control the LEDs. Have you compared the CAN message you are sending vs Ardupilot to confirm the packet being sent is correct. Also if you still face issues, please create a log of CAN messages using this tool pydronecan/tools/dronecan_bridge.py at master · dronecan/pydronecan · GitHub With this tool you can add “fileout:” as one of the endpoints to record. Share this log so I can debug the issue.

1 Like
6

Hello,
with the updated bootloader, the LEDs are “breathing” at boot, and then they turn off when firmware loads.
Curious thing is, sometimes it will get the command immediately after boot, sometimes we need to reboot the Here4 or our board to make it working.
But at least we have some progress, thanks for your help!

7

@HeliEngadin are you sending the lightcommands regularly or just once?

8

10 to 20 Hz
What is the timeout for LEDs? If there’s any

9

There’s no timeout, last command sticks.

1 Like
10

Regarding IERR 0x800 277, it is the only error message present on the bus, and comes from the Here4.
At the moment we can’t connect directly to it, but we will later.
This error looks like a watchdog reset; firmware is latest official with IMU messages set at 10 Hz.
It only appears after some time after Here4 power on.
What can be the cause?

11

@HeliEngadin the reason for your issues is actually the IMU message/sample rate set very low. In IMU waits we only allow 16bit waits so any period near 65535 will be a problem with current firmware. Setting message rates lower than ~20Hz is basically going to cause issue.

I will push a change to support lower frequencies, meanwhile I recommend using IMU message rates higher than atleast 20Hz.

The LED issues might be originating from that as well. There is a possibility of IMU data just spaming the CAN bus as the IMU wait times can be completely rubbish

12

That’s interesting, we will set it to 50Hz then.
Thought that the problem would be with higher refresh rates than lower ones…