In the previous post I’ve talked about HORYU-4 CW telemetry. Here I report my findings when trying to decode 1200baud AFSK telemetry. Since the satellite transmits digital telemetry only over Japan, the recordings I’ve analysed have being kindly provided by Tetsurou JA0CAW. There is a telemetry format document from Kyutech, but as it is the case with the CW document, it is rather incomplete and lacks several important details.
The document gives the impression that a custom packet format is used, where the start of the packets is marked by 0xdd 0xdd and the end is marked by 0xaa 0xaa 0xaa. However, HORYU-4 transmits standard AX.25 frames. The packets that are described in the document are embedded as the payload of the AX.25 frame. Therefore, the frames can be decoded with any software TNC for 1k2 packet radio. In theory, it should be possible to ignore the AX.25 wrapper up to some extent and use the embedded packet only, correcting for errors using the Hamming codes that are included in the packet. This would be advantageous, because AX.25 uses a CRC-16 checksum, which isn’t able to correct errors. However, to do this one should first understand how these Hamming codes are supposed to work, and I haven’t managed to do it yet.
I’ve used Direwolf as an AX.25 decoder, as it is better (and more complex) than a simple decoder implemented in GNUradio. The list of packets decoded is in this gist.
As you can see, some of the packets only contain garbage, mostly in the form of 0x22 or 0xaa bytes. The rest seem to follow the format that is described in the document: 85 bytes which start by 0xdd 0xdd and end by 0xaa 0xaa 0xaa (note that there are always two extra 0x00 bytes at the end of the packet).
The first obvious remark is that there is very little data in the packets. The header (first 7 bytes including the leading 0xaa‘s) contains information, but the mission log (the remaining bytes) contains few non-zero entries.
The document says that every third byte in the packet is a Hamming code, presumably for the two bytes before it. However, none of the usual Hamming codes produces 8 or less check bits out of 16 message bits, so it must be some unusual implementation. I had the idea to “reverse engineer” the Hamming code. If you assume that each Hamming code is a linear function of the two bytes before it, then with enough samples you can find that linear function. However, this doesn’t work, due to the following triplets of bytes, where the last byte is presumably the Hamming code for the first two bytes: 0x12 0x31 0x05, 0x12 0x31 0x23, 0x12 0x31 0x49. Clearly the Hamming code for the bytes 0x12 0x31 should be the same all the time. Either I have no clue about how Hamming codes are being used or something is wrong.
Also, the first bytes of the mission log don’t agree well with the document. For instance, take 00 00 00 13 00 e1 39 70. The first two bytes are the “total days”. A value of 0 makes sense here if the counter resets often. The third byte is the Hamming for the first two bytes, which seems OK. The fourth byte is the “total hours”. Here, 0x13 = 19 hours, which makes sense. Moreover, all the bytes that appear in this position in other frames are smaller than 0x17 = 24 hours, which is fine. The next byte is “total minutes”. Here we have 0, which can be OK. In other frames we have values not exceeding 0x3c = 60 minutes. Moreover, the other “total time” that appears is 18 hours and 49 minutes, which makes sense given that all the packets are probably from the same pass. The next byte is the Hamming for the two preceding bytes. Its odd behaviour has been mentioned already. The next byte is supposed to be the mode. Here we have 0x39, but this value doesn’t appear in the list of modes. In other packets we have the values 0x31, 0x37, 0x3a, which don’t appear in the list of modes either. I have the impression that this value is not mode but “seconds”. These would make sense given the three packets in the same recording with values 0x31, 0x37, 0x3a. I don’t know what to make of the next byte. In this case it’s 0x70. In other packets it has the values 0xc0, 0x60, 0x20. This doesn’t seem to be the mode either. 0x70 and 0xc0 don’t appear in the list of modes and it would be unlikely that the satellite changed modes so fast.
So, altogether it seems that there is little useful information in these packets. It bugs me that, even with the document at hand, I’ve been able to figure out very little about the format and the Hamming code used in the telemetry.