Davis VP2 wind speed and direction arrays

[mcrossley]

Steve

I think there is some a bit odd about the directions being reported in the wdirdata array. I don't think this is specific to MX, but that is what I am currently using, I pretty sure I first noticed this under Cumulus. It may be specific to the Davis VP2.

My Instromet Climatica page uses those two arrays, I have a 5 second real-time interval, so I read out the last two array values and display them sequentially.

I noticed when it is quite calm, that the display would often bounce between two direction values quite far apart when I was pretty sure the wind vane wasn't actually moving at all. I assumed it was a bug in my code somewhere, but tonight I put together a simple php script to return the relevant value, and the data does seem to be being read correctly from the arrays.

Currently, the wind direction is predominately from around 330 degrees. The MX console shows this, as do my normal gauges, but the array data keeps getting values of 280 degrees inserted into it. I have compared the data against the VP2 console, and that is never showing 280 - though it is hard to compare with the time lag.

I'm not sure what I can do to investigate this further. Ideally I'd like to be able to stream the raw values MX is reading via the serial port and see if these erroneous values are being 'created' by the console. Does MX have a web socket that presents this data?

[mcrossley]

FORGET this for now - something strange going on with PHP....

[mcrossley]

Question about <#nextwindindex>:

I'm subtracting one from this to index into the array, but it looks like I need to subtract 2. When I subtract 1 it looks like I am reading the last 'old' value from the array that will be overwritten next. So is the number supplied by Cumulus 1 relative rather than 0 relative as I was expecting?

[steve]

As far as I can tell from looking at the code, Cumulus 1 and MX behave the same - the arrays are zero-based internally, and when it creates the wspddata and wdirdata webtags, it starts at entry zero. The code in both writes each new reading to the nextwindindex position, and then increments nextwindindex by 1, modulo 3600.

[steve]

I ran a quick, limited test with my "bench" WMR200, just for a couple of minutes after startup.

Cumulus 1:
nextwindindex = 4
wdirdata = 292,292,292,292


MX:
nextwindindex = 3
wdirdata = 292,292,292

So they both appear to be doing the same thing as far as that goes.

I had a look at my live system to check the wraparound case, but the wind hasn't changed much in the last couple of hours, so it's not obvious where the new data actually ends.

[mcrossley]

Steve, here is a quick script to look at my data: http://weather.wilmslowastro.com/test/testwindarray.php

The code is simple and doesn't cope with wrapped data, but it shows the problem I think:

Code: Select all

echo "nextwindindex = $nextwindindex<br>";
$currwindindex = ($nextwindindex - 1) % 3600;
echo "currwindindex = $currwindindex<br>";
$start = ($nextwindindex - 10) % 3600;
$end = ($nextwindindex + 10) % 3600;
if ($end > $start) {
    for ($i=$start; $i<=$end; $i++) {
        if ($i===$currwindindex) {
            echo "<b>[$i] = $wdirdata[$i]</b><br>";
        } else {
            echo "[$i] = $wdirdata[$i]<br>";
        }
    }
}

[mcrossley]

You can see it with a couple of refreshes, eg...

nextwindindex = 2055
currwindindex = 2054
[2045] = 325
[2046] = 322
[2047] = 321
[2048] = 301
[2049] = 301
[2050] = 293
[2051] = 320
[2052] = 307
[2053] = 303
[2054] = 298
[2055] = 298
[2056] = 298
[2057] = 298
[2058] = 298
[2059] = 298
[2060] = 298
[2061] = 298
[2062] = 298
[2063] = 298
[2064] = 298
[2065] = 298

[mcrossley]

Got it! It is a timing thing. I had the nextwindindex value after the arrays in the php realtime file, if I move it before them, then it works. It looks like the file is still being updated as I read it, so I'm sometimes getting the new arrays with an old index value. Moving it before the arrays seems to have fixed it - well kludged it - I'll try adding some code to test for the file update and backoff for a period before I include it...

[steve]

I think there's always going to be a chance of the data changing between reading the two items, and the chance increases as the frequency of wind reading increases. This true for Cumulus 1 and MX, although it's possible that in C1 the data updating is locked out while a page is being processed.

I don't know of any way around that, other than a new tag which combines the array and the current index. Or (probably better) a tag that lists them in chronological order. It's not really what the arrays were originally intended for, they're just the last 3600 readings regardless of when they occurred, to feed the scatter plot from the original static Cumulus gauges, so the order didn't matter.

[mcrossley]

Thanks Steve, once I understood the problem I have worked around it. My PHP code was using a combination of realtime.txt and PHP tags. I was checked for the update of the realtime.txt file, and waiting a while after it was updated before proceeding. The tag file was then just included, and that was where the problems were occurring. I have now switched to only using the PHPtags and check for the update of the real-time tag file then wait a while for that to be updated before proceeding.

The original idea was that I could 'replay' the wind speeds/directions, using a lower web update time - say a real-time of 30 seconds - but still have the display updating every couple of seconds, albeit delayed around 30-60 seconds for reality. That would have been for people who are more bandwidth constrained using slower real-time update intervals.

As I have a real-time of 5 seconds, I only need to replay the last two values.

Sorry to mess you around, but I couldn't understand what was happening, writing stuff down helps the process!