One last hurdle to overcome before getting to see the data 'in the clear' is the P-N (pseudo-noise) encoding, sometimes
known as scrambling or randomising. The 8160 bit information field has been XORed with the output of a PN generator
circuit before transmission. This is done for technical reasons, it creates more 'bit' transitions in the modulated signal even
if the raw input data contained long runs of all '1's or '0's. Back on the ground at the receiver, the demodulator bit clock
recovery circuit now has more transition edges with which to kick the clock recovery phase-locked loop into phase. If
you imagine the extreme case of all '0's (or '1's) being sent, then the received signal would simply be a continuous
carrier wave with no meaningful information on it to indicate bit rate or initial phase.

Here is an excerpt from the JMA LRIT spec regarding the randomisation process.

The 'generator polynomial' is a fancy way of stating how to hook up the feedback XOR gates in a shift register based
circuit, as shown below. The factor of each X term indicating which flip-flop to take a pick-up point from. 1 is simply
X to the power zero. X to the 8 and 1 (X to the 0) define the total length of the generator shift register. This is all
secret satellite men's business from the deep, dark past - I cannot, in any way, show you how to derive this from first
principles. (I saw a circuit for a 15 stage generator in an old GMS satellite specification decades ago...)

The beautiful thing about XORing is that if you do it again in the same order you will recover the original data values.
Conveniently, we are able to do this in a byte-wise fashion with a pre-loaded table of PN XOR values. In my code,
I simply include this header file, which defines a pre-prepared array of 1020 XOR coefficients, as if they had come
from the above generator circuit. These are bit-wise XORed with the CADU information field, byte by byte, in a
1020 byte FOR loop. NOTE:- the 4 ASM bytes are not PN encoded and should be skipped.

In C code, for example:
for(i=0; i<1020; i++) {
..cadu_byte[i+4] = cadu_byte[i+4] ^ rantab[i];
}

You should now have a file full of 1024 byte lines made up of the 4 byte Attached Sync Marker and 1020 bytes
of 'payload' data. This un-scrambled data field is refered to as the CVCDU and becomes the input to the next
layer of processing.

BACK