More details about Orion uncoded telemetry

In a previous post I analysed the residual carrier telemetry of the Artemis I Orion capsule using some recordings done by CAMRAS with the 25 m radio telescope at Dwingeloo observatory. I noticed that, in contrast to some recordings that I had done early after launch with the Allen Telescope Array, in those recordings the telemetry was uncoded instead of using LDPC. I related that finding to some tweets from Richard Stephenson about the project switching frequenctly between residual carrier and OQPSK, and between uncoded and LDPC.

I wanted to study the situation in more detail, for example to see what combinations of residual carrier / OQPSK and uncoded / LDPC were possible. Since CAMRAS hasn’t made available on their web server all the recordings they did, due to disk space constraints, I asked them to publish a few additional recordings that seemed interesting to this end. This is a short post with my findings about those new recordings.

The list of recordings studied in this post is


I selected all the recordings that included a residual carrier signal with good SNR and enough bandwidth to decode, and also included an OQPSK recording in the list (there are several other OQPSK recordings more).

The spectra of the beginning of the recordings are shown below. These were produced with this script. Note that it is possible to see the amount of idle frames that are present from the strength of the spectral lines. The two recordings from 2022-12-08 have lots of idle data.

I have used this GNU Radio flowgraph to decode the residual carrier telemetry and this flowgraph to record the OQPSK telemetry. The flowgraphs are very similar to the ones I’ve used in previous posts. For each recording, I have done small adjustments to the flowgraph involving the sampling rate (there is a Rational Resampler block for resampling to a common sample rate of 5 Msps in the residual carrier decoder) and the carrier frequency (there is a Rotator block that is used to move the signal to baseband).

I have updated the Jupyter notebook that shows histograms and raster plots of the symbols in each recording. The plots for each recording (including the ones examined in the previous post) can be seen in that notebook.

The last recording has very good SNR. The histogram shows few bit errors. In the raster map we can see that there are a few bursts of idle frames, but most of the data is encrypted telemetry.

Since this recording has so good SNR, I have added a CRC check, mainly to validate that the last two bytes of uncoded frames are a CRC-16 as I suspected. As expected, the CRC algorithm is the CRC-16-CCITT-False specified by CCSDS as Frame Error Control Field (see for instance Section 4.1.6 in the AOS Space Data Link Protocol Blue Book). In this recording, 97.4% of the decoded frames have correct CRC. In the other recordings the bit error rate is higher, so very few or no frames have a good CRC.

The Jupyter notebook indicates which recordings use LDCP and which use uncoded telemetry. In the cases in which idle frames are visible in the raster map, it is easy to tell apart LDPC from uncoded by looking at whether the idle frames have parity check bits or not. In the other cases, I have tried to use an LDPC decoder. If the LDPC decoder fails with all the frames, then the conclusion is that the telemetry is uncoded, because the SNR is always good enough that the LDPC decoder would work if the frames were actually LDPC.

All the recordings examined have turned out to be uncoded (except for one from the day after launch which we already examined in the previous post). These are all from the last part of the mission (starting at 2022-11-30, which includes the end of the DRO and the return trip to Earth), because before that CAMRAS was recording with the wrong polarization and the SNR of the earlier recordings is very low.

It seems that there is a prevalence of using uncoded telemetry during the last phase of the mission. Perhaps there are some confounding factors at play in this study, such as the possibility that in most or all of the CAMRAS recordings the spacecraft was being tracked by the DSN station in Madrid (i.e., the recordings are not a random sampling of the mission timeline).


  1. Regarding the ‘Rotator block’ (which is new to me), a couple of questions, please:
    #1, a radio-oriented person like myself thinks in terms of RF frequency (as opposed to the underlying math involved). Is there a way to know what value to use for ‘Phase Increment’ to equate to a desired shift in RF frequency?
    #2, is there some advantage in using the ‘Rotator block’ over the Frequency_Xlating_***_Filter types of blocks?

    1. Hi Scott,
      The phase increment for the rotator block is in units of radians / sample. So you can compute it as 2 * pi * frequency(in Hz) / sample rate.

      The Frequency Xlating FIR filter actually includes a rotator. But it also does a bunch of stuff that we don’t really need here: filtering and decimation.

Leave a comment

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.