RS92 PTU

[rs1729]

The RS92 PTU data is described here:
https://brmlab.cz/project/weathersonde/telemetry_decoding

Frequencies of capacitive sensors can be measured as periods 1/freq. The RS92 PTU values can be approximately calculated as described in the lecture notes by Haeberli (2001):
https://www.file-upload.net/download-14470162/haeberli-convert.pdf.html
(probably for a predecessor of the RS92)
RS92 seems to use degree 5 polynomials to model the sensors, though for the two humidity sensors the upper two coefficients are zero.

In
2453b79
only the uncorrected values are calculated. Temperature and pressure are close enough.
The humidity sensors are heated in intervals (up to -60C/100hPa), however if the temperature difference is not constant, the temperature at the humidity sensor would have to be estimated depending on e.g. air temperature and air flow (climb rate). At lower temperatures and higher relative humidity the corrected relative humidity would be noticeably higher (applying e.g. Hyland/Wexler).
cf.
https://amt.copernicus.org/articles/7/4463/2014/ (amt-7-4463-2014)
https://www.vaisala.com/sites/default/files/documents/9781461439080-c1.pdf

[rs1729]

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

[rs1729]

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

[rs1729]

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:

RS/rs92/rs92mod_ngp.c

Lines 365 to 418 in 471e023

	static int xor_ptu(gpx_t *gpx) {
	int j, k;
	ui32_t a, c, tmp;
	ui8_t *pcal = gpx->calibytes+0x24;
	for (j = 0; j < 8; j++) {
	tmp = 0x1d89;
	for (k = 0; k < 4; k++) {
	a = pcal[j+k] & 0xFF;
	c = tmp;
	//add(A, C, A);
	a = a + c;
	c = a;
	//shl_add(A, 10, C, A);
	a = (a << 10) + c;
	c = a;
	//shr_xor(A, 6, C, A);
	a = (a >> 6) ^ c;
	tmp = a;
	}
	a = tmp;
	c = a;
	//shl_add(A, 3, C, A);
	a = (a << 3) + c;
	c = a;
	//shr_xor(A, 11, C, A);
	a = (a >> 11) ^ c;
	c = a;
	//shl_add(A, 15, C, A);
	a = (a << 15) + c;
	//y = a & 0xFFFF;
	gpx->xptu16[2*j ] = a & 0xFF;
	gpx->xptu16[2*j+1] = (a>>8) & 0xFF;
	}
	return 0;
	}

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.