A Brief Look at LES-5’s Telemetry Format – Riddles in the Sky

les5sync

It’s not exactly every day that you get the chance to work with any data, let alone telemetry data from a 50-year-old satellite. However, thanks to Scott’s observations of LES-5 and subsequent investigation into its telemetry beacon, the opportunity arose. Based partly on the work of others, as well as what I’ve managed to glean from the technical documentation that has been gathered, I’d like to explain my process for processing data from LES-5.

A Look at the Data Structure
In the past I’ve worked with GNURadio in order to process recordings of telemetry and data from several different satellites, including constellations such as ORBCOMM and Meridian. Then, to both visualize and process the demodulated data I generally use Python.
Thanks to previous analysis by Daniel Estévez, we already knew a few things about the general structure of the data, most importantly that it exhibited a periodic structure every 1024-bits. Although some trends in the data were found, the bits in this data needed to be manually aligned, and it was unclear where the synchronization word and frame counter were located.
Luckily, there is documentation available online regarding a telemetry decoding system, LESTR-2, which was used to process the bitstream from an LES-5/6 beacon receiver and subsequently produce a human readable output. Although this technical note does not provide details on the exact content of the telemetry data, it does provide valuable information regarding the synchronization word and frame counter (albeit in the most vague way possible)
Page 12, LESTR-2 Telemetry Ground System
At first, I tried using these synchronization words, with the bits ordered from left to right as shown above. However, I was completely stumped when my script that I had created completely failed to find any frames with this synchronization word. After taking a look at the figure a bit more closely, the bits would be ordered opposite to the direction that they are recorded in a file. Think of it this way: When GNURadio is saving our bitstream to a file, each new bit is attached to the end, but in this figure, the newest bits are being pushed into the left-hand side. Once I managed to get over that hurdle, success! Finally, synchronized frames from LES-5!
Example of Synchronized Frames from LES-5
Something I immediately noticed when looking at this image is that we don’t seem to have data fields which are consistent between the frames, with the exception of the first few words in the frame. Earlier, I mentioned that contiguous data fields were able to be seen when looking at the data, but with bit “frames” instead of these 256-bit (including the 2 sync-words) frames. Looking at the LESTR-2 technical document once again, one of the figures seems to give a bit more insight into this.
Page 11, LESTR-2 Telemetry Ground System
Looking at how the frames are organized into what is referred to as an “LES-5 FORMAT”, this is the more organized structure we had seen previously that repeats every 1024 bits (every 10.24 seconds). Given that there are four frames within each “format”, there most likely will be a frame counter that keeps track of these frames. The main piece of information regarding how the frame counter was detected in the telemetry receiving system is described as follows:
“Upon detection of 010000000 (decimal 64) followed by a proper check word, frame zero is identified.”
Page 5, LESTR-2 Telemetry Ground System
Since there are only four frames within every LES-5 Format, the frame counter should just be a simple 2-bit counter, which would be pretty easy to spot, as it is even referenced that it should be in Word 2. The mention of a “proper check word” had me a bit curious, but it became fairly evident upon viewing the first few words of each frame.
First four words of LES-5 Frames, Frame counter highlighted
Organizing the Data
The frame counter cycles through a 2-bit binary sequence, just as expected. Looking at the word immediately after the frame counter, it would appear that the check word that they mentioned is just the current frame count plus one. At first, I was completely surprised that this was the check word, because in other satellites I’ve looked at, it’s usually some form of CRC checksum. This was a pretty humbling moment though, because we have to take into consideration the time when this satellite was designed. Flight computers weren’t something that existed yet, everything was done using discrete logic, so any unnecessary complexity was often avoided.
Nevertheless, now we can separate out all of the frames that correspond to a particular frame number. I found that this would be a beneficial path to take, because the contiguous data fields that were observed beforehand occurred at intervals of 1024 bits. This means that for each frame type, the data fields will stay consistent, which is perfect if we want to plot out a particular data field as it changes over time.
So far, all of the data has been handled as individual bits, but for the purpose of analyzing trends in each word, the script converts each 256-bit frame into a list of 32 integers, with each list of integers also including a Modified Julian Day timestamp. For each frame type, a CSV output containing all of this data is output, which can then be examined easily in software such as Microsoft Excel.
Conclusion
As it stands, the script that I’ve created will drop frames that have even single-bit errors and does not do any parity checks, but in the future, this would help in choosing between volume of data or accuracy of data. I’m excited to see what data can be extracted from LES-5’s telemetry beacon, especially with regards to the other RF experiments present on-board.

Author: Taylor Bates

I’m an Electrical Engineering student currently living in Virginia, with an interest in satellite communications.
View all posts by Taylor Bates

Leave a Reply

Your email address will not be published. Required fields are marked *