Golf-T - Initial Telemetry Decode

2020-Jan-28

Last week I received the first telemetry from the GOLT-T flat sat but I hit an issue trying to decode it. It looked like the header did not contain the right values. But when I inspected the bits by hand the header looked fine.

I re-ran the test a few times analyzing where the sync words appeared. One of the things I print as part of the debug in FoxTelem is the position of the Sync words in what I call the "bit stream". FoxTelem numbers the bits it receives so we can tell how far apart the sync words are and if we have a valid frame. From a run with the test file I got this for the first frame:

Attempting to decode ...
SYNC WORD 0 FROM 5829 total:5829 DATA STARTS: 5860 total:5860 at: Tue Jan 28 21:20:33 EST 2020

1 0 0 0 1 1 1 1 1 0 0 1 1 0 1 0 0 1 0 0 0 0 1 0 1 0 1 1 1 0 1 
SYNC WORD 0 FROM 12490 total:12490 DATA STARTS: 12521 total:12521 at: Tue Jan 28 21:20:39 EST 2020

1 0 0 0 1 1 1 1 1 0 0 1 1 0 1 0 0 1 0 0 0 0 1 0 1 0 1 1 1 0 1 
CAPTURED 660 high speed bytes
RS ERASURES: 0 ERRORS CORRECTED:1
RS ERASURES: 0 ERRORS CORRECTED:0
RS ERASURES: 0 ERRORS CORRECTED:1

That tells me that the first Sync word was added at bit 5829. The number after the word FROM is the position in the circular bit buffer. The total number is the number of bits since the decoder was started. So the first number is reduced as we purge bits from the buffer. The circular buffer has not yet been filled (and wrapped around) so the numbers are the same.

The second sync word is at 12490. But that is not quite what I expected. 12490 - 5829 = 6661. If we subtract the 31 bit sync word, which is included in that total because the bit positions are from the start of one Sync word to the start of the next, then we get 6630, or 663 bytes. Remember that each byte is encoded as 10 bits in our 8b10b line encoding scheme. So for some reason the frame is 3 bytes too long. One interesting thing is that the RS decoder successfully decoded the frame, even though I only grabbed 660 bytes when 663 were transmitted. Notice that it had to "correct" some bytes. I'm not sure if its cool or worrying that the Math all worked even though some bytes were likely missing. But perhaps that is all connected to the bug I am chasing..

In FoxTelem Version 1.09 I have soft coded the definition of what I call the telemetry "format". So in a file called GOLF_BPSK.format we have this:

name=GOLF_BPSK
mode=BPSK
bps=1200
frame_length=660
data_length=564
header_length=12
header_layout_file=GOLF-T_header.csv
trailer_length=96
word_length=10
sync_word_length=31
rs_words=3
rs_padding=35,35,35

That defines 660 byte length frames with a 12 byte header. We have 3 Reed Solomon blocks (or words), and because 3 RS words can hold slightly more data than the data we are transmitting, then we need to pad the data at the decoder. Specifically the last 35 bytes of each RS Word are populated with zeros. The Reed Solomon error correction approach is a block code. The blocks are fixed length and called words (don't ask my why because I don't know). In our implementation they consist of 223 bytes of data and 32 check bytes, so 255 bytes in a word. You will see it referred to as RS 255/233. Given we have 35 padded zeros, we are only using 188 bytes in each word. 3 * 188 = 564, which gives us the 564 data bytes we need. This approach means we don't have to transmit the redundant padded zeros over the air and all the math works to correct the errors at the decoder.

But I digress. I discussed the long frames with the IHU software team and we concluded that the header was currently 15 bytes and not 12. To see if we had worked out the issue I changed the header length to 15 and the frame length to 663. That meant the data length is now 567, because it is all the data in the frame, including the header.

I ran the test again and it decodes, with the result below!

How does FoxTelem know how to unpack the format

In the display above FoxTelem has taken the data from the transmitted frame and parsed it into the telemetry fields. Luckily I don't have to go through all of the fields and hand code how it does that. For all of the spacecraft we have a design spreadsheet that specifies all of the telemetry values, their length in bits and a set of other parameters we need to display them in FoxTelem. That design document is shared by the IHU software team, who use it to generate the C header files needed for the spacecraft, and by the ground station team (mostly me) who use it to generate the layouts needed for FoxTelem and the display of telemetry on the amsat.org web pages. I use a python script to generate the layouts and they are shipped with FoxTelem in the spacecraft directory. Below are the first few lines from the GOLF-T Realtime layout:

FoxTelem golf-t real time telemetry layout

In the layout the key parameters are FIELD which is the name used internally in FoxTelem to store the data and BITS which is the length of the data to parse out of the frame. Once the data is parsed out FoxTelem uses the other parameters to display it. UNITs are written after the value, CONVersion specifies the type of conversion to apply to the data so that we have a human readable value, and MODULE, with the parameters after it, are all used to build the display and show the telemetry values in groups.

Of course most of the telemetry conversion are wrong for GOLF-T currently. I just defaulted them to something sensible. Also the groupings and names will all need to be reviewed and updated as we test things.

One other slight complication is that FoxTelem builds the display shown above from three of the layouts - Realtime, max and min. We could have separate tabs for each of those payloads, but its nice to see them all together.

This process is then repeated for Whole Orbit data and Experiment data so that they are displayed on the given tabs. Each has a layout. In fact there are multiple payloads in each frame. We don't just send 600 bytes of real time data. So how does that work?

How does FoxTelem know which Payloads are in a Frame?

Each frame has a type identifier in the header. In fact the Golf-T header has the following provisional format (+/- 3 bytes hi hi):

FIELD	        BITS
satelliteID	     8
type	         8
resetCnt	    16
uptime	        32
protocolVersion	 8
modes	         8
pad1	        40

So the second byte tells us the mode. The GOLF-T_em.MASTER spacecraft file, which is shipped with FoxTelem, has a set of lines like this:

numberOfFrameLayouts=3
frameLayout0.filename=GOLF-T_Type0_ALL_WOD.frame
frameLayout0.name=All WOD
frameLayout1.filename=GOLF-T_Type1_HEALTH.frame
frameLayout1.name=Health
frameLayout2.filename=GOLF-T_Type2_MINMAX.frame
frameLayout2.name=MinMax

There will be more lines as we build out the software. For now we have just defined three frame types. So if the frame type byte in the header is one then we lookup frameLayout1 in the spacecraft file. That tells FoxTelem we have a Health frame and that the frame layout is defined in the file GOLF-T_Type1_HEALTH.frame. That file has this content:

number_of_payloads=6
payload0.name=wodtelemetry
payload0.length=92
payload1.name=wodtelemetry
payload1.length=92
payload2.name=wodtelemetry
payload2.length=92
payload3.name=wodtelemetry
payload3.length=92
payload4.name=rttelemetry
payload4.length=92
payload5.name=wodtelemetry
payload5.length=92

Which tells FoxTelem there are 6 payloads in the HEALTH frame, that five are named "wodtelemetry", one is named "rttelemetry" and that they are 92 bytes long. The keywords "rttelemetry" and "wodtelemetry" are actually also defined back in the GOLF-T_em.MASTER spacecraft file with some lines like this:

layout1.filename=GOLF-T_maxtelemetry.csv
layout1.name=maxtelemetry
layout2.filename=GOLF-T_rttelemetry.csv
layout2.name=rttelemetry
layout3.filename=GOLF-T_mintelemetry.csv
layout3.name=mintelemetry
layout4.filename=GOLF-T_radtelemetry.csv
layout4.name=radtelemetry
layout5.filename=FOX1E_radtelemetry2.csv
layout5.name=radtelemetry2
layout5.parentLayout=radtelemetry
layout6.filename=GOLF-T_wodtelemetry.csv
layout6.name=wodtelemetry

These are payload layouts. From this FoxTelem knows that the payload called rttelemetry has a layout file called GOLF-T_rttelemetry.csv. That layout file is the example realtime layout I showed above. The other layouts are defined in a similar way.

This approach, while a little complex, means I don't have to change any code as we play with the telemetry formats. The IHU team can repack the payloads into frames in different ways and they can add, modify or remove telemetry channels as needed to meet the mission parameters.

Unknown Mode

You might have also noticed that the mode is marked as UNKNOWN in the display above. The mode is passed in the header in almost exactly the same way that we do for HuskySat and Fox-1E, but we have not yet fully defined what the bits mean. That will come shortly.

73 Chris
g0kla/ac2Cz

Enter Comments Here:

Comments on this post

No comments so far.

Golf-T - Initial Telemetry Decode

2020-Jan-28

How does FoxTelem know how to unpack the format

How does FoxTelem know which Payloads are in a Frame?

Unknown Mode

Comments on this post

Hardware Projects

Software Projects

Other Projects

Workbench Notes

References