• About PSAS
• Get Involved!
• Schedule
• Projects
• Presentations
• Mailing lists
• Contact us

• Teams
  • Airframe
  • Avionics
  • Communications
  • Ground
  • Payload
  • Propulsion
  • Rocket Science
  • Safety
  • Software
  • Uncertainty
  • Regulation
  • PSU Student Club

Part of our capstone project was to decide what communications bus the next generation rocket should use. Numerous suggestions were thrown out (from FireWire to MIL-STD-1553) but only two communication buses were considered in depth: the Universal Serial Bus (USB) and the Controller Area Network (CAN) bus.

Bus Requirements

Avionics Team Requirements

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.

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.

Software Team Requirements

High level software control

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.

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. Firmware and device driver development should not require proprietary software or a propriety environment (i.e. Windows).

CAN and USB Comparison

Avionics Team Requirements

Reliability

Both USB and CAN are differential buses, and are more immune to EMI than single-ended buses. 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.

Performance

CAN provides 1Mbps, and full-speed USB provides 12Mbps.

Software Team Requirements

High Level Software Control

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.

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.

Summary

Hardware Requirements

Software Requirements

As the chart shows, the Avionics team wanted the CAN bus because it provided better hardware reliability and was widely used in safety critical systems. However, USB was an overall win for the Software team. In the end, the promise of higher bandwidth and better open source support won over the Avionics team.