Design Updates – Flight of Leftovers

Various elements of “The Flight of The Leftovers” have been coming together. Here’s a a brief overview of what’s going on:


Okay, I screwed up on this one, but not bad enough that it will compromise the launch. It just means we’re going to fly a little heavy and a little hot. Here’s the backstory:

Several weeks ago, I requested the Xeno XL-200F D-cell batteries for the Intro to Space Camp flight. 10 of these batteries were ordered, but the company didn’t ship them in time for the flight; they arrived two days after launch. We ended up purchasing the same cells at BatteriesPlus (at twice the Amazon price) for that flight. This led to 10 extra batteries.

The batteries are Lithium Thionyl Chloride; they are very high capacity (16.5Ah), but have a very high internal impedance, yielding a low current draw. After the batteries were in my possession, I re-read the spec sheet, and it turns out that the max current draw is 200ma, 500ma peak. It was a simple oversight, but required a decent amount of redesigning to compensate for.

Here’s where the second problem comes in: I’m using linear voltage regulators. With my prior knowledge, I didn’t know switching regulators were an easy option, so I went straight for the LM350. With launch less than a week away, there isn’t time to swap to switchers. I’ve never built a circuit that involves switching regulators, and the Chinese eBay options are many weeks away.

So, all things considered, we’re flying batteries with a low current output and inefficient voltage regulators. The Pi draws exactly 400ma (measured from the input side of the voltage regulators). Because we have so many batteries, we’ll just fly two pairs (7.2V@200ma x2). The LM350 gives us a perfect 5v. The chemistry slips my mind at the moment, but there’s another form of Lithium battery commonly found in military surplus that can handle a very high current draw. We’ll be flying those and switching regulators for the next flight.


Since I found out that it was possible to modulate NBFM from GPIO pin 4 on the Pi, I had planned on running SSTV and APRS from that one “transmitter.” After further discussion and testing, it’s been determined that we shouldn’t use this for our transmissions. There are two main problems: signal quality and transmitted power. The power output is <20mW. Signal quality can be addressed by the fact that we’d be modulating FM from a 500MHz square wave. In the radio room, we were able to receive SSTV on frequency, at +/- 10KHz, 20KHz, and 30KHz. It would have been dirty to fly such a transmitter. We’re not ruling it out for future flights, but filtering and amplification is a must-have if we go that route.

For this flight, we’ll be flying two Baofeng UV-3R’s. One for SSTV, the other for APRS. The SSTV Baofeng will transmit some APRS for redundancy, but that’s only once every 3 minutes or so. Due to the nature of this project, I want to power the Baofengs from an external source, so I built some battery eliminators that seemingly resemble the original batteries with a cable coming out. I learned a lesson the hard way: don’t feed the Baofengs more than 4.2v! Anything more WILL fry the CPU. This particular lesson happened to be taught twice. The Baofengs will accept 3.4v to 4.2v. Anything less, it becomes a receiver. Anything more, it becomes a brick.


The telemetry side of things is slowly but surely coming together. It’s boiled down to these parameters: voltage regulator temp, internal temp, external temp, radio battery voltage, Pi battery voltage, Pi CPU temp, and altitude. Although pressure would be interesting, the sensors aren’t as cheap as the 1-wire thermal sensors, and I honestly don’t have the time to program it in with the launch being several days away.

For battery voltages we’re measuring values from an 8-channel, 8-bit TI ADC. I’ve built some resistor dividers to scale the voltages of 0-8.5v to 0-5v. This gives us a dynamic range that encompasses the typical battery voltages (7.2v). Programming the SPI interface wasn’t much fun. I learned a lot in the process, but I ended up bit-banging it with Python. Although not ideal, SPI is the perfect interface to bit bang with, since you define the clock in software.

Thermal sensors are basic 1-Wire devices from Maxim Integrated. I made the mistake of buying the parasitic power versions. Parasitic power allows you to charge a capacitor inside the thermal sensor by sending the high value from your GPIO pin. The thermal sensors then use this charge to make their measurement, and send it back to the controller. This sounds nice, but it’s a huge compromise on reliability. I’ve spent more time writing data quality check code than it’s worth because I keep getting 85 or 127 degrees as the values (both are invalid and suggest errors). Mouser didn’t have the regular type in stock. Next time I’ll just get it from Digikey. I will admit, it’s awesome that you can toss multiple sensors in parallel with eachother, and each one will be read individually. I literally have twisted pairs running through the box connecting these three sensors to eachother and the Pi.

Sending the telemetry is probably the easiest part. The format is simple: T#sss,aaa,bbb,ccc,ddd,eee,0000000. The a-e fields are the data values, these can be 0-999 (though the original spec says 8-bit, 0-255). sss is just a counter. It ensures that out-of-order packets are properly accounted for. 00000000 are 8 binary bits (say 0 for no GPS lock, 1 for lock). I’m not planning on using the binary portion. A typical packet should look like this: K5UTD-4>WIDE1-1,WIDE2-1:T#020,455,234,967,236,442,00000000. This is the 20th telemetry packet, and you can read the subsequent values yourself. It’s simple to form such a packet in Python.


Tracking was the first thing I did, and honestly the most stable code I’ve written for this project. At boot, the Pi launches gpsd for communications with the GPS. gpsd is a very versatile program, and even supports USB GPS systems. I did most of this testing with a Garmin eTrex Legend before I had the uBlox wired into the UART.

The Python code polls gpsd once per second, and writes an APRS position packet with that data to /tmp/position (yes, yes, poor practices, I know). This packet includes position, APRS symbol, altitude, and a comment (“RasPi Tracker Alpha”). Another script, bash this time, picks up the packet every 45 seconds. It runs the aprs command (part of python’s afsk library), which spits out a wav file. The command looks something like this: aprs -c K5UTD-4 -o aprs.wav ‘$(cat /tmp/packet)’. The next few lines of code toggle a GPIO pin, play the audio file on the left channel, and then turn off said GPIO pin.


High resolution imaging is coming from a Canon SX110IS. It’s an 8 year old point-and-shoot, but is perfect for this task. Luckily, it takes two AA batteries, so interfacing it to 4 AA Li-Ion cells was not difficult. Because I lacked wooden dowels, I soldered a lead onto the positive side of one (dead) AA battery, and another onto the negative side of another battery. I taped the opposing ends, and ran the two wires out of the battery bay to be connected to two pairs of AA lithium cells.

Low resolution imaging was handled by a $15 Fry’s webcam. Not all webcams are created equal, but fortunately this one was equal enough to have built-in Linux support. Some webcams are more equal than others, right? Anyway, fswebcam was the easiest choice for image collection. My single command tells it to wait for 30 frames to compensate for AGC, add a header with a title and subtitle, and a timestamp. All of this is sent to image.png, which the sstv binary takes and modulates into a Martin 1 wav file. From there, it’s sent to the SSTV Baofeng.


I think that covers all of the updates for now. I’ll post soon with more info as the launch approaches. We’ll most likely be launching on Sunday, August 16th somewhere in the DFW area.