Regarding Observation 2908977 …
Hi @EA4GPZ , I tried to decode WAV, using last SALSAT.yml , unfortunately no lucky…
I’m just looking into this, using observation 2908790, which also a good one.
The problem is that the CRC-5 on the LTU header is not what gr-satellites expects. If we bypass this check, the CRC-13 is not correct either, but we get the following (which I’m yet to confirm if it makes some sense):
Container:
SrcId = 8
DstId = 127
FrCntTx = 0
FrCntRx = 0
SNR = 15
AiTypeSrc = 0
AiTypeDst = 0
DfcId = 0
Caller = False
Arq = False
PduTypeId = False
BchRq = False
Hailing = False
UdFl1 = False
PduLength = 57
CRC13 = 3588
CRC5 = 10
Maybe @bastla can help us with the CRC.
If I force to skip some more checks, I get to the PDU data, which I think doesn’t make sense:
header = Container:
CRC = 4376
FCIDMajor = 25
FCIDSub = 0
Urgent = False
Extended = True
CheckCRC = True
Multiframe = False
TimeTaggedSetting = True
TimeTagged = True
DataLength = 37
TimeTag = 2030-06-15 06:09:08.500000
Extension = Container:
VersNo = 0
DFCID = 0
ExtensionRFU = 0
ChannelInfo = 0
QoS = False
PDUTypeID = False
ARQ = False
ControlRFU = 1
TimeTagSub = 256
SCID = 0
SeqNo = 0
I’m guessing something is not correctly aligned or the endianness is not correct.
2 Likes
@EA4GPZ At first sight your LTU looks good: SrcId #8 refers to the first UHF TNC of SALSAT, #9 to the second. #0…7 are allocated to S-Net so you definitely got the correct satellite. 
The CRC differs from S-Net because there were implementation bugs which should be fixed now. 
The bugs are described in the S-Net reference document.
The PDU looks (partly) good as well: FCID Major #25 is the housekeeping telemetry block for S-Net and SALSAT. FCID Sub #0 indicates the standard TM. An extended flag set to True is also correct for SALSAT. The time stamp is encoded LSB first and the OBC time was initially set during the first pass. Before this event the on-board time was set to some initial time I have to check with the team. Regarding the PDU extension VersNo #0 is correct but the DFCID should be 0b11 and your RFU flags should be set to 0.
But I think you’re very close now. Good job! 
Thanks @bastla!
Presumably I’ve implemented correctly the changes in the CRC in this commit in gr-satellites, which was present in the tests I did this morning. I took the code from the MR in gr-satnogs, and verified that the code is being called with buggy_crc = False. I might have made a silly mistake somewhere, though.
Since you say that most of the fields seem correct (I wasn’t quite sure what values to expect), I don’t think the problem is endianness or alignment.
The time stamp is read as a little-endian uint32_t. The same as for S-NET.
I have added some debugging code so we can see the intermediate results concerning the CRC calculations. I’m pasting the results here for one of the frames:
BCH decode of LTU is succesful
LTU contents:
[0 0 0 1 0 0 0 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 1 1 1 0 0 1 0 1 1 1 0 0 0 0 0 0 1 0 0 0 1 0 1 0]
Adapting LTU for CRC5 calculation
CRC5 will be computed over the following data:
[0 1 0 1 1 0 1 1 0 0 0 0 0 0 1 0 1 0 0 1 0 1 1 1 0 0 0 0 0 0 1 1 0 0 0 0 0
0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0 0 1 0 0 0 1]
Doing not-buggy CRC5 implementation
Computed CRC5 of LTU 12
CRC5 present in CRC field 10
CRC5 fail
Container:
SrcId = 8
DstId = 127
FrCntTx = 0
FrCntRx = 0
SNR = 15
AiTypeSrc = 0
AiTypeDst = 0
DfcId = 0
Caller = False
Arq = False
PduTypeId = False
BchRq = False
Hailing = False
UdFl1 = False
PduLength = 57
CRC13 = 3588
CRC5 = 10
Going to compute CRC13 of PDU (non-buggy implementation
Data to compute the CRC13 over is
[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 1 1 0 0 1 1 1
1 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 0 0 0 0 0
0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0
1 0 1 1 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1 0 1
0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 0 0 1 1 0 0 0 0 0 1 0 0 1 1 1 0 0 0
0 0 1 0 0 1 0 1 1 0 0 1 1 1 1 0 0 1 0 0 0 0 0 0 1 0 0 1 0 1 0 1 1 0 1 1 0
0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 0 1 1 0 0 0 0 0 0 1 0 0 0 1 0 1 0 1
0 0 0 0 1 1 1 1 0 0 1 1]
CRC13 calculated from data 5009
CRC13 present in LTU header 3588
CRC13 fail
Container:
header = Container:
CRC = 4376
FCIDMajor = 25
FCIDSub = 0
Urgent = False
Extended = True
CheckCRC = True
Multiframe = False
TimeTaggedSetting = True
TimeTagged = True
DataLength = 37
TimeTag = 2030-06-15 06:09:08.500000
Extension = Container:
VersNo = 0
DFCID = 0
ExtensionRFU = 0
ChannelInfo = 0
QoS = False
PDUTypeID = False
ARQ = False
ControlRFU = 1
TimeTagSub = 256
SCID = 0
SeqNo = 0
telemetry = None
The code with debugging enabled is in the salsat branch.
@bastla I’m reading the documentation and I’m confused. In pages 9 and 10 it says that the CRC13 is computed over the LTU header data and the CRC5 is computed over the PDU.
In S-NET it was the other way around (CRC5 protects LTU; CRC13 protects PDU). This has been implemented as such in gr-satellites and validated with over-the-air signals. Has this changed in SALSAT or is this a typo?
I think it should be a typo, since it makes sense to use the longer CRC13 to protect the PDU, which is longer than the LTU.
The document “TUBiX10 Projects S-Net&SALSAT. Communication System Specifications" section 5.2.1 “PDU Header” states: “A 14-bit Cyclic Redundancy Check (CRC) is used for error checking. The so-called CRC-14 is obtained by starting from Byte 4 (FCIDMajor) until the end of the payload data. 0x21E8 creates the generator polynomial. The initial value starts with 1,0x3FFF respectively.”
Probably it is reason why CRC-13 is not correct.
This is also present in S-NET. There is a CRC-14 in the PDU, but there is also a CRC-13 in the LTU header. The CRC-14 was never implemented in gr-satellites. I don’t remember why, but maybe because it’s somewhat redundant in the presence of the CRC-13.
For anyone reading this thread: the bug in the SALSAT CRC calculations in gr-satellites has now been identified with the help of @bastla and fixed in the master branch.
3 Likes