Recently, together with people from Harbin Institute of Technology and CAMRAS, we have published in Zenodo the data collected during the DSLWP-B mission. This data release includes all the raw telemetry frames uploaded to the DSLWP telemetry server.
I have made a Jupyter notebook that loads up and parses the telemetry, with the idea of providing a simple way to study the data.
The DSLWP satellites transmitted CCSDS TM Space Data Link frames. The whole mission telemetry collected in the telemetry server is a list of all the Space Data Link frames submitted by the groundstations, with some additional metadata.
Each of the satellites had two redundant V/U transceivers (for example, in the case of DSLWP-B one used 435.4MHz and the other 436.4MHz). A different Spacecraft ID was used for each satellite and transceiver, so that DSLWP-A0 (435.425MHz) used 146, DSLWP-A1 (436.425MHz) used 402, DSLWP-B0 (435.4MHz) used 147 and DSLWP-B1 (436.4MHz) used 403.
Additionally, three Virtual Channels were used. Virtual Channels 0 and 2 were used to send telemetry. The payload of these channels were independent KISS streams in which telemetry packets were embedded. Virtual Channel 1 was used to send SSDV. The payload of each Space Data Link frame belonging to Virtual Channel 1 was a single SSDV frame as described in this post. The reassembly of the SSDV data from the whole mission telemetry was done together with Tammo Jan Dijkema in this Jupyter notebook and is included in the Zenodo data release (both as SSDV files and decoded JPEG images).
The telemetry packets embedded in the KISS streams are CCSDS Space Packets. There are several different kinds of packets, whose format can be seen here. These are HKUV, containing housekeeping data from the transceiver, HKWOD, which contains housekeeping whole orbit data from the satellite bus and both transceivers, CfgUV which contains the configuration of the transceiver, and CfgCam, which contains the configuration of the Inory Eye camera.
How the type of each packet is decided can be seen here. The APID in the Space Packet header and a protocol byte immediately following the Space Packet header are used to determine the type of the packet.
Obtaining the Space Packets from the Space Data Link frames is not straightforward. The KISS stream needs to be “followed” to extract the packets. However, in the telemetry database there are often versions of the same packet submitted by different stations, some with bit errors. The frames do not have any CRC, so wrong data must be determined heuristically. The virtual channel frame count field in the TM header is used to try to recover the contiguous KISS stream. When there are duplicated frames, the frame submitted by the “best” station is chosen. This procedure still produces several corrupted frames, so some sanity checking is done by ensuring that the data length field in the Space Packet header matches the length of the packet.
After recovering all the Space Packets for each Spacecraft ID and Virtual Channel, we use construct to parse the telemetry. Once this is done, there are still some bit errors, but hopefully they can be spotted because they produce data which is obviously wrong.
As a simple example of what can be achieved by analysing whole mission telemetry, I have plotted some of the telemetry variables. The figure below shows the value of the payload runtime in the HKUV frames, coloured by Spacecraft ID and Virtual Channel.
We see that both DSLWP-A and -B transmitted some data at the beginning of the mission during the transfer orbit until the Amateur payloads were turned off. DSLWP-A was never heard again. DSLWP-B transmitted many telemetry packets during its 2 hour activation slots (note that the runtime always reaches nearly 7200 seconds). Periods of more frequent activity in the mission, such as the autumn of 2018 and July 2019 can be seen easily in the plot.
Telemetry is often transmitted on Virtual Channel 0, but we see some periods of time were Virtual Channel 2 is used instead. I do not know the reason for this.
The figure below shows the TX modulation parameter in the HKUV packets. It shows the change from 250baud to 500baud happening during October 2018.
A zoom in this plot shows that the B1 transmitter was changed on 2018-10-19, while the B0 was changed some days later. This change was reported in this post.
The change is seen more clearly in the HKWOD telemetry, which contains the state of both transceivers. The values of UVB are offset for clarity. We see UVB changing a few days before UVA.
Below we show the PA temperature of the transceivers. During each activation, the PA temperature would rise from around 30ºC to 50-60ºC as the transmitter was kept on continuously for tens of minutes to transmit SSDV images.
The figure below shows the raw value of the battery temperature in the HKWOD packets. The conversion equation is not included in gr-dslwp, so I haven’t included it in my telemetry parser yet. It is apparent that the raw value is negatively correlated with the temperature.
In fact, conversion equations are missing for all the fields in the HKWOD packet, but the telemetry server implements all these conversions, so it should be easy to port the code.
Update 2019-12-27: Wei Mingchuan BG2BHC has sent me the equations to convert the telemetry fields, and I have updated the Jupyter notebook accordingly. The figure below shows the battery temperature correctly decoded.
One question about the plots on this page: can you spot in the PA temperature plots the time slots in which both B0 and B1 were transmitting? We only did this a few time at the end of the mission; in the beginning it was not allowed because of overheating concerns.
If we zoom in in the time segments when both B0 and B1 were transmitting (I don’t recall when was that, might have to search in the Dwingeloo recordings), I bet we’ll see that everything heats up faster than when only B1 is transmitting.
That’s a good idea for something to do with the data.