Colorado Ultraviolet Transit Experiment (CUTE) update

Hi space friends!

First, and unrelated to the subject of this post, I’d just like to just say thanks (again) to the entire SatNOGS community for the overwhelming amount of support for CUTE. We’ve been awed by the number of observations recorded on SatNOGS and, as such, SatNOGS has become something of a hot topic around parts of LASP. I am hoping that this makes for increased collaboration with the SatNOGS/open source/Ham radio community on future LASP CubeSat missions.

But now, the bad news, and the reason for my post: we have been having issues with the CUTE payload (i.e., the instrument electronics), wherein turning the instrument on seems to cause the entire spacecraft to reset after a variable amount of time, typically around 90 to 120ish minutes. We’re not yet sure of the underlying cause, but out of three times that we have tried turning the payload on, a spacecraft reset followed not long thereafter in all three cases. We have observed one spacecraft reset that occurred when the instrument was off for which no explanation is yet known (but probably SEE-related).

In the anticipated normal science mode of operation, we would not beacon instrument telemetry, as the spacecraft bus FSW (unfortunately) lacks a way of filtering which data from the instrument is beaconed: i.e., enabling beaconing of instrument data while the instrument is gathering exposures would cause the transmitter to appear ‘stuck on’ and transmit indefinitely (for as long as exposures were being taken).

But, because we haven’t been able to proceed with instrument commissioning due to these resets, we’ve decided that it would be a good idea to modify the beacon to include payload telemetry for as long as we are not exposing images (i.e., until we manage to figure out a work-around to this resetting issue). This would add a new APID to the beacons, 0x1FF, which is what we call the ‘sw_stat’ packet.

At time of writing, a functioning sw_stat decoder has been added to upstream gr-satellites in commit e058f0ee. I made modifications to the .ksy parser for also opened a merge request (#211) for satnogs-decoders. I am hoping that someone can approve this merge request so that sw_stat data can be added to the SatNOGS dashboard.

Around 5 hours ago (~18:00 UTC), the CUTE payload was turned back on. The plan was to turn it back on and enable sw_stat beaconing (as described), but owing to a miscommunication, this was not enabled at that time. We plan on enabling beaconing of sw_stat packets at around 03:12 UTC on October 20th (i.e., the next pass over Boulder, CO today–9:12 PM here).

This time around, we turned on the payload (instrument electronics) sans the +12V rail. The payload is supplied 3 voltages that it uses (+3.3V, +5V, and +12V). The +3.3V and +5V rail are used for digital circuits, and the +12V rail is used for the instrument shutter, and was intended to be used to power a thermoelectric cooler to cool the spectrograph’s imaging detector, but a failure during TVAC has made that portion of the circuitry vestigial. (A current sense amplifier failed, which caused the TEC H-bridge controller to output too high of a voltage/current, which blew the thermoelectric cooler. For flight, the destroyed CSA was removed from the PCB, and a damaged ADC was replaced.) Instrument telemetry that we downlinked over S-band from around the time of one of the spacecraft resets seemed to suggest a possible issue with the +12V rail, as the ADC (the same one which was replaced) is showing one of its channels (related to TEC voltage) periodically spiking to just below its maximum value (2^16-1). So, we suspect that there may be something amiss on the +12V side of things that is causing the reset.

So, prioritization of observations of CUTE from ~03:12 UTC Oct. 20th for around a day afterwards would be hugely appreciated (if that is at all possible). We’re really hoping to obtain telemetry at the moments leading up to a reset to help deduce the root cause. I would be happy to provide more details of what we’ve observed and suspect w.r.t. the resets if people are curious.




Thanks for the update @nsdecicco . Good luck with figuring out the root cause of the issue you are experiencing. I went ahead and added many observations on the network in the hopes of helping you more within this 24h timeframe.

For the decoder, I am sure @DL4PD will be reviewing this quickly.

Keep the updates coming!


Hi Nick,

scheduled some CUTE observations via my station 2134

Direct links here

Good luck!

The update is only required for the dashboard, not receivers?


Hi @n5zkk, yes, I believe that’s correct. Without the decoder updated, receivers can still receive, demodulate, and decode telemetry into a string of hex bytes, but you won’t be able to make sense of the bytes, and so those won’t appear in the dashboard, either.

@satcolintel5 Thanks!!

By the way, since turning the payload on (sans the +12V rail), the telemetry we have seen in the SatNOGS dashboard makes it appear that the spacecraft has NOT reset in this time (going on ~22 hours now!).

The tricky part will be figuring out how to get the instrument shutter to open and stay open with the +12V rail off, as the circuitry which operates the shutter has been designed to autonomously close the shutter if the +12V rail is turned off :frowning:


Another update: at around noon MST (~18:00 UTC), the sw_stat beacon was turned off as what seemed to be a software glitch caused the UHF transmitter to stay stuck on and transmit continuously, clogging up the band. We’ve reached out to the bus vendor to try to determine what the root cause of that might have been, but for the time being those beacons will probably remain disabled.

Now that the payload appears to be working without resetting the spacecraft, the operations folks are going to try to proceed with acquiring dark and bias frames from the instrument detector for the next few days, while we work in parallel to see if there is a work-around for the shutter.


I’ve just merged the changes you made and tagged a new version. In a few minutes there will be the latest version released in DB.

Let me know if I can do any further things (like re-decoding all packets to decode the already stored sw_stat packets in DB).