Topic: Davis VP2 anemometer wind speed curve

[DeKay]

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

windDirection = 9 + windByte * 342 / 255

This is what happens when I do this stuff without enough sleep.

[rdsman]

It would be interesting to see what the minimum raw direction (not 0) value that the VP2 ISS sends out.  It appears to be 0x02 for the Vue ISS, which displays a Wind Direction of 4 on the console.  Here are some other samples:

0x05 = 8.
0x06 = 9.
0x07 = 11.

0x1C alternates between 39 and 40.
0x27 alternates between 55 and 56.

Both 0xD6 and 0xD7 = 302.

Just something to ponder..........

[kobuki]

I think I've already mentioned it more than once, but the transmitted min/max values I observed while playing around with the vane were 1 and 255 (omitting 0). Translating them to degrees is a different matter, per se.

[LABob]

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.

If I was designing a system like the Davis and one of my design constraints was transmitting a 9-bit value (rounding up bits need to represent 0-359) using only 8-bits of data, I might consider transmitting two types of packets serially. If you use one bit of each packet to mark whether it's the first or second packet in a pair, you could use the remaining 14 bits to transmit the data easily with room for some ECC if you wanted.

Having said that, I have no idea how the Davis does it but I hadn't seen anyone mention tht possibility in this thread.

EDIT - I should clarify that I didn't mean bursting two packets, but rather sending each packet during the regular scheduled transmission from the ISS. That would give the appearance of a moving average, but is subtly different.

[johnd]

If I was designing a system like the Davis and one of my design constraints was transmitting a 9-bit value (rounding up bits need to represent 0-359) using only 8-bits of data, I might consider transmitting two types of packets serially.

That might be worth it if you had some sort of super high-precision mechanism and mounting whereby you could guarantee that the combination of intrinsic sensor error and mounting accuracy was <1 degree. But in practice (and as per higher up the thread) you're lucky in practice to reach an accuracy of 10 degrees. So a single byte actually suffices with plenty of room to spare.

[kobuki]

That might be worth it if you had some sort of super high-precision mechanism and mounting whereby you could guarantee that the combination of intrinsic sensor error and mounting accuracy was <1 degree. But in practice (and as per higher up the thread) you're lucky in practice to reach an accuracy of 10 degrees. So a single byte actually suffices with plenty of room to spare.

This made me wonder. For a professional installation, how much precision can you achieve while aligning the vane to north? And how?

[LABob]

That might be worth it if you had some sort of super high-precision mechanism and mounting whereby you could guarantee that the combination of intrinsic sensor error and mounting accuracy was <1 degree. But in practice (and as per higher up the thread) you're lucky in practice to reach an accuracy of 10 degrees. So a single byte actually suffices with plenty of room to spare.

10 degrees is huge. You can eyeball the direction of the mount to better than 10 degrees. I know mine's a little off because I used a plumb bob to line up Polaris and the mast from about 50 feet away and then used binoculars to check the alignment of the mount, but if someone wanted to get crazy and break out a surveyor's transit or something you could get pretty danged close. Of course after learning of the gap at the north end and the fudging of the measurement I see that there's no reason to bother.

[johnd]

OK, it does depend on how much time and effort you're prepared to go to I agree. And if you had a large scale map that indicated some suitable object around due North that you can use as a reference then that would obviously help too. I guess you could use the arm shadow at solar noon as a reference too.

But if you've got the anemometer up on top of a pole 5-10m high then you're a better man than me if you can eyeball the arm direction to much better than 10 degrees. In practice, most users don't even know whether they should be using magnetic or true North as a reference. And in practice too, it doesn't make a huge difference to weather records. Most of the time, all people are interested in is whether the dominant direction in a period was eg NNE or SW or some such compass point.

[kobuki]

OK, it does depend on how much time and effort you're prepared to go to I agree. And if you had a large scale map that indicated some suitable object around due North that you can use as a reference then that would obviously help too. I guess you could use the arm shadow at solar noon as a reference too.

But if you've got the anemometer up on top of a pole 5-10m high then you're a better man than me if you can eyeball the arm direction to much better than 10 degrees. In practice, most users don't even know whether they should be using magnetic or true North as a reference. And in practice too, it doesn't make a huge difference to weather records. Most of the time, all people are interested in is whether the dominant direction in a period was eg NNE or SW or some such compass point.

Yeah. But I was wondering about the installations you do for professional jobs. Anyway what I gathered is that prolly the most accurate is the astronomical approach, then a good compass + current local magnetic declination data. Also, on Google Maps (and prolly on all other online maps) North is aligned with true North. Our street is fairly straight and if at construction the workers took care and were precise, our house walls are perpendicular/parallel to the street line within 1-2° so I can easily measure the direction (difference in angle) to true north on the online map. So I align my vane mast parallel to a wall and compensate for it (+30° in my case). I'd guesstimate 2-3° of error.

Any thoughts?

[W3DRM]

If you have a smart phone, download one of the many GPS applications and use that to tell you almost exactly where true north and magnetic north is. Most of the GPS apps automatically calculate the declination based on your lat/lon readings. This certainly beats trying to figure it out with a map or lot drawings.

[C5250]

There are plenty of magnetic declination calculators online, e.g. http://www.ngdc.noaa.gov/geomag-web/#declination

[rdsman]

DeKay:

When you have a moment, can you look at the lower two bits of radio.DATA[4]?  On the Vue, it is always a 1 or 3.

[DeKay]

DeKay:

When you have a moment, can you look at the lower two bits of radio.DATA[4]?  On the Vue, it is always a 1 or 3.

Are you asking in general or for any particular message type?  I seem to be getting all combinations. The value is bouncing around quite a bit.  I just saw a 0xa8 go by...

[rdsman]

Are you asking in general or for any particular message type?

The message type does not appear to matter.  I'm only interested in knowing if either of the lower two bits change as wind direction is changing.

Thanks......... 

[LABob]

Just to confirm prior observations by others I analyzed over 458,000 wind direction readings recorded over the last year. Despite almost half of a million readings there is not one single recording of the following headings: 1, 2, 3, 4, 6, 7, 8, 352, 353, 354, 356, 357, 358, 359. Meaning there's a gap from 352 - 8 where the only possible values are 355, 0, and 5. This is mildly unfortunate since NNW - NNE winds are pretty common here, and that's where my sensor is "deaf".

[dalecoy]

This is mildly unfortunate since NNW - NNE winds are pretty common here, and that's where my sensor is "deaf".

If that's particularly bothersome, you can adjust the "deaf direction", of course.

[Old Tele man]

This is mildly unfortunate since NNW - NNE winds are pretty common here, and that's where my sensor is "deaf".

If that's particularly bothersome, you can adjust the "deaf direction", of course.

UNANSWERABLE QUESTION: ...but, *WHY* must the purchaser "compensate" for the manufacturer's SHORT COMINGS with a supposedly 'professional' product?

[mmuc]

...there is not one single recording of the following headings: 1, 2, 3, 4, 6, 7, 8, 352, 353, 354, 356, 357, 358, 359.  Meaning there's a gap from 352 - 8 where the only possible values are 355, 0, and 5.

So if viewing your data as "bins", one would expect the 355, 0, and 5 bins to have about 4 or 5x as many samples as other nearby directions (and maybe the 351 and 9 bins to have 2 or 3x as many).  Do you see that?

This doesn't seem that bad, as the spec sheet of my Vantage Vue says "resolution" of 1 deg but an "accuracy" of 3 deg, and since the gaps you mention (351,355), (355,0), (0,5), and (5,9) are 4, 5, 5, and 4 deg wide, they're only mis-reporting when the "true" value is in those gaps by 2 or 2.5 deg at most.

In other words, if I'm understanding what you all have discovered, the gap in the every-2.5-s STRMON raw-byte-values-converted-to-degrees is (351,9), and with Davis' apparent averaging of consecutive values or however they're getting around this, the gaps are smaller, (though the effective update rate becomes 5 s).

(note, just averaging doesn't quite explain this, as there would be the occasional time when consecutive readings jumped from say 350 to 16 and the average would be 3.  So they may just be averaging and rounding to the nearest of 355, 0, 5.)

[LABob]

There is a large spike in values for 355, 0, and 9. Just what we'd expect if the "true" values were replaced with one of these three.   

[mmuc]

@LABob, Sorry to be pedantic but if everyone's above theorizing is correct, then I think you mean that the 355, 0, and 5 bins (not 9) have more than all the "normal" bins?

Then also 351 and 9 would either be statistically about normal, or could be abnormal but less so.  That would also tell us a wee bit more about how they're doing it.

[kobuki]

There is a large spike in values for 355, 0, and 9. Just what we'd expect if the "true" values were replaced with one of these three.   

Interesting. I'm guessing that they use the earlier angles of the vane for making up these values. So when the vane was previously at somewhere between N-NW, values of 355 would soon appear to be in a local maximum spike. To put it another way, when the ISS sends 0, AKA "on blind spot" value, the last value is repeated by the console until another valid value is transmitted.

[LABob]

@LABob, Sorry to be pedantic but if everyone's above theorizing is correct, then I think you mean that the 355, 0, and 5 bins (not 9) have more than all the "normal" bins?

Yeah, sorry about that. There is something more going on than just the "hole" in the north. Check out this graph I made from those 450,000+ readings:



You would expect a relatively smooth line over time, but instead we see this very jagged line. What's causing this? Upon closer inspection we find that depending on the heading, odd or even headings are recorded more often than the other. For example, between 0 and 20 the odd numbers occur more than twice as often as the even numbers. Between 21 and 46 the even numbers dominate. Between 47 and 70 the odd numbers dominate, and so on. Strange things indeed.

[LABob]

Just brainstorming here: Maybe Davis is doing something like dividing the compass into 16 sections (4 bits), and each section into 16 headings (another 4 bits). When a wind direction is read from the sensor the ISS constructs a one byte representation with 4 bits representing the section and 4 bits representing the heading within that section. Since 16 doesn't fit evenly into the number of headings they report they'd have to fudge a little. The question is what technique are they would use to calculate the numbers such that it would cause odd or even headings to predominate.

One possible way to test this would be to manually control the wind vane see what the ISS is transmitting. If there is a 4 bit nibble that suddenly changes values somewhere around 22°, 46°, and so on, we would know this is indeed what is happening.

[mmuc]

Very amusing seeing the warts on the Davis data.  Maybe mother nature just simply has a superstitious side and genuinely has a preference for odd numbers under 20, even numbers up to 45, and so on.  (ha ha)

To me the jaggedness (and that it shifts in and out of phase i.e. even to odd and back) screams moire effect caused by quantization error, possibly followed by re-scaling and rounding/truncating (something their A to D does, or subsequent scaling/rounding algorithms whether in hardware or firmware)
http://en.wikipedia.org/wiki/Quantization_%28signal_processing%29

In other words, some underlying signal (voltages in the potentiometer, A-to-D, or hardware, or whatever) is quantized to (as you suggest) 16x16 levels, and then needs to get re-quantized (maybe with the same 2-sample averaging step y'all figured from above) to 360 levels (well 360 less the missing ones, so 342).

There is just no way to get 360 (or even 342) unique values into or out of a 1 byte number.  So whatever trick they're doing is not statistically unbiased.  But given their claimed 3 deg accuracy I think we're splitting hairs on the jaggies.  I'd be a little pissed though if I was a real weather scientist or something and had those 355, 0, 5 spikes/gaps in my data.

[mmuc]

Just brainstorming here: Maybe Davis is doing something like dividing the compass into 16 sections (4 bits), and each section into 16 headings (another 4 bits). When a wind direction is read from the sensor the ISS constructs a one byte representation with 4 bits representing the section and 4 bits representing the heading within that section. Since 16 doesn't fit evenly into the number of headings they report they'd have to fudge a little.

Oh, by the way, seems to me, dividing into 16 main headings (the traditional compass rose, 22.5 deg precision) and each of those into 16 finer divisions (1.40625 deg precision) would be the PERFECT way to do it if it weren't for the apparent blind spot problem at north.  Seems to me they could then claim 1.4 deg precision, 0.7 deg accuracy, before any calibration effects.  Instead it seems they're dividing the non-blind section (9, 351) into 256 and getting all these artifacts we're seeing..

(precision vs accuracy... if I'm remembering high school physics... e.g. a digital weight scale, generally you consider your (best case) accuracy to be half of your last digit of precision, unless you know something more from the specifications or you know how the scale was designed and that is has some attribute that makes the accuracy worse, needs calibration to set its zero point, etc.)