KY7DR-3 Balloon Tracker

On 2014 Jul 23 a tracker I built was launched on a high-altitude balloon as part of the Columbus High School DREAMS science program (Columbus, GA). The tracker was built with an Argent Data T3-Mini with ADS-GM2 GPS and Baofeng UV-3R+ HT. It was configured with a profile for under 10,000 ft that transmitted position every 30 seconds with a path of WIDE1-1,WIDE2-1, and over 10,000 ft it transmitted position every 60 seconds with no path. Testing on the ground worked as expected.

Tracker Pictures

T3-Mini and ADS-GM2 on the bench
Tracker flight package, unwrapped (T3-Mini and ADS-GM2 on top and horizontal facing up, dipole at the bottom)
Tracker ready for flight, wrapped in pink foam (on the left, with yellow tape-measure dipole and inside a gallon zip-loc bag). In the end the two shiny mylar-covered boxes did not fly due to running short on lift gas for the balloon (this was the 3rd balloon to fly that day).

The UV-3R+ radio ran on "low" power, so I'm guessing 1 watt or less (doesn't say in the specs that I have).

The T3-Mini was powered by a 9V Lithium (standard rectangular 9V battery package), and the T3-Mini provided 5V for the GPS. Packets report voltage and temperature on-board the T3-Mini, which has always read high (I presume due to the toasty little voltage regulator on the board).

Shortly after launch the packet rate increased dramatically, more than once per second, and I don't know why. The profile switch did eventually occur, but not when expected.

Here are screen shots of my T3-Mini configuration:

Packet Diarrhea Root Cause Hypothesis

I think I've found a possible root cause of the packet diarrhea. In the profile switching I have two criteria: altitude and speed. Altitude was put in so that the balloon would use a conventional digi path while at low altitude and no digi path at high altitude. Speed was put in so that I could test the profile switching on the ground (in a car), which I should have done but did not do so thoroughly enough.

As the balloon rose, starting in profile 1, it gained speed and altitude. When its speed exceeded 50 MPH (but altitude still < 10k) it would switch to profile 2 and transmit. Now in profile 2 it would see that it's at an altitude of < 10k and immediately switch back to profile 1 and transmit. Profile 1 would then switch back to profile 2 and transmit, which would switch back to profile 1 and transmit, and so on, until the system exceeed 10k feet in altitude. As long as it was < 10k feet in altitude and < 50 MPH it was fine, and as long as > 10k feet and > 50 MPH it was fine. But when it met one but not both criteria, it would start rapidly flipping back and forth, transmitting each time. Bah.

While that seems plausible, the speed indicated in the raw data (link below) doesn't seem to support this theory.

GPS Loss at Altitude

Also the tracker was set to report NOFIX if it lost GPS, which it did for most of the middle of the flight. It was working when it took off and working when it landed (or else we may never have recovered it), but for much of the middle of the flight it reported NOFIX.

Flight Logs

During actual flight the tracker was in several "phases" of behavior, most of them unintended. Here are some interesting events in the flight.

Pre-launch and immediately post launch: Worked as intended, transmitting every 30 seconds with a path of WIDE1-1,WIDE2-1.
Balloon released approx 11:00 am EDT from rural Georgia (USA).
11:02:32 First packet on aprs.fi, telemetry packet T#039, showing WIDE1-1,WIDE2-1 path
11:03:10 First position packet on aprs.fi, 8.5V 66C HDOP01.0 SATS10
Position packets generally coming in about every 30 sec or more, as expected. Altitude generally going up, but sometimes dip down briefly.
11:05:44 Start seeing packet diarrhea, with "Rate limited (< 5 sec)]" in the aprs.fi log, altitude 2777 feet.
11:05:45 Altitude 3370 (550 ft/second rise?)
11:10:19 Comment packet indicates we're still in profile 1, as expected
11:10:25 Altitude 9139 ft
11:10:26 Altitude 3370 ft (where I have seen that number before?), 8.5V 63C HDOP01.4 SATS10
11:11:02 Altitude 9697 ft
11:12:14 Altitude 10902 ft
11:12:18 Comment packet indicates we're in profile 2, as expected
11:12:19 Telemetry packet T#050
11:13:07 Altitude 12071 ft
11:13:09 Comment packet indicates we're in profile 1 (not expected at this altitude)
11:13:11 Telemetry packet T#058
11:20:37 Altitude 20790 ft
11:30:32 Plausible position packet, Altitude 31564 ft, 8.4V 61C HDOP0.10 SATS09
11:30:46 Started getting "NO FIX" packets (8.4V 60C) amongst position packets w/out "NO FIX"
11:34:37 8.4V 61C HDOP0.10 SATS09 (last non-NO FIX packet for a while)
11:50:37 Got one "NO FIX" packet reporting 8.3V 32C, and another reporting 8.4V 40C
12:34:24 First non-NO FIX packet in a while (first in an hour), Altitude 32785 ft (highest I've found), 7.9V 23C HDOP00.8 SATS11
12:34:30 Telemetry packet T#238
12:34:56 Last "NO FIX" packet received, 7.9V 23C
12:36:00 Altitude 31566, 7.8V 28C HDOP00.7 SATS12
12:36:56 Telemetry packet T#253
12:37:07 Telemetry packet T#000 (counter to 255 wrapped, I presume)
12:40:01 Altitude 27279, 7.7V 33C
Lots more packet diarrhea going on...
12:50:00 Altitude 16501 ft, 7.7V 44C HDOP00.7 SATS13
13:00:07 Altitude 7384 ft 7.9V 51C
13:21:50 Screen shot of my ground tracking station (APRSDroid) after touchdown, Altitude 351 ft, 8.2V 57C HDOP00.7 SATS12
14:16:48 Last position packet on aprs.fi log, Altitude 3026 ft, 8.1V 55C HDOP00.7 SATS13

Here is a bunch of raw packets as harvested from aprs.fi. It's not complete, but it's something.

Here is a bunch of raw packets as logged by a friend's ground station (in a vehicle) that was on the same chase (but not in the immediate area of the landing).

Screen grab of flight path, from http://aprs.fi/:

Release point (approx): 31° 56.56' N, 83° 27.07' W
Recovery point (approx): 32° 19.21' N, 83° 32.47' W