Closed LukePrior closed 2 years ago
Well, autorx calls it "bt" in the json, but it does not include the bt value there, but instead the countdown value cd...
https://github.com/projecthorus/radiosonde_auto_rx/blob/edf32f50078d26dc105e83d556eddd2647f8b13e/demod/mod/rs41mod.c#L1820
fprintf(stdout, "[...], \"bt\": %d, \"batt\": %.2f", [...] gpx->conf_cd, gpx->batt );
cd is s->countKT in my code.
Well, autorx calls it "bt" in the json, but it does not include the bt value there, but instead the countdown value cd...
That explains it sorry for the confusion.
Would you like me to open a PR to change to the uploaded value to countKT?
Is that value also 0 if it has not yet been decoded?
Ok, so it appears that rdzTTGOsonde reports -1 when auto_rx reports 65,535 which I'm guessing is something to do with how the 16-bit value is handled.
Yes, that should better be an uint16 instead of an int16. Will change that in the next version.
Ok, so it appears that rdzTTGOsonde reports -1 when auto_rx reports 65,535 which I'm guessing is something to do with how the 16-bit value is handled.
Doesn't countKT report -1 once the countdown reaches 0?
It's been working OK for me in my data tab and screen displays.
Ok I saw on last night's data that its also - 1 before the countdown is triggered.
I think the latest update should mean that this is now in line with auto_rx and will close this issue once I see some data in SondeHub.
Hmm, the values sometimes seem slightly off:
That is expected to happen.
The counter value is sent only every 51 frames. If the value is not updated, we send the previously captured value. If we have a CRC error on the frame with the counter, we skip an update, so it is possible to lack 51 (or multiples thereof) behind. This behaviour should be consistent with autorx. So even with two autorx (unless I missed something in the code), you might see such situations if one station is receiving a weak signal with crc errors.
My software actually stores the frame number for which the counter was last updated. We could use that to predict the "real" countdown value (as countKT + frame - crefKT).
The counter value is sent only every 51 frames. If the value is not updated, we send the previously captured value. If we have a CRC error on the frame with the counter, we skip on update, so it is possible to lack 51 (or multiples thereof) behind. This behaviour should be consistent with autorx. So even with two autorx (unless I missed something in the code), you might see such situations if one station is receiving a weak signal with crc errors.
That makes sense I will close this issue.
My software actually stores the frame number for which the counter was last updated. We could use that to predict the "real" countdown value (as countKT + frame - crefKT).
Hmmm interesting, but I think it is probably best to only upload what the sonde has sent so we match auto rx.
Hmmm interesting, but I think it is probably best to only upload what the sonde has sent so we match auto rx.
I was thinking the same thing. Do we have to send the value every time or can we just send the value when the corresponding 16 byte subrame block is received? The only issue would be if any of these values span a single 16 byte block but I don't think any of them do.
Do we have to send the value every time or can we just send the value when the corresponding 16 byte subrame block is received?
I think sending it every frame is fine but maybe we can not send it if it has been over 51 frames and we don't have a new value.
Ok, that makes sense. Tried to implement that in the last commit, but without testing.
Hi,
The code I added yesterday to upload burst_timer values to SondeHub works correctly but I believe that the decoded value is incorrect. I have checked SondeHub and the only value ever uploaded by rdzTTGOsonde is 30600 even when the value reported by auto_rx for the same frame is different. This leads me to believe that there is an issue with the decoder.
I believe we get the burst timer value here: https://github.com/dl9rdz/rdz_ttgo_sonde/blob/devel/RX_FSK/src/RS41.cpp#L701 This is how auto_rx calculates it: https://github.com/projecthorus/radiosonde_auto_rx/blob/master/demod/mod/rs41mod.c#L1177