SSDV (Slow Scan Digital Video) is a packetised digital form of SSTV (Slow Scan TeleVision). It can be used to transmit small images along with the regular telemetry transmitted by a payload during flight. Any digital mode that can carry text or data can be used, although the current implementation is limited to 8-bit RTTY (Radio TeleTYpe).
|0||Sync Byte||1||0x55 - May be preceded by one or more sync bytes|
|2||Callsign||4||Base-40 encoded callsign. Up to 6 digits|
|6||Image ID||1||Normally beginning at 0 and incremented by 1 for each new image|
|7||Packet ID||2||The packet number, beginning at 0 for each new image (big endian)|
|9||Width||1||Width of the image in MCU blocks (pixels / 16) 0 = Invalid|
|10||Height||1||Height of the image in MCU blocks (pixels / 16) 0 = Invalid|
|11||Flags||1||000000xx: 000000 = Reserved, xx = Subsampling Mode (0 = 2×2, 1 = 1×2, 2 = 2×1, 3 = 1×1)|
|12||MCU offset||1||Offset in bytes to the beginning of the first MCU block in the payload, or 0xFF if none present|
|13||MCU index||2||The number of the MCU pointed to by the offset above (big endian), or 0xFFFF if none present|
|224||FEC||32||Reed-Solomon forward error correction data. This may be omitted for storage, or if the mode already provides FEC|
Sizes and offsets are in bytes, with each packet being 256 bytes in total (or 224 bytes with no FEC data).
The image should contain just the scan data from a JPEG image (an “Abbreviated image” in JPEG terminology), with none of the markers or headers that normally make up a JPEG image. Because there are no headers, the image must conform to the following rules:
Each packet ends with 32 bytes of Reed-Solomon codes, calculated from the 223 bytes beginning with the packet type (offset 1) to the end of the payload data. These codes allow the receiver to correct up to 16 byte errors in a received packet (including the Reed-Solomon codes themselves).
Whilst the Reed-Solomon decoder is able to handle incorrectly received bytes it is useless when it comes to missing bytes. When a byte is dropped for any reason all subsequent bytes will be in the wrong position and the decoder will see most as errors. To better handle this the receiver should be able to detect and insert an appropriate number of padding bytes, allowing the decoder to see them as errors and correct.
C code to generate the Reed-Solomon codes is available here: rs8encode
When a packet is lost there are a number of scenarios that may need to be handled:
Once these conditions have been dealt with, normal decoding can resume.
The current implementation uses 8-bit RTTY at various baud rates. A more appropriate method should be used in future.
One idea is to pack the SSDV packets (sans-FEC) into an AX.25 frame for transmission over standard amateur radio packet networks. It may even be possible to do this in such a way that the format is compatible with the APRS network.
dl-fldigi contains a decoder built in, that listens to the RTTY stream for packets and decodes when received. It also can upload the packet to a central server where the data from multiple distributed listeners can be combined - often filling in gaps.
NOTE: Versions prior to DL3.1 contained an older version of the SSDV decoder which can not handle the finalised format described above.
I have written a small command line application that can encode and decode the packet data. It is used by the server to produce the images from the data uploaded by multiple dl-fldigi users.
An example of how I used the code on the hadie flights can be seen in the flight software, available on github:
The camera used on these flights was a C328-based UART camera.