PDB1 Power Distribution

The five XT90 connectors are wired in parallel on the battery bus. One is the battery input and the others pass the battery voltage directly to motor controllers; the schematic names J13 ‘Power Connector’ and J6, J8, J9 and J10 ‘Motor Power Control’. The battery voltage is not fused or switched on its way to these connectors. The main converter takes its power from the same bus, and a 68 µH inductor with capacitors filters the input of the 5 V regulator (U5) that supplies the isolated amplifier. All five connectors have the same pinout; the positive pin is marked on the connector.

Three XT60 connectors carry the regulated rails, each with the positive pin marked on the connector and the other pin on signal ground. J7 is the 12 V main rail (the schematic calls it the camera connector), J5 the 5 V rail and J4 the 7.2 V rail, which is fed through the 20 A fuse F1. The 7.2 V converter has no enable switch under firmware control: it starts by itself as soon as the 12 V rail is present, with a soft start. Two green LEDs show that the 5 V rail (LED1) and the 7.2 V rail (LED2) are present.

J11 is CAN bus 1 (FDCAN1, the primary bus) and J14 is CAN bus 2 (FDCAN2, the backup bus). Each connector carries the CAN signals and also the 12 V and 5 V rails as outputs, so that a node on the bus can be powered from them. They are outputs of the board: do not connect a supply to them. The mating connector is the Phoenix Contact 1027605. The board has no termination resistors on either bus; fit a 120 Ω termination at both ends of the bus, for example in the harness.

J12 is an 8-pin JST GH connector (1.25 mm pitch) with four thermistor inputs. Each input has a signal pin (odd pin numbers 1, 3, 5, 7) beside a ground pin (even pin numbers 2, 4, 6, 8). Connect a 10 kΩ NTC thermistor between the signal pin and the ground pin; the BOM specifies the Semitec 103JT-100 (B = 3435 K). The thermistors are not on the board. Each input has a 200 kΩ pull-up to the 5 V rail and a 100 pF filter capacitor. An input with no thermistor reads open: the firmware detects this, reports no temperature for that input and raises no warning. A shorted input is reported as a warning. An input can also be ignored with TEMP_DISABLE.

J3 is a Tag-Connect TC2050-IDC footprint: ten pads that a TC2050-IDC cable presses against, with no connector fitted (the schematic names it the ST-LINK V3 MINIE connector). It carries SWD for programming and debugging; the debugger must work at the 3.3 V logic level of the board (pin 1). The pads on pins 6, 7 and 8 are not connected.

J1 and J2 are 3-pin footprints that are not fitted. J2 has ground (pin 1), the microcontroller reset NRST (pin 2) and 3.3 V (pin 3). Pin 2 of J1 is the enable of the 7.2 V converter, which the firmware never drives.

Every node on a DroneCAN bus has a unique node ID from 1 to 127, which is the source address of the messages it sends. The PDB1 has no node ID jumpers. It uses a static node ID of 64 unless another one has been stored in flash over CAN. Give each board on the same bus its own node ID, and keep it different from the flight controller’s own node ID.

To store an ID over CAN, use the standard DroneCAN parameter services (for example in the DroneCAN GUI tool, or tools/can_param.py from the firmware repository): write the integer parameter NODE_ID (1 to 127) with uavcan.protocol.param.GetSet. The stored ID is used after the node restarts, which can be requested with uavcan.protocol.RestartNode. Writing 0 removes the stored ID, which gives 64 again. The ID can also be stored while programming with tools/flash_and_check.py --set-node-id. Writing flash stops the processor for a few tens of milliseconds.

The board publishes three messages on the primary bus (CAN bus 1, J11): uavcan.equipment.power.CircuitStatus (type ID 1091) twice per period, once for the battery and once for the 12 V rail, uavcan.equipment.device.Temperature (type ID 1110) once for each temperature, and uavcan.equipment.power.BatteryInfo (type ID 1092) once per period when a battery has been configured. The period is 100 ms (10 Hz) by default. The tables list the fields exactly as defined in the DroneCAN DSDL [7]; the last column shows the value this board writes. CircuitStatus and Temperature fit in one CAN frame; BatteryInfo is sent as a transfer of four frames.

uavcan.equipment.power.CircuitStatus (DTID 1091)

uavcan.equipment.device.Temperature (DTID 1110)

uavcan.equipment.power.BatteryInfo (DTID 1092)

The messages carry no timestamp. The values are averages of the readings taken since the previous message: about a dozen readings per input in a 100 ms period.

Six integer parameters can be read and written over CAN with uavcan.protocol.param.GetSet (for example from the DroneCAN GUI tool or tools/can_param.py). They are stored in flash and kept across restarts: the node ID in the flash page at 0x0801F000 (page 62), the telemetry period in the page at 0x0801F800 (page 63), the thermistor mask in the page at 0x0801E800 (page 61), the number of battery cells at 0x0801E000 (page 60), the full cell voltage at 0x0801D800 (page 59) and the empty cell voltage at 0x0801D000 (page 58). An erased page means the default.

PX4 does not read CircuitStatus. It builds its DroneCAN battery from uavcan.equipment.power.BatteryInfo when its UAVCAN_SUB_BAT parameter is enabled [8], and its pre-arm check refuses to arm when the battery data is missing, more than 5 seconds old, or shows a low or critical charge. The PDB1 publishes BatteryInfo once the number of cells is set with BATT_CELLS (for example can_param.py 64 set BATT_CELLS 12). It is not published before that, because the charge it carries is estimated from the battery voltage and would only be a guess; PX4 then reports a missing battery.

The estimate is linear between the empty and full voltage of a cell (BATT_CELL_EMPTY, BATT_CELL_FULL; 3.30 V and 4.20 V by default) multiplied by the number of cells. A real battery’s voltage is not linear in its charge and sags under load, so the percentage is approximate. The current in BatteryInfo is the 12 V rail current only: the motor current is drawn from the battery through each motor controller and is not measured by the PDB1, so PX4’s current and consumed-charge figures count only the 12 V rail until a battery current sensor is added. This has not yet been tested with a flight controller.

The board runs one node with one node ID on both buses. CAN bus 1 (J11, FDCAN1) is the primary bus: it carries the telemetry and NodeStatus, and answers the services. CAN bus 2 (J14, FDCAN2) is the backup bus: it carries NodeStatus, so the node is visible on that bus, and answers the services, but it carries no telemetry. A request is answered on the bus it arrived on, and a parameter written on one bus applies to the board. Each bus recovers by itself from bus-off, 100 ms after the controller goes off the bus.

The board reports its state in the health field of NodeStatus, and the vendor-specific status code is a bit mask that says why. An overcurrent trip or a failed thermistor is reported as a warning; if the ADC stops delivering samples, no telemetry is valid and the health is ERROR.

The bits are added when several apply, for example 3 for an overcurrent trip and a failed thermistor.

Connect an ST-LINK with a Tag-Connect TC2050-IDC cable to J3 to load firmware or debug over SWD. The board must be powered: the debugger takes its target voltage from J3 pin 1, so the battery input has to be connected. The repository’s tools/flash_and_check.py programs the board and then checks over CAN that the node answers GetNodeInfo. The node ID, telemetry period and thermistor mask stored in flash can be set and cleared with the tools below.

The firmware repository includes Python scripts for use with a serial USB-CAN adapter (a ‘USB-CAN analyzer’ at 2 Mbaud, set to 1 Mbit/s CAN). Any DroneCAN GUI tool can also read and set the parameters.

For example, can_param.py 64 set TEMP_DISABLE 1 makes the board ignore the thermistor on TH0 even if one is fitted. Changes to PUB_PERIOD_MS and TEMP_DISABLE take effect at once and are kept in flash; a new NODE_ID is used after the node restarts.