Tim and Andrew have been deeply bothered by the transition to USB for a long, long time. USB was just never meant to be used in a highly distributed safety critical system. Today, however, we managed to push through our fear and loathing of the Universal Serial Bus by identifying the minimum feature sets from LV2 we thought we wanted in LV2b.
There features included:
- Quick and easy access to the APS and PYRO nodes for power up and safety critical sequencing.
- Some long distance, highly robust, safety critical communications channel.
- An externally accessible serial console to the FC.
- Rechargable battery and shore power connection.
What we came up with is a star topology bus, like USB, that we like to call the "Universal Rocket Bus", or URB. Yes, it's a dumb name, but it stuck.
Physical Topology
USB has a star topology. This is useful for centralized data flow and terrible for distributed control. Frankly, it's what we liked least about USB. That said, we realized that as we upped the number of power switches on the APS in order to be able to switch the power on individual boards, the power also became star-like. So the USB and power are both star-like, and that gave us the idea that perhaps the USB hub for the avionics system belongs on the APS.
It was clear we needed more than USB, however: there's no possibility of node-to-node communication, and if the host controller or hub crashes, you're toast. As you might have guessed, our first instinct was to go with CAN. Although terrible for data, it's great for robust control. And we're much more interested in small control messages for the node-to-node communication than steaming data. We could implement CAN very cheaply by moving from the LPC2148 to the LPC2368 since they're essentially the same chip (and we already have code for the CAN peripheral for the 2368). The fatal flaw to using CAN is that we also have to get CAN to work on the MPC5200... and the software people are going to completely freak if we ask them to do that. So we scratched that off the list, possibly to bring up later when the software team isn't so twitchy.
So, what other alternatives do we have? Not very many. Although CAN is clearly the right choice for many reasons, the only other viable alternative is point-to-point serial (UART) connections. Since we already have a star-like topology anyway, we could implement a point-to-point serial connections using a multiplexor on the "root node" of the star.
So, by combining power, USB, and serial into a single star-like bus, we get the Universal Rocket Bus!
Notice how it's a standard USB bus, but now with 6 wires instead of four:
- Power + (Vbattery which is 10V - 19V)
- Power - (ground)
- USB data (D+)
- USB data (D-)
- Serial data (TX)
- Serial data (RX)
It's a bit ugly, but we can use the same connector as LV2 but with four extra conductors (since we always double up the connectors).
USB Topology
Looking at the URB from the USB side of things, it's just a USB star:
Serial Topology
We believe only the APS and PYRO nodes need to communicate point-to-point. While there are many nice features if other nodes can talk to each other - like GPS time stamps, secondary sensor streams, etc - only the APS and PYRO nodes require "FC offline" communications, especially around power up and certain safety-critical flight transitions. All other nodes could suffer with USB as their only communication channel.
That said, we felt it would be a win if we could manage to get a serial console to all nodes, especially the flight computer. We can acheive this by using the APS as the "central serial hub". Using a dual 8:1 multiplexor, the APS can choose which of any nodes to open a serial session with. And nodes could even request contact with the APS if we decided to implement a wired-OR pull up on an interrupt-on-change pin of the APS' LPC2148.
Finally, the outside world can be relayed through the APS by a serial connection on the shore power connector. This could be from a nearby laptop, or from a serial terminal over ssh from the launch tower computer.
