Reliability
The bus must be capable of handling EMI, along with short and open conditions on the PHY layer. The bus must tolerate the acceleration and vibration associated with a launch. The bus should also have been used in real-time systems where a failure in the bus might result in lives being lost (such as medical equipment or automobiles). The bus must provide a way for the software to prioritize messages so that system critical messages will be sent, even at the expense of non-critical messages.
Data Integrity
The Software team would like the high-level software to deal with retransmission of corrupted packets and packets that were not received by the intended recipient. System critical messages like commands for parachute deployment and manual overrides from ground support are important to retransmit if a failure occurs. Retransmission of time-based data like IMU readings is not useful and may eat up the bandwidth of the bus.
If a node is continuously sending corrupted packets, the faulty node should be suspended or shutdown. It may be desirable for a faulty node to shut itself off, but the node should be able to be shut off by the flight computer.
Performance
The bandwidth of the bus must be large enough to keep data flowing and nodes operational. Some nodes will require access to the bus on regular intervals, while others will be sending non-periodic data packets. The previous rocket's CAN bus provided 1Mbps, and at most 40% of that bandwidth was used. The bandwidth requirement may change, so more bandwidth would be better.
Connectivity
The bus should be able to interface to laptops during testing with minimal difficulty. The communications connectors should be easy to remove during development and testing, but must lock down during flight. It would also be ideal if the node controllers could be flashed over the bus.
Firmware and Device Drivers
The firmware for the node controllers should be maintainable. If there already exists tested bus protocol drivers, it would be advantageous to use them to minimize the development time and design complexity. The open source RTOS we choose should have a hardware-independent driver framework for the type of bus selected.
Communication Buses under consideration: USB and CAN
Reliability
Both USB and CAN are differential busses, and are more immune to EMI than single-ended busses. CAN is used in some automobile systems, but not in any systems where failure of the bus alone would result in an accident. USB is used in some medical devices, but not in life-critical devices.
CAN and USB differ in how they prioritize messages. CAN provides a message-by-message prioritization: when the bus is idle and two nodes attempt to transmit, the node with a higher prioritization continues to transmit and the other node waits for the bus to become idle. USB allows the software to reserve bandwidth for each USB endpoint.
USB relies on a host (in our case, the flight computer) to initiate all transactions, even interrupts. This means that if the flight computer powers off, no messages will flow on the bus. With the CAN peer-to-peer model, the bus would still operate if the flight computer were offline.
Data Integrity
The CAN controller handles packet retransmission automatically. The Software team is concerned about the automatic retransmission of all corrupted packets. Often we don't want an older time-dependent message (such as an IMU message) to be retransmitted if it means that we don't receive the newest message. If a high priority node starts sending lots of corrupted packets, it may flood the bus with automatic retransmissions. This is a remote possibility, but it demonstrates the inflexibility of the CAN transmission protocol.
USB provides some flexibility when it comes to message retransmission. If the transmitter uses isochronous transfers, there is no ACK of the message, and corrupted packets are not retransmitted. Isochronous transfers provide guaranteed bandwidth, and would be ideal for messages from the IMU. Control transfers provide a limited amount of guaranteed bandwidth (10% of the frame, or more if the isochronous transfers take less than 90% of the bandwidth). They are acknowledged by the receiver, and automatically retransmitted if the message was not acknowledged or if it was corrupted. Control transfers would be ideal for system critical messages, such as data from the DTMF receiver board or commands to the recovery node. Each USB endpoint could be set to a different transfer type.
Performance
CAN provides 1Mbps, and full-speed USB provides 12Mbps.
Connectivity
A USB communications bus could be directly plugged into a software developer's laptop. CAN requires special conversion hardware (such as USB to CAN adapters) to interface with a laptop. USB will require a special connector, since the standard connector does not lock into place. However, CAN has no standard connector, so we will be creating our own custom connectors anyway.
Firmware and Device Drivers
The most likely candidate for an open source RTOS is eCos, and the flight computer will run Linux. PSAS members have experience writing CAN drivers, but they also have local contacts with people who write Linux USB device drivers. There are many Linux and eCos USB drivers available that could be modified, but few CAN drivers. Linux and eCos both have a hardware-independent driver framework for USB, but not for CAN.
PSAS members have written CAN drivers, and PSAS has contacts with programmers who have written USB drivers for Linux. Even if we find a device driver that meets most of our needs, there will probably be some custom "hacking" on it.