RS41 R-Series No GPS Position

[darksidelemm]

(Duplicating this here from the auto_rx repo)

R-series Vaisala RS41s are being detected, but no GPS data is being extracted.
An audio sample of a sonde that has this issue is here: https://rfhead.net/sondes/brokenrs41.wav
Download and pipe into rs41dm_dft (rs41ecc in auto_rx/) using;
cat brokenrs41.wav | ./rs41ecc
Only the serial number will be shown.

[darksidelemm]

A longer sample is here: https://rfhead.net/sondes/brokenrs41_2.wav
Observations:

• GPS frame CRCs are failing (all 3 of them)
• iTOW and Week number are all over the place.

Did something change in the packet format?! Or are the sondes just broken?

[darksidelemm]

Additional information:
The sonde in the air over Adelaide is now showing a decrementing burst-kill counter. This implies that the sonde has burst, and that the onboard GPS is working correctly.
Additional sample of the sonde on descent here: https://rfhead.net/sondes/brokenrs41_3.wav

[darksidelemm]

Another interesting observation:
On a 'working' radiosonde (sample from a previous launch), we get cal sub-frame 0x32 (which contains the burst/countdown timer values) about once every 50 frames, like so:

[ 7854]  0x32: ec 72 80 00 5b 02 07 00 f9 ff a5 01 1b 79 00 00 [OK] : countdown timer 0x72ec = 29420sec = 490.3min
[ 7905]  0x32: b9 72 80 00 5b 02 07 00 fb 01 a4 01 1b 7c 00 00 [OK] : countdown timer 0x72b9 = 29369sec = 489.5min
[ 7956]  0x32: 86 72 80 00 5b 02 07 00 fd 03 a4 01 1b 7f 00 00 [OK] : countdown timer 0x7286 = 29318sec = 488.6min
[ 8007]  0x32: 53 72 80 00 5b 02 07 00 fe 05 a3 01 1b 82 00 00 [OK] : countdown timer 0x7253 = 29267sec = 487.8min

We usually get the other calibration frames in sequence.

On the above 'broken sonde' sample, we are getting the 0x32 sub-frame with EVERY frame:

[ 6385]  0x32: e5 76 8c 01 5d 02 07 00 f9 f5 bc 01 1b 17 00 00 [OK] : countdown timer 0x76e5 = 30437sec = 507.3min
[ 6387]  0x32: e3 76 8c 01 5d 02 07 00 f9 f5 bc 01 1b 17 00 00 [OK] : countdown timer 0x76e3 = 30435sec = 507.2min
[ 6388]  0x32: e2 76 8c 01 5d 02 07 00 f9 f5 bc 01 1b 17 00 00 [OK] : countdown timer 0x76e2 = 30434sec = 507.2min
[ 6389]  0x32: e1 76 8c 01 5d 02 07 00 f9 f5 bc 01 1b 17 00 00 [OK] : countdown timer 0x76e1 = 30433sec = 507.2min
[ 6390]  0x32: e0 76 8c 01 5d 02 07 00 f9 f5 bc 01 1b 17 00 00 [OK] : countdown timer 0x76e0 = 30432sec = 507.2min
[ 6391]  0x32: df 76 8c 01 5d 02 07 00 f9 f5 bc 01 1b 17 00 00 [OK] : countdown timer 0x76df = 30431sec = 507.2min
[ 6392]  0x32: de 76 8c 01 5d 02 07 00 f9 f5 bc 01 1b 17 00 00 [OK] : countdown timer 0x76de = 30430sec = 507.2min
[ 6393]  0x32: dd 76 8c 01 5d 02 07 00 f9 f5 bc 01 1b 17 00 00 [OK] : countdown timer 0x76dd = 30429sec = 507.1min`

This suggests there may be something very very wrong with the radiosonde.

[darksidelemm]

Further information:
The packets I am seeing contain a 'new' 0x80 frame, containing 167 bytes of data. I haven't seen any reference to this frame type before. This would explain why rs41dm_dft is reporting gibberish GPS data, as it's using hardcoded offsets into the frame, instead of looking for the header and frame length.

Still, this 0x80 frame type appears to be a bit of a mystery!

Got frame type: 79, length: 40, CRC:OK
Got frame type: 80, length: 167, CRC:OK
Got frame type: 76, length: 44, CRC:OK
{'content': '\xf9\x18R0230556\x1a\x00\x00\x03\x00\x03\x13\x00\x00&\x00\x0722\xddv\x8c\x01]\x02\x07\x00\xf9\xf5\xbc\x01\x1b\x17\x00\x00', 'crc': '\x90\t', 'type': '79', 'len': 40}
{'content': '\xe0\xf0\x0bE\x0f\xba\xb8.\xa9\x1fK\xc3\xa9\x90\x9d\xa9\x922\n\xf6\xdb\x00q\xa0\xc5pm\x03\xc4\xdcC\xb5.\x1e\xf1\x11tp#g\xea\xd9T`W\x97@\xbd<\xc0vgo\xb69&)\xc1a\xfe\x1fN\xc7\x81v\xca,\xaf\x1aR1\x1e\xe3\xab\x8e\xc0\x92\xbaA7\xa0\xdf\t\xe3\xa6\xdf\xa6\xcdJ\x14\xd0\xc9\xbd}\xa6\xa5\x96\x8cc\x85\xeb\x9c\x08\xbap\x10qV\xd3\x9c<z\x15G\xc8\x19\x8aG\x1b{\xec!\x08\xd3XS\xd7\xcb\x1d\xac-\xf89C\x01\x9d\xb7$R\xc2,y\x1f\xc4\xce-\x10u\xff)\xda<\xf8/\xafG\xa6\x81\x01H\x97\x0bPd\xbc\xff\xa8', 'crc': 'J,', 'type': '80', 'len': 167}
{'content': '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00', 'crc': 'x\x9a', 'type': '76', 'len': 44}

[darksidelemm]

Wait nope - 0x80 frame types are encrypted! https://github.com/bazjo/RS41_Decoding/tree/master/RS41-SGM

Uh oh...

[rs1729]

(projecthorus/radiosonde_auto_rx#157)
Looks like RS41-SGM.

[ 4250] (R0230556) # 7928[0] 80A7[0] 762C[0]
[ 4251] (R0230556) # 7928[0] 80A7[0] 762C[0]
[ 4252] (R0230556) # 7928[0] 80A7[0] 762C[0]
[ 4253] (R0230556) # 7928[0] 80A7[0] 762C[0]
[ 4254] (R0230556) # 7928[0] 80A7[0] 762C[0]
[...]

Encrypted block in 0x80A7. When there is no standard gps-block/pck, the decoder displays only the pck_ids and crc_check (0==OK).

EDIT/remark:
The pck-crc info is only displayed when using the "--crc" option:
./rs41ecc --ecc --crc <audio.wav>

[darksidelemm]

Yep my mistake, you can close this. I wrote a patch on the plane which detects the encrypted packet and prints a warning, and adds a field to the JSON output. Will submit a PR sometime tonight or tomorrow.

…

On Mon., 8 Apr. 2019, 17:15 rs1729, ***@***.***> wrote: (projecthorus/radiosonde_auto_rx#157 <projecthorus/radiosonde_auto_rx#157>) Looks like RS41-SGM. [ 4250] (R0230556) # 7928[0] 80A7[0] 762C[0] [ 4251] (R0230556) # 7928[0] 80A7[0] 762C[0] [ 4252] (R0230556) # 7928[0] 80A7[0] 762C[0] [ 4253] (R0230556) # 7928[0] 80A7[0] 762C[0] [ 4254] (R0230556) # 7928[0] 80A7[0] 762C[0] [...] Encrypted block in 0x80A7. When there is no standard gps-block/pck, the decoder displays only the pck_ids and crc_check (0==OK). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_fk5CcWEFlJIUs67uKbO8DbCODq1zOks5veuySgaJpZM4chHBc> .

[rs1729]

https://github.com/rs1729/RS/blob/master/demod/rs41dm_dft.c#L1140
Didn't mention RS41-SGM, 'cause it's encrypted...