Request to add CUTE to the SatNOGS DB

SatNOGS
1

Hi all,

I am an EE at the Laboratory for Atmospheric and Space Physics (LASP) at the University of Colorado Boulder (CU). I’m a member of the team that built the Colorado Ultraviolet Transit Experiment (CUTE) 6U CubeSat. Our spacecraft is launching with LandSat-9, which is slated for the end of this month (Sept. 2021). CUTE is a 6U CubeSat containing a Cassegrain telescope and near-ultraviolet (NUV, 250-330 nm) spectrograph intended for study of atmospheres of short period exoplanets. The spectrograph uses a Teledyne E2V CCD42-10 charged-coupled device (CCD) detector for imaging spectra.

I am working with the developer of gr-satellites to add support for CUTE to said software package (see this issue report), but to do so, I need a temporary NORAD ID assigned to CUTE by SatNOGS in order for my code to pass CI checks.

I wasn’t sure the right way of interacting with the Libre Space / SatNOGS community, so I filed an issue over on the SatNOGS-ops issue tracker. I haven’t yet seen a response, though it has only been a few days since I filed said issue. That issue report contains the relevant information w.r.t. transmitters (frequencies, modulations, encodings, etc.).

Please let me know if there is something else I need or should do to get CUTE into the SatNOGS DB, and thanks all for building this fantastic community and network!

Thanks,

Nick DeCicco

–
Nicholas DeCicco
Professional Research Assistant
Laboratory for Atmospheric & Space Physics
1234 Innovation Drive
Boulder, CO 80303

5 Likes
2

Hi @nsdecicco thanks for the info. The issue is very detailed and will be processed as soon as possible in the next 2 days. Four questions:

  1. Which of the two modulation is the default? The GMSK 19k2 or the GFSK 9k6, or both at the same time?
  2. From Orbital Launches of 2021 it looks like that your launch is at 2021-09-27, is this valid?
  3. Is there any preliminary TLE set? Or any info on the launch details or a state vector?
  4. Any details on the decoding schema of your frames? Having the decoding schema, ideally in a kaitai struct, will help to create a decoder to decode all the frames that will reach SatNOGS DB and visualize the data in a dashboard at dashboard.satnogs.org.

PS For the temporary NORAD ID, I’ll make sure that it will be 99510.

3 Likes
3

Hi fredy,

Thanks for the response.

Which of the two modulation is the default? The GMSK 19k2 or the GFSK 9k6, or both at the same time?

The default modulation is GFSK 9k6. The radio can only transmit with one modulation at a time. Basically, our operators have a choice of increasing the baudrate to 19k2 if they want. I am not sure if that change would persist through a reboot. We may need to come up with a way to communicate what our bitrate/modulation is to the amateur community. (CUTE does have a website and a Twitter account–I suppose these could be used for this purpose.)

From Orbital Launches of 2021 it looks like that your launch is at 2021-09-27, is this valid?

Yes, 2021-09-27 is correct.

Is there any preliminary TLE set? Or any info on the launch details or a state vector?

Unfortunately, we don’t have a preliminary TLE from the LSP, though they did tell us that we’d get a state vector likely ~15-45 minutes after launch. I believe the plan is that GSFC will generate a TLE for us from the state vector after launch.

Any details on the decoding schema of your frames? Having the decoding schema, ideally in a kaitai struct, will help to create a decoder to decode all the frames that will reach SatNOGS DB and visualize the data in a dashboard at dashboard(.)satnogs(.)org.

For documentation of the encoding of our 70cm AX.25 frames, please see my comments on gr-satellites issue report #297. I wrote an internal tool to convert our telemetry definitions to a gr-satellites friendly telemetry parser using the Python construct library–see cute_70cm.py, cute_bct_soh.py, and cute_bct_fsw.py in lasp/gr-satellites/python/telemetry. I didn’t realize that SatNOGS had an equivalent kaitai-based solution, but I could adapt our internal tool to generate a kaitai YAML file from our telemetry definitions as well.

If I were to do this, what repo are these kaitai structs versioned in? I could make a fork / open a pull request as I have done for gr-satellites for this as well.

PS For the temporary NORAD ID, I’ll make sure that it will be 99510.

Thanks! I’ve used this value in my gr-satellites pull request.

3 Likes
4

If I were to do this, what repo are these kaitai structs versioned in? I could make a fork / open a pull request as I have done for gr-satellites for this as well.

Disregard that question–I did find the kaitai struct decoders at librespacefoundation / SatNOGS / satnogs-decoders · GitLab :slight_smile:

1 Like
5

@nsdecicco the satellite is now added in SatNOGS DB, please check the entry for the satellite and its transmitters and let me know if everything is ok.

The transmitter at 19k2 is set inactive according to the above. About updates on bitrate/modulation, website and twitter works usually well for amateur community. For SatNOGS Network and DB you can suggest a change of status(active/inactive) by editing the transmitter status in the transmitters page. The suggestion is reviewed in a couple of hours and if it is approved the change is directly available to SatNOGS Network.

I see, please let us know as soon as possible you get them so we can track better the satellite. Until then probably we can generate some pre-launh TLE from the Rocket details. cc @cgbsat and @kerel

Thanks for the info! If you need any help on the kaitai struct please let us know, especially @DL4PD who has created many of them. Also as soon as we have this ready we can start creating the dashboard, ideally even before launch.

For more direct communication feel free to join our matrix channel, more info about it in this wiki page.

6

@nsdecicco the satellite is now added in SatNOGS DB, please check the entry for the satellite and its transmitters and let me know if everything is ok.

Everything looks correct, thanks for getting that posted.

For SatNOGS Network and DB you can suggest a change of status(active/inactive) by editing the transmitter status in the transmitters page.

Noted, thanks!

I see, please let us know as soon as possible you get them so we can track better the satellite. Until then probably we can generate some pre-launh TLE from the Rocket details. cc cgbsat and kerel

Will do.

Thanks for the info! If you need any help on the kaitai struct please let us know, especially DL4PD who has created many of them. Also as soon as we have this ready we can start creating the dashboard, ideally even before launch.

As of now I have made some progress with the kaitai struct–I am writing a script to convert our internal telemetry definition file to a .ksy file, which appears to work for our state of health (SOH) packet (except for the AX.25 and CCSDS header, which I will need to add next).

I do have one question, though, which is related to conversions: I noticed that @DL4PD’s CSIM decoder has conversions listed in the ‘doc’ field of each telemetry point. Is this information parsed and used when building the dashboard? Or, is there somewhere else that you would like me to catalog that information…?

And, along these lines–is there a repo where dashboards are stored? I found satnogs/satnogs-dw, but I don’t see a repository, just an issue tracker. Is the repo private?

As an example of what I am referring to, consider this telemetry point in csim.ksy:

      - id: battery_voltage
        -orig-id: BATTERY_VOLTAGE
        type: u2
        doc: |
          Battery Voltage
          value = 0.0020000001 * battery_voltage [V]

Thanks,

Nick

1 Like
7

Conversion formulae are documented in the ksy file but are not parsed. The fact, that, if there is a mistake somewhere in the formulae, we need to have a merge request and a new tag of the repo to get the CI triggered. All conversions are made inside the dashboard, using a fancy editor for this.

There is no repo for dashboards, as it is not trivial to export and import those along different grafana versions.

8

@nsdecicco we have generated a preliminary TLE set here. In this thread we are going to post any updates from the launch. A quick question, when CUTE is expected to start transmitting after deployment?

9

Hi all,

A quick question, when CUTE is expected to start transmitting after deployment?

First, just for posterity’s stake (for anyone reading through this thread), this question was answered by @aregan over on this other thread here.

I noticed that @DL4PD’s CSIM decoder has conversions listed in the ‘doc’ field of each telemetry point. Is this information parsed and used when building the dashboard? Or, is there somewhere else that you would like me to catalog that information…?

Conversion formulae are documented in the ksy file but are not parsed. The fact, that, if there is a mistake somewhere in the formulae, we need to have a merge request and a new tag of the repo to get the CI triggered. All conversions are made inside the dashboard, using a fancy editor for this.

And, along these lines–is there a repo where dashboards are stored? I found satnogs/satnogs-dw, but I don’t see a repository, just an issue tracker. Is the repo private?

There is no repo for dashboards, as it is not trivial to export and import those along different grafana versions.

Good to know. I’ve pushed a .TSV file with CUTE SOH telemetry definitions here:

After some struggling, I did just manage to get a kaitai struct decoder working for CUTE telemetry and tested this against some of the observation data recorded on the network thus far. I opened a pull request to add this file to satnogs-decoders here:

… only to find that Patrick beat me to it last night! :stuck_out_tongue:

I have no preference as to which gets used; both should work just fine.

By the way, we just had a pass in the past ~30 minutes over Boulder, CO, and we tried using the most recent TLE that Goddard gave us, only to find that the current SatNOGS TLE outperformed it by about 5dB of extra signal :slight_smile:

In good news–we managed to get two commands in! Both were to increase the beacon rate to 4 seconds. Note that these are automatically overridden after about 5 minutes by an internal macro, so the next observations obtained by SatNOGS ground stations will see beacons at 16 second intervals again.

Thanks everyone for the observations, TLEs, the decoder, etc.!

5 Likes
10

Oh, also, here is the most recent Goddard TLE from this morning (~10 AM UTC-6:00)

1 99999U          21271.77083333  .00145021  00000-0  11565-1 0 00007
2 99999 097.6135 339.7814 0024140 250.2663 283.5278 15.00181134000153
1 Like
11

Could you compare mine to yours? I am struggling with some details: the battery voltage should be correct when the raw value is divided by 500 (or, from the docs: mx+b, where m = 0.002 and b = 0 - which is pretty equal to x / 500) :smiley:

The result shows a voltage like 120, which should be something around 12 (factor 10?)…

1 Like
12

Hi @DL4PD,

I am working on generating a CSV of all of the observation data thus far–I can upload that shortly… hang tight for a minute.

Thanks,

Nick

2 Likes
13

Oh, well, I will need a bit more work on the decoder, as I didn’t recognise there are some signed 16 bit integers.

Edit:
But: I think there is an offset somewhere… It’s curious that there was a one bit padding inside the secondary header… any hints?

1 Like
14

Hi @DL4PD,

Did you take a look at the decoder I opened the pull request for? Might be easiest to start by diff-ing yours and mine. (Or just use mine :slight_smile: this one is generated from a script and should have all of the correct types.)

There should not be a 1 bit padding inside the secondary header, but a 1 byte padding. I don’t believe that this field ever has anything other than 0x00 in it.

Note that there were a few telemetry points that BCT wanted to scrub from the telemetry file, so they overwrote these with 0xDEADBEEF and erased the telemetry defs from the .tsv file. My decoder generator script finds these missing telemetry defs and puts padding in as appropriate. You can see these at lines 357-358 and 363-364 of my decoder.

Here’s a CSV of the first 11 observations from yesterday:

Python code to decode the data (derived from my gr-satellites decoder) is also in that zip file.

2 Likes
15

Quote of the week for SatNOGS :slight_smile: Thanks @nsdecicco for trusting our community and technology for your mission :slight_smile:

4 Likes
16

Yeah, I’ve had a look and I requested a tiny change.
Thanks for your work!

Edit:
I’ve got a basic dashboard up - let me know if you like to have editor access.

17

Just out of curiosity: the data is still present but has just “no name and conversion rule” applied!?

18

Hi @DL4PD,

Just out of curiosity: the data is still present but has just “no name and conversion rule” applied!?

If I am understanding your question correctly, then no: the raw telemetry literally contains the hex sequence 0xDEADBEEF. There is no useful data there :slightly_frowning_face:

1 Like
19

Uploading the mission patch for displaying it in dashboards:

twitter_6IEiazqq_400x400

2 Likes
20

@nsdecicco @DL4PD great work on the decoder and the dashboard!

2 Likes