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:

Power

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.

RF

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.

Telemetry

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

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.

Imaging

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.

Flight of the Leftovers?

As part of the Intro to Space Camp that I assisted with at UT Dallas, four balloons were purchased: two 1200g and two 600g Totex balloons. With the space camp, we launched one of the 1200g balloons, and “used” the other in a “learning experience.” So, presently, we have two 600g balloons and a size-K tank of helium.

Due to the complexity of the last launch, we’ve agreed to slim this one down. A lot. Here are our new goals:

  • Imaging. We want photos from the edge of space.
  • Telemetry. Temperature, altitude, and battery voltages are parameters we want to see.
  • Tracking. Recovery is imperative.

How do we go about doing this? With a Raspberry Pi of course! Back in June, I demonstrated SSTV transmissions using a webcam and GPIO pin 4 on the Pi. It was quite simple: take the picture, feed the png file to a program that pumps out a wav file, and then transmit the wave file using a modified version of the PiFM binary. The transmission is >10mW, possibly up to 20mW. I was able to key our on-campus repeater using a piece of RG-58 soldered onto the pin and a rubber duck antenna.

Imaging

Although we’re still in the design phase, I’d like to fly two cameras: SSTV and Hi-Res. As mentioned above, it’s not difficult to run SSTV from the Pi. The higher resolution images would be taken from a “Point-and-Shoot” camera, probably a Canon with CHDK. I personally own a Canon SX110, and with our current budget, we’ll likely be flying a certain SX110.

At the highest resolution (9MP), the SX110 will hold ~1000 photos on a 4GB card. Why fly only 4GB? CHDK is limited to 4GB cards due to the nature of the bootflag that tells the camera to boot into the modified firmware. Cards larger than that require multiple partitions, and then partition swapping to take advantage of the higher capacities. 4GB is simplest. Although we’d like the flight to be rather short, planning on a 4 hour flight would be wise. When you do the math, it yields 15 seconds as being the ideal interval for getting 4 hours of photos.

Telemetry

Education has been a goal of this launch, and being able to get something out of this launch will justify the expense of helium, balloons, and payload. Pictures are typically the most interesting and flashy byproduct of these events, but telemetry provides useful data that can influence future designs. What are things we can measure using Commercial-off-the-Shelf parts (COTS) and send through the APRS network? Several things came to mind: pressure, temperature, battery voltages and altitude. I’m sure SparkFun sells sensors that can measure many more things, but for the purpose of this launch we should probably stick to just those.

What parameters exactly should we measure? Internal temperature, external temperature, and altitude are most important, in my opinion. Behind those come battery voltages, and finally pressure. In all honesty, I don’t really care about pressure. Sure, it’s interesting, but I’m not going to bend over backwards (or pay more than a couple of dollars) to fly a pressure sensor.

Tracking

Oh, tracking. Tracking is easily the most complex part of any launch. There are many different ways to approach tracking, but for ease of reception, we’re going to narrow it down to “things that use the APRS network.” Although it would be fun to DF our way to the landing site, I’m going to opt to use the systems that will easily plot the balloons position on a GPS or aprs.fi.

On the last balloon launch, we flew a TinyTrak4 and a MicroTrak400. The TinyTrak performed flawlessly, and ultimately offered everything we needed to transmit position and telemetry. The only drawback to the TT4 is the price (yes, I am a broke Engineering student). $65 isn’t too much, but we’ve already determined that a Pi will fly. Maybe we can connect the GPS to the UART? What if we modulated the AFSK with the Pi, and pumped it out through the GPIO pin, like the SSTV?

 

Anyway, there are many things to consider. Budget is the main constraint. We’re not being funded by any group (aside from launch mechanics), and most of these things aren’t particularly cheap. Stay tuned for more info!