AX2150 / AX100 CCSDS scrambler implementation

[briany100]

Hi, we are working on the development of an uplink and downlink soft modem to use with the GOMSpace AX2150 radio. This is a relatively new S Band product, however based on the manual (we haven’t turned the radio on yet!) it seems to be configured in a very similar manner to the AX100 radio in “ASM + Golay” Mode.
We have made good progress – packets can be generated with an added preamble and syncword, the packet length field is Golay encoded, we can add a CRC32 and encode and decode with Reed Solomon, and have everything pop out again on the downlink using the gr-satellites AX100 Deframer (which is really using the U482C Decoder). Just one element is not working correctly, which is the CCSDS scrambling, currently we can only get it to work by turning scrambling off.
For the uplink we are using the GNURadio additive scrambler with parameters mask 0xA9, seed 0xFF, length 7, count 0 with a reset based on a packet length tag key. For the downlink the (de)scrambler is integrated in the U482C Decoder. We expected these to be functionally identical but it seems that this is not the case. The implementation for the U482C Decoder doesn’t use the GNURadio version but uses a separate implementation found in randomizer.c. They “should” be the same as they are, we understand, both based on the polynomial h(x) = x8 + x7 + x5 + x3 + 1. However they give different results – we have reimplemented the “randomizer” version in Python and fed both versions with a sequence of zero bytes - the “randomizer” implementation gives the expected result matching the CCSDS Blue Book description (first 9 bytes 0xff 48 0e c0 9a 0d 70 bc 8e) whereas the GNURadio version gives 0xff 12 70 03 59 b0 0e 3d 71. So the GNURadio version with these parameters looks to be giving the wrong answer.
So, is there some quirk regarding the U482C / AX100 scrambler implementation we are missing which means the GNURadio based scrambler doesn’t work here, but does for other satellites? Is this a configuration error?

[daniestevez]

It looks like a configuration error with the Additive Scrambler block. Can you share the complete flowgraph that reproduces this problem?

[briany100]

Hi Dani, thanks for the super quick response - hope you are having a good Christmas!
I found the problem - I had inserted the scrambler upstream of the unpacking block, and set the bits to byte parameter to 8. Moving it downstream of the unpacking block and setting this parameter to 1 fixed everything.
Looks like the bits to byte parameter actually changes how the algorithm works.
A screenshot of the updated flowgraph is attached. Brian
ax2150_tx_rx.pdf

[daniestevez]

This is exactly what I suspected. Bits per byte = 1 with an unpacked input (i.e., downstream of Packed to Unpacked) has a completely different behaviour compared to bits per byte = 8 with a packed input. With bits per byte = 8, if I recall correctly a whole byte is XORed with the contents of the LFSR register before shifting the LFSR by one place. This is something that I've only seen a few RFICs do. A standard additive LFSR scambler (including the one in CCSDS) uses one bit from the LFSR register each time, shifting once per input bit, so that's why you need bits per byte = 1. Good to see you figured this out.