CAN bus compatibility is only the first requirement. DroneCAN and Cyphal are different higher-level protocols, so a DroneCAN peripheral does not become a Cyphal peripheral because its connector fits. Working integration also requires matching frame modes, firmware support, message definitions and configuration. The practical question is whether the exact autopilot build understands the exact peripheral firmware and its required functions. DroneCAN project and PX4 CAN overview.
For a conventional PX4 installation, its current CAN overview recommends DroneCAN and describes Cyphal support as work in progress. That is a useful starting point, not a substitute for checking a particular device and release.
On This Page
- Separate the five compatibility checks
- Resolve the UAVCAN naming trap
- Read the dated compatibility matrix
- Check connectors, power and bitrates
- Understand what can share one bus
- Commission the function, not just the node
Separate the five compatibility checks
A CAN controller can receive a valid frame without the application understanding its contents. CAN in Automation distinguishes the CAN data link from the application mechanisms built above it. Work through the following checks in order. CiA, CAN data link layers.
| Check | What must agree | What a match does not prove |
|---|---|---|
| Electrical connection | Transceiver interface, CAN H/L wiring, ground reference, termination and supply | Compatible software |
| CAN framing and timing | Supported Classical CAN or CAN FD mode and configured bitrates | A common higher-level protocol |
| Transfer protocol | DroneCAN or Cyphal/CAN implementation at both endpoints | Support for every sensor or actuator function |
| Data definition | Message layout, meaning and compatible version; the appropriate identifiers | That the autopilot uses the received data |
| Application integration | Driver, subscriptions, output mapping and intended operating behavior | Suitability under untested vehicle conditions |
Source basis: DroneCAN basic concepts, Cyphal v1.0 specification, and the project setup guides below. The ordering is an integration checklist, not a certification scheme.
DroneCAN packages typed messages and service requests into transfers, which may span several CAN frames. Its CAN transport uses extended, 29-bit identifiers. Node IDs identify participants; data-type IDs help identify the data being exchanged. A node ID is therefore not a sensor type or an actuator channel. DroneCAN CAN transport.
Cyphal uses subjects for published messages and services for request/response exchanges. The integrator must align subject or service IDs with compatible data types at the endpoints. Giving two ports the same number does not make differently defined payloads compatible. Its CAN transport also uses 29-bit identifiers, but that shared frame format does not make it DroneCAN. Cyphal specification, sections 2.1 and 4.2.
For example, a custom sensor may successfully announce itself while publishing measurements the flight controller has no subscriber for. DroneCAN permits vendor-specific data definitions; implementing its network services is not the same as implementing the measurement interface an autopilot expects. DroneCAN basic concepts.
Resolve the UAVCAN naming trap
Older drone manuals often use UAVCAN without a version. PX4 explains the useful distinction: the UAVCAN v0 lineage became DroneCAN, while UAVCAN v1 became Cyphal. DroneCAN's own first version is called DroneCAN v1; it must not be confused with UAVCAN v1. DroneCAN project history and PX4 CAN overview.
Read the actual firmware documentation before interpreting a legacy label. PX4 still uses the parameter name UAVCAN_ENABLE for its DroneCAN driver. Changing that parameter does not convert a peripheral to Cyphal. PX4 DroneCAN configuration.
When asking a supplier about compatibility, request the protocol lineage and firmware revision, not simply confirmation that the device is “UAVCAN compatible.”
Read the dated compatibility matrix
Documentation checked September 9, 2026. These are representative documented configurations and explicit integration limits, not results from bench or flight testing. Firmware versions below identify the cited instructions; they are not recommendations to install an old release. Peripheral firmware revisions are not pinned in those instructions, so confirm the delivered revision separately.
| Autopilot and peripheral | Documented protocol path | Connector, power and bus rate | What the documentation supports |
|---|---|---|---|
| ArduPilot-capable flight controller with original CubePilot Here3; manufacturer instructions reference ArduCopter 4.1.5 | DroneCAN | Four-pin CAN cable; 5 V supply pin; original Here3 rated 1 Mbit/s | Manufacturer setup example. Match physical port to the DroneCAN driver and configure GPS; do not extrapolate to Here3+ FD operation. Here3 manual |
| PX4-capable flight controller with original Here3; manufacturer instructions reference PX4 1.12.3 | DroneCAN through the legacy-named UAVCAN setting | Four-pin CAN cable; 5 V; 1 Mbit/s | Manufacturer setup example for that documented release. Recheck allocation and subscriptions against the installed PX4 release. Here3 manual |
| PX4 with Holybro DroneCAN M8N GPS; PX4 v1.17 guide | DroneCAN | Four-pin JST GH; 4.7–5.2 V; less than 200 mA at 5 V; 1 Mbit/s | A dedicated device setup page exists. The DroneCAN variant matters; the receiver chip name alone does not identify the interface. PX4 device guide |
| PX4 with a Cyphal-only CAN peripheral | Requires a Cyphal implementation and matching application interface | Device-specific supply, connector and supported frame mode; no universal value | Main-branch overview calls support work in progress. Establish support for the exact build and peripheral before selecting it. PX4 CAN overview |
| ArduPilot with a Cyphal-only CAN peripheral | No turnkey Cyphal driver shown in the cited CAN protocol table | Device-specific; an electrical match does not fill the driver gap | No drop-in support is established by that table. A custom integration needs its own documented implementation and tests. ArduPilot CAN setup |
Treat “not established” as a requirement for more specific evidence, not proof that a custom solution is impossible. Ask for the board target, release, peripheral firmware and supported message interface as one configuration. A statement that two products each support CAN leaves that configuration unresolved.
Check connectors, power and bitrates
The common Pixhawk CAN connection is four-pin JST GH, but DroneCAN hardware recommendations also describe M8 and DE-9 connectors. Their power conventions differ: the Micro/JST GH arrangement is nominally 5 V, while the specified M8 and DE-9 arrangements use nominally 24 V. These are connector conventions, not permission to apply either voltage to an unidentified device. DroneCAN hardware recommendations.
Here3's published pin sequence is 1: 5 V, 2: CAN H, 3: CAN L, 4: ground. Its manual advertises Here3+ at 8 Mbit/s, unlike original Here3. Do not transfer the original model's bus assumptions to the plus model. CubePilot Here3 manual.
Before connecting power, compare both pinout drawings using their stated viewing direction, then check continuity through the harness. Budget the carrier's available supply current against the connected devices, including startup demands where specified. Treat bus electronics and motor power as separate wiring questions. A passive connector adapter only rearranges conductors; it cannot translate protocols or establish an adequate supply.
PX4's wiring guidance calls for a bus with a 120-ohm termination between CAN H and CAN L at each end. Account for built-in terminators before adding external ones, and follow the device power instructions separately. PX4 CAN wiring.
ArduPilot exposes the physical interface rate through CAN_Px_BITRATE and documents 1 Mbit/s as the usual default. Use the rate supported and configured across the actual bus. ArduPilot CAN setup.
Cyphal/CAN supports Classical CAN and CAN FD. Its bitrate configuration separates arbitration and data-phase rates. “Cyphal” therefore does not automatically mean FD. Cyphal specification.
An FD-capable node can handle Classical CAN frames, but an ordinary legacy Classical CAN controller can disrupt FD traffic by transmitting error frames. Do not enable FD across a mixed bus merely because one peripheral advertises a higher speed. Verify every participant or use a documented separation arrangement. CiA, CAN data link generations.
Understand what can share one bus
Coexistence means traffic can share a medium; interoperability means applications understand one another. Neither implies the other. DroneCAN's transport specification permits sharing with protocols using 11-bit CAN identifiers. That statement does not establish arbitrary mixed operation with another 29-bit protocol. DroneCAN CAN transport.
ArduPilot documents a narrower practical exception: when the primary driver is DroneCAN, selected secondary protocols can be enabled through CAN_Dx_PROTOCOL2. Its list includes USD1, Benewake, TOFSenseP, NanoRadar and scripting options. This is not a documented automatic DroneCAN-to-Cyphal translator. ArduPilot DroneCAN setup.
For a proposed mixed DroneCAN/Cyphal network, require explicit support for both stacks on the chosen interface, compatible timing and frame modes, and evidence that identifiers and traffic do not interfere. If those conditions are not demonstrated, separate the buses. A gateway must deliberately translate the required measurements or commands, including their units, validity and timing; forwarding raw frames is not application translation. These are integration requirements inferred from the two protocols' different transfer and data models.
Even a single-protocol bus can have a capacity problem. PX4 recommends dedicated CAN interfaces for DroneCAN ESC traffic because it can deprive other nodes of bandwidth. Adding a second connector to a chain does not create another independent bus or prove redundancy. PX4 DroneCAN guide.
Commission the function, not just the node
On ArduPilot, CAN_Px_DRIVER maps a physical port to a logical driver, while CAN_Dx_PROTOCOL selects that driver's protocol. A port number and driver number need not be identical. Protocol or driver changes require a reboot. ArduPilot CAN setup.
On PX4, UAVCAN_ENABLE=2 enables DroneCAN sensors with dynamic node allocation; 3 also enables ESC output. Individual subscriptions and publishers still matter. A discovered battery, for example, needs the relevant battery subscription for its data to be used. Check the release-specific instructions for the selected function. PX4 DroneCAN guide.
For an integration review, retain a short record of:
- Autopilot board and build, peripheral model and firmware, and protocol lineage.
- Harness pinout, measured supply within the device's limits, terminators and configured bitrates.
- Node identity, required message types or subject assignments, and active application configuration.
- Actual measurement delivery or correctly mapped actuator behavior, plus the documented response to loss of that data.
For troubleshooting, use the first failed layer to choose the next check. No bus activity points toward power, wiring, timing or a disabled interface. A visible node with no usable measurement shifts attention to message support and application configuration. Intermittent delivery under load calls for traffic and error-counter inspection, not repeated changes to node names. These are starting points for diagnosis, not exclusive fault causes.
Use the manufacturer's secured bench procedure for actuator checks before allowing vehicle movement. Verify the function the vehicle will use, including its documented loss-of-data behavior, and repeat affected checks after firmware or configuration changes. The commissioning record above is an engineering recommendation drawn from the configuration dependencies.
Choose the peripheral with a documented path through all five compatibility checks. Where that path stops at a matching plug, a familiar protocol name or a visible node, resolve the missing integration before treating the combination as usable.
Sources
- DroneCAN project: protocol lineage and naming.
- PX4 CAN overview, main-branch source: stated protocol support and wiring guidance.
- DroneCAN basic concepts: typed messages, services and vendor definitions.
- DroneCAN CAN transport specification: identifiers, transfers and the 11-bit coexistence provision.
- Cyphal specification v1.0, May 16, 2025: data-model and CAN transport requirements.
- PX4 DroneCAN guide: driver, subscription and bus-allocation configuration.
- CubePilot Here3 manual: model-specific wiring, rates and historical setup examples.
- PX4 v1.17 Holybro DroneCAN M8N guide: device interface, supply and setup specifications.
- ArduPilot CAN bus setup: physical ports, logical drivers and protocol selection.
- ArduPilot DroneCAN setup: function configuration and bounded secondary-protocol support.
- DroneCAN hardware recommendations: connector and power conventions.
- CAN in Automation, CAN data link generations: link-layer scope and Classical CAN/FD coexistence limits.
Last checked: September 9, 2026.
