Gust values from LOOP2 packets

[swyman18]

Does anyone happen to know if the Gust value supplied by the Davis LOOP2 packets is definitely supposed to be the peak value for "last 10 minutes", or some other time frame?

The reason I ask is I see gust value behavior similar to the following in my data log file every so often:
Values are mph:

13:19 - 16.0
13:20 - 16.0
13:21 - 18.0
13:22 - 16.0
13:23 - 16.0

Now, I'm assuming that if at some point between 13:20 and 13:21 there was a value of 18.0 mph in the LOOP2 packet, then why would it not continue to provide 18.0 (or higher) for at least the next 10 minutes?

I should say that I haven't really had any trouble with MX capturing the highest gust of the day which is really the most important thing, so what I'm seeing is fairly minor. I'm just curious if I am thinking of this the wrong way or if perhaps my VP2 is supplying strange gust values.

I know also I can turn off the LOOP2 function in the Cumulus.ini which I may do at some point. I'm just curious if any other VP2 users see something similar.

Thanks!

[steve]

That's interesting - I thought I had seen the same thing myself while I was watching the wind gauge, but I forgot to investigate later. The description of the field in the spec is:

Code: Select all

Field            Offset Size Explanation
10-Min Wind Gust  22     2   It is a two-byte unsigned value in 0.1mph resoluation.

I'll check my code, it's quite possible that I've got something wrong.

[steve]

I think my code is OK. As noted previously, the spec is wrong to say that value is in 0.1 mph resolution, it's just the integer value (2 bytes, LSB first). But there does seem to be something odd about what it's doing. I added some extra tracing, and got this:

2015-02-11 09:31:48.996 Loop2: 4C-4F-4F-EC-01-FF-7F-41-75-86-02-39-BB-01-0C-FF-B1-00-80-00-79-00-0F-00-B4-00-FF-7F-FF-7F-27-00-FF-52-FF-2C-00-25-00-25-00-00-00-FF-28-00-00-00-FF-FF-00-00-00-00-00-00-09-00-00-00-02-00-00-FF-FF-30-75-30-75-41-75-FF-06-0B-08-02-0C-04-17-10-02-09-09-FF-7F-FF-7F-FF-7F-FF-7F-FF-7F-FF-7F-0A-0D-DF-4E
2015-02-11 09:31:48.996 10-min gust from loop2: 15
2015-02-11 09:32:22.677 Setting max gust from loop value: 17
2015-02-11 09:32:27.669 Loop2: 4C-4F-4F-EC-01-FF-7F-42-75-88-02-39-BB-01-0F-FF-AE-00-7F-00-76-00-11-00-AE-00-FF-7F-FF-7F-27-00-FF-52-FF-2C-00-25-00-24-00-00-00-FF-21-00-00-00-FF-FF-00-00-00-00-00-00-09-00-00-00-02-00-00-FF-FF-31-75-31-75-42-75-FF-07-0B-08-02-0C-05-17-11-02-09-09-FF-7F-FF-7F-FF-7F-FF-7F-FF-7F-FF-7F-0A-0D-DA-16
2015-02-11 09:32:27.669 10-min gust from loop2: 17
2015-02-11 09:33:05.671 Loop2: 4C-4F-4F-EC-01-FF-7F-42-75-86-02-39-BB-01-0D-FF-B1-00-80-00-7A-00-0F-00-B4-00-FF-7F-FF-7F-27-00-FF-52-FF-2C-00-25-00-24-00-00-00-FF-1E-00-00-00-FF-FF-00-00-00-00-00-00-09-00-00-00-02-00-00-FF-FF-31-75-31-75-42-75-FF-08-0B-08-02-0C-06-17-12-02-09-09-FF-7F-FF-7F-FF-7F-FF-7F-FF-7F-FF-7F-0A-0D-BE-C0
2015-02-11 09:33:05.671 10-min gust from loop2: 15
2015-02-11 09:33:43.642 Loop2: 4C-4F-4F-EC-01-FF-7F-42-75-86-02-39-BB-01-0C-FF-B0-00-80-00-7F-00-0F-00-B4-00-FF-7F-FF-7F-27-00-FF-52-FF-2C-00-25-00-24-00-00-00-FF-1E-00-00-00-FF-FF-00-00-00-00-00-00-09-00-00-00-02-00-00-FF-FF-31-75-31-75-42-75-FF-08-0B-08-02-0C-06-17-12-02-09-09-FF-7F-FF-7F-FF-7F-FF-7F-FF-7F-FF-7F-0A-0D-39-56
2015-02-11 09:33:43.642 10-min gust from loop2: 15

MX reads a LOOP2 packet and sets the 10-minute gust value to the value from the packet. It then reads LOOP packets for about 40 seconds, and if the current 2-second wind speed is higher than the 10-minute max reading, it updates the max gust immediately.

In the trace above, it started with max gust 15 in LOOP2 at 09:31:48, then at 09:32:22 it got a value of 17 from the LOOP packet, and this was confirmed in the next LOOP2 packet at 09:32:27. But the following LOOP2 packet at 09:33:05 had reverted to 15. The max gust should have stayed at 17 or higher until at least 09:42.

Can anyone spot anything obviously wrong with what I'm doing?

[freddie]

Can anyone spot anything obviously wrong with what I'm doing?

I can't see anything wrong with your logic. It is interesting, however, that the documented precision of the speed is out by an order of magnitude. Maybe the same applies for the duration of the period that the gust is derived from - it looks suspiciously like a 1-minute maximum gust to me...

[freddie]

Can anyone spot anything obviously wrong with what I'm doing?

I can't see anything wrong with your logic. It is interesting, however, that the documented precision of the speed is out by an order of magnitude. Maybe the same applies for the duration of the period that the gust is derived from - it looks suspiciously like a 1-minute maximum gust to me...

But - looking at the times in the surrounding packets, it isn't even a minute! Also - looking at the direction of the 10 min gust, this changes from 180 degrees associated with the 15 mph value, to 174 degrees associated with the 17 mph value. It then changes back to 180 degrees when the speed reverts to 15 mph. It's almost as if there is a fault in the logic within the VP.

[steve]

I've sent Davis an email. I haven't had much luck in the past when asking technical questions about the protocol, but we'll see.

It seems very odd that after all this time with other software using LOOP2, that no-one else has noticed this, not even (apparently) the authors.

Could reading the LOOP2 packet reset the value, perhaps?

[freddie]

It seems very odd that after all this time with other software using LOOP2, that no-one else has noticed this, not even (apparently) the authors.

Maybe other software hides it somehow? The example I was thinking of was only updating your representation of the max gust if it exceeded the previous value, if it had still occurred in the past 10 minutes?

Could reading the LOOP2 packet reset the value, perhaps?

I would sincerely hope there wasn't an undocumented side effect of this magnitude! If this was the case, then surely it would be done for every packet?

[steve]

By varying the time between requesting the LOOP2 data, I think I have discounted it being reset - it just seems to be the peak over a very short period of time, less than a minute, as you say. It means I can't just use it on its own, I'll have to keep track of the peak in the last 10 minutes myself (as I do if LOOP2 is unavailable), and yes, use the LOOP2 figure only if it's higher than my calculated figure, just to allow for readings that would otherwise have been missed. I'll hold off on making the changes to see whether Davis get back to me.

[swyman18]

Thanks, Steve for the research and contacting Davis. It'll be interesting to see if you get a response.

It certainly is curious that they haven't caught this themselves somehow.

[swyman18]

Well, just for the heck of it, I put in the LOOP2 disable entry into my Cumulus.ini and already it appears to have missed a daily high gust entry. My console is showing a high just of 22.0 mph at 11:12 HST and MX seems to have not picked it up. I'm going to leave LOOP2 enabled since ultimately it is more important to me to capture that high gust for the day. The 10 min gust "hiccup" I can live with.

Although, it sounds like your coding proposal should work fine. Shame you have to resort to that to overcome the LOOP2 "glitch".

I was always a bit perplexed when people would complain about Cumulus 1 missing high gust readings with Davis stations.. Perhaps I was just lucky, but I never had that issue. One thing I noticed is that in Cumulus 1, the screen would refresh every 1 second and would never have a problem capturing every live 2.5 second wind reading. Although I'm assuming the screen refresh time does not necessarily correlate with LOOP readings, obviously.

[steve]

Perhaps I was just lucky, but I never had that issue. One thing I noticed is that in Cumulus 1, the screen would refresh every 1 second and would never have a problem capturing every live 2.5 second wind reading. Although I'm assuming the screen refresh time does not necessarily correlate with LOOP readings, obviously.

The DLL which Cumulus 1 uses just asks for one loop packet at a time. Some versions of firmware (and Virtual VP) return the first LOOP packet much more quickly, so you are less likely to miss readings. I seem to remember that there were other issues with those versions of the firmware, though.

[steve]

I had a reply from Davis on Friday, but it was just to say that they had passed my query on to their software engineering department.

[steve]

I hadn't heard from Davis, so I gave them a nudge, and I now have an answer. It's a known (to them) bug in the VP2 ISS firmware (and presumably also in the anemometer transmitter firmware, as I have one of those and I see this too). This does not affect the Vue as they were able to fix the problem with that.

So I'll change the code to make Cumulus calculate the 10-minute peak and only use the LOOP2 value if it's higher.

[swyman18]

Sounds good, Steve, thanks for the follow-up.

[swyman18]

I've installed 3022 and will keep an eye on the 10 min gust plots over the next few days to see how they look.
Thanks!