Topic: Davis VP2 anemometer wind speed curve

[Yfory]

I looked at the circuit and saw the mechanical issues with the pot as it passed over the zero point of the pot. Your point is very good one and that is the effect of a gap at the crossover point if there are erroneous values output to the console.

I am trying to help anyone who is interested in the wind speed and direction and I did not see your post referencing the article we have both looked at. I found the article a very good starting point for basic information on the wind speed and direction as Davis handles the electronics and mechanics. If this seems to be a repeat of information, I apologize!

Davis has kept costs down with this simple and excellent, low cost solution but the basic mechanics are a problem. Davis has solved the problem, probably within their coding at the pot zero point including the problem of a possible loss of a signal. Since most pots become dirty or noisy and even skip areas over time, the loss of a signal at any point on the pot could be a problem so it seems clear that this issue has been addressed by Davis most likely by value checking, value variation checks, and value limits in the console code.

[kobuki]

Well, no prob, thanks for trying to help. I figured a simple method for the gap detection in the meantime. It's not perfect, but for the required precision it's more than adequate and I'm still refining it. I'll make a short writeup in one of the next few days, if anyone's interested.

Just an honest remark. Using a pot for the wind vane direction in this time and age... What about hall-effect rotary encoders, Davis? Digital output, no gap, and a lot better precision. Yes, like 1$ more (or maybe even cheaper than a pot), but this anemometer is not the cheapest on the enthusiast/prosumer/smb market as it is.

[DeKay]

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!

Thanks!

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

That looks strangly like something another guy wrote.  Ah, here it is...

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.

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.

Good find!  And guess what?  There is a hack in my Github code that takes the value I calculated and fudges the value by seven degrees.  This was on a day it was dead calm and the direction was near North.  Then I saw the next day when it was again calm and the reading was way out again with my code vs. the console.  IIRC, it was also calm but the direction was on the other side of North.

Somebody sometime should ask Davis how they can quote an accuracy spec on wind direction of three degrees.

Just an honest remark. Using a pot for the wind vane direction in this time and age... What about hall-effect rotary encoders, Davis? Digital output, no gap, and a lot better precision. Yes, like 1$ more...

Well, they charge around $169 for a datalogger that has a $1 memory chip and a few other bits and pieces, so do the math   

[kobuki]

DeKay, yeah, I saw that correction in your code. It's probably not enough in itself. Concluding my wind vane tests, I could say the following:

- values sent by the iss are in the range of 0 to 255, representing the starting and the ending edges of the measuring potmeter
- there's about 10-11 degrees of a blind spot at Norh, with straight North sitting approximately in the middle of the spot, between the end and the start of the pot (or between max. resistance and zero resistance)
- the blind spot starts after the position of the transmitted value of 255 and ends before the transmitted value of 1
- zero values sent by the ISS indicate that the pot's on the blind spot

As ugly as it sounds. Doesn't it sound like something's defective in my unit? Well, I'm afraid it's not the case, it's by design.

DeKay, do you think it would be possible to determine the edges of the blind gap, using the info above? I have no console so I can't look at the translated values. Maybe you could have a look at it sometime? For the time being I'll just assume +-5 degrees, but I'd like to have some more precise figures.

OTOH, now I have almost all info for creating my own transmitter. Besides stuff above, all I miss is the wind speed correction values < 20 mph and a lot of testing...

[mcrossley]

Possibly (350/255)*val+5 ?

[kobuki]

Possibly (350/255)*val+5 ?

Possibly. The question is not the math, it's just a simple scaling of the values. I'd like to know what the code in the console translates them into at the extremes of the pot. DeKay used a correction value of 7, for some reason, +-5 is just an assumption on my part.

[DeKay]

Possibly (350/255)*val+5 ?

Possibly. The question is not the math, it's just a simple scaling of the values. I'd like to know what the code in the console translates them into at the extremes of the pot. DeKay used a correction value of 7, for some reason, +-5 is just an assumption on my part.

Heh.  My "some reason" was a two second hack to get my number to agree with that of the console, having no real understanding of the vane's dead zone at the time.

It sounds like at some point, I'm going to have to go outside and swing my wind vane around while My Lovely Wife sits inside where it is warm and scribbles down two sets of numbers: the raw value from the ISS and that displayed on the console.  Figuring out the correlation from there is easy.  It is bound to look similar to what mcrossley has written.

Having said that, this is something I'd be more than happy if someone else wanted to dive in to.  I have more than enough to keep me busy (clock chip, proper archiving, my day job, etc).  That and it is -10C here right now.  Anybody that can get STRMON data out of their console is welcome to contribute!!!

[kobuki]

It sounds like at some point, I'm going to have to go outside and swing my wind vane around while My Lovely Wife sits inside where it is warm and scribbles down two sets of numbers: the raw value from the ISS and that displayed on the console.

No need. You can just log the raw data with your receiver while having the console hooked up to Cumulus or some serial logger so you can inspect LOOP packets. For timestamping serial logs I use kitty, a fork of putty.

But man, -10°C... It was 15+ °C (60+ °F) here almost all day

[kobuki]

Spec for the pot

Yeah, read that. It says:

Effective Electrical Angle ..................... 340 ° +3 °

But visually inspecting/measuring the vane angle it's much better than that. I guess this is the tolerance value. Plus when the brush/wiper hops on rail/off rail, there's a sudden spike in the readings. Sucks but can be handled in software. In practice it should not cause problems though.

When the slider is out of contact the 909K resistor will define the output voltage.

As I previously noted, I wasn't able to get a clear readout at the dead gap (rather, just random noise), so I had to invent some tricks. With a better ADC I wouldn't need that, I guess.

[kobuki]

Possibly (350/255)*val+5 ?

Possibly. The question is not the math, it's just a simple scaling of the values. I'd like to know what the code in the console translates them into at the extremes of the pot. DeKay used a correction value of 7, for some reason, +-5 is just an assumption on my part.

BTW, I settled on:

Code: [Select]

    val = POT_GAP_DEGREES - 1 + (361 - 2 * POT_GAP_DEGREES) * rawVal / 255;
Where POT_GAP_DEGREES is 5 (+/-), currently.

incoming raw value == 0 OR gap detected -> output 0
otherwise -> output according to the above figure

Value scales nicely from 5 to 355, sticking to zero at the gap. Let's hope the prevailing wind direction is not North.

[johnd]

Don't forget that there have been different anemometer revisions over the years. Unless you're definitely using a recent example for testing, there may be differences from the latest published specs.

One other thought: In practice, it's quite tricky for most amateurs to align an anemometer arm to North to better than say 10 degrees (if that), especially when it's at the top of a tall mast. So while I'd never question anyone trying to get readings as accurate as is reasonably practicable, there's not going to be much real benefit from trying hard to achieve a precision of eg 1-2 degrees in reading the pot when the accuracy may be limited to eg 10 degrees for other reasons.

[kobuki]

I've no reason to doubt lexingtonwx's schematic which shows that the 909K should pull the output up to the supply voltage when the slider is off the track so it's surprising to read that you are getting noise rather than 255 in the gap. Maybe you should put an ohmmeter on there and verify the connections? Or maybe your A/D input is too low impedance relative to 909K?

Right, I tested things with the 909k resistor in mind. Just to make sure I've measured the gap resistance a few mins ago after I read your post and it's indeed there. My AVR has a minimum impedance requirement on its ADC of about 20k for a source so probably this is the problem. (You can get away with a lot more but 909k apparently won't cut it.)

[kobuki]

Don't forget that there have been different anemometer revisions over the years. Unless you're definitely using a recent example for testing, there may be differences from the latest published specs.

One other thought: In practice, it's quite tricky for most amateurs to align an anemometer arm to North to better than say 10 degrees (if that), especially when it's at the top of a tall mast. So while I'd never question anyone trying to get readings as accurate as is reasonably practicable, there's not going to be much real benefit from trying hard to achieve a precision of eg 1-2 degrees in reading the pot when the accuracy may be limited to eg 10 degrees for other reasons.

I completely agree. Though, I kinda do this for fun, and aimed to be a maximalist in discovering all the equipment paramters as accurately as possible. Finding good and accurate information on the HW allows less room for errors for making my transmitter.

[kobuki]

Right, can't expect much precision if you are going from a 20K pot directly into a sampling input like the AVR A capacitor at the input might help in the evaluation phase when you are manually positioning the vane. Assuming you give it a little time to settle between measurements the added cap would charge up to the pot voltage and then help to supply the current spike that the input will slurp to charge its own sampling cap. Questionable whether it would help in the real world measurement though, what you really need is a simple op amp buffer.

Actually, I have no problems sampling the 20k pot in any position. It's the 909k R causing headaches. What I did is that I put a 47k (arbitrary, this looked OK for the purpose) R in series with the swiper wire of 20k pot. I power the anemometer assembly through the 47k, read a sample, then power it normally and read another sample (this latter is the "real" value). With some juggling with the readouts it's easy to tell when the swipe is in the blind zone. I use 2 digital pins for the 2 different Vcc inputs. This is a hack but works with a sigle additional resistor. (I hope I succeeded in explaining what I did without schematics.)

[kobuki]

I'd like to ask a little more help from someone with a standalone anemometer transmitter and computer connection to the console. Would it be possible to start an STRMON and log like 1-2 minutes of its output? I'd like to see what sort of packets it's transmitting from the standalone wind station. Obviously it shouldn't transmit all kinds of packets of which there're like 8 different types.

[johnd]

An anemometer transmitter is no different to a standard ISS transmitter. So it's certainly got the capability to transmit all types of ISS data packet. You don't configure it to behave simply as a wind transmitter - it just follows its default behaviour.

The only question is whether the SIM board circuitry is cute enough to sense which sensors are actually plugged in and only to transmit packets relevant to those particular  fitted sensors. I doubt this is what happens - since each transmitter will be operating on a separate channel, I would guess that packets for non-fitted sensors are still generated and transmitted but just ignored at the console. But certainly I could be wrong about this.

[kobuki]

Thanks for the info, John. The standalone anemometer transmitter being the same model confirmed my suspicion that it's probably sending all types of packets with default values. In fact, when I unplug everything from the normal ISS SIM, it continues to send all the packets with zeroes/0xff (depending on sensor type) in place of valid values. I'll stick with this for now.

[C5250]

The SIM board in an ISS, anemometer transmitter, temp station or temp/hum station are all the same board and transmit the same packets. It's left to the receiver to sort out what is valid data.

[mcrossley]

I just ran a quick select on my SQL database to extract the 10 minute snapshots of the wind bearings recorded by station since the middle of last year. It clearly shows the 'gap' at North, however it does contain 346 different reading values in the database (excluding zero, which Cumulus records for calm).

So there no values between 351 and 009, except for two oddities are 355 and 005.

The following other values are 'missing': 025, 028, - EDIT: That was from a smaller sample, ignore!

Taking out the 9, 355, 360 values, that gives 343 'continuous' values between 009 and 351, how does it do that with only a single byte of data?

Code: [Select]

Dir Count(*)
5 490
9 183
10 117
11 157
12 65
13 142
14 81
15 129
16 47
17 133
18 83
19 146
20 43
21 87
22 136
23 46
24 131
25 78
26 120
27 36
28 98
29 69
30 109
31 43
32 130
33 97
34 108
35 34
36 131
37 74
38 99
39 26
40 87
41 74
42 83
43 27
44 96
45 95
46 103
47 30
48 70
49 80
50 31
51 86
52 61
53 77
54 27
55 78
56 56
57 58
58 23
59 79
60 51
61 72
62 17
63 65
64 51
65 65
66 21
67 89
68 50
69 80
70 25
71 69
72 41
73 27
74 56
75 36
76 84
77 35
78 84
79 48
80 80
81 29
82 80
83 57
84 95
85 31
86 96
87 73
88 127
89 39
90 133
91 64
92 109
93 50
94 124
95 76
96 146
97 65
98 149
99 83
100 51
101 144
102 93
103 148
104 53
105 133
106 119
107 156
108 50
109 143
110 114
111 169
112 68
113 151
114 84
115 181
116 47
117 137
118 105
119 137
120 58
121 159
122 99
123 187
124 66
125 91
126 167
127 66
128 156
129 108
130 160
131 58
132 162
133 92
134 157
135 56
136 142
137 95
138 146
139 71
140 154
141 82
142 141
143 56
144 152
145 81
146 169
147 76
148 143
149 100
150 172
151 58
152 117
153 179
154 73
155 210
156 114
157 219
158 84
159 267
160 127
161 259
162 106
163 318
164 179
165 326
166 134
167 347
168 234
169 417
170 195
171 426
172 262
173 486
174 216
175 565
176 284
177 230
178 582
179 329
180 627
181 258
182 669
183 357
184 687
185 345
186 707
187 418
188 656
189 337
190 769
191 456
192 807
193 322
194 820
195 507
196 740
197 320
198 779
199 501
200 789
201 354
202 797
203 436
204 308
205 697
206 422
207 736
208 309
209 739
210 404
211 714
212 297
213 621
214 368
215 639
216 268
217 672
218 335
219 614
220 250
221 620
222 290
223 578
224 261
225 542
226 295
227 503
228 219
229 484
230 345
231 207
232 396
233 235
234 474
235 184
236 390
237 188
238 378
239 187
240 302
241 155
242 280
243 131
244 269
245 142
246 245
247 118
248 225
249 128
250 241
251 92
252 227
253 117
254 187
255 85
256 102
257 203
258 88
259 213
260 108
261 200
262 96
263 193
264 124
265 202
266 98
267 195
268 106
269 194
270 108
271 207
272 114
273 165
274 76
275 169
276 92
277 165
278 91
279 202
280 111
281 152
282 60
283 116
284 186
285 75
286 161
287 100
288 170
289 57
290 185
291 117
292 215
293 70
294 183
295 104
296 197
297 67
298 174
299 119
300 155
301 69
302 168
303 108
304 204
305 55
306 213
307 102
308 65
309 187
310 131
311 177
312 68
313 209
314 103
315 272
316 80
317 179
318 118
319 202
320 70
321 225
322 109
323 220
324 85
325 200
326 142
327 221
328 81
329 203
330 106
331 216
332 74
333 181
334 121
335 61
336 204
337 197
338 185
339 72
340 191
341 122
342 230
343 75
344 221
345 107
346 201
347 69
348 187
349 113
350 192
351 77
355 745
360 723[/size]

[kobuki]

The SIM board in an ISS, anemometer transmitter, temp station or temp/hum station are all the same board and transmit the same packets. It's left to the receiver to sort out what is valid data.

Thanks for the confirmation!

[kobuki]

I just ran a quick select on my SQL database to extract the 10 minute snapshots of the wind bearings recorded by station since the middle of last year. It clearly shows the 'gap' at North, however it does contain 346 different reading values in the database (excluding zero, which Cumulus records for calm).

So there no values between 351 and 009, except for two oddities are 355 and 005.

The following other values are 'missing': 025, 028,

Taking out the 9, 355, 360 values, that gives 343 'continuous' values between 009 and 351, how does it do that with only a single byte of data?

Thanks for looking into this, the data is very useful. I think the console (or the software inserting into the DB) averages several values over a sliding window or simple back-to-back windows so it can produce more than 255 different non-zero values.

About the values near North: odd, indeed. I think there's some uncertainty in Davis' handling of the blind gap too.

[mcrossley]

Thanks for looking into this, the data is very useful. I think the console (or the software inserting into the DB) averages several values over a sliding window or simple back-to-back windows so it can produce more than 255 different non-zero values.

About the values near North: odd, indeed. I think there's some uncertainty in Davis' handling of the blind gap too.

Ah, yes! The dead band is from 351 - 009. So if the console averages over the last two readings, you can also get the two 'odd' readings.
(351+360)/2 = 355 [rounded down] and (0+9)/2 = 5 [rounded up]

[DeKay]

So there no values between 351 and 009,

Cool.  So assuming a straight line fit:
y1 = 9, x1 = 1 and y2 = 351, x2 = 255

windDirection = windByte * 1.346456693 + 7.653543307

is giving great results for winds around 55 to 76 degrees right now.  I am either bang on or off by a single degree.  Probably a delta in two different floating point / rounding implementations or just another cheat by Davis to simplify the algorithm.

And in playing with this, I've discovered my wind vane is almost completely seized up 

[mcrossley]

I am either bang on or off by a single degree.  Probably a delta in two different floating point / rounding implementations or just another cheat by Davis to simplify the algorithm.

And in playing with this, I've discovered my wind vane is almost completely seized up 

Is that with a 'static' vane (or at least one that isn't moving much)? Your straight line fit will have gap values that Davis seem to filling with a rolling two reading average. It would be interesting if someone could test that theory by either simulating a vane moving between two positions, or tying to manually move one back and forth every sample period.

Actually thinking about this as I peck away on a tablet keyboard, it cannot be that simple. The single fill in values in the dead zone (5 and 355) mean that they are only generated by averaging adjacent readings. If it were otherwise then all the dead band would be filled with values albeit with lower bin counts.

My data only contains about 68,000 samples, heavily skewed to our prevailing SSW winds. I'll try plotting it later and see if the missing values that have been filled in are visually obvious.

[kobuki]

Cool.  So assuming a straight line fit:
y1 = 9, x1 = 1 and y2 = 351, x2 = 255

windDirection = windByte * 1.346456693 + 7.653543307

Well, instead of floating point magical constants, I'd suggest the usual integer formula:

windDirection = 9 + windByte * 342 / 255

Which, of course, contains yet another 2 magical constants but they're in an easier to comprehend direct relation to the wind byte value - and they can be made #defines.

OTOH, I'm a bit disappointed in this whole thing. I observed a few degrees less error at the North position of the vane (at around 6° max). Davis seems to just assume the factory tolerance of the part which is 240 degrees, and pretty much aligns with these computation figures and mcrossley's collected data.

EDIT: I've just realized that the figure above is essentially the same I devised earlier, using the POT_GAP_DEGREES define, but with a value of 9.