DroneNet not enumerating on CAN — PPP stuck at "reconnecting"

BotBlox Hardware
1
  • Matek H743-WING V3, custom ArduPlane 4.7.0 (PPP enabled)
  • DroneNet BB-DRN-C-1
  • USART → FC UART7/SERIAL1 (TX, RX, RTS, CTS, GND)
  • CAN → FC CAN (CAN_H, CAN_L, GND)
  • Powered via 5V Input port (5.0V measured)

Current FC parameters:

  • SERIAL1_PROTOCOL=48, SERIAL1_BAUD=12500000
  • CAN_P1_DRIVER=1, CAN_D1_PROTOCOL=1, CAN_P1_BITRATE=1000000
  • NET_ENABLE=1, NET_OPTIONS=1

Problem:
On the DroneCAN screen I see only two nodes: ID 127 (Mission Planner) and ID 10 (name “?”, empty HW/SW version, OPERATIONAL). I was told ID 10 is likely the flight controller itself — meaning the DroneNet may not be appearing on the bus at all. PPP stays stuck at “reconnecting” and no DroneNet parameters can be read.

Questions:

  1. What is the correct wiring and termination to connect the DroneNet to the FC over CAN?
  2. Which exact FC-side parameters must be set for the FC to see and talk to the DroneNet over CAN? Are the ones I listed above correct/complete?
  3. What node ID should a working DroneNet appear as, so I can confirm it has enumerated?
  4. If it’s not enumerating, is this a wiring/termination issue or does the DroneNet firmware need reflashing first?
2

Hi,

Thanks for the detailed setup information. Your configuration is very close. I would troubleshoot the CAN/DroneCAN side first, independently of PPP.

1. CAN wiring and termination

The CAN connection should be:

  • FC CAN_H → DroneNet CAN_H
  • FC CAN_L → DroneNet CAN_L
  • FC GND → DroneNet GND

Since you are already powering DroneNet through its dedicated 5 V input, leave the +5 V pin on the CAN connection disconnected. DroneNet should only be powered from one source at a time.

DroneNet has a split CAN termination network populated on-board, equivalent to approximately 120 Ω across CAN_H/CAN_L. You therefore need the second 120 Ω termination at the opposite end of the bus, i.e. at the FC end if the FC does not already provide it.

A useful check is to power everything off and measure resistance between CAN_H and CAN_L:

  • ~60 Ω = two 120 Ω terminations, which is what we want
  • ~120 Ω = only one termination
  • ~40 Ω = likely three terminations

2. FC parameters

For DroneCAN discovery, these are correct:

CAN_P1_DRIVER     = 1
CAN_D1_PROTOCOL   = 1
CAN_P1_BITRATE    = 1000000

1 Mbit/s is the correct CAN bitrate for the DroneNet/AP_Periph side.

For PPP over SERIAL1, I would use:

NET_ENABLE         = 1
NET_OPTIONS        = 1
SERIAL1_PROTOCOL   = 48
SERIAL1_BAUD       = 12500000
BRD_SER1_RTSCTS    = 1

NET_OPTIONS=1 enables the PPP Ethernet gateway without enabling the CAN multicast options.

On the Matek H743-WING, ArduPilot maps SERIAL1 to UART7, and UART7 does have RTS/CTS, so your choice of SERIAL1 is correct.

Because you are running PPP at 12.5 Mbaud, I would explicitly enable hardware flow control with BRD_SER1_RTSCTS=1. Also make sure the UART wiring is crossed correctly:

FC TX  -> DroneNet RX
FC RX  <- DroneNet TX
FC RTS -> DroneNet CTS
FC CTS <- DroneNet RTS
GND    -> GND

Then reboot the FC after changing the serial/CAN configuration.

The additional NET_P1_* parameters are needed later to configure actual IP traffic, but they are not required for the DroneNet to appear as a DroneCAN node. ArduPilot’s DroneNet setup uses the same CAN and PPP parameters above.

3. DroneNet node ID

I would not use a particular numeric node ID as the test for whether DroneNet is present. AP_Periph supports dynamic DroneCAN node allocation when CAN_NODE=0, so the assigned ID can vary.

The positive identification you should see in Mission Planner is a separate node named:

org.ardupilot.BotBloxDroneNet

That is the name ArduPilot specifically documents for DroneNet.

Check the FC parameter CAN_D1_UC_NODE. If that is set to 10, then the node you are currently seeing at ID 10 is indeed the flight controller. In that case, the DroneNet is currently missing from the bus.

4. Wiring/termination vs firmware

A firmware reflash should not normally be required before first use — a working DroneNet should enumerate over DroneCAN as supplied.

However, we have seen this exact failure mode before: the board powers normally and the Ethernet switch may operate, but the STM32/AP_Periph side does not appear on DroneCAN because of outdated or incorrect AP_Periph firmware. In those cases, reflashing the current firmware via SWD restored DroneCAN operation.

So I would troubleshoot in this order:

  1. Confirm CAN_H/CAN_L/GND wiring.
  2. With power off, confirm approximately 60 Ω between CAN_H and CAN_L with the complete bus connected.
  3. Confirm the three CAN parameters above and reboot.
  4. Check CAN_D1_UC_NODE to verify whether node 10 is the FC.
  5. Check whether the DroneNet STM32 status LEDs are blinking; a solid/dark status LED can indicate that the STM32 firmware is not running correctly.
  6. If the physical CAN layer checks out but org.ardupilot.BotBloxDroneNet still never appears, I would then reflash the DroneNet with the latest AP_Periph firmware.

The PPP “reconnecting” state is secondary at this stage. I would first get the DroneNet appearing reliably on DroneCAN, then debug the UART/PPP link if it still does not come up.

Best,
Josh