There are many components to the balloon’s electronics, so I will try to cover each section in a summarized overview.

One of the biggest design goals here is reliability and fail safes.  From every system down to every line of code we need to consider what will happen if the the unexpected occurs.  An example of this might be if a message is send from one component to another we need to expect that it might not get there the first time – or it might not be exactly what we are expecting.  In terms of large scale design this means overall redundancy for mission objectives.  First and foremost being tracking the payload (the electronics package) as it flies over northern NY.  Ultimately we need to know the position.

For this reason all the electronics have been broken into two main subsystems – the xbee system and the APRS system.  Both of these systems have separate batteries, GPS, antennas and radios.  If one just plain stops working we have the other, and using one should not degrade our knowledge of the location of the payload.   I say ‘should not’ because the only unknown here is the overall range in free space of the xbee radios, but I will get into that when we start range testing.

The APRS subsystem

The APRS system is our ‘dumb’ system.  It does nothing except transmit GPS NMEA sentences.  This is accomplished with the Opentracker.  This device converts the serial data from the GPS into sound that can be transmitted over the radio, specifically using the APRS formatting method.  Some APRS data comes into receivers and is sent to a server online at aprs.fi.  However it is important to note that APRS can be received and decoded by any person with a radio and computer, and therefore does not rely on network connectivity or cell service – a point which I will cover in another post.  The APRS system is not charged by solar panels.  It runs off a 7,800 mAh 2 cell Lipo battery pack.  It will last a very long time -but once it runs out that’s it.

Here is a depiction of the APRS system. (red lines are power black are signal)

The Xbee subsystem

Simplicity is good, and generally it is more reliable, but Clarkson is an engineering school.  We are not going to just throw an iphone in a box and send it up – nor are we going to just send up an APRS tracker.  The second system, the Xbee system adds complexity, but also adds interactivity.  Xbees  are integrated data radios that act as a serial data link between two devices.  The have lots of fancy features, few of which we will use.  The Xbee will be connected to the xbee controller, which we built.  The xbee controller is responsible for handling all the commands the xbee receives.  The Xbee may request position, or other data from the position supplier uC (I may refer to micro controller as uC).  This system also monitors voltage levels, current consumption etc.  But that’s not all.  The cameras have to be controlled.  The balloon watch uC will handle this, as well as log data about the photos it takes.  (The cameras will play a special role in this project and I will have more about that system later)

Here is a block diagram showing the basic layout of the xbee system. (red lines are power black are signal)