Tempest'26 technical questions

Tempest Owners
1

These might be questions for @WFsupport or @WFstaff

I was talking to a user who tried the original Tempest when it came out some years ago who returned it due to a couple issues they detected at that time, so I wanted to ask if this was either known or fixed in the current Tempest’26

  • They reported the Tempest did not do frequency hopping and they ran into interference issues as a result. Does it do hopping now ? Have others reported interference issues ?

  • They also reported what looked like queueing of UDP packets waiting for a transmission window (kinda contrary to UDP send and forget)

  • They also reported seeing duplicate UDP packets transmitted

So I suppose in summary:

  • does the Tempest’26 frequency hop ?
  • has anything changed in how the Hub transmits UDP from day one of the original Tempest ?
  • are there any other changes under the hood to mention ?

It’s been a lot of years since we’ve seen engineering-level details in the forums, so I wanted to catch up on what today’s scoop is. Any authoritative info would be greatly appreciated…

update - I’d love to see a teardown howto for the new repleacable battery too…

1 Like
2

Hi Vince!

Thanks for these questions.

Frequency hopping
Different regions (US, UK, CAN, EU, AU) have base frequency regulations set by a governing authority, like the FCC in NA. These rules require consumer RF devices to operate on a specific frequency. Tempest systems shipped are pre-configured to operate on the destination country’s permitted radio frequency. That frequency can be configured and has been configurable. The Hub/Devices have several channels they can operate on, for example, in NA, channels: 902, 906, 908, 910, 912 MHz. The devices will pick clean channel to avoid interference. The Tempest devices have always had this capability.

The Hub uses Direct Sequence Spread Spectrum (DSSS) with listen before transmit to prevent interference. True interference issues have been very rare to come across.

UDP
As for the duplicate UDP packet issue, I’m not sure what to make of that. It sounds like a specific problem or old edge case.

Local data is delivered over UDP Multicast. There are a couple ways one could receive duplicate UDP messages: a station may re-send them if it thinks it needs to, or a network configuration may be causing the packets to be duplicated. Either way, the node server should be able to handle them.

New Sensors in T26
The Tempest 26 is using a new temperature/humidity sensor (SHT40) and haptic rain sensor, the latest versions from the manufacturer. There should be an overall performance and accuracy improvement for those measurements. The haptic sensor will have lighter rain detection capability and more consistency.

Replaceable Battery
We don’t have detailed, public facing instructions on replacing the internal battery but we will soon. It is relatively easy to do, however, it’s not something anyone will have to worry about for a very long time. The Tempest device uses a super long-lasting, rechargeable lithium titanate (LTO) battery that can go through more than 20,000 charge cycles before seeing significant performance degradation, far exceeding the typical lithium-ion batteries found in other products. That said, to further our goals to maximize longevity, the latest Tempest model has been modified so that the internal battery is removeable and replaceable for devices that outlast their battery.

4 Likes
3

Thanks much for the reply. Let me ask some followups please.

Retired engineer here and former Tempest field tester ages ago, so kinda looking for engineering type answers:

UDP

  • When/why would a station 'think it needs to" resend UDP ? That should never ever happen. It’s UDP. You transmit the message and that’s that. If there’s nobody listening for it, not your problem.

    (this is different from storing ‘unsent’ messages in the Hub and sending them later (once) in a catchup scenario when there was a LAN or Internet network issue)

  • Also - “the node server” ??? - what are you referring to there ?

  • Re: queueing ‘unsent’ messages - I recall the sensor queues up unsent messages when it loses RF connectivity to the hub (fine), and also that the hub queues up unsent messages when it loses TCP/IP connectivity to the LAN or WAN.

    Can you refresh my memory - what is the hub’s check for TCP/IP connectivity that it uses for queueing up readings and sending (or resending?) them later ?

Solar Improvements

I forgot to ask earlier…

  • How much solar energy a day (pick a metric - lux hours ?) does the Tempest need to stay charged ?

    When the marketing blurb says ‘bigger solar panels’ can you quantify that ? How much better are the new solar panels in achieving that ?

Battery replacement

I ask more re: the issue with folks having their batteries fail far shorter than the expected number of cycles. This has been pervasive in all WF gear since the earliest pre-release days of all devices dating back to the Indiegogo campaign before the Air/Sky were released.

I’m a bit surprised/disappointed that there is so much marketing blurb about the new gear with zero documentation nor any technical specs re: precision like every other vendor always publishes. Rather surprising

But thanks for the reply for sure !!!

2 Likes
4

Stupid question - Is the solar charge controller also field-replaceable (a FRU in old IBM speak)? It seems to be another common failure point in Tempest v1, and one of mine is among the casualties…

2 Likes
5

No replies to my followup questions nor @vreihen’s followup ?