In order to try and document what we've been talking about with
regards to the rocket instrumentation project, to try and help get
some more documentation together in a concrete way, I've taken what
we've discussed thus far with regards to the hardware in the system
and put together a schematic.

This is only preliminary, and it's based only on the discussions I've
had and the posts I've seen. It's entirely plausible that it is
completely different to what you might have in mind, I know, so feel
free to contribute your own feedback.

http://minerva.splcrew.net/RocketInstrumentation.png

i) Temperature sensor.
Here I've just assumed that we can use a DS18B20 to measure
temperature; pretty simple really, just one microcontroller pin, and a
4.7 k pull-up resistor. We could of course have multiple sensors
throughout the rocket and just bus them all together, and connect them
all back to the one connector on the main PCB. There are other sensors
we could use in theory, but the DS18B20 is common, convenient to use,
and there is heaps of experience and documentation with regards to
using it in the Arduino community.

ii) GPS.
Here I've just picked an EM406A from SparkFun for the sake of drawing
this schematic, although we could use any one of a number of others.
It's pretty easy to interface, requiring no external components, just
a two-wire serial interface to the microcontroller (without a spare
UART available, this serial communication needs to be bit-banged using
software, which isn't really a problem, I don't think, but then again
I'm not a programmer. Do we need to choose a microcontroller pin for
the serial input with a hardware interrupt, or something like that?)

iii) Light sensors.
Just two LDRs connected to two microcontroller ADC inputs, connected
with a couple of resistors as voltage dividers. Pretty simple, really.
The resistor values might need to be tweaked depending on the typical
resistances of the LDRs used, but they should be pretty flexible, and
100 k should be about right, since we really only want qualitative
information from them anyway.

iv) Real-time clock.
I've just assumed we're using a DS1307 here, and this is really just a
very simple schematic which is needed to support this device. There
are a couple of 10 k pull-up resistors on the I2C bus, and a LED
connected to the 1 Hz clock output, just as a bit of an indicator that
the system is powered up and alive.

v) Flash memory.
Mike mentioned the AT45DB61B, and that looks like the perfect device.
It has heaps of storage, it's fast, it's easy to interface, and it's
inexpensive. There's nothing not to like with this suggestion. This is
a 3.3 V device, however, but the datasheet says that the
communications signals are 5 V tolerant, so there shouldn't be any
trouble with interfacing it. 2 Mb ought to be enough for anything
(touch wood) but if it isn't, there's no reason why another chip
couldn't be added on the SPI bus.

vi) RF telemetry.
Here, just for the sake of drawing the schematic, I've assumed we
might be using an XBee device, although if you wanted to change the
design to use, say, one of the DR3100 devices there wouldn't be much
of a change, they're still 3 V devices, using bidirectional serial
comms back to the microcontroller, so there really isn't much
difference. The XBees have a couple of LEDs to indicate their status,
eg. that they've got a communication link to another device, so I've
just added these in, since a few blinkenlights don't hurt :)

Note that the XBee is a 3.3V device, so I've just divided the data
input from the microcontroller down with a 2:1 voltage divider, which
should be fine.

vii) Microcontroller
Here I've just assumed that a standard Arduino Duemilanove board is
used, although there's no reason why we couldn't put the
microcontroller and everything in one board in theory. I've especially
chosen the pins allocated for the I2C and SPI buses to correspond to
the AVR's pins for those hardware interfaces, although if the
interfaces were implemented in software, any other pins could be used,
really. Because it's all abstracted into the off-the-shelf Arduino
board, there's really nothing else to comment on in this module of the
design.

viii) Accelerometer and ADCs.
I've just assumed we're using an ADXL330, and the LTC1298s and MPX4115
as Mike mentioned, which is a cool idea.
I chose the ADXL330 pretty much arbitrarily, since it's the first one
I could find an Eagle library for, it seems pretty common, and
SparkFun stock it.
I've put a bit of low-pass RC filtering on the output from the
barometric sensor, using the component values just as given from
Freescale AN146.
I'm currently working out the maths to read out the altitude from the
output from the barometric sensor, which isn't that trivial.

ix) Power supply
Here I've got a MAX1555, which will charge a 3.7 V Li-Poly cell from a
USB connection... if one of the standard Arduino boards was used, or
if we put a USB connector and FTDI chip on the board, this USB input
could be connected to the USB 5 V rail, for example by connecting it
to the drain of the PFET on the Arduino Duemilanove board. That way,
when you plug in a USB cable to download telemetry data from the
Arduino, you're charging the battery.

There's also a MAX1703, which steps up the 3.7 V from the battery to
regulated 5V, and a LM1117-3.3,  to regulate the 5V down to 3.3V. The
MAX1703 circuit is just standard datasheet material.

If we add up the power consumption for these devices, we're looking at
this:

ATMega168: 200 mA @ 5 V
EM406A: 44 mA @ 5 V
MPX415: 10 mA @ 5V
DS1307: 1.5 mA @ 5 V
LTC1298s: 350 uA * 2 @ 5V
Total: 257 mA @ 5 V

XBee Pro: 215 mA @ 3.3 V
AT45DB161B: 35 mA @ 3.3 V
ADXL330: 200 uA @ 3.3 V
Total: 250.2 mA @ 3.3 V

Here I've made conservative assumptions using the worst-case values,
eg. using the values for current draw during active write to the
DataFlash, active AD conversion at the highest possible sample
frequency, using the XBee Pro instead of the normal one, and so forth.

Anyway; this is all preliminary, I've made some somewhat arbitary
choices with regards to certain components just for the sake of
putting some ideas to paper, and more discussion would be great. Of
course, it's entirely possible that I've done something stupid with
the above schematic, and peer review with some other sets of eyes
would be useful. Anyway, I hope you find it useful.

Luke