• 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

Title

Node Front End Design for the PSAS LV2b Avionics System

Purpose

This product is designed to be manufactured and used by the the Portland State Aerospace Society (PSAS) on their amateur rocket. This product is a node front end which will facilitate communication between sensors, actuators, and the flight computer, along with providing power to the sensor and actuator nodes. The front end will be the local processor on the node. It will gather, process, and send data over the communications bus, along with responding to commands and input.

Product Environment

Compared to commercial electronics, avionics systems must endure a harsh physical and electrical environment while meeting a higher standard of reliability. The temperature and vibration limits of the avionics environment are similar to those of industrially rated systems, and like many industrial and medical systems, avioncs systems have a high cost of failure. Avionics failures can become life threatening. In particular, failure of the PSAS avionics system could cause the rocket to behave in unsafe ways, endangering the lives of PSAS members and bystanders at the launch site.

Temperature constraints

The avionics package will be subject to a wide temperature range. During normal transport, storage, and development, temperature will vary over the normal range for commercial electronic equipment, that being 0 to +50 degrees C. However when the avionics package is in operation, the temperature will vary over a wider range. Military equipment is typically specified for -50 to +100 degrees C. This range would be desirable for the avionics package.

We have recorded various temperature extremes in previous LV avionics:

• Approximately -5 degrees C while the avionics rests on the launch pad for 4 hours or more on a very cold desert morning in winter;
• Approximately +40 degrees C while the avionics rests on the launch pad out in the sun on a clear day.

Other factors that can contribute to temperature variations are internal heating of the avionics package due to RF power amplifier heat dissipation, and external heating of the space-frame due to atmospheric friction which is conducted into the interior.

It should be noted that previous LV avionics packages had no active thermal management systems. All thermal control was provided through the use of heat spreaders that warmed up the entire avionics module. Forced air cooling was not used; ambient air heat sinks or heat pipes were not used. These mechanisms for thermal dissipation should be reused in future launch vehicles.

Vibration and acceleration

Previous launch vehicles(LV) flights had been designed with the understanding that the airframe will be subjected to accelerations up to 20 g during the boost phase of flight. This value was determined through simulation by the PSAS mechanical engineering and propulsion teams based on the allowed time duration of boost. 20 g is a maximum static continuous acceleration. It is possible to determine a typical vibration level that this system must withstand using accelerometer measurements recorded during previous LV flights from the on-board IMU.

The vibration characteristics of future LV2 flights (LV2 is the current launch vehicle revision), are expected to be similar since the same airframe and propulsion system will be used in this LV family. The revised avionics system will use simple passive vibration isolation and have minimal additional armoring for survivability.

Standard construction techniques include:

• G10 or FR4 PCB materials at around 1.6mm thick
• mounting non-surfacemount components axially, and additionally supporting them with beads of RTV material
• lacing connecting wires using plastic zip-ties at approximately 50mm or less
• providing strain relief on connectors with head shrink tubing
• consitent fastener retention by threadlocking, washers, or other means as required

Accessibility and usage by developers

Even though the primary design goals are set by the extreme requirements of flight, this circuit must work well in the hands of its developers on the workbench where it will spend 99% of it’s operating life. Because of this, the circuit must be durable enough to withstand the following:

• frequent connecting and disconnecting from the daisy chain without adverse effect to connectors or wires
• transport and handling with moderate care in static resistant bags
• repeated power up and down
• unexpected power shutdown without any shutdown procedure being run
• possible reverse power connection
• possible misconnection of power and communications on the daisy chain
• survive short duration overvoltages, for example 125% for 3 seconds.

The nodes should be tolerant of these conditions, and should not adversely effect the development systems (often laptops) connected to the nodes when these conditions are present. (For example, cross-connecting power and communications should not damage the serial port of the developers laptop.)

Choice of materials to meet environmental conditions

It is completely reasonable to require the materials used for construction of nodes to be avaliable commercially off the shelf (COTS). There should be no need for rare, hard to find materials.

High Radiation Environments

It is outside the scope of the LV2 family to consider the effects of high radiation environments, however for future LV projects this may become necessary. For this reason, it seems important to keep the idea of hardening to high radiation levels, at least those experienced in low earth orbit (LEO) for 14 day missions, somewhere on the design horizion.

Reproducibility

PSAS is focused on using open hardware/software and inexpensive, commercial-off-the-shelf (COTS) parts. Our goal is to be able to have other avionics teams look at the website, download our software, and use our specs to duplicate our work. The PSAS industry sponsor wants us to create a white paper explaining our design, the design process, and justifying our design decisions.

PSAS is a student group, and as such has a high attrition rate for student members. The documentation for this project must be clear and detailed enough such that another group of PSAS members could reproduce and modify our design without our assistance. They should also be able to generate a list of required parts for replacement nodes.

Constraints

Cost

Because PSAS is a nonprofit, grant-driven group, the front end should be inexpensive. The industry sponsor would like to target a cost of less than $150 including parts, fabrication, and stuffing.

Robustness

It is very important that the whole front end should be mecahnically and electrically robust. A front end failure costs more than just replacing a component: precious PSAS volunteer time used to replace the component, the logistical investment in an attempted launch scrubbed by a front end failure, a possible loss of the vehicle if a node front end fails in flight, and in the very worst case, a severe injury to a person if an actuator node malfunctions. Thus, front end subsystems should be designed to be as reliable as possible and fail gracefully.

Redundancy

Although system redundancy can improve robustness, the resulting growth in size and complexity is not reasonable for a small, inexpensive, complexity-constrained system like PSAS avionics system.

Power

The node front end should minimize power consumption in order to reduce battery size and weight. The new front end should use an equal or lesser amount of power than the previous node front end used, roughly 190mW.

Electrical supply variation and noise

There is a common power system on the LV2 avionics package that is provided by the Avionics Power System (APS). The APS routes an unregulated battery voltage around to the various subsystems through a switch matrix. The primary power source is a 14.4 V Lithium Ion Polymer battery bank. The battery voltage can vary above or below the nominal; it may be as high as 20 V (when external shore power is used to charge the battery pack which has a maximum voltage of 16.8 V), and as low as 10 V (when the battery is deeply discharged).

Several of the avionics subsystems (and thus front ends) have a direct power connection to the APS via the power switch matrix. Other subsystems are daisy chained off of a single power switch. In both cases, power is routed from the power switches in the same cable bundle as the node communications bus. The power is passed through the same connector on redundant pins.

If power cables were daisy chained, it is possible for noise from one node to be injected into the power bus. It is also possible for communications noise to be coupled onto the power circuit since the conductors are an unshielded twisted pair (UTP). Finally, external noise (such as RF or other EMI sources) could be coupled into the node power circuit.

Since power to the node could contain noise, there should be high frequency inductive and capacitive decoupling as the power enters the nodes' circuit. The range of high frequency noise could be from the base crystal oscillator range of 10 MHz, well up to microwave at around 2.4 GHz. The largest RF noise is expected to be near the communications transmit frequencies of 1.2 GHz, and 2.4 GHz.

Size

The older front end nodes ranged in size from as small as 1" x 3" to as large as a 5" diameter hexagon. The reason for the variance is due to the generic front end circuitry being customized for each sensor group on a node. The part of the board that contains the older front end side was about 1" x 2". The new generic front-end should be comparable in size. Ideally, it would be less than 2.25" square and less than 1/2 in. thick.

Microcontroller

The industry sponsor, wants the front end to use a 32-bit microcontroller becuase the performance/cost point of 32 bit microcontrollers is equivalent to 16 bit microcontrollers for low unit quantities. The micrcontroller should have many implementations, by more than one manufacturer if possible. The node will be in use for at least three years, so it would be a plus if we were be able to purchase new microcontrollers without changing the design. If the manufacturer had several versions of the microcontroller that had the same footprint, we could easily update to more RAM or flash.

The microcontroller must also have current and active open source software tools like gcc, gdb, and binutils. The software team should be able to port an open source real time operating system (an RTOS, like eCos) to the microcontroller. The microcontroller must have a useful open debugger protocol, like JTAG.

This must be a microcontroller designed for embedded use: it must have at least 128kB on-board flash, and at least 32kB SRAM on board. The microcontroller must be faster than 10 MIPS (Millions of Instructions Per Second); it should be around 60 MIPS. It should also be a low voltage microcontroller (less than 5V) with power-saving modes.

The microcontroller must have an on-board interface to the chosen communication bus. Currently, CAN or USB is being considered. Ideally, the microcontroller would have both CAN and USB, so that the avionics team could have the option of using the old bus (CAN) and still have the flexibility to explore an untested bus (USB). The microcontroller should also have serial connection(s), such as a UART (Universal Asynchronous Receiver Transmitter) or SPI (Serial Peripheral Interface).

The microcontroller must be able to be routed and mounted on a two layer PCB. QFP (Quad Flat Pack) will work for 2 layer PCBs, but PLCCs (Plastic leaded chip carrier) and DIPs (Dual Inline Package) will most likely be too big, given the space constraints. A 32-pin BGA (Ball Grid Array) package might be feasible, if we can get funding to have it mounted commercially. Also, the pin count has to be considered due to the limited routing space on two layer PCB; more I/O's are not neccesarily a desired spec. A QFP should have less than 64 pins (100 pins might be feasible, but 144 pins is the absolute maximum).

The desired peripherals for the microcontroller include a decent integer math ALU, 10 bit ADC, PWM x3, watchdog timer, and brown-out reset.

Switching Power Supply Requirements

The nodes switching power supply is a DC to DC converter that conditions the power source described above into the regulated voltages needed by the microcontroller, communications physical layer (PHY), and subsystems, sensors, or actuators in the application specific section of the node. It is conceivable that the application specific section of the node will have power requirements that are not met by this power supply and is outside the scope of this project.

The power supply must accept an input voltage in the range of 10 to 20 VDC, conceivably with some noize on it. The conversion efficiency must be at least 70% or better. For comparison, the previous power supply was 80% or more efficient between a load range from 10mA to full load. Another comparison point is size; The previous supply had a plane area of 1 sq.in. with components mounted on both sides of the board. (i.e. 2 sq.in. total surface area). The Electromagnetic Interference (EMI) created from this supply must be compatible with onboard communication systems, meaning it must not adversely effect them over the supplies full range of operation. This will drive the drive the decision of converter frequency, and will require this frequency by crystal oscillator locked. There must be a capability to shut down the supply from an external logic signal from the microcontroller. The supply must provide protection to the node in the form of undervoltage lockout, over voltage protection, and reverse polarity protection. The supply must also provide overcurrent limit protection to the supply bus (typically in the form of a fuse).

Communications Bus 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.

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.

Manufacturing Constraints

Once the front end is designed, PSAS will have the printed circuit board fabbed commercially for free through PCB Express. The board will be a two-layer PCB. Signals should be routed to the edge of the node front end to the "dividing line" between the front end and what will become the specific avionics node's custom circuitry. This makes routing easy during the customization of the node.

Circuit components must be surface mount for size constraints and mechnical robustness. It is conceivable that the board have a conformal coating applied once development is complete to enhance resistance of destructive effects of moisture, propulsion gasses, and ozone. Where possible, all external connectors are to have redundant pins for each connection.

Mechanical

The front end should also have robust mechanical connections to ensure parts don't come loose due to vibrations, pressure, or strong gravitational pull during launch. These mechanical connections should fit snugly and lock down during flight. Connections include wiring from the sensors, power supply connections, and communications bus connections. The connections to the communications bus should be easily removable to facilitate testing and debug.

Product Lifecycle

The front end design will probably be used for at least three years. The group is slow to change technologies, so the node should be as state-of-the-art as possible, while using parts that will be available and supported for the next few years. It is especially important that the microcontroller be available for the lifetime of the node, since porting an open source RTOS to a new microcontroller may take a few months. A newer version of the microcontroller with the same footprint may take less time to adjust to, so picking a stable microcontroller family would be sufficient.

Testability

The microcontroller should have a useful debugging connection, such as JTAG. The mechanical connections should be easy to place and remove, so that boards under test can be added and replaced in the avionics system.

Software Requirements

Where ever possible, PSAS wants to use open source and/or free software. This may include device drivers, firmware, and development tools. Cadsoft's EAGLE CAD is a free program that the Capstone group will be using for the printed circuit board design. The free version only allows creation of two-layer boards, which is one reason (besides cost) for the two-layer board limitation.

Legal Requirements

All the PSAS software, device drivers, firmware, and schematics falls under the GNU General Public License. This license is a "copyleft" license, meaning anyone can redistribute it and/or modify it under the terms of the GNU General Public License (as published by the Free Software Foundation). For more information about GPL, see http://www.gnu.org/licenses/licenses.html. Some parts of the node spec may not fall under the GPL, such as the proprietary boot loader for an ARM chip.

The communications front end must comply with FCC rules and regulations, such as Part 15 of Title 47 of the Code of Federal Regulations. Part 15 governs the design of unlicensed RF devices. Under these rules, the node must not unintentionally, accidentally, or intentionally interfere with other equipment and must accept interference from other equipment. The full description of the regulation is available at http://www.fcc.gov/oet/info/rules/.