one of the good things that worked during my last balloon launch was the transmission of images from the balloon using SSTV.

Due to the geography of my country, it’s very difficult to catch the balloon after it lands. so up until now I wasn’t able to recover the memory stick from the camera. so, it was great fun to finally see some pictures from up there.

it was especially important as the GPS broke down 5 minutes into the flight. but I was able to identify some landscape features and draw a rough map of its heading.

but the technology did start to show it age.

I was fortunate that a 4X1WS had a VHF Yagi antenna and was interested in participating. it was not planned beforehand, but he was the only one able to receive the transmissions.

also, the image quality was below what we got used to expect. so, for the next version I set out to do better.

the two common technologies are HamDRM (a.k.a DSSTV) and SSDV.

HamDRM is derivation of the Digital Radio Mondiale digital voice and data transmission protocol. it is implemented on the popular Linux software QSSTV (I think there are also Windows alternatives). image quality is good, but I could not find simple source code I can run “headless” (without a GUI) on my Raspberry pi. also, like SSTV it requires good link between the balloon and the receiving station.

SSDV is a method used by UK HAB enthusiasts. it takes a JPG pictures, removes some of the meta-data and sends it as packets over a RTTY link. there is a network of receivers all over the country who upload the received packets to a centralized server.

I really liked the distributed approach of SSDV, but I lacked the ground stations needed. but this gave me an idea: there are already a few APRS nodes spread out in Israel, working 24/7. what if I could use them to receive the data?

so, I searched the web and found the work of Sven Steudte DL7AD who build very nice pico balloons. I wrote to him, and he was very helpful.

basically, SSDV splits the JPG file into fixed size chunks. each SSDV packet is 256 bytes: 16 bytes are header, 205 bytes payload, 4 bytes CRC and 32 bytes forward error correction (FEC). if we want to send it over APRS we can strip the CRC & FEC as the APRS has its own error detection algorithm. we can also loss some redundant bytes from the header. so, we get 9 header bytes and 205 data bytes (total 214 bytes) per packet.

there are a few considerations regarding APRS that needs to be addressed. it does not support binary data, and message length is limited to 256 bytes. while some software will pass such messages, Sven & I wanted to stay within the spec. so our 214 bytes needs to be encoded to readable ascii by using base91 encoding. this will result with 264 bytes, so we need to split each SSDV packet into two APRS packet, each with the (striped) header and half of the payload.

there is support in the APRS for experimental user-defined data format. these packets start with “{{” and a letter for the data type. Sven used “{{I” & “{{J” for them and I followed.

I did however want to add some redundancy and error correction. APRS has CRC check on the received packets. if the CRC does not match, the packet is dropped. having multiple receivers should compensate for that, but I wanted to be more robust. so, I’ve created a third packet dubbed “{{K” which is a XOR between the I & J payload. that way even if one packet out of the 3 is lost, I can reconstruct the original message.

the next piece of software was the gateway between APRS and the SSDV server. since the packets are all in standard format, any receiving IGate would upload them to the APRS-IS network. so I wrote a special client that listens to packets sent to APE6UB. APExxx is a telemetry destination route. 6ub is my callsign suffix. the software then builds a collection of packet received by all listeners. is any 2 of 3 packets are found, it reconstructs the original SSDV data and uploads it to the ssdv.habhub.org server where it can be viewed

I still need to run many test, but so far it looks very promising. the audio file is around 2-3 minutes, compared to the 2 minutes of SSTV at the same resolution. but quality is much better.

there are also some improvements I’m still consider. the jpg file size changes in response to the image scenery. it can be changed to use constant bit-rate (like is done in mpeg video) and thus keeping transmission time constant. another thing is the fact that SSDV splits the JPG file in arbitrary constant blocks, disregarding the internal structure of JPG who is internally built from 8×8 blocks. aligning these block to the SSDV frames would result in less damage in case a packet is lost. but I still need to figure out how to do this without breaking compatibility.

if you’re interested looking at the code you can find it here. if you got any idea how to make it better, leave a note bellow