Author Topic: Update times from sensors  (Read 114 times)

0 Members and 1 Guest are viewing this topic.

Offline ManPereira

  • Member
  • *
  • Posts: 3
Update times from sensors
« on: May 15, 2018, 11:15:43 AM »

I am looking for an explanation, but till now I do not get a complete answer, ](*,) so here I am asking your comments.
Weather Stations has different interval times for update values from external sensor to internal console i.e. Wind speed, wind direction, rain...
Davis has only 2 seconds between dates, others have more time between updates: 12 seconds, 24 seconds and even more.
My question is:
In case we are using a weather station that has 12 seconds between updates, what happens? In case of wind speed (or wind direction, rain) what sensor sends to console?The biggest value? The last value? Or an average for the values between the 12 seconds time?
Or it sends what is happening in right moment it sends the values to console?
It seems that the values we can have do not help so much because we can have a value that do not represent reality. If it sends a complete reading for all values, a kind of packet / block with all the values it would be great, if not perhaps we need to sacrifice money in order to get a weathersations with the shortest update time...
Perhaps the questions is irrelevant for amateur purpose, however this situation makes me think a lot... I know that Davis are very good and 2 seconds between updates, but very pricey for my purse
Your comments would help a lot in order to make my decision.

Thanks, Manuel

Offline SLOweather

  • Administrator
  • Forecaster
  • *****
  • Posts: 3371
Re: Update times from sensors
« Reply #1 on: May 15, 2018, 02:09:20 PM »
Ah, you have touched on one of the intricacies of weather station design. One of the things i learned long ago is, "Everything is a system", and weather stations are a perfect example of that.

As the system designer, you need to balance things like power system life (solar, batteries and supercaps if the station is not wired), how often it transmits data, the length of the transmitted data, and how often the sensors are read, as well as sensor types, size of the rain gauge cone, diameter of the anemometer or propeller , balance of the wind vane (center of gravity vs: center of rotation vs: center of pressure), and sensor resolution.

You mentioned Davis. Wind speed is the most variable of the various parameters over a short time period. Davis's nominal 2.5 second update time is not so coincidentally the time it takes for one full revolution of the anemometer cup assembly at 1 mile per hour. If you do a little real or thought experiment, you may realize that the theoretical tangential or circumferential velocity of the downwind cup is the same as the wind speed. However, there is aerodynamic friction from the other cups and bearing friction, so you need a correction factor to compensated for that.

I built a larger (diameter and cup size) 3 cup anemometer and its correction factor is almost the same as the the Davis correction factor. In theory, if you could build a perfect  anemometer with a one mile circumference, in a one MPH wind it should turn at one revolution per hour.

If you want to measure slower than 1 mph wind velocities, you can:

1) Make a smaller diameter cup assembly. That gets small fast, and reaches a less than useful size or incurs more loss from less drive force

2) Increase the number of sensors or magnets on the shaft. You probably can't do more than 4 or so without interference. But, that also lessens the sample time and transmit interval, increasing power needs. Some designs I have seen use a chopper wheel and opto sensors but that uses even more power

3) Or, increase the sample time a 5 second sample in the Davis case woudl read down to a half MPF, but that may be approaching the threshold of the cup assembly.

The only other parameter I can think of that might come close to needing a rapid update time is rain. However, to match the Daivs 2.5 second wind time, the rain rate would have to be 14.40 inches per hour.

Wind direction can bobble around pretty quickly, so just update it when the speed is read.

Everything else is treated similarly. Manage the sample interval against the rapidity with which the parameter changes against the power consumption. In Davis's case, I think they buffer the data from things that are sample every 15 seconds or a minute and send a complete data packet every 2.5 seconds. That helps insure against missed transmissions, too. And so rain tips aren't missed, I believe the rain is sent as an incrementing integer which rolls over, and the console keeps track.

In the case of your station, what happens to the date during the 12 second interval is up to the manufacturer. The interval is probably to preserve the battery. Perhaps they read the wind speed more often and send gust data separately or not. Maybe they average it over 12 seconds. You could possibly figure some of that out with experiments on the bench.

In short, you get what you pay for in most instances