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:39] – [Software] 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. | ||
| + | </ | ||