The first balloon will have SSDV, RTTY, APRS and spread spectrum on VHF/UHF. The second one will have THOR4, JT65 and WSPR on HF, and SSDV on UHF. We are expecting 30,000m altitude on both balloons.

Spread spectrum transmission will be on our new tracker, using Zachary Manchester implementation for project KickSat ( See here for project details ). The binary 0s and 1s are modulated with two 511-bit Gold sequences before transmitted at 64kbps using MSK. As confirmed by Zac, this will be how the Sprite spacecrafts will transmit after launch. Our payload telemetry will alternate between RTTY and Gold codes on 434.075Mhz.

This will be the first flight for our new pico tracker:

Reception of the Gold codes will require GNURadio, and a supported SDR receiver (RTL or Funcube should work). Zac has some instructions on installation here. He is in transition from using Gnuradio 3.6 to 3.7 so the installation script will require some tweaking. If you are familiar with Linux or have used GNUradio this should be straight forward.

The HF transmissions will be time-scheduled as previously done on PSB-5, minus 40m band.

Transmissions in the first half of the hour (minute 0-29) will be on 30m, and 20m on the second half of the hour (minute 30-59). In each 10 minute block the sequence will be THOR4 (5 minutes), JT65 (2 minutes) and WSPR (2 minutes).

We will have test transmissions from Melbourne on HF and UHF from time to time in the next few weeks, and would appreciate any test reports or comments. Please include your location in the test reports, and send them to info@projectspaceballoon.net

Hope to see you on the launch days

The flight lasted 5 hours, gaining maximum altitude of 18,914m.

We were able to test HF telemetry on multi bands and multi protocols with hams and non-hams around Australia. Telemetry was received from as far as WA 2,500km away.

THOR4 was very good with HF noise, and was easy to use with dl-fldigi. It would make a good choice for HF telemetry.

JT65 was solid, however some work will need to be done to integrate it with spacenear.us tracking site. With the limitation of 13 characters of free-text per message, it would be ideal for an extension of the JT65/9 family of protocols to be developed for telemetry. The time-synced start of transmission is also not optimal for mobile telemetry tracking.

WSPR was working well, we had 26 WSPR spots on all bands, the majority was on 30m. The main advantages of WSPR for us is the reliability, and number of existing receiving stations. Like JT65, extension to the protocol would be required to make it useful for HF tracking.

Most of the initial HF telemetry was received on 30m at the time of launch, and we could see 40m and 20m coverage coming in at the end of the flight. For future flights we probably will use only 30m and 20m for telemetry.

The star of the experiment however was the Raspberry Pi computer that was multi-tasking all HF protocol encoding and transmission, and house-keeping tasks, including GPS sync for time and frequency, RF generation, SSDV image encoding, communicating with GPS tracker, under extreme conditions that saw the ambient temperature rising to 66 degree Celsius (payload insulation was working too well!), and constant payload movement.

The complex payload could not have been developed and tested in such a short time for us without the versatile linux environment on the Pi. It does have limitations but we managed to address many of them for the flight. Still more work to do, but the Raspberry Pi has proven to be a very versatile and mature platform for ham radio and HAB experimenting.

A big thank-you to everyone for assistance with tracking, and testing before the launch.

Credits also goes to various people that contributed to the softwares and protocols associated with the experiment, such as Joe Taylor K1JT, Oliver Mattos and Oskar Weigl who implemented PiFM, MD1CLV, PE1NNZ for coding WSPR on the Pi, who gave us the idea of implementing other protocols on the Pi, and Philip Heron for SSDV codes.

SSDV photos

Payload landing site

We are sending away a Raspberry Pi with high-def Pi-Cam camera, interfacing to our standard tracker.

One main objective of the flight is to test HF tracking. DominoEX8 THOR4, JT65 and WSPR will be the three transmission protocols, beside the usual RTTY/SSDV on UHF.

DominoEX8 was chosen as one of the protocols to be tested on the flight, but initial tests showed that without Forward Error Correction (FEC), it was lagging far behind JT65, at least in our intended application of telemetry tracking on HF.

Thanks to a suggestion by Mark VK5QI, we replaced DominoEX8 with THOR4 at the last minutes, and that looks much better. THOR4 uses the same modulation scheme as DominoEX8 (incremental FSK) but with FEC.

The predicted path should be something like this, but we will need to run the prediction closer to the date.

The payload will send back SSDV images and telemetry on UHF until it is beyond radio line-of-sight. After that HF will be the only way of getting telemetry from the payload, assuming we can keep it afloat until then

To assist with tuning, the HF transmissions will be assigned different time slots, which are just the number of minutes in the hour.

Basically it is transmitting on 20m band in the first 20 minutes of the hour, 30m band in the second 20 minutes and 40m band in the last 20 minutes. Please note the JT65 frequencies are not standard JT65 QSO frequencies.

In each 20 minute interval there will be 8 minutes of THOR4, 8 minutes of JT65, and 4 minutes of WSPR.

On UHF it will be 434.650MHz, RTTY 300baud, 8 None 1, 450Hz shift.

dl-fldigi can be used to decode RTTY/SSDV and THOR4. The data format for THOR4 is the same as normal RTTY telemetry, ie. sentences with call sign, sequence number, time, coordinates, altitude, speed, satellites, GPS status and battery voltage as can be seen in this fldigi decode for DominoEX8.

Check here for instruction on RTTY/SSDV decoding: http://projectspaceballoon.net/ssd/

With JT65, we will need to use WSJTX software from Joe Taylor http://www.physics.princeton.edu/pulsar/K1JT/wsjtx.html

The existing JT65 protocol has a limitation of 13 characters per message, so our telemetry data will be sent as two JT65 packets:
Packet #1: VK3YT+Altitude(4 digits)+Satellite(2 digits)+Temperature(2 digits)
Packet #2: Lat+Long without decimal point+temperature sign (-/+)

In the screen capture, the two lines of test telemetry are:
VK3YT00110725 & -37480144846

This translates to:
- Altitude = 0011 * 100 = 1100m
- Number of Satellites = 07
- Temperature = 25C
- Lat = -37.480
- Long= 144.845

If you receive JT65 telemetry from the payload, please send a screen capture or the two lines to info@projectspaceballoon.net and we will manually upload that to spacenear.us. If JT65 proves to be viable for long range telemetry we will look at integrating the decoding software with spacenear.us

WSPR can be decoded using WSPR software http://physics.princeton.edu/pulsar/K1JT/wspr.html

You can check the WSPR spots (received transmissions from a WSPR beacon) here http://wsprnet.org/olddb.

WSPR propagation map can be found here http://wsprnet.org/drupal/wsprnet/map

When looking for the signals, the HF frequency should be quite accurate as that is GPS compensated. You will need to check the transmission timeslot table, and look for the signals either audibly or visually.

This is spectrum sample for a THOR4 signal.

This is spectrum sample for a JT65 signal. Note the very narrow bandwidth of less than 400Hz. Each JT65 transmission starts on the second second of the minute and completes in 46 seconds. Therefore time on the computer has to be accurate within 1 second of UTC time. Please consider syncing the time with internet time servers

Actual RF spectrum from the Pi after a LPF

Tracking data will be uploaded on the day to http://spacenear.us/tracker

Initial testing looks promising, this is a WSPR transmission received from the payload. The distance is 16,000km.