Hi all together,
as the AMSAT FOX satellites are very popular these days and they produce a lot of telemetry, I am working on a kaitai struct to decode the bytestream into human readable data (e.g. display them in a grafana dashboard). I am really loosing my mind with this as the DUV stream is a bit weird to me
A DUV stream for slow speed telemetry consists of 6 bytes of header and 58 bytes of data (= 64 bytes frame, 512 bits). The bitordering is a little curious, as the on board computer seems to transfer little vs big endian values, previously generated in a shift-reg.
For now: let’s have a look at the header only. This keeps the issue small.
From the documentation, the bitstream should contain (bits MSB first, so
fox_id is located at the most left 3 bits):
fox_id[0..2], reset_cnt[3..18], uptime[19..43], frame_type[44..47]
A typical frame from e.g. FOX-1A produces a header like this one:
B1 18 C0 AF 9F 10 [data ..]
This is clearly readable as “FOX-1A (first byte, 3 LSBits = 0x1), frame type 1 (6th byte, 4 MSBits = 0x1 = realtime telemetry)”. As you can see, the endianess is somehow “scrambled”: the FOX-ID is located in the bits 0, 1 and 2, but right-aligned. Bits 3, 4, 5, 6, 7 belong to the upper bits of
reset_cnt. Simply exchanging the nibbles doesnt work, as this would move e.g. the 4th LSBit of the first byte into the 4 MSBits, what results in
fox_id being 0x0! Maybe I am just to blind to see the issue, but how can I reproduce the correct bit-order in here?
If someone knows where to find it in the code of
FoxTelem please show
Any other solutions are also very welcome (maybe there’s a mathematical trick to solve this - I just can’t see).
Hope this is meaningful - if not: please feel free to ask.
On interest I can upload some files and the struct I am dealing with at the moment.