Repeat Air UDP packets?

When I started sniffing UDP packets in Python before cobbling together my weewx station driver, I noticed that the Hub was re-transmitting the previous obs_air packet right before the current one. I was not sure at the time if it was a Python buffering error, or if the Air/Hub were intentionally re-sending the last observation in case it was lost in transit a minute earlier. To avoid re-sending the same data to weewx twice, I saved the timestamp of the newest packet in my driver, and throw away anything received that’s older than that (ie, a repeat).

When I was running the sniffer again trying to figure out why the v31 Hub packets were making my driver stop, I noticed that obs_sky packets did not appear to be re-sent like obs_air packets.

Has anyone else observed this? Just trying to figure out if it is a bug, feature, or the result of an Air v17 running for 320+ days without a reboot…

I have never observed this issue in capturing UDP data. If I can help you debug please let me know.

If you use Android I suggest you install this application so you can monitor the data being sent from the Hub.

https://play.google.com/store/apps/details?id=jp.gr.java_conf.tcp_udp_testtool

1 Like