Compact Total Irradiance Monitor (CTIM) #355
Replies: 2 comments 9 replies
-
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. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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.
*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:
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.
Beta Was this translation helpful? Give feedback.
All reactions