[tobyportugal]

Good evening,

To excuse my question, I do not know well (0/10  ) the WeatherDuino software.

Which is the time (sec) of transmission between the TX/RX?
For you help to understand my question: Davis VP2 transmits to the console the data “wind” all the 2,5sec.

Thank you, good evening.

[werk_ag]

Which is the time (sec) of transmission between the TX/RX?

Wind data is sent each 3 seconds.

[tobyportugal]

Which is the time (sec) of transmission between the TX/RX?

Wind data is sent each 3 seconds.

Hello,

With 3 sec, Ultrasonic seems to me an expenditure unjustified.
A track for the future: - > 1sec 

Good weekend with all

http://www.meteo-la-rochelle.fr/comparai...metres.php

[AllyCat]

Hi,

It's important to remember that 434 MHz is a shared radio frequency, used by many other commercial systems (I have nearly 10).  The typical transmission period for "repetitive" systems (temperature senders, etc.)  is one minute, or much longer for wireless doorbells and garage door openers, etc.  So 3 seconds is already rather fast and 1 second would probably "kill" most of the other available systems, because of all the "collisions" between data packets from different sources.

But of course the "transmission" and "measurement" times do not need to be the same.  The humble "Fine Offset" weather stations transmit only once every 48 seconds, but the data packet contains an "average" wind value (obviously over the 48 seconds period) and a "gust" value, which is the maximum of 24 values measured in two-second intervals. 

I don't know how the Weatherduino data/protocol is organised, but obviously a (separate) "gust" value would allow the transmitter to calculate a (maximum) value over as small a period as desired (or at least practical).

Cheers, Alan.

[werk_ag]

...  So 3 seconds is already rather fast and 1 second would probably "kill" most of the other available systems, because of all the "collisions" between data packets from different sources.

I think you are right, Alan. Besides the possibility to "kill" other existing systems, it also will "kill" WeatherDuino systems that are using two or more TX units.

I don't know how the Weatherduino data/protocol is organised,...

WeatherDuino uses one data packet for each type of data. The data packet with Wind data (which includes Gust, 2 min average speed, 10 min average speed and direction)  is the only one that is sent at each 3 seconds. Rain is sent at each 31 seconds, and the others a little more. The interval between data packets was chose using prime numbers to minimize collisions, which as proven to work very well specially when there is just one transmitter unit. When there is more than one TX unit, obviously the probability of collision increases, but even with four units (maximum allowed) its possible to run a very reliable system, specially because when a user uses more than one TX unit, usually each unit do not send all the types of data packets. Per example, one sends data from instruments that should be placed at above the roof level (as is the case of the anemometers), and the other TX units send data from instruments that usually are placed more near the ground level (as is the case of the rain gauge, and temperature / humidity sensors).

Hope my poor English was enough to make my writing understandable.  

[tobyportugal]

Hello,

Thank you with you two for your explanations, with IMTRANSLATOR I have +/- understood.
The solution passes by one dated logger XD-05.

I will start with the beginning: to make function “normal” WeatherDuino.

Good Sunday.

[werk_ag]

Toby
I think that we are trying to say that for the general purpose of a weather station there is absolutely no need to do gust readings at 1 second intervals.
Some time ago when I started with the WeatherDuino system, I did several experiments to try to determine what should be, or what could be the best interval to do wind gust readings.
Interestingly, I remenber that doing gust readings at intervals of 1 second always produced lower readings (also produced more flat graphics) than when the readings are done at intervals of 2 to 3 seconds.
Anyway, as Alan said, one thing is the "transmission" time another one is the "measurement" time. In the case of WeatherDuino, both are 3 seconds.

[tobyportugal]

Toby
I think that we are trying to say that for the general purpose of a weather station there is absolutely no need to do gust readings at 1 second intervals.
Some time ago when I started with the WeatherDuino system, I did several experiments to try to determine what should be, or what could be the best interval to do wind gust readings.
Interestingly, I remenber that doing gust readings at intervals of 1 second always produced lower readings (also produced more flat graphics) than when the readings are done at intervals of 2 to 3 seconds.
Anyway, as Alan said, one thing is the "transmission" time another one is the "measurement" time. In the case of WeatherDuino, both are 3 seconds.

Yes, I understood and I know standards WMO.
I have a VP2 to standards WMO http://www.infoclimat.fr/observations-me...ghlight=05

The relief at home is particular with winds which come from the valley by going up (it is very particular on the left with 100m or on the right there is more this phenomenon.
If you look at the comparative one on MéteoCaldas, you will see that the direction of the winds at home is often different.
I simply seek to understand this phenomenon at home.

[AllyCat]

Hi,

The data packet with Wind data (which includes Gust, 2 min average speed, 10 min average speed and direction)  is the only one that is sent at each 3 seconds.

So a "user" (Toby) could change the definitions to (perhaps) "fast gust" (1 second or less), "normal gust" and "average" (2 or 10 mins as desired) ?

It doesn't need an Ultrasonic sensor to measure faster gusts:  For example: Measuring the PERIOD of a single rotation of a cup anemometer may be good enough.  Then the Gust (speed) = "Reference distance" / "Time of one revolution (or pulse period)".  The "distance" would be the "circumference of the cup rotor" multiplied by the "Anemometer factor"  (divided by pulses / revolution when necessary).

I don't know enough about the Arduino hardware, nor Weatherduino software, to say if that would be an "easy" or even a "possible" modification to the software.  

The relief at home is particular with winds which come from the valley by going up (it is very particular on the left with 100m or on the right there is more this phenomenon.
If you look at the comparative one on MéteoCaldas, you will see that the direction of the winds at home is often different.
I simply seek to understand this phenomenon at home.

That is rather more difficult.  It is reasonably "easy" to calculate a gust speed over any (short) time and then choose the maximum (fastest) value to transmit (and read) at a more acceptable rate.  

But what is the "maximum" of a wind DIRECTION ?  Theoretically, there is the "Rate of Change of Direction" but most (good) wind vanes are damped to avoid fast swings (see all the complaints about the Fine Offset vanes because they are NOT damped). So for that, perhaps you  DO need an Ultrasonic Sensor !

Cheers,  Alan.

PS: I don't know how well the "Translator" can manage this technical stuff.  Feel free to explain in Portuguese if it helps.

[stefan]

Hey guys,
I occasionaly found your topic discussed here.
We recently developed a cheap ultrasonic anemometer only cost 380 USD/UNIT.
HY-WDC2DVSE Ultrasonic Wind Vane Anemometer
Compatible with Davis Vantage Pro2 Equipment
Our website: www.hongyuv.com/en
My email: stefan@hongyuv.com
Contact me if you have any interest.