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