dl9rdz / rdz_ttgo_sonde

266 stars 93 forks source link

Burst Timer only ever returns 30600 #179

Closed LukePrior closed 2 years ago

LukePrior commented 2 years ago

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.

image

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

dl9rdz commented 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.

LukePrior commented 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...

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?

LukePrior commented 2 years ago

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.

dl9rdz commented 2 years ago

Yes, that should better be an uint16 instead of an int16. Will change that in the next version.

eben80 commented 2 years ago

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.

image

image

eben80 commented 2 years ago

Ok I saw on last night's data that its also - 1 before the countdown is triggered.

LukePrior commented 2 years ago

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.

LukePrior commented 2 years ago

Hmm, the values sometimes seem slightly off:

image

dl9rdz commented 2 years ago

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).

LukePrior commented 2 years ago

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.

mycarda commented 2 years ago

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.

LukePrior commented 2 years ago

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.

dl9rdz commented 2 years ago

Ok, that makes sense. Tried to implement that in the last commit, but without testing.