Today's meeting was a design review of the LV2 Recovery Node, the CAN node which fires the pyrotechnic charges which deploy the recovery system (parachutes). Tim did the design, and broke up the node into four schematics: The Switching Power Supply (SPS), Battery Backup (BB), Highly Available Power Supply (HAP), and pyrotechnic firing circuit (PYRO).
Tim did an excellent job A) designing the circuits and B) presenting them to us (Michael, Markus, Larry, Glenn, Andrew). Go Tim go!
Here are a Michael's notes (thanks Michael!) with Andrew's (AG) appended.
- split voltage divider into two separate dividers, one for setting the feedback voltage, one for defining the window for the comparators (R200-R203)
- add a diode in parallel with a high-value resistor in the line that controls Q200, so it will charge fast but discharge slow (to prevent oscillation of the crowbar/comparator circuit)
- test/characterize the fuse circuit
- test/characterize the low-voltage detection circuit
- ability for recovery node to stop charging the Li-ion battery (AG)
- be sure not to short to ground through the mounting hardware which would bypass the balanced input chokes (AG)
- Does C203 have enough energy to blow the fuse so that the crowbar does not cause brownouts on the main avionics power bus? If not, should we make it bigger (AG)
- looks good
- update notes to show that Q401 is necessary to prevent battery drain through R401/R402 voltage divider, since divider is connected to UPS even when HAP is off
- document the shorting screw
- update documentation for U2101-U2104, which do NOT accept 5V logic inputs (thereby creating the need for Q2105-Q2108)
- can we find a better chip than thte IR2118 (i.e., one with logic level inputs)? (AG)
All, general, presentation:
- clearly show whether each off-page marker is an input or an output
- possibly assign signal names that show what the source of the signal is (which submodule it is from, or who is driving it)
- it is a Good Idea to have a computer or notebook handy with datasheets for every component in the circuit, so when people ask Annoying Questions you can refer to them
- a key for what the different shaped signal boxes mean (AG)
- a block diagram for the whole system, with signal names (AG)
- many circuit design choices led to changes in the software. When presenting each section of the circuit, it would be good to make some notes regarding the assumptions that particular circuit is making about the software. Collectively, these notes become a Requirements Spec for the software team, who will probably tell you to go to hell.
- reiterated: need flowcharts for the software of behaviours needed by the hardware (AG)
Some other issues: The control lines to the pll are missing. The pll needs four lines, a clock, data in, data out (so what went in can be verified) and enable. My notes that I am doing in liew of short term memory will contain the needed data. Am doing up the board, but The Schematic has ERRORS in it. I need to revise it in a couple of small ways, but the existing one isn't right. I caught this doing my layout for the board.- 01 Jun 2003