# How is Data Whitening done?

Is it safe to define that Data Whitening is always X-ORing a payload with a pheudorandom sequence known to both receiver and transmitter?

In more detail, lets assume the following case. I have the exact pseudorandom string that is used for Data Whitening of a SX-1234 transceiver (a random transceiver). Lets also assume that I have captured the already whitened payload received by another SX-1234 transceiver. Provided SX-1234 does not perform any other encoding steps other than data whitening, if I simply X-OR my received payload with the pseudorandom string, will I get back the originally transmitted data?

If not, what other methods are there for data whitening other than simple X-ORing.

• This is perhaps an interesting question but whitening transformations are outside of the scope of amateur radio. Jan 6 '18 at 12:29
• While I don't necessarily agree that it is definitely off-topic, I think your questions on whitening might likely get better answers on dsp.stackexchange.com. (Let me know if you'd like them migrated.) Jan 6 '18 at 15:21
• @KevinReidAG6YO is it still possible to migrate there after I answer here? I concur on your assessment. Jan 6 '18 at 16:05
• @MarcusMüller Can you please advice whether I should post my encoding related question on this forum here after? Jan 7 '18 at 2:07
• how would I know the question, which is still in your head? Read both site's help pages to decide on which site it fits better. Jan 7 '18 at 7:22

Is it safe to define that Data Whitening is always X-ORing a payload with a pheudorandom sequence known to both receiver and transmitter?

No, but that's a very common way of doing it. However, you can scramble and whiten a sequence by pushing it through an appropriate Linear Feedback Shift Register, and I'd assume that this is even more commonly applied in practice.

I have the exact pseudorandom string that is used for Data Whitening of a SX-1234 transceiver (a random transceiver)

That is a rather uncommon case. As said above, I'd assume most systems do NOT just XOR with a fixed sequence, but scramble the data itself.

And even for systems where the data is XOR'ed with a pseudorandom sequence, I'd assume that for whitening reasons, you'd want that sequence to be long. Such sequences aren't stored, but again, generated using things like linear feedback shift registers, or other algebraic approaches. Such a sequence can easily become very long.

So, unless SX-1234 is a very old standard, it's questionable that you "captured" the whole sequence. Maybe you mean you've got the generator for the same sequence? Then you "only" have to sync up to your data stream.

It's very hard to estimate the current state in that sequence from a short observation (that's a requirement for good pseudorandom generators, and it's often very desirable, again, for autocorrelation/whitening reasons). So your syncing can, often, only be approached by a brute force trial of all possible shift – a usually impractical approach.

Provided SX-1234 does not perform any other encoding steps other than data whitening, if I simply X-OR my received payload with the pseudorandom string, will I get back the originally transmitted data?

No. If SX-1234 is prudent enough to whiten the data, then it'll certainly also employ channel coding (and that can be, if you don't know anything about the channel code, pretty much encryption). Oh, and let's not forget interleaving, which, especially for systems that transmit long streams of data, is employed to convert burst errors into sporadic errors (which the channel code can much easier correct).

• Thanks as always @Marcus. I'm trying to understand Matt Knights gr-LoRa work (a USRP based attempt to reverse engineer LoRa). In his work, he just assumes that LoRa whitening is simply X-ORing data with a pseudorandom string. He simply sends a payload of 0X00 and makes the silicon "reveal" this pseudorandom string. That was fascinating! But now I'm doubtfull how he did it. Because Semtech LoRa chip is sophisticated enough to not just X-OR (as you said) with payload. So How was Matt Knight so sure it was just simple X-OR and nothing more? Well thats a question no one can answer I guess. Jan 7 '18 at 2:01
• don't call it gr-LoRa, it's gr-lora, capitalization matters. For LoRa, that XOR'ing might be the case; it's a low-rate uncoordinated MAC, so short sequences make sense. The whitening for LoRa only needs to be very minimal, because a) it's a spread-spectrum procedure, anyway, and b) the rate is very low, so that channels change quickly enough for sequences not to be long. Special cases! Jan 7 '18 at 7:24
• Thanks for you openios @MarcusMuller. Could you please explain how the capitalization matters? I said gr-LoRa since LoRa is spelt that way. Thanks for highlighting my mistake. Althought it would be great to know why it is so. However, I am so surprised how Matt Knight was so smart to know LoRa modulation used simple X-ORing for Data Whitening. Anyway, I'm grateful he decoded it for us. Thanks to him and GNU Radio, we know so many things about LoRa now. Jan 7 '18 at 13:35
• capitalization matters in Python and C++ – and the module is called gr-lora, not gr-LoRa, no matter what the standard is called. Matt is a cool and clever guy – and he had public patents at his disposal; also, if you're analyzing something like that, you'd typically start out hoping it's something simple, and simply trying. Jan 7 '18 at 15:49
• You might want to read Matt's article in PoC||GTFO 0x13 if you haven't already, and watch one of his talks, e.g. the GRcon'16 talk (with its slides), if you haven't already. Jan 7 '18 at 15:49