-
I've used projecthorus/pysondehub to download the history of S3220801 (sondehub --download S3220801 > S3220801.JSON) as that sonde seemed to have failed at 2022-05-30T23:47:31Z (Payerne indeed launched S3231440 twenty minutes later on their backup frequency) and noticed that up to frame-id 4411, both radiosonde_auto_rx and rdzTTGOsonde seem to report consistent packets, but beyond that, only rdzTTGOsonde reports, and apparently "duplicates" of frame-id 4411. And from frame-id 5761, one rdzTTGOsonde instance seems to be repeating "duplicates" of frame-id 4181. I guess that radiosonde_auto_rx does "filtering" that rdzTTGOsonde does not do, that those frames beyond 4411 were really sent by the sonde and really received by those few rdzTTGOsonde. I was just fearing my rdzTTGOsonde had gotten stuck and reporting illegitimate frames. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Interesting observation. The frame# is directly received, it updates only if a new valid frame is received. Also other fields (batt, temp, humidy) change in the frames after #4411, so what is reported are not simply duplicates. It is just that the position (lat/lon/alt) seems "stuck" at the same value. And there are multiple base stations receiving those frames, so it should also not be a single receiver being stuck somehow. Maybe a defect in the RS41 causing it to stop sending its GPS position? My software should not send any frames with invalid (wrong CRC) position subframes to sondehub. But if the RS41 stopped sending position subframes at all, and all subframes in the transmission have a valid CRC, then I assume it can happen that the position is simply not updated in my software (so the last position "sticks" to its value), and as all CRCs alre correct, data is uploaded to sondehub. We would need raw data to check this further.... |
Beta Was this translation helpful? Give feedback.
Interesting observation.
The frame# is directly received, it updates only if a new valid frame is received. Also other fields (batt, temp, humidy) change in the frames after #4411, so what is reported are not simply duplicates. It is just that the position (lat/lon/alt) seems "stuck" at the same value. And there are multiple base stations receiving those frames, so it should also not be a single receiver being stuck somehow.
Maybe a defect in the RS41 causing it to stop sending its GPS position?
My software should not send any frames with invalid (wrong CRC) position subframes to sondehub. But if the RS41 stopped sending position subframes at all, and all subframes in the transmission hav…