i should be able to do some buffering in the driver. that gives me a chance to ensure the packets are in monotonically increasing order.
i should probably dump duplicate packets too. also, the time resolution from taptap is nanoseconds. i trimmed that to microseconds since datetime does not handle nanoseconds (and i don't feel like introducing a pandas or numpy or other massive dependency). that trimming might be causing some of the duplicate packets. so is it ok to post multiple LOOP packets with the same timestamp? i will end up with duplicate timestamps but different data, for example data from panel 1 might arrive with same timestamp as data from panel 5. > On Oct 9, 2025, at 15:17, Tom Keffer <[email protected]> wrote: > > What to do? I see 3 options: > • > The best solution is to make sure the timestamps of the LOOP packets arrive > in monotonically increasing order. I thought we required this somewhere in > the documentation, but if we did, I can't find it. > • Right now, there are two choices when checking a LOOP packet timestamp: > it's either in the accumulator's interval, or it is not. Instead, we would > allow 3 states: if it's before the interval, discard it. If it's in the > interval, incorporate it. If it's after the interval, create a new > accumulator (as described above). > • While the old accumulator is sitting around waiting for the archive delay > passes, we could put it in play and allow the out of sequence packet to be > added to it. This would give a 15 second grace for LOOP packets to catch up. > I'm not keen on this one because it feels ripe for unintended consequences. > Is solution #1 possible? -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/weewx-user/7F58A9A9-A349-4F87-95DB-47ABBF980F94%40gmail.com.
