Topic: Davis VP2 anemometer wind speed curve

[kobuki]

I want to place my VP2 anemometer on our roof, far and separate from the ISS. There exists a ready-made solution for this purpose from Davis, but since I'm using [this], why not hack an anemometer transmitter as well? Seems simple, since almost all information on the instrument is available, see [here] and [here]. However, according to the second page, the wind speed curve in regards to the cup anemometer RPM is not linear. This is a quick sheet of the RPM vs. mph values and their coefficients (base data taken from the 2nd page):

mph   rpm    coeff
17  7.353   2.3119
34  14.88   2.2849
62  29.76   2.0833
95  52.08   1.8241

(1 m/s = 2.23694 mph for a standard conversion, BTW)

According to the Davis anemometer specs, 1600 rotations in an hour equals to 1 mph of wind speed. That directly translates to 1 rotation/s = 1 m/s wind speed (so it seems to be calibrated to an SI unit, not bad). Now the question is: how to determine the curve? According to [this Wikipedia article], the 3-cup anemometers should be linear with a 3% margin of error. The coefficients above show way higher error figures. I thought of writing a small code for the Arduino that creates pulses, emulating the rotating anemometer, sweeping the wind speed range from 0.5 RPM to 50 RPM, to determine the exact curve coefficients and in turn try to find a fitting curve equation.

Any thoughts?

[Old Tele man]

Divide the MPH reading by the coefficient value (K) to get the RPM number:

RPM = MPH / K ...or, transposing: K = MPH / RPM

...thus:

1) 7.353 rpm = 17 mph / 2.3119
2) 14.88 rpm = 34 mph / 2.2849
3) 29.76 rpm = 62 mph / 2.0833
4) 52.08 rpm = 95 mph / 1.8241

...or, knowing RPM, you can estimate what the coefficient number (K) should be for any given RPM (to reasonable accuracy, R² = 0.9914) using a 2nd-order polynomial trendline:

K = -5E-05·(RPM²) - 0.0083·(RPM) + 2.3914

[kobuki]

Thanks, but the numbers are just samples measured by the creator of my second link in my first post, and I calculated the coefficients from mph/rpm in the table I posted. The nonlinearity of the coefficient is observable this way.

EDIT: just noticed you edited your post. Thanks, I'll look into that equation later, but would you care to tell me how you managed to calculate it?

[Old Tele man]

...by applying a four-point trendline analysis (in MS Excel) to the data, letting: X = rpm(i) and Y = coefficient(i).

Here's how I would approach this task:

1) drive in you car at same/similar speeds as Davis used and record the RPM number for each speed.
2) do TWO runs, one NORTH and one SOUTH (or EAST and WEST, etc.) and average the results (to mitigate ambient winds)
3) divide to get the coefficient number (K) at each speed.
4) then, plug and crank the numbes.

[kobuki]

Ah, I see! After all, Excel does have some useful features

I'm not completely convinced though. I have a hunch that the relation curve is exponential or logarithmical, but I have no proof of anything.

[Yfory]

Expanding on the earlier comment about using the MS Excel program...

If you have access to Microsoft Excel you can enter your data in an Excel spreadsheet and make a simple graph of the data.

Excel has an excellent curve fitting program as a part of the graph options section which can give you a linear, 2nd order, 3rd order etc. best fit line or curve and the corresponding equation on the graph.

I have used this process and it simplifies the curve fitting process. You can then simply enter the best fit equation in the Arduino code. Then run a simulation program to check and verify data output at your known points.

I did this with a Honeywell HIH series humidity sensor and got good results from 20% to 100%. The top of the HIH humidity curve has a non-linear tail...a slowing as the sensor as it approaches 100% which I could include in my code.

But I found, except for minor errors over 96%, the Davis algorithms work very well.

[Old Tele man]

I'm not completely convinced though. I have a hunch that the relation curve is exponential or logarithmical, but I have no proof of anything.

Yes, at slow speeds there's friction losses from the bearings and at high speeds there's turbulence spill-over from the cups. The curve I'm seeing (from your data above) is a horizontal "lazy-S" when a 3rd-order polynomial trendline is assumed:

K = A·(RPM³) + B·(RPM²) + C·(RPM) + D; R² = 1.000

...where:
A =  0.000011
B = -0.001021
C =  0.014846
D =  2.25363

[kobuki]

Thank you guys, lots of useful info and comments!

@Old Tele man: about testing by driving in a car - well, I have already thought of that. But since the SIM trasmits the mph data, for a more "scientific" approach, I'd probably just need to simulate the rotation of the spoons by applying a precise PWM signal to the anemometer input pin, with a varying frequency and a fixed duty cycle that's able to excite the detection circuit/algorithm, and observe the wind figures the SIM is transmitting. I'll see about these approaches.

In your equation for K, what is R²?


@Wtronics: thanks, that's definitely useful to know. I'm only using Excel for basic tasks and haven't really digged into it deeper. By Davis algorithm, you mean the one Old Tele man calculated, or some of your own, maybe an original Davis?

[Old Tele man]

@Old Tele man: about testing by driving in a car - well, I have already thought of that. But since the SIM trasmits the mph data, for a more "scientific" approach, I'd probably just need to simulate the rotation of the spoons by applying a precise PWM signal to the anemometer input pin, with a varying frequency and a fixed duty cycle that's able to excite the detection circuit/algorithm, and observe the wind figures the SIM is transmitting. I'll see about these approaches.

In your equation for K, what is R²?

Oops, I should not have arbitrarily assumed that you had "no electronics knowledge", which is why I suggested the "quick-n-dirty" mechancial (car) approach. Yes, having access to the appropriate electronic equipment (pulse generator, oscilloscope, etc.) is definitely a more precise approach (I'm retired EE).

R² is the Coefficient of Determination (also called "goodness-of-fit"), a mathematically computed value used to describe "how well" the trendline 'equation' is able to match the computed Y-values (from the X-values) to the actual Y-values, with R² = 1 indicating perfect match. It's one of values that the MS Excel Trendline function can display on the graph, if selected.

[LittletonCOwx]

Wait,

17mph equals 7.353 rpm?  That doesn't sound right.  Shouldn't that be rps?

[kobuki]

@Old Tele man: thanks for the explanation.

@LittletonCOwx: yes, sorry, from the start, I should have used rps or rather, frequency.

Based on some additional information I managed to gather, finding a fitting curve probably isn't possible after all. Lookup tables are to be used, and additional interpolation on values in the tables. OTOH, it seems that the newer anemometers for the VP2 (such as mine) are indeed more or less linear, within a margin of error. Davis even issued a calibration lookup table for OEMs. I've also been told that in addition to the values the SIM is transmitting, the console also adjusts the wind values, using another lookup table. They're regularly evaluating and testing their instruments, as it appears. For newer revisions the double lookup might not be necessary, but that isn't clear yet. I'll post more info later if I can.

2 relevant links:
http://www.davis-tr.com/Downloads/Davis_Rzgr_Kepceleri_Karakteristikleri.pdf
http://toolbox.davisnet.com/downloads/weather/Misc/7911_Anemometer/7911%20OEM%20Applications.pdf

[Old Tele man]

Interesting. Notice the similarity of the 2.25 constant in the Davis™ approximation equation:

V = P(2.25/T)...where: V = mph, P = pulses per period, T = time in seconds.

and the D-coefficient constant derived via the 3rd-order polynomial trendline analysis:

D = 2.25363.

[kobuki]

Yes, and the specs for the Davis anemometer state that for a 1 mph readout, the spoons rotate 1600 an hour. That translates to 1 rps = 1 m/s, and 1 m/s = 2.23694 mph (close enough to 2.25). I originally thought that it's just a simple multiplication with some curve corrections, but the posts below and some other info (and actually thinking realistically) got me sidetracked. That's why I started this thread.

See this thread, especially these posts.

Additional confirmation for linearity here.

[Old Tele man]

Have you graphed those (below) data points (ie: coeff vs MPH) so that you could actually "see" their resulting "line"? -- it's not a straight line.

mph  pps   coeff
17  7.353   2.3119
34  14.88   2.2849
62  29.76   2.0833
95  52.08   1.8241

So, the fundamental question becomes: (a) are you wanting an equation for any/all Davis anemometers or (b) are you wanting an equation for a single (ie: calibration) Davis anemometer?

If for ANY/ALL anemometers, then "close-enough" is probably all you can achieve. But, if for a SINGLE anemometer, a trendline "equation" will be most accurate. And, equation variables can be changed (as can lookup tables) when recalibration or sensor replacement occurs. And, although I, personally, prefer equations (if cpu cycle time permits), lookup tables are typically "faster," hence their widespread use.

[kobuki]

Did you graph those (below) data points (ie: coeff vs MPH) so that you could actually "see" their resulting "line"? -- it's certainly not straight.

I did. They're not straight, and I think that was clear from my first post in this thread - that's why I was looking for a curve.

Which probably do not exist, maybe as a coarse approximation (which might or might not be adequate). wxtech (see links in my previous posts) confirmed it with his own measurements. But we don't know what revision of the anemometer he used.

However, Davis has provided calibration data where the error curve looks different. It's similar but the error is nowhere near the difference between first and last rows of the 4-row table. So basically, it's Davis who is claiming linearity by providing a linear equation and an error lookup table, where the error figures are based on actual wind tunnel measurements, relative to the provided, linear calculation. There's a high chance that the newer anemometers are more linear, or in other words, mostly linear with an error. I only want *my* anemometer to provide valid data for me, albeit it might be useful for others with the same anemometer. So I gather information for this model/revision.

About lookup tables: there're 2 main uses in similar scenarios. First is speeding up computation, second is when no mathematical approach exists for the problem or it's not practical. Error values are fairly random, but for the same instrument they are repeatable within a margin of error so small that it does not change results significantly. The error rate is influenced by several factors, like turbulence around the anemometer itself, the mechanical characteristics, the shape of the mast and the cylinder (on newer revisions the lower part of the cylinder is thinner), etc.

Plotting the Actual Wind Speed / Reported Wind Speed (0 deg), you'll see a curve that resembles the 4-row table, but there're dips and spikes that can't really be modeled so a lookup table is to be used instead for the maximum possible precision, using the provided correction values. The error for 0 degs is between 0.86 and 0.93, it's very close to linear in respect to the speed range covered, indeed.

So as anyone can see, there're mainly 2 sets of data that in my eyes, contradict each other. The solution is possibly that the Davis-provided data and the instrument tested by wxtech differ in revision. The later ones are supposedly better.

[kobuki]

K = A·(RPM³) + B·(RPM²) + C·(RPM) + D; R² = 1.000

...where:
A =  0.000011
B = -0.001021
C =  0.014846
D =  2.25363

Old Tele man, could you please help me. I can't for the life of me figure out how you arrived at this equation in Excel. A few hilighted steps will prolly be enough. Thanks.

[Old Tele man]

Here's the step-by-step process for MS Excel 2003:

1) enter the MPH values in first column.
2) enter the PPS values in second column (PPS = old RPM).
3) enter the coefficient K values in third column.
4) select the first two columns and click the "Chart Wizard" function.
5) select the XY (Scatter) chart; click "Finish"
6) MS Excel will popup a graph of PPS vs. MPH (purple outline = X-variables; blue outline = Y-variables)
7) click on one of the plotted points on the graph.
CHART popup will appear, select "add Trendline"
9) select POLYNOMIAL; change ORDER from 2 to 3.
10) in OPTIONS box, select both Display Equation and Display R-squared value...on charts
11) click the purple selection box and move it over onto the K coefficient column
12) the graph will change display to show K vs. PPS.
13) the graph will now display K(Y-variable) vs. PPS (X-variable) along with 3rd order polynomial equation and R-squared value.

[kobuki]

Thanks for the detailed steps. I can't do 11, it just won't allow me to move the purple selection box (nor change its selection rectangle to cover the coeff column). Could you attach your sheet to your explanation? Since it's not an Excel support forum, I suppose we should just keep on track with the original discussion instead of me asking for more help here for this Thanks. BTW, I'm using Excel 2010.

[kobuki]

Alright, here's a quick write-up on my anemometer simulator experiment I've just finished. I wanted to confirm the values the ISS/SIM is transmitting as wind speed. Everything I write here are in regards to my own anemometer model. What I assume is, that it is the newest model available for the VP2, and Davis-supplied OEM integration docs pertain to this model.

What I did know

• figures are trasmitted in mph, calculated from the cups' rps
• Davis issued a simple linear calculation method for translating rps values to mph
• Davis also issued an error correction lookup table for 3 different, perpendicular wind directions

What I wanted to confirm

• Do ISS-transmitted values need some adjustment or error correction, or curve processing?
• The lookup tables don't contain values from mph values 1..19. What about these?

How I executed the experiment

• created a small Arduino sketch, based on DeKay's receiver, to log incoming wind speed, direction and some aux data
• created another sketch and a small breadboard circuit for emulating precise pulses to be sent to the SIM directly

The HW I assembled uses an Arduino-controlled Reed relay in place of the anemometer's Reed tube. I hooked up the wind vane directly to the sim, so I could turn it around and observe if it has any effect or not.

I planned simulating mph values starting from 1 and incrementing by 1 until 160, but it proved to be pointless - it will become obvious why. So I ended up simulating pulses from 1..25 mph by steps of 1 and 5..160 mph by steps of 5.

Results

For both ranges I've tested:

• the transmitted wind figures match exactly the formula provided by Davis, without any corrections: mph = 2.25 * rps
• turning the wind vane around in any angle doesn't affect transmitted values at all
• not strictly a part of the test, but the start and end values do seem to be 0 and 255 for the vane direction

Results and answers

• Yes. They need to be corrected, most probably using the error lookup tables issued by Davis.
• No idea. I will assume that for these small values there is no need for corrections. The anemometer is fairly linear in respect to provided EC values. I might just interpolate to the first EC value available at 20 mph.

Other observations

As it turns out, wind speed error corrections and other processing is done entirely in the console. All the SIM's microcontroller does is count pulses or rps, do a multiplication/rounding and send the product as mph in its radio packet to the console for further processing. This is a clever idea since it's available indoors and with the proper equipment from Davis it's easy to update the firmware and thus increase precision, fix console firmware bugs, etc.

[johnd]

I've always imagined that the ISS has a gating period of 2.25 secs and counts the revs in that period to use as the basis for conversion to a recognised wind speed unit.

[kobuki]

I've always imagined that the ISS has a gating period of 2.25 secs and counts the revs in that period to use as the basis for conversion to a recognised wind speed unit.

Yes. That basically gives the same measurement - actually something like this is what they recommend. But it's not very precise for revolution periods near or above the 2.25 "gating period". Measuring pulse distance/period gives me a speed value for every revolution (nevertheless, averaging on a predefined interval is still a good idea).

[DeKay]

• not strictly a part of the test, but the start and end values do seem to be 0 and 255 for the vane direction

This entire thread is full of awesome, but I'm hoping you might be able to dig a little more into the above, Kobuki.

I had thought the console reported wind direction by scaling the wind direction value by (360*255) but I am not sure this is right anymore.  I was seeing some deltas between my code and the console reading, even when the wind was still.  Either there is a bug in my code (haven't looked hard at it yet) or my initial assumption is wrong.

Care to dig into this a bit while you've got all this set up?

[kobuki]

This entire thread is full of awesome

Thanks (In the name of the other posters too, I guess.)

Sure, I'll have to dig into it anyway. The vane direction indicator is a linear potentiometer with a blind spot that's bridged with another, ohmically bigger resistor so it never leaves the ADC input floating but the gap remains detectable. So no wonders here, simple to measure with the ADC. Yesterday I tried to turn the vane in all four perpendicular directions and the ISS-transmitted values were spot on in the 0..255 scale, for each direction.

What I can think about in your case is that earlier you might have manually reset/adjusted the straight to North direction on your console. The vane mast is supposed to point straight to North but it can be manually skewed in sw for cases where it wasn't possible.

[Yfory]

DeKay,http://

I am an admirer of your great work in reverse engineering the coding of some systems we need to know more about - thank you for your time and effort!

Here is a very detailed description of the apparently two Davis wind sensors.

http://www.lexingtonwx.com/anemometer

The first output is the speed which has been well covered here.

The second and separate output is the wind direction. From the very limited schematics I see, it appears that the direction is a full output in itself probably a 0 to 255 value depending an where you are coding your adapted program from in the sensor to console output chain. The coding equation, assuming an 8 bit ADC in the chain, seems to be a basic

Wind direction in degrees = (360/255)*(direction output value)........"direction output value" being 0 to 255 as an ISS input to the console.

The full schematic is clearly not available so this is just a guess - but it might be a good starting point.

[kobuki]

Wtronics, sorry if it sounds a bit harsh, but please pay a little more attention to what I post here. This page you linked was one of the first links I posted. It proved to be a great help on my quest to RE my anemometer and inspired me to execute my own tests, but as it stands the one tested on that page is an old variant, and it appears as the calculations are not correct any more for wind speed, at least for the anemometer revision I use, and probably all new revisions.

The wind direction is a different matter. It should be as simple as taking a sample with an ADC on the pot used as a voltage divider, but there are a few problems, at least in my case. There's a "blind" gap on the pot at North and it causes about +-5..6 degrees, in total about 10-11 degrees of values lost. The ISS treats that range as 0° and sends 0 in its radio packets. When the pot is in the blind range, the vane electronics is supposed to pull the output pin to Vcc via a 909k resistor, but my MCU (an ATmega32u4 in an Arduino Leonardo) sees it as floating and the Arduino framework returns with noise when the vane is in that state.

Now I'm trying do devise a method to alleviate this problem and detect when the pot output is floating. I'd be glad if someone could come advise some simple solution, although I'm aware that this isn't an electronics support forum