Download psas.pdx.edu

2005/06 Capstone Avionics Systems
Team Project



Project Title: The Node
Front End design for
the PSAS LV2b
Avionics System
Members:

Sarah Bailey

Jacob Davidson

Glenn LeBrasseur
Date: 2006-2-3
2005/06 Capstone Project Team


Team members:

Sarah Bailey

Jacob Davidson

Glenn LeBrasseur
Industry sponsor:


Andrew Greenberg
Faculty advisor:

Mark Faust
Who are our customers?



Our single customer is the Portland State
Aerospace Society (PSAS)
PSAS is currently in the process of designing
their fourth rocket or launch vehicle (LV) titled
LV2b
Our Capstone Team will produce the interface
electronics of all of the LV's avionics systems
Redesign of a network based open
avionics system

What is it?


Why is it needed?


To ensure the integrity of the data the rocket generates and
its safe recovery from a flight, all systems within the rocket
must reliably interface with each other
What needs to be done?


The common electronics which will control the interfacing of
the various LV avionics systems
Design and build the interface circuitry
What will be produced?

A two-layer PCB containing the electronics implementing the
interface
Who is the Portland State Aerospace
Society (PSAS)?




Founded in 1997
First US student chapter of the Aerospace and
Electrical Systems Society (AESS) which is a
technical society of the Institute of Electrical and
Electronics Engineers (IEEE)
As far as the group knows, they are the most
advanced amateur rocket group in the world
PSAS designs, builds and launch amateur
rockets or launch vehicles (LV) into the lower
atmosphere
What is the purpose of PSAS and
their objectives?


Pioneering active guidance and open source
software and hardware aerospace systems
Long term goal:

Design, build and put a “nanosatellite” into Earth
orbit
What are the future plans for PSAS?



Design their fourth rocket, LV2b, which will be a
research platform for active guidance
The rocket will consist of a network of nodes,
each doing a specific function
The following is the block diagram of the LV2a
avionics system:
We are going to redesign the old
node interface of each node
LV2b nodes

MASTER NODE: Flight Computer (FC)

Amateur TV (ATV)

Inertial Measurement Unit (IMU)

Global Positioning System/Satellite (GPS)

Environmental Sensors

Magnetometer

Recovery Node
Where does the Capstone team fit
into PSAS plans?


We are in charge of designing the common
electronics that run all of the avionics nodes
Called a node front end, it includes:

32-bit microcontroller

Switching power supply

Communication bus interface
Block diagram of LV2b Node Front
End
LV2b Avionics Node
Switching power
supply
32-bit
microcontroller
Power
bus
Comm bus
Node Front
End
Application specific
circuits (e.g. IMU,
GPS)
What are the deliverables required
of the Capstone Team?



Design of the node front end

Schematic capture and PCB layout

Design notes
Front End prototype which includes:

Commercially built two-layer PCB

Populated and tested components
A white paper of the node front end design
What is the Node Front End?
(Example: Recovery Node)
What is the Node Front End?

Designed for PSAS

Used with every Avionics Node

Communications relay

Local processor for sensor data

Supplies power
Node Front End Environment


Rocket Environment:

-5o C to +40o C

Intense vibration

Acceleration up to 20 g

EMI (10MHz to > 2.4GHz)
Test Environment

frequent handling and transport

frequent power and communications
connect/disconnect
Front End Constraints

Should be < $150

Must be very robust

Immune to EMI

1" x 2" in size

< 0.5" thick

Power consumption <= 190mW

Condition power bus (10-20V) to required
voltages for the node
Parts Constrains

Parts should be

surface mount

able to be routed on a two-layer board

connectors should lock down during flight

Board may have a conformal coating

Redundant external connectors
Reproducibility

COTS components

open source or free software

documentation

PSAS wiki

design notebook

white paper
Power Supply Requirements



must condition 10V to 20V input to required
node voltage
> 70% efficiency
EMI from supply should not interfere with other
systems

external shutdown control

undervoltage lockout

overvoltage protection

current limited
Communications Bus Hard
Requirements

Must handle




shorts and opens on PHY layer
acceleration and vibration
Must prioritize messages


EMI
System critical messages should be sent, even at
the expense of non-critical messages
bandwidth >= 1Mbps
Communications Bus Soft
Requirements

“Shoulds”:

software handling retransmission

Faulty nodes can be shut down by FC

previous use in critical real-time systems

easy interface to laptops

node controllers flashed over bus

existing bus protocol drivers
CAN vs. USB

differential bus

differential bus

1Mbps

12Mbps

CAN in cars

message-by-message
prioritization




peer-to-peer
automatic
retransmission


USB in medical
devices
bandwidth
prioritization
mastered bus
depends on transfer
type
CAN vs. USB



laptop interfaces
through special
hardware
PSAS members wrote
CAN drivers for PIC
no CAN drivers for
Linux or eCos




laptop can directly
plug into the bus
local contacts who
wrote USB drivers
Linux has many USB
drivers
eCos has hardwareindependent USB
driver framework
Microcontroller Requirements

Needs:

32-bit, >= 128K flash, >= 32K SRAM

> 10 MIPS (around 60 MIPS is the goal)

OSS tools like gcc, gdb, or binutils

open debugger protocol (e.g. JTAG)

Usable packaging


QFP, less than 144 pins (64 pins is ideal)

BGA < 32 pins (with commercial mounting)
communication bus connection (USB or CAN)
Microcontroller Requirements

Wants

multiple implementations from more than one
manufacturer

integer math ALU, 10 bit ADC, 3 PWM, watchdog
timer, brown out reset

reasonable voltage requirements (3.3V only or
3.3/5V)

existing open source RTOS, like eCos

low power modes

low cost