JY1SAT is a Jordanian 1U Amateur cubesat that carries a FUNcube payload by AMSAT-UK. As usual, the FUNcube payload on-board JY1SAT has a linear transponder with uplink in the 435MHz band and downlink in the 145MHz band, and a 1k2 BPSK telemetry transmitter in the 145MHz band. The novelty in comparison to the older FUNcube satellites is that the BPSK transmitter is also used to send SSDV images and Codec2 digital voice data.
Here I show how to decode the SSDV images using gr-satellites.
The SSDV images can be decoded with the FUNcube dashboard software, but this software is closed-source and there is no public description about the format in which the images are sent. Scott Chapman K4KDR and I have been exchanging emails with some people in the FUNcube team to get some details about the format. With the help of this information I have been able to figure out how the SSDV data is embedded into the telemetry. However, I would still be grateful for a complete telemetry description. In particular, I don’t know what is the format of the realtime telemetry for JY1SAT or how Codec2 digital voice recordings are sent.
The JY1SAT frames, as in the case of any other FUNcube satellite, are 256 bytes long. This size comes determined by the AO-40 FEC protocol they use. As we can see in the telemetry description in gr-satellites, a frame is composed of a 2 byte header, which encodes the type of satellite and frame, 54 bytes of real-time data, and 200 bytes of payload. Normally, the payload is used to send whole orbit or high resolution telemetry data, or fitter messages.
In the case of JY1SAT SSDV frames, the 200 bytes of payload are used to embed an SSDV frame, with a custom header, so as to save some space.
To test my decoder, I have been using this recording made by Scott. The SSDV frames in that recording have a header indicating SatID = extended, FrameType = 32 or 33, and extheader = 0x10. I don’t know why the SSDV data is sent in two different frame types. A complete telemetry description would clarify this. Some other data (perhaps Codec2 data) is also set with the same frame types and extended header as SSDV.
An ad-hoc header is used for the SSDV frame contained in the 200 byte payload. The differences between the JY1SAT SSDV frame and the usual frame format are the following:
- The callsign field is omitted
- The payload data is only 189 bytes long
- The checksum and FEC fields are omitted
With these details in mind, I have adapted the SSDV decoder to support this ad-hoc format. The adapted SSDV decoder can be found in my ssdv fork. This decoder now supports the DSLWP-B SSDV format, the JY1SAT format, and the standard format.
To decode SSDV data using gr-satellites, the instructions are as follows. You can use the recording by Scott to test the decoder. Note that you need to use a BFO parameter of 2000Hz in the gr-satellites decoder with this recording, rather than the default of 1500Hz. You can edit this value in the GNU Radio flowgraph. You also need to have installed my ssdv fork.
The JY1SAT decoder in gr-satellites saves all the received frames to a file called
jy1sat_frames.bin in the current directory. You can change the path of this file by editing the GNU Radio flowgraph of the decoder. This file is appended to when the decoder runs, since an image can be completed by using data from several passes. You can download a sample
jy1sat_frames.bin file in this gist. This sample file is taken from Scott’s recording.
The jy1sat_ssdv.py script in the
apps folder of gr-satellites needs to be run on the
jy1sat_frames.bin to detect the different images, classify and sort the SSDV frames corresponding to each image, and call the SSDV decoder for each image. It can be run as
jy1sat_ssdv.py jy1sat_frames.bin jy1sat_output
This will produce files
jy1sat_output_n.jpg for each of the images, where
n is the image number. Running this script on the
jy1sat_frames.bin sample file given above, we obtain the following partial image.