'Stuck' values

[micromet]

Does anyone else experience stuck values when using cumulus with the Davis VP2? This has become a frequent problem for me. I have two Davis Vantage pro 2 stations, one using Cumulus 1.9.2 and the other 1.9.0. Both occasionally get stuck on a particular value for a while (sometimes hours), and I don't know why. It is usually just one reading, for example wind direction or humidity, and the other values are fine during this time. This makes me think it's not a problem with the wireless signal.

For example, yesterday the humidity got stuck for one station and the wind direction for the other (http://geography.kcl.ac.uk/micromet/WXTplot.htm - updates daily so problem may not be there, depending on when you click). Another example is http://s10.postimage.org/lgei1lbd5/davis_stuck.jpg.
* these graphs are produced from the cumulus realtime.txt data, which is then averaged and plotted using R. The stuck values are present from the initial cumulus data that is recorded (at 0.5Hz).

Following suggestions from WXforum I will try and find out if the values are also stuck on the console, but wondered if anyone here had experience a similar problem.

Thanks

[steve]

The only reasons I can think of for a single item flat-lining are either that the data value being read is actually staying the same, or (perhaps more likely) that the Davis DLL is returning an error for that item and Cumulus continues to use the last available reading. The only time I've seen this (and I have it at the moment as my temperature/humidity sensor is broken) is when the console is telling the DLL that it has no reading for that sensor.

Having said that, what you're doing is somewhat unusual, so who knows....

The first thing to check would of course be to see if the console is doing the same. If the data gets stuck for several hours, that should be quite easy to do? Secondly, does the graph in Cumulus do the same, and is the data in the Cumulus data log doing the same?

Version 1.9.0 is positively ancient, by the way, and no longer supported; but that doesn't seem to be relevant here, as 1.9.2 is doing the same. What version(s) of firmware do the consoles have?

It's probably worth zipping up the diags folder and attaching it, I may be able to spot something.

[micromet]

The only reasons I can think of for a single item flat-lining are either that the data value being read is actually staying the same, or (perhaps more likely) that the Davis DLL is returning an error for that item and Cumulus continues to use the last available reading. The only time I've seen this (and I have it at the moment as my temperature/humidity sensor is broken) is when the console is telling the DLL that it has no reading for that sensor.

Having said that, what you're doing is somewhat unusual, so who knows....

The first thing to check would of course be to see if the console is doing the same. If the data gets stuck for several hours, that should be quite easy to do? Secondly, does the graph in Cumulus do the same, and is the data in the Cumulus data log doing the same?

Version 1.9.0 is positively ancient, by the way, and no longer supported; but that doesn't seem to be relevant here, as 1.9.2 is doing the same. What version(s) of firmware do the consoles have?

It's probably worth zipping up the diags folder and attaching it, I may be able to spot something.

Thanks for the suggestions. I checked the graphs in cumulus and they do display the same thing - i.e. the stuck data is there. I tried to look at the station data via weatherlink but it only stores the last 2 days worth of data, during which the problem hasn't happened. It is quite frequent though so I'm sure I'll be able to check in a day or so.

Physically looking at the console it not as easy, the main reason being that we only really see the data the next day on the 'daily plots', by which time the stuck values have usually changed. We also operate both stations remotely (they are on the top of residential tower blocks in London), which doesn't make things any easier.

Thanks again for your help

[steve]

Thanks for the suggestions. I checked the graphs in cumulus and they do display the same thing - i.e. the stuck data is there.

At least that eliminates a problem with the route you're using to get the data.

I tried to look at the station data via weatherlink but it only stores the last 2 days worth of data, during which the problem hasn't happened. It is quite frequent though so I'm sure I'll be able to check in a day or so.

Yes, that would be useful.

Unfortunately there's no extra logging of the data that you can turn on in Cumulus, unlike with other stations. At a reading every 2 to 3 seconds, I couldn't work out a good way to do it without creating unmanageably large files. If it turns out the problem doesn't affect the WL data, I'll see if I can work something out.

It would still be useful to see the diags files...

[micromet]

Here is the Diags folder from the station that experiences the problem most often. Do you need to know the dates/times that it occurred? If so, the wind direction from September 4th is a good example of the problem, it appeared stuck for several hours from midnight onwards.

Thanks for taking a look, really appreciate it!

[steve]

You seem to get a problem reading data from the station just after midnight on several occasions:

22/08/2012 00:00:18.638 : VP2: LoadCurrentVantageData_V, error = -32701

but this would result in all of values going missing, and in any case it clearly resolves itself immediately. Other than that, there are no obvious issues - but failure to read individual sensors wouldn't get logged anyway.

This one's running 1.9.1, by the way.

[micromet]

You seem to get a problem reading data from the station just after midnight on several occasions:

22/08/2012 00:00:18.638 : VP2: LoadCurrentVantageData_V, error = -32701

but this would result in all of values going missing, and in any case it clearly resolves itself immediately. Other than that, there are no obvious issues - but failure to read individual sensors wouldn't get logged anyway.

This one's running 1.9.1, by the way.

Ah, my mistake, the other is definitely running 1.9.2. Well you've managed to narrow it down for me, thanks, as soon as it happens again I'll verify if its in the Davis data also.

[micromet]

An update (copied from the WXForum thread):

It seems as though it may be some combination of signal problem, cumulus and the Davis Station;

The plot of yesterdays data, as processed by us:


So, what does the cumulus data look like?


Looks stuck.

And the weatherlink data?..



It seems there was a break in the signal for roughly an hour, and after this the Solar Rad doesn't come back (even though the other measurements do). However, Cumulus doesn't seem to see this and instead reports the same value. In fact, during the hour break the humidity also appears stuck, but jumps back to the actual value once the signal returns.

Of course this doesn't explain why the Solar Rad was stuck at 70 while we still had signal. Unfortunately I only have the last 2 days data from the station itself so I can't see when the stuck values started, but I can say that it has been like that since at least midday on monday.

----------


Interestingly, the stuck period ended today, but still no signal from the weather station:

Weatherlink (still no SolarRad signal):


Cumulus:

[steve]

Cumulus will always re-use the last value it read, if it's unable to get a new value; it has no concept of 'no value', so it has to use something. So in that respect, I think what you see in Cumulus is basically the same as you see in Weatherlink, and there is no issue in Cumulus and your problem is simply one of communication between the sensors and the station.

Cumulus doesn't know anything about the signal between the sensors and the station, other than what the Davis DLL tells it in the form of error codes when it tries to read the data. It's only concerned with the connection to the station, but even that is handled by the DLL. If there is loss of signal from the ISS and the DLL is unable to read the data from some sensors, then when the signal from the ISS is restored, the DLL should just start being able to get data for that sensor again.

If you zip up the diags folder and attach it, I'll see if there have been any errors reported by the DLL (although individual sensor failures aren't logged).

[micromet]

OK, that's good to know. Out of interest, is there a reason that Cumulus doesn't record the ISS signal strength? Is it just not possible?

Thanks again, you've been really helpful.

[steve]

OK, that's good to know. Out of interest, is there a reason that Cumulus doesn't record the ISS signal strength? Is it just not possible?

I don't think it's possible to read the signal strength from the console (it's not mentioned in the interface spec). The 'ISS Reception' figure in WL is the percentage of good packets received vs total possible packets. Cumulus provides the figures required for the calculation as web tags, it doesn't actually do the calculation. From the help:

Davis Reception Statistics (only applicable to Davis stations)
All figures are reset when Cumulus starts, and are updated once a minute. Note that these are simply the figures supplied by the station (they are also available on the console). Cumulus just reads them and passes them on. Please don't ask me to interpret them for you; if you have concerns or questions about these figures, please contact Davis.

<#DavisTotalPacketsReceived> Total number of data packets received
<#DavisTotalPacketsMissed> Number of missed data packets
<#DavisNumberOfResynchs> Number of times the console resynchronised with the transmitter
<#DavisMaxInARow> Longest streak of consecutive packets received
<#DavisNumCRCerrors> Number of packets received with CRC errors


There are no data read errors in the diags file, so it must be lack of data from individual sensors.

[micromet]

There are no data read errors in the diags file, so it must be lack of data from individual sensors.

Thanks for looking