search

rs1729 / RS

radiosonde decoding
GNU General Public License v3.0
171 stars 56 forks source link

RS92 PTU #32

Closed rs1729 closed 3 years ago

rs1729 commented 3 years ago

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 https://github.com/rs1729/RS/commit/2453b799a9ffd5bcadc424d5f28351871eb86353 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 commented 3 years ago

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

rs1729 commented 3 years ago

RS92-NGP calib-data and PTU seems to be xor-obfuscated. https://github.com/rs1729/RS/commit/345f60d24613c41e666bf3a7dab416987072d153

rs1729 commented 3 years ago

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: xor_diff_ngp Though XORing NGP and SGP does not immediately reveal a potential XOR mask: xor_diff_ngp_sgp 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: https://github.com/rs1729/RS/blob/471e023236bbd922cb2eeef949ebbd8d52daf239/rs92/rs92mod_ngp.c#L365-L418

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.