# Repeat Air UDP packets?

**URL:** <https://community.tempest.earth/t/repeat-air-udp-packets/447>\
**Category:** Developers\
**Created:** [February 18, 2018, 7:50pm UTC](https://community.tempest.earth/t/repeat-air-udp-packets/447 "2018-02-18T19:50:21Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![vreihen](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tempest.earth/vreihen/32/13217_2.png) [@vreihen](https://community.tempest.earth/u/vreihen)\
**Post date:** [February 18, 2018, 7:50pm UTC](https://community.tempest.earth/t/repeat-air-udp-packets/447/1 "2018-02-18T19:50:21Z")

</div>

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…

---

<div class="post-metadata">

**Author:** ![GaryFunk](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tempest.earth/garyfunk/32/5729_2.png) [@GaryFunk](https://community.tempest.earth/u/GaryFunk)\
**Post date:** [February 18, 2018, 8:16pm UTC](https://community.tempest.earth/t/repeat-air-udp-packets/447/2 "2018-02-18T20:16:08Z")

</div>

> [@vreihen](#):
>
> 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.

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](https://play.google.com/store/apps/details?id=jp.gr.java_conf.tcp_udp_testtool)