RS92 PTU about rs HOT 3 CLOSED

The RS92-NGP (still flying in the US) might have different calibration data or a new firmware.

from rs.

RS92-NGP calib-data and PTU seems to be xor-obfuscated.
345f60d

from rs.

RS92-NGP

The RS92-SGP has 66 calibration coefficients starting at offset 0x40 (5 bytes each, 1 byte index plus 4 byte float32).
At first glance the RS92-NGP calibration data does not show these calibration values, although the config bytes suggest there are also 0x14A bytes for the coefficients, 5 bytes each.
However the XOR difference of two NGP-config/calib datasets shows the same parts being constant that are constant across RS92-SGP:

Though XORing NGP and SGP does not immediately reveal a potential XOR mask:

It turns out that except for the index and the float32-MSB, the middle bytes are permuted.

The 8x3=24 raw PTU values are also obfuscated. Here there are no constant values to be expected, only the MSB of each int24 should be constant most of the time. Observing a longer recording one can notice that the bytes change along with the (16 bit) frame counter, hence XORing the frame counter and the raw PTU gives data that looks more like 8 int24 values.
From a whole flight all the bytes (more or less) can be reconstructed. This shows that after 16 bytes the mask repeats, i.e. probably again 16 bytes (or 8 16-bit words).
Now a look into the EEPROM data shows, how the mask is generated and how the data is scrambled. Thanks to @pinkavaj for making a disassembler!
https://github.com/pinkavaj/vsdsp_asm
The seed starts at offset 0x24 in the config data, the raw asm function does something like this:

Another interesting observation is the data whitening sequence that RS92-AGP (and RS41) use instead of Manchester coding, this sequence can be found in the RS92-SGP and RS92-NGP as well. But the PTU scrambling of RS92-NGP is probably done for a different reason, it uses Manchester coding anyway.

from rs.