Compact Total Irradiance Monitor (CTIM)

[aefyhrie]

Mission

The Compact Total Irradiance Monitor (CTIM) is a 6U CubeSat demonstrating next-generation technology for monitoring total solar irradiance. CTIM uses silicon-substrate room temperature vertically aligned carbon nanotube (VACNT) bolometers to measure the total irradiance of the sun with an accuracy <0.1%.
We are scheduled to launch no earlier than June 29 on Virgin Galactic’s LauncherOne. It has been assigned a temporary NORAD ID of 99402.

Radio Overview

Like other cubesats from LASP (e.g. CUTE) CTIM has two radios: a UHF radio for command and telemetry, and an S-band radio for science data downlink.

Band	70 cm (UHF)	13 cm (S-band)
Mfg. / Model	SpaceQuest TRX-U	SpaceQuest Tx-2400
Frequency	437.25 MHz	2.402 GHz
Modulation	GFSK	GFSK
Baudrate	9.6k	500k
Framing / Encoding	AX.25*/G3RUH	CCSDS with Manchester encoding, Reed-Solomon FEC
Antenna	Low-gain RHCP monopole array (four deployable monopoles)	High-gain patch
Transmit Power	33.6 dBm	33.9 dBm

*the AX.25 header is formatted incorrectly, and is explained below

70 cm (UHF) Radio

Framing

The data from CTIM was intended to follow the AX.25 structure exactly, but errors in the framing were discovered too close to delivery to alter the flight software. Therefore, we will call the framing "AX.25-like".

The header differs from true AX.25 frames in the following ways:

1. the "source" and "destination" callsigns locations in the headers are swapped -- on downlink the "source" should be "CTIM" but instead it is "LASP", and the "destination" should be "LASP" but instead it is "CTIM".
2. The "source" (second) callsign should be bit shifted to the left by one bit, which it currently is not.
3. The header should end in an "extension bit" set to 1 in order to signal the end of the ax.25 header, which it currently does not

Basically, the callsign encoding is wrong: in addition to the source and destination being swapped, and "LASP" not being bit-shifted, the source address (here, erroneously "LASP") should end in a 1 to signal the end of the address field.

Here's the original header:
86 A8 92 9A 00 00 00 4C 41 53 50 00 00 00 03 F0
The "source" callsign here is 'CTIM\x00\x00' with CTIM's ASCII hex-values properly bit-shifted one bit to the left. The "Destination" callsign is 'LASP\x00\x00' with LASP's ASCII hex-values not bit-shifted.
The callsigns are followed by the control field (0x03) and PID (0xF0), as is standard for AX.25 headers.

This is what the header would be if it were in true AX.25 format:
98 82 A6 A0 40 40 40 86 A8 92 9A 40 40 01 03 F0

Again, unfortunately these errors were not found until too close to delivery to be changed (since our ground-side software largely throws the headers away and is interested only in the frame's data).

The AX.25-like header is followed by a CCSDS header, including a secondary header that contains a timestamp.

Beaconing

The 70cm transceiver is configured to beacon sw_stat packets that contain spacecraft state of health information at a rate of once every 10 seconds by default, though that timing can change after commissioning.
These packets have an APID of 0x01 and fit inside one frame.

Progress and Code to Merge

I have implemented and tested a .py parser of these AX.25-like beacons for inclusion in gr-satellites. I have also made a simple .yaml file for inclusion in the gr-satellites repo for raw data decoding. I have pushed both of these changes to a fork of this repository:

https://github.com/lasp/gr-satellites

I have tested the python parser on beacons from our satellite, the output of which is attached here:
ctim_output.txt

Once the code has been reviewed and we have discussed the changes, I assume the path forward is to open a pull request to the main branch of gr-satellites? [edited]
If there a different way to proceed would be preferred, please let me know.

[daniestevez]

Thanks for all the details and for your effort!

I've taken a quick look at the code in https://github.com/lasp/gr-satellites and I think you can already open a pull request with it. Once the pull request is in place, I'll take a more detailed look and I might have a few simple comments (these are best handled in the pull request, since Github has very good support for code reviews).

Regarding the S-band transmitter, have you done any work with it? I think that gr-satellites might already have all the tools needed to decode it (except for parsing the telemetry), since it has a CCSDS Reed-Solomon deframer.

[aefyhrie]

In this case the viterbi combo block is dealing with the Manchester encoding of our data. It contains a finite state machine to de-code the data from Manchester to normal bits, hence feeding it hard symbols. It is an interesting idea to think about feeding it soft symbols -- I would have to ponder how we would change the state machine (or some other aspect of the block) to be able to handle that

[daniestevez]

Do you have a reference that explains how to decode Manchester coding with a Viterbi decoder in this way? I was reading this and this, and I think I get a rough idea of how it works, but I'm missing some details.

By the way, this is how I usually decode Manchester. It's included as the Manchester Sync block in gr-satellites. The main idea is that the only difficulty is to figure out how to group pairs of samples output by the Symbol Sync (which runs at twice the baudrate). The observation is that in the correct group pairs the two elements of the pair should have opposite sign, while if pairs are not grouped correctly there will be pairs whose two elements have the same sign (this only happens when the transmitted bit changes). For each pair of input samples, it decides the correct grouping by looking back at a history of the last samples. This is not particularly CPU efficient, but it works well.

[aefyhrie]

Hey Daniel,
The FSM was set up by my predecessor (who no longer works here), so I was similarly on the hunt for references to understand his implementation. The reddit post you linked to has the general gist of it, but I also found this reference and this reference to be particularly helpful.

It sounds like your Manchester decoder works similarly to the FSM viterbi decoder (via probabilistic decoding of the symbols).
I am interested in trying the Manchester Sync block and seeing how it compares to the Viterbi Combo block as we've implemented it

[daniestevez]

Thanks for the references!

After reading them, I'm still wondering how this works. If I understood correctly the state machine definition in the second reference, the state machine is drawn here, where the arrows show transition / output and I've already written the pair of output symbols as 01 and 10 instead of 1 and 2.

It's clear to me that this state machine represents a Manchester encoder. The state represents the previous input bit, and the output gives the two output symbols corresponding to the current input. Therefore, from the sequence of states (which is what the Viterbi decoder gives us), we can recover the input sequence.

However, the output doesn't depend on the state, only on the input. Therefore, I think that Viterbi decoding is trivial, in the sense that given a sequence of outputs, Viterbi decoding will independently, for each output y_k choose as state s_{k+1} the one that is more likely given y_k (since the transition doesn't depend on the value of s_k). So it seems to me that we don't need a Viterbi decoder at all.

The other thing that I don't understand is that for Manchester decoding, the difficulty is how to pair the input symbols, since a priori there are two possibilities. Once we know the correct choice, Manchester decoding is easy. The same happens often for convolutional codes (which are often decoded with a Viterbi decoder). For an r=1/2 code which is BPSK modulated, we also need to pair the input symbols correctly before feeding them to the Viterbi decoder. The Viterbi decoder doesn't handle this. It's treated externally by performing both choices in parallel, or by picking one choice and switching if the metrics are too high.

Therefore, I wonder how for Manchester coding we can solve with a Viterbi decoder the only thing (the pairing of symbols) that for a convolutional code we don't handle with the Viterbi decoder. Maybe I didn't understand something important in the set up.

[aefyhrie]

Hey Daniel,
I have the same picture of the FSM as I understood it a few months ago in my notebook. You have written up beautifully some ideas I've been skating around for a few months now, so thank you!

I agree that I think the Viterbi decoding is trivial, and doesn't handle the input symbols properly. In fact, we often end up with fully bit-inverted frames that I handle in post-processing (searching for 0x1acffc1d and its bit inverse as a sync pattern). I think this happens because the Viterbi block makes the "wrong choice" in pairing the input symbols.

You mention that it seems we don't need a Viterbi decoder at all -- I don't disagree. I think in our case the Viterbi combo block was a convenient way to implement a semi-intelligent FSM that can handle bit errors on the input (for example, your Manchester sync block would probably work with some other re-organization of the flowgraph)

[K4KDR]

Yes, thanks very much for so much detail this early in the process.

Please forgive a question that is not directly related to your decoding scheme & gr-satellites, but it might be helpful or informative to others...

Regarding the 2402 MHz S-Band downlink, have you done any testing (or have any experience) with receiving that signal in light of the nearly universal presence of wi-fi in that frequency range? Is the only workable approach to create an environment complete absent sources of 2.4 GHz wi-fi? I ask because when trying to receive signals from other satellites in this frequency range, I have found it impossible even in my somewhat rural residential setting.

On a related note, will the S-Band downlink only be enabled "on-demand" over your ground station? Or, might there be something to receive via S-Band elsewhere in the orbit?

Thanks very much!

-Scott, K4KDR

[aefyhrie]

Hey @K4KDR , our S-band dish is on top of our building on a busy university campus with many sources of 2.4 GHz wi-fi.
We have been able to pick up data downlink from our satellites while on orbit, though our performance degrades at lower elevations. It is possible that we are able to pick up the signal because we are using such a large dish (4.2 m diameter). We are exploring the impacts of noise on the suspicion that our daytime downlinks are lower quality than nighttime downlinks due to the background noise levels.

And yes, the S-band downlink is only enabled on-demand over our ground station. We do not plan on transmitting science data elsewhere on-orbit, though the UHF beacon will be on all the time!

[K4KDR]

Thanks very much for the reply!

Yes, no doubt that large dish makes a huge difference. So with the S-Band downlink only active over your station, the rest of us can just concentrate on the 70cm downlink. Appreciate the info!