David VE3KCL launched his second balloon flight on 22-Jul-2015 at about 12:40Z. Like the former flight, this one also uses a special U3 firmware version on an Arduino Nano board, with QRP Labs Si5351A Synthesiser. Two "party" balloons were used, filled with hydrogen. The payload total weight was 39.6g and there was a calculated 2g of free lift. 

The transmission schedule includes CW on several different bands (for the reverse CW network), 30m JT9 and a special WSPR message on 30m. The special WSPR message types encodes two additional WSPR messages which contain the additional 5th and 6th character of the locator, altitude, battery voltage, temperature, ground speed, GPS status, and number of GPS satellites (a single bit, 0 means under 8, and 1 means 8 or more). The "special" WSPR transmissions therefore show up in the WSPR database with locators and powers which are not the actual locator and power, but encode the additional data. The conversion back to actual flight data is done later in an Excel spreadsheet. This is very experimental at the moment. 

Telemetry

The transmission schedule for the flight is based on a 12 minute transmission cycle, commencing on the hour and repeating every 12 minutes:

0:00 CW ID, and 22wpm CW on 30m, 20m and 17m bands
0:01 JT9 on 10,139,800: "#CS#AT" (callsign, altitude)
0:02 JT9 on 10,139,800: "#LT#A0" (latitude, temperature on analogue A0)
0:03 JT9 on 10,139,800: "#LN#A3" (longitude, battery on analogue A3)
0:04 WSPR on 10,140,150 (standard WSPR transmission)
0:06 WSPR on 10,140,150 with special type #1
0:08 WSPR on 10,140,150 with special type #2
0:10 22wpm CW on 15m, 10m and 6m bands
0:11 Calibration
0:12 Repeat...

Special WSPR type #1 encodes 5th and 6th Maidenhead locator, and altitude into the message; type #2 encodes temperature, battery voltage, ground speed, GPS status and Satellite coverage.

Example, WSPR reports at 13:52Z, 13:54Z and 13:56Z are:

13:52 VE3KCL FN05 13 (normal WSPR)
13:54 VE3KCL DN55 43 (special type #1)
13:56 VE3KCL MP87 20 (special type #2)

This telemetry decodes to:

The JT9 also contains some of the same data but receive station network coverage is likely to be less comprehensive. The advantage of the WSPR telemetry is that there is an existing vast network of WSPR receiving stations, automatically receiving and loging the data. The CW on multiple bands is such that it could be decoded by the reverse CW network i.e. "TEST TEST DE VE3KCL VE3KCL". 

Flight data

The flight lasted about 2 hours 15 minutes, ascended to a maximum altitude of 4,120m and travelled approx 91km. The flight was therefore similar to the former flight.  Dave has since attributed the shortness of the flight to problems he has found with the gas cannister used to fill the balloon, which apparently still contained some propane. The gas mixture therefore did not provide as much buoyancy as it should have, and the theory is that one of the balloons burst at 4,120m causing the gradual descent. 

In the charts and path map below, BLUE is data from the JT9 telemetry, and RED is data from the WSPR telemetry. There were 11 data packets. Some comments on the data are below. Click the images for larger versions. 

Altitude: The reported altitude is parsed from the GPS data, the snapshot is taken right before the calibration i.e. at approximately the 11th minute of each 12 minute transmission cycle; this is then the data used in the subsequent transmission cycle. The JT9 transmission contains the full precision altitude reported by the GPS receiver, whereas the WSPR telemetry is more compressed, so the resolution is lower: 20m in this case. Considering the scale of the data, it is to be expected (and actually happened) that the JT9 and WSPR altitude data match each other closely.

Battery voltage: it is reported in JT9 as the 10-bit analogue-to-digital value converted by the ATmega328 processor. In WSPR the data is highly compressed, and so the telemetry supports 40 battery voltage values in the range 3.0 to 4.95V with resolution 0.05V. It should be noted also that unlike the location data from the GPS module, the battery voltage is snapped at the message encoding stage, which means right before each message transmission. Not at the beginning of the whole 12 minute cycle. Therefore the JT9 and WSPR data is not even sending the same data value to start with. It is not surprising the values don't track each other exactly.

Temperature: it is reported in JT9 as the 10-bit analogue-to-digital value converted by the ATmega328 processor. Dave uses an LM335 temperature sensor which has a linear voltage/temperature characteristic with a slope of 10mV/C, and output 2.73V at 0C. The WSPR data is compressed, and the temperature range is -49C to +38C with resolution 1C. Like the battery voltage, the snapshot is taken at the message encoding time at the start of each transmission, NOT once at the start of the whole 12 minute cycle; therefore WSPR and JT9 aren't reporting temperature values taken at the same instant. That and the resolution limitations make it un-surprising that the values don't match exactly.

Speed: groundspeed is parsed directly from the GPS serial data. It is not sent in JT9 in this balloon flight. The compressed WSPR telemetry format encodes speed from 0 to 79m/s with 2m/s resolution. Note that the speed data in the chart seems to be wrong by a factor of 2. The distance between two location reports 1 hour apart in the middle of the flight is 54km. This equates to 15m/s which is about half what is reported in the telemetry. There may be a bug in the firmware or in the spreadsheet, and it needs further investigation. 

Path: The path plot (blue line) is from the JT9 data, which is latitude/longitude to the full resolution provided by the GPS NMEA serial data string. Each data point is shown as a BLUE dot. The RED dots are the location data as determined by the WSPR telemetry. The compressed WSPR telemetry format transmits 6-character Maidenhead locators (Maidenhead subsquare resolution). The balloon is therefore known only to be in a certain Maidenhead subsquare, which means an uncertainty in its position, of several km. This is why the red dots (WSPR) don't precisely match the blue dots (JT9). This resolution compromise in the WSPR telemetry still provides quite reasonable accuracy and for a longer flight would be adequate for tracking purposes. 

Other: During the flight, the GPS Status bit was consistently 1 (means the data validity flag in the $GPRMC sentence is "A", which means valid); and the Satellites bit was always 1, meaning at least 8 satellites were tracked at all times. 

Photos

The photos below show various aspects of the payload (click for larger images) and are mostly self-explanatory. The foam-enclosed flight package contains five modules: uBlox GPS receiver, Arduino Nano (programmed with U3 firmware), QRP Labs Si5351A Synth kit, LiPo battery, and voltage boost converter. For weight saving, the GPS receiver doesn't use a patch antenna or an external patch antenna. Instead Dave uses a small length of miniature coax, and a wire dipole. The antenna is plenty good enough for good GPS reception. 

Dave uses a thin wire 30m dipole suspended from the two hydrogen party balloons. The electronics paylaod is suspended at the center of the dipole.