This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
mission:tech:odyssey:pdu [2012-06-29 08:19] – [Protocol] chrono | mission:tech:odyssey:pdu [2014-04-05 16:35] (current) – [Video] chrono | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ~~NOCACHE~~ | ||
+ | ====== 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' | ||
+ | |||
+ | The idea is to have modular, bus-controlled, | ||
+ | |||
+ | All devices are fed directly from the PDU, bypassing the on-board converters, thereby increasing the overall efficiency. | ||
+ | |||
+ | ===== Specs ===== | ||
+ | |||
+ | [{{: | ||
+ | |||
+ | ~~CL~~ | ||
+ | |||
+ | * 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/ | ||
+ | * Current (Input) | ||
+ | * Temperature | ||
+ | * Costs to operate: 0.5W | ||
+ | * Operational Temperature: | ||
+ | ===== Main Power Busses ===== | ||
+ | |||
+ | ==== 12V ==== | ||
+ | |||
+ | |||
+ | ==== 5V ==== | ||
+ | |||
+ | |||
+ | ==== 3.3V ==== | ||
+ | |||
+ | |||
+ | ===== Interface ===== | ||
+ | |||
+ | ==== Sensors ==== | ||
+ | |||
+ | * Allegro ACS715LLCTR-30A-T Hall effect-based linear current sensor | ||
+ | * Power Supply, 12V, 5V & 3.3V Voltage Monitoring | ||
+ | * DS18S20 Temperature sensor | ||
+ | |||
+ | ==== Controller ==== | ||
+ | |||
+ | AVR ATmega88 | ||
+ | |||
+ | ==== Software ==== | ||
+ | |||
+ | The protocol and software were developed with a strong focus on security/ | ||
+ | |||
+ | === ATmega88 Firmware (and sources) === | ||
+ | |||
+ | Developed and tested with GCC | ||
+ | |||
+ | === PDUD - PDU Daemon (Python) | ||
+ | |||
+ | 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 / | ||
+ | * 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 | ||
+ | |||
+ | |||
+ | ==== Protocol ==== | ||
+ | |||
+ | |||
+ | === Command Frames === | ||
+ | |||
+ | The following tables show the protocol structure with example data: | ||
+ | |||
+ | ** Command-Request Frame** | ||
+ | |||
+ | 8 byte frame length | ||
+ | |||
+ | ^ Byte ^ 0 ^ 1 ^ 2 ^ 3 ^ 4 ^ 5 ^ 6 ^ 7 ^ | ||
+ | | Def.| Frame Begin (FB) | Bus Device Adress (BDA) | CMD | P1 | P2 | P3 | CHK | Frame End (FE) | | ||
+ | | DATA | 0xFB | 0x10 | 0xCA | 0xFF | 0x00 | 0x00 | 0xB4 | 0xFE | | ||
+ | |||
+ | ** Command-Response Frame ** | ||
+ | |||
+ | 4 byte frame length | ||
+ | |||
+ | ^ Byte ^ 0 ^ 1 ^ 2 ^ 3 ^ | ||
+ | | Def.| Bus Device Adress (BDA) | R1 | R2 | CHK | | ||
+ | | DATA | 0x10 | 0xFF | 0x00 | 0x79 | | ||
+ | |||
+ | |||
+ | === Data Frames === | ||
+ | |||
+ | ** Data-Request Frame** | ||
+ | |||
+ | 8 byte frame length | ||
+ | |||
+ | ^ Byte ^ 0 ^ 1 ^ 2 ^ 3 ^ 4 ^ 5 ^ 6 ^ 7 ^ | ||
+ | | Def.| Frame Begin (FB) | Bus Device Adress (BDA) | CMD | P1 | P2 | P3 | CHK | Frame End (FE) | | ||
+ | | DATA | 0xFB | 0x10 | 0xDA | 0x00 | 0x00 | 0x00 | 0xA7 | 0xFE | | ||
+ | |||
+ | ** Data-Response Frame ** | ||
+ | |||
+ | 13 byte frame length | ||
+ | |||
+ | ^ Byte ^ 0 ^ 1 ^ 2 ^ 3 ^ 4 ^ 5 ^ 6 ^ 7 ^ 8 ^ 9 ^ 10 ^ 11 ^ 12 ^ | ||
+ | | Def.| BDA | Loops | PDU_I || PDU_U || PSU_U || PS5_U || PS3_U || CHK | | ||
+ | | DATA | 0x10 | 0x59 | 0xC3 | 0x56 | 0xA2 | 0x97 | 0x23 | 0x42 | 0x08 | 0x15 | 0xE1 | 0xFA | 0xCC | | ||
+ | |||
+ | |||
+ | === On the wire === | ||
+ | |||
+ | 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. | ||
+ | |||
+ | {{: | ||
+ | {{: | ||
+ | {{: | ||
+ | ===== Operational Readiness Test (ORT) ===== | ||
+ | |||
+ | ==== ORT Specs ==== | ||
+ | |||
+ | ** 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/ | ||
+ | * 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, | ||
+ | |||
+ | ==== Video ==== | ||
+ | |||
+ | {{mission: | ||
+ | ===== Repository ===== | ||
+ | |||
+ | Grab the latest code and all related files: | ||
+ | |||
+ | <WRAP round download> | ||
+ | **Anonymous GIT Access**\\ | ||
+ | //git clone [[git:// | ||
+ | </ | ||
+ | |||
+ | |||
+ | <WRAP round tip> | ||
+ | If you want to add files or commit changes, send your work to the ops-team or apply for git RW access by sending your pub-key to the ops-team. | ||
+ | </ |