S-NET telemetry parser

Recently I have added a telemetry parser to the S-NET decoder in gr-satellites. Recall that I have talked about S-NET and its decoder in a previous post. To implement this telemetry parser I have used the information in Mike Rupprecht DK3WN’s web, some additional information shared by the S-NET team, as well as some recordings done by Mike. Many thanks to Mike and the S-NET team for all their help. Here I describe a few details about the telemetry.

The structure of the telemetry frames can be seen in the following image, taken from Mike’s web.

S-NET telemetry frame structure

The telemetry frame is sent as the PDU in an LTU frame. The frame starts with an 18 bit syncword and a CRC-14. These don’t make much sense when the telemetry frame is sent inside a single LTU frame, since the start of the frame is already clear and the PDU of an LTU frame is protected by a CRC-13. My guess is that the syncword and CRC-14 are there in case the telemetry frame is fragmented and sent inside several LTU frames (or perhaps when it is sent over another different link layer). Or maybe for aggregation, where several telemetry frames are sent inside the same LTU frame PDU. So far, I haven’t seen any of these things being used.

The Frame Content ID fields identify the type of frame. The S-NET team has only shared the details for EPS telemetry frames (FCID Major 9, FCID Sub 0) and ADCS telemetry frames (FCID Major 0, FCID Sub 0).

After this, there are 6 bits of flags. The multiframe flag hints at the possibility of performing fragmentation or aggregation. The optional timestamp is given as a little-endian 32bit integer, in units of 0.5s since 2000-01-01 00:00:00UTC (a rather weird timestamp format). The “Is Time Tagged” flag indicates whether the optional timestamp is included (not all packets use it). I don’t know the purpose of the “Time Tagged Setting” flag.

The data length field contains the length in bytes of the user data. Again, this field doesn’t make a lot of sense when the telemetry frame is sent inside a single LTU frame, as there is already a length field in the LTU header.

The S-NET team has shared the format for the ADCS and EPS beacons. This can be seen in the S-NET telemetry pyconstruct definitions.

An ADCS frame looks like this. It is interesting that the current position of the satellite is included with the ADCS telemetry. The name of the fields includes SGP4, so this probably indicates that the position is calculated using TLEs rather than being obtained with GPS as other small satellites do.

    header = Container: 
        CRC = 14448
        FCIDMajor = 0
        FCIDSub = 0
        Urgent = False
        FutureUse = False
        CheckCRC = True
        Multiframe = False
        TimeTaggedSetting = True
        TimeTagged = True
        DataLength = 57
        TimeTag = 2018-03-06 22:34:22
    telemetry = Container: 
        iModeChkListThisStepActive = 1
        iAttDetFinalState = 3
        iSensorArrayAvailStatusGA = 15
        iSensorArrayAvailStatusMFSA = 3
        iSensorArrayAvailStatusSUSEA = 0
        iActArrayAvailStatusRWA = 0
        iActArrayAvailStatusMATA = 0
        AttDetMfsDistCorrMode = 4
        AttDetSuseDistCorrMode = 4
        flags = Container: 
            AttDetTrackIGRFDeltaB = False
            AttDetSuseAlbedoTracking = False
            SUSE1AlbedoFlag = True
            SUSE2AlbedoFlag = True
            SUSE3AlbedoFlag = False
            SUSE4AlbedoFlag = False
            SUSE5AlbedoFlag = False
            SUSE6AlbedoFlag = False
            AttDetAutoVirtualizeMFSA = True
            AttDetAutoVirtualizeSUSEA = False
            AttDetNarrowVectors = False
            AttDetMismatchingVectors = False
        omegaXOptimal_SAT = -0.161538461538
        omegaYOptimal_SAT = -0.211538461538
        omegaZOptimal_SAT = 0.265384615385
        magXOptimal_SAT = -16570.0
        magYOptimal_SAT = -20980.0
        magZOptimal_SAT = 20230.0
        sunXOptimal_SAT = -0.30425
        sunYOptimal_SAT = -0.40390625
        sunZOptimal_SAT = 0.86271875
        dCtrlTorqueRWAx_SAT_lr = 0.0
        dCtrlTorqueRWAy_SAT_lr = 0.0
        dCtrlTorqueRWAz_SAT_lr = 0.0
        dCtrlMagMomentMATAx_SAT_lr = 0.244094488189
        dCtrlMagMomentMATAy_SAT_lr = 0.133858267717
        dCtrlMagMomentMATAz_SAT_lr = 1.97637795276
        iReadTorqueRWx_MFR = 0.0
        iReadTorqueRWy_MFR = 0.0
        iReadTorqueRWz_MFR = 0.0
        iReadRotSpeedRWx_MFR = 0
        iReadRotSpeedRWy_MFR = 0
        iReadRotSpeedRWz_MFR = 0
        SGP4LatXPEF = 42.4338028169
        SGP4LongYPEF = 19.4802259887
        SGP4AltPEF = 568.0
        AttitudeErrorAngle = 0.0
        TargetData_Distance = 64000
        TargetData_ControlIsActive = 0

I haven’t seen an EPS frame yet, which I still need to test my EPS frame parser. Most of the frames transmitted by S-NET are not ADCS or EPS frames. For instance, the FCID Major 48, FCID Sub 1 message type is seen a lot. Unfortunately, we don’t have the information for the format of these messages. You can see the full decode of one of the recordings in this gist.

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.