# DroneNet not enumerating on CAN — PPP stuck at "reconnecting"
**URL:** https://forum.botblox.org/t/dronenet-not-enumerating-on-can-ppp-stuck-at-reconnecting/634
**Category:** BotBlox Hardware
**Tags:** dronenet
**Created:** [August 13, 2026, 4:46pm UTC](https://forum.botblox.org/t/dronenet-not-enumerating-on-can-ppp-stuck-at-reconnecting/634 "2026-08-13T16:46:59Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@Yarik](https://forum.botblox.org/u/Yarik)
#### Post date: [August 13, 2026, 4:46pm UTC](https://forum.botblox.org/t/dronenet-not-enumerating-on-can-ppp-stuck-at-reconnecting/634/1 "2026-08-13T16:46:59Z")
- 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?
---
### Author:  [@josh\_elijah](https://forum.botblox.org/u/josh_elijah)
#### Post date: [August 16, 2026, 10:40pm UTC](https://forum.botblox.org/t/dronenet-not-enumerating-on-can-ppp-stuck-at-reconnecting/634/2 "2026-08-16T22:40:46Z")
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:
```plaintext
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:
```plaintext
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:
```plaintext
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:
```plaintext
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