Power Distribution Unit (PDU)

The PDU is designed to efficiently convert electrical energy for three main power bus lines: 12V, 5V and 3.3V. This was done to overcome the problem of having to deal with inefficient power-converters found in many industry produced off-the-shelf components, used in the various application cases all over Apollo-NG's infrastructure.

The idea is to have modular, bus-controlled, point-of-load conversion modules for remote systems and to use the PDU's highly-efficient (>90%) buck/boost converters to supply the MCU, Storage-Devices, Audio, Communications- and Navigation-Equipment and all other hardware in close vicinity of the System-Module-Rack (SMR).

All devices are fed directly from the PDU, bypassing the on-board converters, thereby increasing the overall efficiency.

[]

• Input: 7-18V
• Output:
  • 12V/5A > 95% Efficiency
  • 5V/5A >= 91% Efficiency
  • 3.3V/5A >= 93% Efficiency
• Overcurrent Protection
• In-Vehicle Protection
• Monitoring:
  • Voltage (Input/12V/5V/3.3V)
  • Current (Input)
  • Temperature
• Costs to operate: 0.5W
• Operational Temperature: -25°C to +75°C

• Allegro ACS715LLCTR-30A-T Hall effect-based linear current sensor
• Power Supply, 12V, 5V & 3.3V Voltage Monitoring
• DS18S20 Temperature sensor

AVR ATmega88

The protocol and software were developed with a strong focus on security/reliability, very low system requirements and enough room for future options and modifications. The software package in the git repo consists of two parts.

Developed and tested with GCC

In order to keep the system impact on the SKU at a minimum, a polling system was out of the question. Luckily the Linux kernel supports inotify, as does python, which made the development of an inotify-event driven system very easy.

• Kernel iNotifier watching changes in /var/state/apollo/odyssey/pdu/*
• Wake on Change Interrupt routine:
  • Read changed value
  • Validate value
  • Check dependencies
  • Execute command on PDU
  • Go to sleep again
• Periodically collecting and updating bus voltages, temperature and power consumption

The following tables show the protocol structure with example data:

Command-Request Frame

8 byte frame length

Command-Response Frame

4 byte frame length

Data-Request Frame

8 byte frame length

Data-Response Frame

13 byte frame length

These DSO screenshots show the protocol on the wire: The left and middle image show different command-request (green) and command-response (yellow) frames, the right image shows a data-request (green) and data-response (yellow) frame. The latency for command execution is virtually non-existant (0.4ms), data-requests take a little more time to collect (2.5ms), this is due to the 13 byte framelength - it takes the ATmega a bit more time to calculate the checksum of the larger frame.

Required tests to pass ORT

• Uptime > 30 days without any erratic behaviour
• Toggle PSU's in a 3 second interval for 96 hours without any erratic behaviour
• Accurate results of temp/voltage/current sensors over time
• Stable RS-232 signal quality
• Low host-system impact of PDU daemon

Results

All tests passed without a glitch, the system works as designed, com signals are solid and the system impact of the PDU Daemon on the host is almost non-existent, due to its use of kernel inotifiers (see the video for a time lapsed summary).

Grab the latest code and all related files: