UDP rapid_wind Event Messages Guaranteed Every ~3 Seconds?

Are Tempest UDP rapid_wind event messages guaranteed to occur around every three seconds (as long as the unit is in Mode 0 (i.e. Voltage >= 2.455 V)? On my unit, I have observed that these messages will occasionally not ever get sent for some reason. When I have captured this issue, I have observed that a hub_status message always seems to get sent instead of the rapid_event message.

Is this expected behavior? In other words, is it expected that a rapid_event message might not get sent perhaps when a hub_status message needs to get sent?

I think I have also seen that obs_st event messages may not always get sent. But, I need to do more testing on this. Nevertheless – Are there conditions where an obs_st event message might not get sent over UDP?

Thank you!

I wouldn’t expect anything to be ‘guaranteed’ but my recollection is that if your wifi setup is a little shaky that some UDP messages can be missed if your listener is wifi (given that the Hub is also wifi). Putting your listening computer on wired ethernet usually fixes things.


that’s one of the basic differences between UDP and TCP, the first doesn’t guarantee arrival of a packet, and it doesn’t know by itself that a packet failed. But I don’t know if the hub itself decides sometimes not even to try sending it, which would be a different issue.


Forgot to ask - why does it matter one way or the other ?


Sorry, I guess I really wanted to know the answer to this – Does Tempest’s firmware always intend to send a “rapid_wind” event message as long as the station is in Mode 0?

As for the reason this question is being asked, I am curious 1) if the current firmware is really working as intended, and 2) if my current program is working correctly to listed to udp packets, and 3) if there are any other reasons why this or any other udp packet might be missing.

Wifi shakiness is definitely a possible reason for these missed packets. Currently, I am indeed running my program on a wifi system. Although I can try switching to wired, there is still a risk of wireless interference since as you mentioned the hub is still wifi. But, it is still worth a try.

But…Although I obviously need to do more testing, I still find it extremely coincidental that a “hub_status” event message happened to occur at almost precisely the exact time the “rapid_wind” event message should have occurred!

Yes, I realize this difference between TCP and UDP. In addition to not seeing this packet with my program, I also did not see this packet when capturing all of the network traffic using Wireshark. Although I could be wrong, I thought a packet that was sent but got corrupted in some manner would be seen by a snooping program like Wireshark. But again, I could be wrong in this regard.

As vinceskahan mentioned, wireless interference could be the cause of this missing packet. It would definitely be nice to hear from the tempest developers themselves if there are any other reasons why a packet might not get sent as expected.

My hazy recollection is that when the hub gets busy it sheds lower priority reports of things over UDP but I couldn’t point you to a thread where it was discussed…

Way back even earlier in a different thread I posted something mentioning perceived packet loss and eventually clued into wired/wireless being ‘my’ cause here. Once I went wired for the listener box I was ‘very’ close to 100% of the expected messages per day. Like crazy close to 100%.

That was some number of firmware revisions ago, FWIW.

1 Like

If you are afraid that your software contains an error it is probably best to compare with existing UDP capturing programs to see if those programs also don’t see you missing data.


Yes - As I mentioned in a previous response, I did use Wireshark (which is regarded as one of the best network snoop programs in the industry) to examine this behavior. And, I found that it did not see the packet that my program also did not see. Although this may still not be proof positive of a missing packet (perhaps due to wireless noise interference), it does seem to imply my program is working correctly.

1 Like

Anything that listens is only as good as where it is on the network in comparison to the device it’s listening for.

Third-grade math applies - add up all the message counts from your software and compare it with the theoretical numbers. You should be within a couple/few of the theoretical count over a day or so if your Tempest is powered fully enough.

  • one device_status per minute
  • one hub_status per minute
  • one observation per minute
  • 20 rapid_wind per minute
  • personally I ignored events as they’re not predictable