ESCAPADE is a twin spacecraft mission that will study the Mars magnetosphere. The science mission is led by UC Berkeley Space Sciences Laboratory and the spacecraft buses were built by Rocket Lab. It was launched on November 13 on the second Blue Origin New Glenn mission NG-2. The spacecraft will spend a year around the Earth-Sun L2 Lagrange point before falling back to Earth for a powered gravity assist that will place them on Hohmann transfer orbit to Mars as the “launch window” to Mars opens. These are the first spacecraft to fly this kind of trajectory.
The day after launch, I used two antennas from the Allen Telescope Array to record the X-band telemetry signals of the two spacecraft, which were approximately 200 thousand km away from Earth. In this post I will show the results of this observation, and how to decode the telemetry. I have published the recording in the dataset “Recording of ESCAPADE X-band telemetry with the Allen Telescope Array shortly after launch” in Zenodo.
Observation set up
I used the ephemerides from HORIZONS to compute an azimuth and elevation time series to point the ATA antennas. The observation was done on November 14, which was the first time that the spacecraft were visible over the US west coast after launch. The following plot shows the azimuth, elevation and distance for the observation.
Since AMSAT-DL observed the spacecraft some hours before I started and shared the waterfall plots in Twitter, I didn’t even need to search around in frequency and figure out a suitable sample rate. I decided to record at 10.24 Msps centred at 8420 MHz, which would be enough to capture the signals of both spacecraft. In hindsight, the spacecraft information in HORIZONS also gives the carrier frequency for each spacecraft:
- ESCAPADE-Blue: Communications : 60-cm fixed X-band antenna, downlink @ 8417.165797 MHz
- ESCAPADE-Gold: Communications : 60-cm fixed X-band antenna, downlink @ 8423.148147 MHz
Note that ESCAPADE-Gold is in channel 20 of the standard DSN assignments, but ESCAPADE-Blue uses a non-standard frequency.
Initially I planned to observe using antenna 1a from the array. This is one of the few antennas that remain with the old feed design, which is less sensitive at higher frequencies. This antenna is not part of the array used by the main science backend, and normally it is only used for the GNU Radio backend, and science and engineering activities. Since I wasn’t seeing any signal with this antenna, and since other antennas were also free at that time, I switched to antennas 1b and 3c after some time. These have the new “Antonio” feed and are more sensitive at higher frequencies. With these antennas I could get a reasonable signal, so I continued using them until the spacecraft set.
Waterfall analysis
The following plot shows the Stokes I waterfall of the signal recorded with antenna 3c. We can see both spacecraft, but the signal strength varies a lot, suggesting that perhaps the spacecraft were using low-gain or medium-gain antennas and changing attitude. The white gap in the middle of the plot corresponds to data that was lost. The disk where I was recording filled up, and I only realized some time after. I had to move the data to another disk before starting to record again.
The following shows the average spectrum throughout the recording. We can see what looks like ranging tones approximately 1 MHz away from the carriers of each spacecraft.
The spectrum obtained with antenna 1b is shown here for comparison. Note that the SNR is significantly worse. The reason for this is unknown at the moment.
Since antenna 3c has much better SNR and the spacecraft signal’s are either strong enough to decode with just this antenna or too weak to decode with two antennas, I have only used the data recorded by antenna 3c.
Here is a detail of the waterfall of ESCAPADE-Blue. The signal is very weak until 14:37:24 UTC, when it suddenly jumps up in power. This suggests a switch in the transmit antenna. A detailed look at the IQ file shows that a transmitter is switched on at this moment (the telemetry modulation takes a few seconds to engage). We can also see groundstation frequency sweeps and some frequency jumps.
The following shows the corresponding spectrum.
In the ESCAPADE-Gold waterfall we can see that the modulation has changed to a lower data rate after the white gap. The signal strength grows gradually at the beginning of the recording, suggesting a change in the spacecraft attitude. At 14:22:47 the signal disappears completely, suggesting that the transmitter has been turned off. A very weak signal at the lower symbol rate appears some time later. It seems that a different antenna is being used. After the gap, there are some ground station sweeps, frequency jumps, and both gradual and sudden changes in received signal power, so probably there is more antenna switching.
Here is the corresponding spectrum.
Modulation and coding
The telemetry modulation is PCM/PSK/PM, meaning that telemetry is BPSK-modulated on a subcarrier, which is phase modulated onto the RF carrier, leaving a residual carrier. There are two configurations seen in this recording. The higher rate configuration uses 16 kbaud and a 64 kHz subcarrier. The low rate configuration uses 2.5 kbaud and a 25 kHz subcarrier. Note that these all use a subcarrier/baudrate ratio that is an integer, as recommended by CCSDS in order to have zero telemetry power at the residual carrier frequency. The coding is CCSDS Turbo code with rate 1/2 and 1115 byte frames in both cases.
The following figure shows a GNU Radio decoder flowgraph for the higher rate telemetry. The decoder for the lower rate telemetry is very similar.
Here is the GUI of the decoder flowgraph running in one of the recordings.
Telemetry
The telemetry frames are CCSDS TM Space Data Link frames. There is an unusual feature that confused me for a while. When there is no data to be sent, the transmitter sends again the last frame, instead of sending an only-idle-data frame. When I started analysing the telemetry, this threw me off, because it causes repetitions in the master channel and virtual channel frame counts in the TM Primary Header. Because of this, I was thinking that I was looking at a non-CCSDS protocol that had some sort of counters that worked differently from the TM Space Data Link protocol. Eventually I realized that not only the frame counts were repeated. The whole frames were identical. Having noticed this, I saw that the frames were indeed CCSDS TM Space Data Link frames, and I could continue parsing the rest of the telemetry.
ESCAPADE-Blue uses spacecraft ID 0x7b, and ESCAPADE-Gold uses spacecraft ID 0x56. I haven’t found the assignments for these in SANA registry. The spacecraft are registered in SANA, but their spacecraft IDs are not.
The frames have a Frame Error Control Field, which is checked in GNU Radio, but they don’t have an Operational Control Field. Only virtual channel 2 is in use. The secondary header flag is asserted. There is an 8-byte secondary header, but it does not conform to the format specified in the CCSDS Blue Book because it is missing the Transfer Frame Secondary Header ID field that contains the Transfer Frame Secondary Header Length. The whole 8-byte secondary header is a timestamp, given as a 64-bit big endian integer that counts units of \(2^{-16}\) seconds. The epoch is 1970-01-01 00:00:00 UTC, but I have not tried to check whether leap seconds are included in this count or not.
This plot shows the downlink utilization, which is computed indirectly by counting how many frames are duplicated. ESCAPADE-Blue begins transmitting a lot of data around 19:00 UTC.
The next figure shows number of lost frames versus time, using the master channel frame count. Values should be interpreted modulo 256 frames. In particular, during large gaps there are many more frames lost than what shown here. We see that except in gaps where the signal fades out, and in some uplink sweeps, decoding is error free.
Virtual channel 2 contains CCSDS Space Packets. There is only one APID in use, APID 51. The packets don’t have a secondary header and they all have the sequence count or name field set to zero. There are packets of many different sizes, but a few particular sizes happen quite frequently.
There are many interesting ASCII strings in the packet payloads. These seem to be log messages from a Linux system. Here are some examples. The Jupyter notebook shows all of them:
/mnt/mmc0/logs/compton/inv_sts/inv_sts-1763132730.mtc.gz
/mnt/mmc0/logs/compton/inv_eps/inv_eps-1762763341.mtc.gz
/mnt/mmc0/logs/compton/inv_cdh_spoc_misc/inv_cdh_spoc_misc-1762770516.mtc.gz
E_CMD_HIST: [ OK ] EPS_SPOC_DIO_ST_OCP_EN ENABLE_STATE=[0, Off]
E_CMD_HIST: [ OK ] CDH_SPOC_IO_GPIO_STATE_SET IDX=[109] STATE=[0, E_Low]
E_CMD_HIST: [ OK ] FJ_ABORT, Proc: CommsFallback
E_INFO: set_st_power_state: End sequence
E_CMD_HIST: [ OK ] MISC_SYSTEM, STRING: echo 'WAIT(2)' >> /tmp/BackorbDownload.fj
E_CMD_HIST: [ OK ] MISC_SYSTEM, STRING: sed -i '$d' /tmp/BackorbDownload.fj
E_CMD_HIST: [ OK ] MISC_SYSTEM, STRING: rm /tmp/*_files_list.txt
E_CMD_HIST: [ OK ] MISC_CONFIG_PARSE, String: tlm_master.set_apid_freq(620, 0.05);
E_CMD_HIST: [ OK ] FJ_START_ABS, Time: 1763146080.000000, File: CommsFallback, Args:
E_CMD_HIST: [ OK ] FJ_START_REL, Seconds: 3600.000000, File: DisableComponents, Args: STA
E_CMD_HIST: [ OK ] FJ_START_REL, Seconds: 0.000000, File: BackorbInit, Args:
E_CMD_HIST: [ OK ] MISC_SYSTEM, STRING: echo PROC BackorbDownload > /tmp/BackorbDownload.fj
E_CMD_HIST: [ OK ] MISC_SYSTEM, STRING: echo \'CMD "MISC_SYSTEM" ("gzip -c -f -k /tmp/BackorbDownload.fj > /tmp/BackorbDownload.gz")\' >> /tmp/BackorbDownload.fj
E_WARNING: LoadProc (File: FJExecute.cpp Line: 1205): Procedure found in working directory, executing: /tmp/BackorbDownload.fj
E_INFO: SetThermostatMode: Setting thermostat 'EESA' to mode ClosedLoop
E_INFO: SetThermostatSetpointsClosedLoop: new setpoints for ON -35.000000 deg C. OFF -30.000000 deg C.
The FJ that appears in some of these messages is FlightJAS, a sequencing language used by the MAX flight software, originally developed by ASI, which is now owned by Rocket Lab. It makes a lot of sense that ESCAPADE runs MAX, since the spacecraft bus is based on the Rocket Lab Photon.
Seeing these detailed messages in a deep space satellite telemetry is a nice change from the usual telemetry, which is only a bunch of numbers, potentially in a highly compacted format. In part, this difference is caused by these spacecraft running a more modern software stack based on Linux, instead of the more traditional custom software stack of other deep space missions. I suspect that the ASCII messages we see here are strings contained in structures in some serialization format, which also contain numerical data. I haven’t looked closely at the payloads of the Space Packets to try to reverse engineer them, but maybe I will do so in the future.
Code and data
The Jupyter notebooks used compute the antenna tracking and waterfalls, as well as the GNU Radio flowgraphs used for preprocessing (waterfall computation and channelization) can be found in this repository. The GNU Radio decoder flowgraphs, the Jupyter notebook used for frame analysis and the binary files containing all the decoded frames can be found in this repository. The link to the IQ recordings is given at the beginning of the post.