PLEASE NOTE: This project has been superceeded by the ArduinoTrack
controller. You can read more about the ArduinoTrack Controller by
clicking the link at the right.
Project: Traveler is a group of high-altitude balloon enthusiasts based in Hutchinson, Kansas. After seeing a couple of demonstration flights from then KNSP (Kansas Near Space Project) leader Paul Verhage, KD4STH, back in 1999, we knew that we wanted to participate in high-altitude ballooning. To sum it up, our small group of ham radio operators (and a few non-ham helpers) put ourselves to the challenge of attaching a radio transmitter, a GPS, and some other paraphernalia to a weather balloon and send the whole thing up into the upper atmosphere with hopes of retrieving it. The paraphernalia would include, among other sensors and actuators, an APRS (Automatic Position Reporting System) transmitter which would take GPS coordinates and transmit them back to the chase teams. The rest of this article outlines our thought process and experiences we've learned along this bumpy road.
Having given us the 'itch', the design of our electronics package began shortly after Paul's demonstration flights here in Hutchinson. I could see very early on that our group would need a versatile microprocessor based APRS solution that could be modified relatively quickly based on the next scheduled launch's payload. Now that our group has a couple of successful flights under our belt, I would like to share a few of our APRS secrets with both fellow ballooners and just plain ol' APRS enthusiasts.
After countless hours of research on the web and on the telephone, I found that I kept coming back to a TAPR (Tucson Amateur Packet Radio, www.tapr.org) creation called the PIC-e. PIC-e is a small board that holds a PIC16F84 microprocessor that interprets GPS data and creates APRS packets from it, which it periodically transmits via an MX-614 modem chip and an external transmitter. The fact that I could build a 'TNC' out of about $50 worth of parts and fly a balloon excited me, but we wanted a little more – we needed some digital and analog I/O (Input/Output).
On to the Drawing Board
With some schematics and source-code in hand from the PIC-e project, I began stripping the circuit down to its bare minimums and figuring out what made it tick. What I found was that the PIC16F84 microprocessor did all of the data collection, formatting, and packetizing and that the MX614 modem simply converted the digital output of the PIC into audio tones for AFSK (Audio Frequency Shift Keying). The more I dug into the design, the more I liked it – it was just want we needed minus a few additional 'features'.
The first thing to be changed was the PIC chip. Now I have nothing against the 'F84, but for our purposes, it is just too limited in its I/O. Fortunate for us though, Microchip had recently announced the PIC16F84's big brothers, the PIC16F87x series. In short, the 'F87x series offers more digital I/O, multiple 10-bit ADCs (Analog-to-Digital Converters), more memory, and full backwards compatibility with other mid-range PIC chips (i.e. The PIC16F84) while still using the flash memory.
Now I was sold. I'd just drop in a PIC16F873 chip with the MX614 modem and we would be ready to fly!
A Soldering Iron in Hand
Things didn't go quite as smoothly as I originally anticipated, and before I was done I had purchased a few hundred dollars in additional tools and equipment, but things were coming together.
The first prototype was built on breadboard and had all kinds of 'features' such as RS-232 level converters – you know, just in case I wanted to hook my laptop into it at 90,000 feet and do some diagnostics. I used multiple microprocessors to keep the load down on the individual PICs (and the component count and complexity up), after all, we can't have that 5 MIPS (Millions of Instructions Per Second) speed demon overheating! After working out some major bugs, I finally got this beast's heart beating and we were transmitting APRS packets. Our group was sold so I turned the schematics over to another project member to get the PCB (Printed Circuit Board) artwork drawn up. Soon we had a drawing in CAD (Computer Aided Design) that represented nearly 100 hours of our time in research and design.
The first PCB version of the circuit was nearly four times the physical size of the current revision. Although not as bad as the initial prototype, the first board had its fair share of 'features'. It included five servo drivers, a diagnostics port, and spare analog input buffers and amplifiers. Despite its obesity, this board flew on Project: Traveler's maiden flight; the capsule rose to over 91,000 feet and flew over 200 miles north of its initial launching point.
We Learned a Lot
We learned a lot from that first flight. The first thing we learned was that when you think you have enough helium in a balloon, add a little bit more. The balloon was only supposed to fly about 70 miles, but due to insufficient helium, it rose too slowly. Next, we realized that sometimes we need lots of 'features' on our controller, and other times we don't need them. And sometimes we just need different features. We also learned that using model airplane servos to actuate cheap 35mm cameras was a waste of money.
So after being so proud of our brand-new PIC based APRS controller, we quickly trashed the unit shortly after retrieving our balloon capsule.
Back to the Drawing Board
Members of the Project: Traveler group held several meetings discussing this most recent flight, as well as future flights and their payload. During one of the meetings it became blindingly obvious that what we need is a universal controller board that can drive servos, or drive motors, or drive cameras (electronically triggerable by-the-way), or drive relays. The key to all of that is 'or'. Because we try to keep our flights light (under six pounds) for safety and regulatory issues, we found that we will probably never need five servo drivers or an RS-232 level converter on a controller, especially not at the same time.
I soon retired to bed with an old copy of a DigiKey (www.digikey.com) catalog for some inspiration. And then it hit me – build a controller board and use a plug to mate it to a daughterboard. The motherboard would consist of a PIC16F873 microprocessor and the MX614 modem. It in itself would contain all essential components for flight (power supply, GPS interface, transmitter interface). On the back side of the PCB, we would attach a surface-mount plug that could transfer power, data, received audio, and GPS information to a daughterboard.
The daughterboard could be either as simple as a couple of transistor drivers or as complex as a second microcontroller making its own decisions. Best of all, this daughterboard could be easily customized based on the flight objectives to handle any conceivable task we could throw at it since it doesn't contain any of the sensitive timing circuitry or software that is on the motherboard. By doing so we seemingly eliminated all of our troubles of trying to decide which 'features' should be on the controller board because it was apparent – whatever we designed would be wrong as soon as we found another gadget to send up.
The Final Configuration
We are now on revision 1.2 of the motherboard. Basically it consists of a Microchip PIC16F873 microprocessor and an MX-Com MX-614 modem chip. The circuit would be built on a standard 3x4 inch circuit board and have a number of plugs and connections to communicate with the outside world.
Early on we picked the Garmin 35-HVS GPS engine. This particular unit is available for under $150 directly from Garmin (www.garmin.com). It's roughly the size and shape of a computer mouse and doesn't have any buttons, controls, or even a plug on the end of its cord; it is truly an OEM (Original Equipment Manufacturer) device. For a transceiver, we settled on Yaesu's VX-1R for its small size, light weight, and detachable antenna (essential when you're plugging into full-sized collapsible dipoles on the outside of the capsule). For balloon flying, output power really isn't a concern since the capsule is virtually always within line-of-sight range.
To connect with the VX-1R, plug P2 is a small five-pin plug that supplies power, ground, and mike audio. I've also included a separate PTT (Push To Talk) line which is grounded during transmit if you will be attaching to a transmitter that doesn't used the combined mike audio and PTT. And finally, I have allocated a pin to return received audio back to the motherboard and the daughterboard if you wish to develop the software to receive signals.
The GPS uses a small four pin plug, P4, to retrieve data from the GPS and supply power to it. The plug supplies power to the GPS and retrieves data from it.
To keep things simple in switching between various types of equipment, I have added two jumpers to the board to select output voltage to the VX-1R and the GPS. Both select between full battery voltage and regulated 5.0 volts. The transceiver's jumper is labeled J1 and the GPS's jumper is labeled J2 on the schematic. In our particular case, we run 5.0 volts to the VX-1R and battery voltage to the Garmin 35-HVS GPS engine. The 5 volt regulator is capable of 1.5 amps but a heat sink should be used if you will be pulling more than about ½ amps.
Using the same infrastructure that we already developed on the first prototypes, I stripped it down to its bare essentials and we began the circuit board design process. Version 1.0 was very successful on its one and only flight but we had a couple of bugs to fix. Version 1.2 is the most recent revision and is described below.
The circuit is extremely simple - chip U1 is a voltage regulator which provides the balloon with a steady 5.0 volts. The 5.0 volts feeds the MX-Com 1200 baud modem (U4) directly and the PIC microprocessor (U3) through diode D4. U3 contains the 'brains' of the project, as well as the hands and eyes. By studying the schematic, you will quickly realize that most of the pins from U3 go directly to either the modem (U4) or the daughterboard connector (P3). The ceramic resonator (X2) provides a steady heart-beat for the PIC at 20.0MHz.
By studying the schematic, you will notice an SD103A diode (D4). Its sole purpose in life is to keep the in-circuit programmer for powering up the rest of the board during the programming cycle. This particular diode was chosen for its low forward voltage drop since we want the PIC processor (U3) to be running as close to 5.0V as possible. Because of the diode drop, the microcontroller powers up at about 4.8V which doesn't cause a problem with most digital circuits except for the ADCs. To compensate, we have to feed the PIC chip, U3, with a solid 5.0 volt reference on pin 5.
Next to the microprocessor lies the MX614 modem chip, U4. There's nothing particularly magical about this chip, especially in the transmit-only configuration we have it setup in. In short, a handful of digital I/O lines run from U3 to U4 sending data and setting a couple of configuration pins on the modem. The modem drives the transmitter directly through pins 7 and 8 with the help of a few resistors and a capacitor. Transistor Q1 is driven by a digital output line from U3 to key the transmitter at the appropriate times.
Plug P3 is a 24-pin, surface-mount plug that connects the motherboard to the rest of the world via a daughterboard. Don't be intimated by the term surface-mount – with a good sharp point on a low wattage soldering pencil, you'll have the plug attached in no time. Pins 1 through 11 are digital I/O, pins 21 through 23 are analog inputs, and the remainder provide received audio, GPS data, and power to the daughterboard. Note that analog input on pin 21 (P3) is shared with the IAT (Inside Air Temperature) sensor U2. If you need the extra analog input, you must first remove U2 and its associated circuitry.
Finally, on the motherboard remain a couple of unusual circuits which deserve explanation. The first is the voltage divider consisting of R1 and R2. It's real simple – it divides the incoming battery voltage down to a level below 5.0V so that the ADCs can read the status of the battery and transmit it back to the tracking stations. The divider results in a voltage that is approximately 1/3 the voltage of the battery it is measuring. The allows the microprocessor to accurately read battery voltages up to 15.5 volts.
Secondly, U2 has a bit of an odd configuration with diodes D2 and D3 supplying its ground. Device U2 is a temperature sensor, LM35CZ, made by National Semiconductor. This particular device is calibrated in Celsius degrees and is used to sense the board/IAT. By design, U2 has an output of 0°C = 0.0V. Unfortunately, the upper atmosphere gets quite a bit colder than 0°C (we've seen -54°C and heard of a lot colder than that on the outside of the capsule). In order to register temperatures lower than 0°C, we must artificially 'raise' the ground on the sensor. Diodes D2 and D3 serve this function and bring the ground lead up about .95V. Resistor R3 is a required pull-down for the output.
The software was written in C using a compiler developed by Custom Computer Services (CCS, www.ccsinfo.com) I originally began developing this project using strictly assembly language. After 10 hours of pure frustration, I ordered the compiler and had the equivalent amount of code running in under an hour. Hands down, the compiler has been one of my better investments that I've made.
Many of the core ax.25 functions were actually written by John Hansen, W2FS, for the TAPR PIC-e APRS beacon and have been modified to fit our controller and my coding-style. Aside from the ax.25 routines, the rest of the code is primarily a large loop that waits a period of time, collects the GPS data, collects telemetry data, and transmits them to the ground. The code itself is fairly simple and anyone with any C-language experience should be able to make modifications and updates to the firmware.
I will also attempt to help individuals if they wish to modify their source-code, but please understand that I have a 40-hour job and a family in real life, and don't have the time nor the energy to rewrite what I've already done. Future updates of the firmware will be maintained on the group's website at www.rckara.org in the Project: Traveler section.
Practically all of the components can be purchased online from DigiKey except for the MX-614 modem. The modems can be purchased directly from MX-Com (www.mxcom.com) if you can get the right person on the phone, but TAPR has purchased a quantity of these and has made the available for six dollars (as of the fall of 2001).
Construction of the motherboard is very simple. I have provided our most recent PCB pattern to etch the board. Most of the traces are ½ of a millimeter in width so you will need a high-definition transfer method (or a sharp pen and lots of patience). I personally endorse the photo-resist methods as sold by Jameco (www.jameco.com). Our board was designed to fit their 3x4 inch positive transfer blanks perfectly. Drilling should be done with a small bit and a drill press. I use a Dremel tool in a drill press mounting kit.
Assemble the circuit board but don't solder U3 or U4 in yet. Check your work carefully for solder bridges and when all is clear, apply a DC current to P1 of at least 6.3V. The 6.3V is important – the board should never be run under this level because the voltage regulator U1 needs about 1.3V above the 5.0 output in order to regulate. Allowing the output of the regulator to drop below 5.0V (thereby causing the microprocessor voltage to drop) is just asking for trouble. During testing I generally use my 13.8V power supply, however, as I have learned the hard way, current limiting/protection would certainly be a good idea with a 35 amp power supply.
Once you have power on the circuit, you should check for a couple of crucial voltages on the board. First check for 5.0V on pins 12 and 16 of U4. If you have anything beyond about 5.0± .1 volts on these pins, then you have have a short, a break, or a bad regulator. Next check for voltage at pin 20 of U3. Because this pin is fed through diode D4, you will have about .1V below the output of your regulator without a load. Once U3 is soldered in place (thereby putting a load on the diode), the voltage will drop down further to about 4.8V. You can also confirm the proper operation of temperature sensor U2 at this point by checking for a voltage of about 1.2V on the hot end of resistor R3. This voltage will vary with temperature but should be close at room temperature.
If you have a proper voltage, then go ahead an insert the last two IC's (integrated circuits), U3 and U4. Remember, if you plan on removing the PIC for programming, put it in a socket. We probably haven't left enough room for a ZIF socket (not to mention they're somewhat hard to find in .3 inch spacing), but speaking from experience, a good quality socket seems to be able to withstand 50 to 100 insertion/extractions without too much wear and tear.
Once the board is complete and working, there is one final step that is essential if you plan on sending this unit up in a balloon or use it in extreme cold. The Project: Traveler group discovered on our maiden flight that as a package which has been at or below freezing drops through lower atmosphere, it tends to condensate. This concept never occurred to us as we prepped the capsule the first time, and consequently at about the time it dropped through 8,000', the transmitter suddenly started making funny noises and then went off the air. Thankfully it came back on about 10 minutes later. After the flight, we were able to reproduce this behavior by creating condensation on the board (lots of circuit cooler). Apparently our Yaesu VX-1R (and I suspect many other HT's) can be keyed up very easily by a little bit of water between the mike line and ground.
The solution to this problem is relatively simple – coat the completed circuit board using a circuit board sealant. Our group used a silicone conformal coating made by M.G. Chemicals which we purchased at a local electronic supply shop and was brushed on to both sides of the circuit board. Newark Electronics (www.newark.com) has a number of products available that should work just fine. A final note on this issue, I was still able to key the transmitter with circuit coolant on the ground if I really tried hard, but it wasn't nearly as easy. The subsequent flight tests indicated that a good couple of coats of sealant seems to have corrected the problem.
Once the motherboard is created and tested, you can then begin thinking about what type of daughterboard you need to create for your particular application. If you are just wanting a simple APRS tracker, then you may not even need to consider this, but if you wish to interface with the outside world, a custom daughterboard is necessary.
I have included schematics for one such custom daughterboard as a sample which we used on our second flight. As you can see from the schematics, the daughterboards tend to be very simple. In our case our primary goal was to control a relay which actuated an ATV transmitter. We also had a separate battery for the ATV (Amateur Television) transmitter so we wanted to monitor that voltage through a second voltage divider. Finally, we wanted to monitor OAT (outside air temperature).
With our objectives laid out, I set out to build a board for us. Since only the necessary interface circuitry is located on the daughterboard, these three functions easily fit on a 3 by 2 inch PCB. The ATV transmitter is hooked up via the DB-9 plug located on the side of the board. The OAT sensor is a LM35AH which is just a more expensive (nearly $18 from DigiKey) version of the unit used on the motherboard, except that it is capable of -55°C. The OAT sensor is also fed out of the same DB9 plug as the ATV transmitter.
The daughterboard shown in the photographs was one of our prototypes and we didn't quite get it right the first time, hence the tack-soldered components on the solder side of the board. All in all, it worked flawlessly. Just don't forget to coat these boards with the conformal coating just like the motherboard. The last thing you want when you're chasing your thousand dollar balloon through the sky is condensation causing problems with the electronics.
In-circuit programming is a feature of the PIC microprocessors which allows them to have their Flash RAM programmed while installed on a circuit board by using only a few pins. To allow for this method of updating, all necessary pins are wired to the daughterboard connector (P3) on the back side of the PCB.
Our first versions didn't have this functionality but I'm growing to appreciate it a great deal. Having tossed a handful of $5 to $10 IC's in the trash in the past couple of months due to bent pins during extraction, I think this will save a little bit on the parts bill. I highly recommend using this method to program you controller for a variety of reasons, but the most important is just saving wear and tear on the processor and it socket while making firmware changes. It would be a shame to lose a balloon capsule because of a worn-out chip or socket.
Due to variations in programmers, you will need to consult your programmer's documentation for actual pin connections, but I included the schematics for our programmer, the WARP-13 by Newfound Electronics ( http://www.new-elect.com/) In our case the connections were simple enough that no PCB was used, just a direct plug-to-plug system with a popsicle stick for a little rigidity on the 24 pin plug. See the photos for further detail.
As I eluded to before in the section on testing, the battery supply must be sufficient to overcome the voltage drop through the regulator. The regulator seems to have about two junctions of drop or about 1.3V. This means that the battery supply, even towards the end of its life span, must remain above 6.3V. Although the circuit will sort of work below this point, it should be considered a critical point and never be forced to work under those conditions. By letting the 5.0V reference voltage drop below 5.0V, you will begin to experience inaccurate analog-to-digital conversion, as well as the risk of the microcontroller shutting down altogether.
Battery consumption verses battery weight always seems to be a large thorn in our side when determining payloads. We are constantly searching for the cheapest, most reliable sources of power for our balloons. Currently, what we are flying are a set of six Energizer Lithium AA batteries which are usually available at WalMart, among other places. Note: because of some of today's lesser-bright youth who are making methamphetamine out of these batteries, WalMart usually keeps them hidden back with the cigarettes and such. They may also pose limitations of purchasing only two or three packs at a time.
The lithium-style batteries were chosen for their high capacity, but more importantly for their low temperature performance. Although this may seem like a waste of battery power to only power an APRS system for a very limited time using these high-capacity batteries, the extra battery life provides a good deal of time to find the capsule if for some reason it gets away from us or it takes some walking to retrieve it. Running a Yaesu VX-1R and a Garmin 35-HVS GPS engine, you should have about eight hours worth of life in the batteries, assuming moderate temperatures (our capsule usually stays just above freezing throughout the duration). Just remember, if you are adding a high current-consuming daughterboard or secondary equipment, it should be powered by a separate power source so as not to drain the primary battery. Our rule of thumb is simple – the primary battery is sacred, don't touch it! This means if you are flying with a second transmitter, you also need to include a second, separate battery for its dedicated use.
Power Up and Testing
Once you have finished installing all of the components and looked over your work for cold joints or solder bridges, it's time to hook up a transmitter and GPS. This can be done inside since an actual GPS lock is not required for operation. The best way to test the circuit is to have a regular APRS tracking station nearby to 'listen' to the controller board. I generally use HyperTerminal for testing the transmitter on the bench because it's simple and easy to see exactly what you're receiving. To get setup tune the transmitter and receiver to an open frequency and apply power.
About ten seconds after applying power, you should see the transmitter key up and send a welcome message similar to the one below:
W0ZC-4>APRS:>APRS Controller initializing...
The transmitter should then unkey and wait about one minute before continuing with the GPS and telemetry data. If you don't see this first message, it can be caused by a variety of reasons, but here's a list of a few possible causes/solutions:
- Lack of power. Check for proper voltages at the microcontroller (U3) and the modem (U4). Also make sure that the radio is turned on and on the correct frequency.
- Processor not programmed. The microcontroller (U3) must be programmed with firmware for it to do anything. If you haven't already done this, you must do so before continuing with testing.
- Mis-wired PTT line. Be sure that the PTT transistor (Q1) is inserted correctly. Also check that pull-down resistor R12 is the correct value for your transmitter. Our Yaesu VX-1R seems to do just fine on a 3.3k but other radios and/or manufacturers may need slightly different values. Finally, make sure that the cable from the 5 pin plug is wired correctly to the radio. You will need to consult the radio's documentation for exact pinouts.
- Stray RF. I have tried to build the circuit as stable as possible, but when the antenna is located within a few inches of the board, RF feedback can develop which can distort the transmitted audio and/or keep the transmitter keyed. Generally repositioning the antenna or plugging into a dummy load will eliviate the problem. I've never had any problems inside of a capsule once the antenna is located six or more inches away from the boards.
Assuming you get the welcome message, you should start to receive APRS data about every thirty seconds or so. From here, it will either work or it won't. If your GPS is having problems communicating with the PIC processor, you will receive an error message similar to this one:
W0ZC-4>APRS:>Watchdog timeout-POSSIBLE GPS FAILURE Controller re-initializing...
This is generally caused by the GPS not sending data to the board. The processor expects to see two NMEA sentences ($GPGGA and $GPRMC) at least every second. If it doesn't see them within the timeout period (about 2.3 seconds) then it will restart the controller and display the above error message. If you are seeing this error message, check to be sure that your GPS is getting power and that data is coming back from the GPS engine to the appropriate pin on the four pin GPS plug. The controller expects to see full RS-232 levels (+15V to -15V) at the plug P4. Be sure that the GPS is sending both the 'GGA and 'RMC sentences – you may need to connect the GPS to a PC and use a terminal emulator (such as HyperTerminal) to confirm this.
If everything is working normally, you will start to receive data that looks similar to the following:
The $GPRMC and $GPGGA strings are essentially taken directly from the GPS engine. They hold the bulk of the tracking capability. You should consult your GPS documentation for a full listing of all of the information contained in these strings, but the most important are the first few sets of numbers. In both strings, the first three numbers are the time, the latitude, and the longitude respectively. Any APRS tracking software will know how to deal with this data and will plot it automatically, but the information is handy to know during testing and debugging.
Those of you familiar with the APRS protocol may soon notice my use of a custom packet header for my telemetry similar to the following. Our reasoning was simply that standard APRS telemetry packet consisting of a few 8-bit data values and eight digital statuses was too limiting for our desires. We chose this custom format so that using our 10-bit ADCs, we can directly display a -45°C air temperature or a 8.135V primary battery voltage directly without having to interpret the data on the ground. In our standard set, the first number is the IAT in degrees Celsius and the second number is the primary battery voltage in millivolts. If you will be using this unit strictly for tracking, you may wish to modify the firmware to not transmit the telemetry packet at all as it is not necessary for strictly tracking purposes.
We have built a number of prototypes and so far they have all been very consistent with regards to the analog acquisition and the associated units conversion for temperature and voltage. However, I have made no provisions in the hardware to tweak or calibrate these measurements. As I said, the prototypes have always come out very close, within ±1 or 2°C and ±.1V, but if your application requires more accuracy, you will need to modify the coefficients coded into the firmware.
Tracking Your Station
It takes many hours of thought and research to actually pull off a full-blow balloon launch, which is beyond the scope of this article, but let me give you the basics of operation to transmit APRS from your vehicle, airplane, balloon, or whatever.
First off is the tracking software. There are a number of readily available software applications available for tracking APRS stations that can be downloaded from the Internet. Two of the more popular programs are WinAPRS and APRS+sa, both of which are available from TAPR's website in the section on GPS/APRS. APRS+sa is, in my opinion, a better piece of software for tracking balloons, but at $70 for it plus the Delorme Street Atlas (www.delorme.com) which is also needed, it is a bit pricey. Both are available as shareware to experiment with (except for the Street Atlas mapping software). You will need to consult the software's documentation to get it running with your particular computer and TNC, but in a nutshell, you will need to enter your callsign, the serial port on your computer that the TNC is connected to, and in some cases, the type of TNC that you are using.
The nation-wide standard APRS frequency is 144.39MHz. To test the APRS controller board, attach the transmitter, GPS, and power and set the unit outside or at least near a window. Back at the computer, you should begin to receive data packets from the controller board. If your software is configured properly, a dot should appear on the map where you are currently located. As the controller is moved around (as in vehicle or balloon), the dot on the map will follow your location as new data packets are transmitted every minute.
Other Issues to Consider
The most important issue to consider with this unit it to test, test, test. In order to operate this unit consistently, you must be willing to take the time to get to know both the hardware and the software very intimately. I would highly recommend getting data sheets on both of the main IC's used, the PIC16F873 and the MX-614 and learn what the individual pins do.
The same is true on the source code. The C source code is available for download from www.rckara.org. If you plan on modifying the code to add a daughterboard or change the behavior, be sure you fully understand the ramifications of your changes. The use of interrupts or timers could cause the packetizing routines to lose their timing values. That's not to say you can use them, because I have - you just have to know when you need to turn the interrupt requests off and get down to business. Once you're finished transmitting the packet, you can then re-enable the interrupt request. The PIC microprocessors are very popular in amateur electronics circles. Even if you personally don't feel qualified, there's probably someone in the neighborhood who could assist or advise in code changes.
The MX-614 modem is as it says, a MOdulator and a DEModulator which means that it could be possible for this unit to also receive data from the ground station. I suspect that this microprocessor is capable of receiving a short string from the ground, but the memory limitations on the chip would prevent much more than about 60 to 80 characters at max. So far I haven't had time to investigate this idea to its full extent, but this would certainly open up some interesting avenues like balloon cut-downs, controlling cameras, or even guiding a parasail. If you don't wish to go through the development on receiving and decoding ax.25 packets, we also provided received audio from the transceiver to plug P3 for the daughterboard. By using a DTMF decoder IC on the daughterboard, you could decode a series of DTMF sequences and transfer them back to the PIC through the digital I/O lines for uplink control to the balloon.
If you are operating the controller board from a balloon or other highly time-sensitive application, we recommend either using an alternate frequency for the APRS or decreasing the time delay in the firmware between data packets. What our group has found is that other ground stations (including the chase teams) tend to put enough traffic on the 144.39MHz frequency that the balloon packets often get covered up. Speaking from personal experience, it is quite unnerving to not get an update from your balloon for several minutes on end.
The primary purpose for developing this unit was for high-altitude balloon chasing however there are many other uses that have probably never crossed our minds. I'll outline a few of the additional missions this unit could serve along with any pertinent information we've found on them:
- Ground-based APRS transmitters – This would require virtually no modifications to the hardware or software. Simply attaching a transmitter and GPS to the motherboard would suffice to track a ground station. If you didn't need/want the additional telemetry data, you could eliminate R1 and R2, as well as U2 and its associated circuitry. The source-code should be modified to not attempt to transmit the telemetry strings in that case. Our local radio club has toyed with the idea of using a handful of these during special events to track sag-wagons and other important points.
- Weather Station – By coupling an anemometer, rain gauge, and/or other input sensors to a daughterboard (and thereby the motherboard), you could periodically transmit the weather from a particular location at various times. Assuming the weather station was stationary, you could eliminate the GPS receiver and manually plug in the coordinates. As someone who flies radio controlled model airplanes, I've often thought this would be nice to have at the flying field to see what the winds were actually like out in the open country (as opposed to the city).
- Wife/Kids Tracker – Just slap on of these in the trunk of their vehicles and you can track on your computer screen where your loved ones are at. I'm not sure of the legality of this one though. :-)
Like I said, I'm sure there are many more applications for a versatile little controller such as this, we just haven't thought of them.
- Schematic Drawings - A PDF of the schematics for this version of the controller.
- Firmware - A ZIP file with the C source code to compile.
There is an enormous amount of information available on the web regarding APRS and high-altitude ballooning. Below is a list of interesting and/or useful sites which have quickly made their way to my favorites list.
- Reno County Kansas Amateur Radio Association (RCKARA) – www.rckara.org. This is our group's website. We try to keep it as up-to-date as possible regarding our ballooning activities.
- Tucson Amateur Packet Radio (TAPR) – www.tapr.org. This group of amateurs is dedicated to the development of new digital technologies.
- Kansas Near Space Project (KNSP) – www.ksu.edu/humec/knsp/knsp.htm. I don't think this site is being updated any more, but they have a lot of good information and photos on the site.
- Treasure Valley Near Space Project (TVNSP) – www.the-one.com/tvnsp. Paul Verhage (KD4STH) who initially got our group started has moved north and is now involved with the TVNSP.
- Nebraska Stratospheric Amateur Radio (NSTAR) – members.home.net/mconner1/nstar.html. A group of amateur's near Omaha, Nebraska.
- Edge of Space Sciences (EOSS) – www.eoss.org. A very active balloon group in Colorado. They have done a number of flights with ATV on board with satisfactory results.
- High Altitude Glider Project – members.shaw.ca/sonde/index.htm. A Canadian who essentially built a radio controlled glider the flies home guided by GPS. Many of the same technologies as the ballooners are used on it.
- Findu.com – www.findu.com. This is a website that collects APRS information from various gateway located across the country and posts them to this website. A typical balloon flight will find its way onto this site because of the range from which the balloon can be heard.
- Microchip – www.microchip.com. This is the supplier of the PIC chips. They have a lot of information on their site about their chips.
- Custom Computer Services (CCS) – www.ccsinfo.com. The maker of the C compiler that I use. Because of its price, it is well known in amateur circles.
- DonTronics – www.dontronics.com. A provider of the WARP-13 PIC programmer that I used to develop this project.
Our hope is that others may find this unit as versatile as we have. We have given this project many hours of careful thought and design to make it as simple and no-nonsense as we possible can. I suspect that development on this project will continue for many years to come, and with each revision, make it smaller, smarter, and a more functional piece of equipment. Plans are already on works for version 2.0 of the board – a 100% surface-mount design with additional memory and I/O!
I know that I have missed some of the very good web sites and individuals who have helped make our ballooning activities possible. Thank you to everyone who has helped us and who makes their information freely available for others to learn from.
73's and happy flying,
de W0ZC and the Project: Traveler Group