weixin_39758494
weixin_39758494
2020-12-09 14:04

Better handling of RS41-SGM Sondes

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.

该提问来源于开源项目:projecthorus/radiosonde_auto_rx

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

11条回答

  • weixin_39758494 weixin_39758494 5月前

    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?

    点赞 评论 复制链接分享
  • weixin_39758494 weixin_39758494 5月前

    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

    点赞 评论 复制链接分享
  • weixin_39758494 weixin_39758494 5月前

    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.

    点赞 评论 复制链接分享
  • weixin_39758494 weixin_39758494 5月前

    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
    点赞 评论 复制链接分享
  • weixin_39593247 weixin_39593247 5月前

    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

    点赞 评论 复制链接分享
  • weixin_39758494 weixin_39758494 5月前

    Renamed this issue to reflect the need for better handling of RS41-SGMs. This will be fixed in 2 steps: - Updating to a newer upstream demod (the new 'mod' decoders) which will indicate the presence of encrypted telemetry, and - (somehow...) add the frequency of an encrypted sonde to a temporary blacklist, to avoid the scan loop continually re-detecting it.

    点赞 评论 复制链接分享
  • weixin_39758494 weixin_39758494 5月前

    Resolved in https://github.com/projecthorus/radiosonde_auto_rx/releases/tag/v1.0.3

    点赞 评论 复制链接分享
  • weixin_39593247 weixin_39593247 5月前

    Looks like the RS41-SGM can transmit also plain text data without encryption. https://www.fingers-welt.de/phpBB/viewtopic.php?f=14&t=43&start=2950#p272805 After radio silence it transmitted two data sets per frame, then transitioned to normal (live?) mode, one data set per frame. The data set packets are almost like the standard RS41-SG(P) packets. Only the usual 7A2A-PTU packet is now a reduced 7F1B-packet with temperature and humidity (afaik rs41-sgm has no pressure sensor). I have a modified version rs41_sgm.c that seems to work in both worlds, don't know yet how to include this (because of crc-handling of frames that could not be corrected). I guess there won't be many of these unencrypted rs41-sgm transmissions anyway.

    点赞 评论 复制链接分享
  • weixin_39758494 weixin_39758494 5月前

    Probably not worth trying to add it into auto_rx, given their rarity anyway. However, that's really interesting information, and might give away some plaintext information about what's within that encrypted block.

    点赞 评论 复制链接分享
  • weixin_39593247 weixin_39593247 5月前

    The unencrypted version has the packets (7928) [7F1B 7C1E 7D59 7B15] (7620) 7928 and 76xx are not encrypted also in the encrypted version: (7928) [80A7] (762C) Maybe just a coincidence, but the length of the data in [...] is the same: 1B+1E+59+15=A7 But the calibration data in 7928 is missing in the encrypted version, only sub-packet 0x32. Maybe it is transmitted only at the beginning, or it is only known in the base station (the key should not be in the transmitted data as well ...), or it is in the 80A7-packet (don't know if the whole GPS2-7D59-packet is really needed).

    点赞 评论 复制链接分享
  • weixin_39758494 weixin_39758494 5月前

    Interestingly I've just been informed that there will be some unencrypted RS41-SGM's flying near here soon... I'll try and grab some data.

    点赞 评论 复制链接分享

相关推荐