I am using the Win32::SerialPort module.  Here is a simple example for windows (COM instead of tty):

use Win32::SerialPort;
my $port = Win32::SerialPort->new("COM5");

$port->baudrate(9600);
$port->databits(8);
$port->parity("none");
$port->stopbits(1);

while (1)

{
  my $c = $port->lookfor();

if($c)
 print $c . "\n";
}

We found that our RHCP antennas (right hand circular polarization – not red hot chili peppers) did quite well.  Doyle walked half a mile out, stuck the antenna in the grass and I never received a signal level lower than 80%.  This is a good start, but we were at 1/40th of our expected range on launch day.  We will do more tests soon.  In the video you will see a perl script running.  I will devote a post to this soon.

Years ago I was into putting cameras on r/c aircraft and sending them up to fly around and send live video.  The equipment was pretty expensive and we were always try to get the best performance out of the least amount of power.  I had an issue at that time where banking the aircraft left or right cause the video signal to fade.  It was then that I learned about circular polarization.  I even have 2 helictical antennas left over from those project, but unfortunately they are made for a slightly different frequency.  So I decided to check out the r/c forums to see if anyone had caught on the using circular polarization.

Other than being fascinated by the leaps and bounds that the ‘FPV’ hobby has made in the last 5 years or so I found a wealth of information about building many types of circularly polarized antennas, most from the member IBCrazy.  I have to say, he provides really great tutorials on the antenna construction.  I also found this site which is a really excellent visualization on antenna polarization.

Anyway, here is a video of the antenna that will be balloon-side:

And the helictical antenna we plan to use on the ground (or in the SAR plane – more on this later).

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)

The Clarkson near space balloon is a project between the Clarkson University ham radio club ‘k2cc’ and a few alumni to build a weather balloon and send it to  > 100,000 feet.  I am working on an overview of the systems that will be onboard and a summary of our mission, but for now here are a few tech oriented videos about some of the main components which have been built so far: