Topic: Wind Speed Update Interval

[dalecoy]

The reason that I assumed that the transmission was the number or revolutions, was that I thought it would make sense for the console to perform the calculation converting revolutions to wind speed in the chosen units.  One conversion, rather than two (mph to some other units).

Of course, if Davis cleverly designed the anemometer dimensions so that (1 rpm) == (1 mph), then that's zero conversions for mph, which is even better.  And explains why two "different answers" can be identical.

[DeKay]

Would you post a link to the relevant blog reference(s), please?  [I couldn't figure out how to effectively search your blog, and that's my problem, but I'd appreciate the reference(s)]

Here you go.  Hit page down a few times and you'll see a screenshot showing the raw data packet.  I watched the output change perfectly in sync with the console display (not shown).
http://madscientistlabs.blogspot.com/2011/01/davis-weatherlink-software-not-required.html

As you pointed out in another post, the manual mentions the eight byte STRMON output but doesn't describe what the data means.  D'oh.

The suggestions that Davis was clever enough so that counts in the interval translate directly to mph was, well... clever!!!  In that case, we're all in violent agreement

[dalecoy]

Would you post a link to the relevant blog reference(s), please?  [I couldn't figure out how to effectively search your blog, and that's my problem, but I'd appreciate the reference(s)]

Here you go.  Hit page down a few times and you'll see a screenshot showing the raw data packet.  I watched the output change perfectly in sync with the console display (not shown).
http://madscientistlabs.blogspot.com/2011/01/davis-weatherlink-software-not-required.html

Cleverness is good!  Violent agreement is good!  And thanks, johnd, for clearing that up.

And yes, I had seen that blog post and the data packet, but hadn't "seen" the console display (for obvious reasons).

{Question for another day:  What is the effect of the "small wind cup" console setting?}

[Bushman]

Page 20 -  http://www.davisnet.com/support/weather/download/VantageSerialProtocolDocs_v230.pdf

I know about that appnote, but it doesn't contain what is being requested.  It says the packet (shown via STRMON) is:

Example (VantagePro2):
>"STRMON"<LF>
<<LF><CR>"OK"<LF><CR>
<"0 = 81"<LF><CR>
<"1 = 0"<LF><CR>
<"2 = 0"<LF><CR>
<"3 = ff"<LF><CR>
<"4 = c5"<LF><CR>
<"5 = 0"<LF><CR>
<"6 = b7"<LF><CR>
<"7 = 42"<LF><CR><LF><CR> . . .

That doesn't explain the format, beyond illustrating the description of "8 bytes".

Well for example in the LOOP packet at offset 9, size 2, the temperature value is sent as 10th of a degree in F. For example, 795 is returned for 79.5°F.

IX. Data Formats
1. LOOP data format
There are two different loop data formats. Rev "A" firmware, dated before April 24, 2002 uses
the old format. Rev "B" firmware, dated on or after April 24, 2002 uses the new format. The only
difference between these formats is the inclusion of the current 3 hour barometer trend in place
of the fixed value "P" in the fourth byte of the data packet.
Only values read directly from sensors are included in the LOOP packet. Desired values (i.e.,
Dew Point or Wind Chill) must be calculated on the PC. The LOOP packet also contains
information on the current status of all Vantage Alarm conditions, battery status, weather
forecasts, and sunrise and sunset times.

[WxStation]

So since the gating period for the anemometer is 2.25 seconds, do these periods occur back to back so that no time is missed? If so the unit is probably recording a pretty accurate peak wind speed.

[dalecoy]

Well for example in the LOOP packet at offset 9, size 2, the temperature value is sent as 10th of a degree in F. For example, 795 is returned for 79.5°F.

...but that example has nothing to do with the format of the data packet that the ISS sends to the console.

[Quibble:  size 2 and value 795? - yeah, I know that's what the appnote says]

[Bushman]

Well for example in the LOOP packet at offset 9, size 2, the temperature value is sent as 10th of a degree in F. For example, 795 is returned for 79.5°F.

...but that example has nothing to do with the format of the data packet that the ISS sends to the console.

[Quibble:  size 2 and value 795? - yeah, I know that's what the appnote says]

My bad - I was thinking a diff part of the stream.  I can ask my RF engineer since they are decoding that, but I'm not sure it will become public.

And yeah, I saw that bit about the size and value... 

[johnd]

And thanks, johnd, for clearing that up.

Well just to clarify the clarification . I don't know that this is the answer - it just seems quite a plausible solution (but I certainly could be wrong). Davis typically don't reinvent the wheel very often so if they have a sensor architecture that works then it tends to get reused. What it does mean though is that if the gating period is 2.25sec as I'm speculating and the minimum packet period is 2.5sec then roughly every 11th gust gets missed. But maybe that's an acceptable compromise.

I also suspect that the different corrections with eg small wind cups and perhaps E vs W wind directions will only be seen at higher wind speeds. For the experimenters here, if you could mechanically drive the cups at say an accurately-known 32rps (ie 1920rpm) then I would speculate that the data packets might show a wind speed of 72mph, but the console display might show something very slightly different (as the second-order LUT comes into play in the console firmware to perform the improved accuracy corrections). Now there's a prediction that could be proved or disproved with the right test equipment!

[dalecoy]

As a practical (engineering) matter, the inertia of the rotating cup assembly would make a 0.25 second "speed change due to a gust" fairly well within the inherent measurement error, wouldn't it?  It's a 2nd order effect. 

I would agree that it would be a problem if we were actually measuring instantaneous wind speed - but we're measuring the effect of wind on a physical object.  Given that situation, it's equally possible that a wind gust can produce an overspeed of the anemometer assembly that lasts longer than the actual wind gust.  [Think of starting with a non-spinning assembly and tapping a cup with a hammer - the resultant rotation lasts a lot longer than the impulse]

It seems to me that, with a physical (inertial) mechanism;
1.  It's impossible to measure the peak wind gust velocity.
2.  The "measured" duration of a wind gust will exceed the actual duration.

[C5250]

As someone who has monitored the actual ISS raw data via STRMON on the console (and the Davis docs confirm this is the ISS raw data), compared it to the number displayed on the console in real time, grabbed pictures showing this, and posting them to a blog, I can assure you the ISS transmits actual mph and not reed switch counts.  Your bit about interrupts from the wind sensor waking the processor is likely 98.232% correct and in sync with what I'm saying.  But it is the ISS that does the trivial calculation / lookup / whatever to mph just before transmitting the data back to the console.

Being someone who has been deep into the firmware, I'll grant you that the second byte may correlate to wind speed in mph, but that is not what it is.

Here is a snippet from a STRMON capture reformatted so it is easier to read, unlike the crappy Davis formating:

Code: [Select]

c0 02 44 08 73 00 aa 75
84 00 00 16 48 00 a7 27
61 01 fe ff c3 00 01 9a
c5 02 46 08 71 00 62 7e
80 02 0a b8 c3 00 ec 51
57 00 00 ff 75 00 80 1a
e4 00 00 80 05 00 49 36
81 02 f2 ff c1 00 4d 20
e0 02 08 1a 01 00 fd eb
e5 02 f2 1a 01 00 49 0c
67 00 00 ff c5 00 b1 9b
54 00 00 ff 75 00 4e fa
e1 05 b4 80 02 00 8b d7
50 02 fe ff 71 00 fd 0b
55 05 b4 ff 72 00 8a ba
87 00 00 16 cd 00 8d aa
51 04 c7 ff 73 00 cc d2
a4 00 00 66 28 00 41 0d

I have plenty of these...

I'll give you a hint about how to read this, the upper nibble of the first byte is the sensor the data is from, the lower nibble is the transmitter ID. In my case, 0 = ISS, 1 = anemometer transmitter, 4 = temp/hum station, 5 = Envoy retransmitting ISS, 7 = temp/hum station. And the last two bytes are a crc.

And STRMON is the raw station data, it's not the entire radio packet though.

[DeKay]

I can ask my RF engineer since they are decoding that, but I'm not sure it will become public.

That's the spirit!!!  On a happier note...

Being someone who has been deep into the firmware, I'll grant you that the second byte may correlate to wind speed in mph, but that is not what it is.

Any data I've looked at has the correlation at 1:1.  Whatever.  We can agree to disagree thanks to the awesome work you've done below....

Code: [Select]

...
c0 02 44 08 73 00 aa 75
I have plenty of these...

I'll give you a hint about how to read this, the upper nibble of the first byte is the sensor the data is from, the lower nibble is the transmitter ID. In my case, 0 = ISS, 1 = anemometer transmitter, 4 = temp/hum station, 5 = Envoy retransmitting ISS, 7 = temp/hum station. And the last two bytes are a crc.

I am not worthy!

Well, maybe I am.  Here's some data I grabbed tonight with STRMON.

Code: [Select]

0 = 60
1 = 6
2 = d3
3 = ff
4 = c0
5 = 0
6 = 78
7 = 75

Byte 1 is (according to me) wind speed in mph.  That's been discussed.  What I found tonight is that byte 2 (0xd3) is wind direction from 1 to 360 degrees.  Bit of trivia: Davis says that 0 indicates it can't get a reading, so you'd never see wind straight out of the North.

If wind can be in the range of 1 to 360 degrees, how can they fit that in a byte?  The answer is, they cheat.  The byte value is basically scaled by 360 / 255.  So a wind speed reading of 0xd3 = 211 (decimal) * 360 / 255 = 297.  The actual reading on my station at the time was 292 and in several trials, the factor comes out to either 1.38 or 1.39.  Close enough for wind direction.

C2520, have you figured out the mapping of  the upper nibble of the first byte to the sensor type?

[DeKay]

I thought I'd dump some of my working notes from the last couple days in case anyone has some time to dig into interpreting the STRMON output a little further.  These should be read together with the notes from C2520 and myself above.

I'm using a byte numbering of 0 - 7 as per STRMON output.

- Signed values from weather station are two's complement, least significant byte first
- CRCs are MSB first
- Values from the station are in imperial units (fahrenheit, mph, inches Hg)

Update rates below are from Davis' specs and manuals.  Data sizes and signing are as per the loop command and are what I expect out of STRMON.  Probably.  I noted above that wind direction via STRMON is actually one byte unsigned.  There may be other exceptions.
- Outside temp: 10 seconds in 10th of a degree F, two bytes signed
- Winds speed: 2.5 seconds, one byte unsigned  (Byte 1 in STRMON, always)
- Wind direction: 2.5 seconds, two bytes unsigned from 1 to 360  (<-- one byte via STRMON, Byte 2 always)
- Outside humidity: 50 seconds in percent, one byte unsigned
- Rain: 10 seconds.  I believe this will be in counts of 0.01.
- Pressure: in Hg/1000, two bytes unsigned  (Rate????)
- Leaf Wetness: 40 seconds
- Soil Moisture: 40 seconds
- Solar radiation: 50 seconds
- UV: 50 seconds
- Soil Moisture: 62.5 seconds

I think all other outdoor related values are calculated in the console.  Not 100% sure about 10 minute average wind speed though.

Known so far.
- Byte 0 is a header as described by C2520.
- Byte 1 always represents wind speed
- Byte 2 is always wind direction
- Bytes 3-5 will carry other data according to the header in Byte 0
- Bytes 6 and 7 are the checksum

The only headers (ie Byte 0) I see from my wireless VP2 are:

40 50 60 80 90 a0 e0
 
The rates they show up at are:
-40 shows either every 47.5 or 50 seconds
-50 shows every 10 seconds
-60 shows every 50 seconds
-80 shows every 10 seconds
-90 shows either 45, 47.5, or 50 seconds
-a0 shows alternately every 40 seconds and 10 seconds (interesting!)
-e0 shows every 10 seconds

Should be easy to correlate the rates seen above with the expected rates from the manuals to get a good first guess at the content of the data in Bytes 3 - 5.  Anyone who wants to have a go at further decoding, please do and update this thread!