Inconsistent Cumulus re-starts

[freddie]

I have a VP2 with the USB data logger, connected via Virtual VP. It has an occasional (well documented) problem where noise causes the USB connection to drop. Virtual VP attempts to restart the logger (not always successfully). Cumulus is set up to restart when the data flow is interrupted (Configuration | Station | Restart if data stops). However, the restart is inconsistent in that sometimes Cumulus continues to generate some files (i.e. realtime.txt, and my data file that Awekas picks up - http://www.hosiene.co.uk/weather/cumulus/awekas_wl.htm) and populates them with zero values for all elements. Interestingly, Cumulus doesn't do this with the web pages.

This is an intermittent problem - sometimes the restart is well behaved (if data flow is still stopped then no updating occurs; if data flow has resumed then updating occurs), but quite often it isn't. Any thoughts?

[steve]

Do you ever get the message which says that it can't connect to the station when it restarts - the "-32701" error? If you zip up the diags folder and attach it, I'll have a look. Note that the diags files are for the last 10 starts, so you will need to supply the files when something of note has happened in one of those.

[freddie]

I get the "-32701" message when there is a "clean" restart (and the data still isn't flowing). I don't get the message for the restarts I'm having problems with. Diags files are attached.

Thanks for your help.

Diags.zip

[steve]

I get the "-32701" message when there is a "clean" restart (and the data still isn't flowing). I don't get the message for the restarts I'm having problems with.

I suspect that's the problem. On some restarts, Cumulus is told it can't connect:

26/12/2011 17:56:46.184 : VP2: OpenTCPIPPort_V, res = -32701

so no attempt is made to read data etc. But on some restarts, it is allowed to connect and initialise:

27/12/2011 10:26:01.811 : VP2: OpenTCPIPPort_V, res = 0
27/12/2011 10:26:02.045 : VP2: InitStation_V, res = 0

but attempts to read anything fail:

27/12/2011 10:26:06.795 : Get Console Latitude, result = -32701, latitude = 0.0
27/12/2011 10:26:09.077 : Get Console Longitude, result = -32701, longitude = 0.0
27/12/2011 10:26:11.264 : Get Station Firmware Version, result = -32701

27/12/2011 10:26:13.452 : VP2: SetStationTime_V res = -32701

27/12/2011 10:26:17.748 : VP2: DownloadData_V = -32701

[freddie]

Hmm, so it looks like the problem is with Virtual VP telling Cumulus lies

OK thanks for your help Steve - I'll pursue this with Virtual VP.

[gemini06720]

Which version of Virtual VP are you using? Are there any other weather software, other than Cumulus, connecting and getting their data from Virtual VP?

I am running Virtual VP version 1.2.5.74 - both Cumulus and Weather Display are getting their data from the Virtual VP serial ports - I also have another (second) copy of Virtual VP (on another computer) connecting to this (first) Virtual VP using one of the TCP/IP ports. None of the software have reported communication problem.

But, if the Davis Instruments WeatherLink software is connected to Virtual VP ... that is when the communication problems really start...

[freddie]

I'm running Virtual VP 1.2.5.74 - the same as you. Cumulus and another instance of Virtual VP (on another computer) are connecting via TCP/IP to the problematic Virtual VP. I don't use WeatherLink.

Maybe Cumulus could flag an error if no data is available despite successfully connecting?

I still don't understand why it is that the web pages don't update - yet the realtime.txt and other data files do...

[steve]

Maybe Cumulus could flag an error if no data is available despite successfully connecting?

It has a facility already for reporting 'data stopped', but that probably doesn't work for Davis stations. I could possibly look at making it work, but I don't know when I'll find time for that.

I still don't understand why it is that the web pages don't update - yet the realtime.txt and other data files do...

You've probably chosen an update interval which is a factor of 60, and the code that handles 'synchronised' web updates happens to check that valid data has been received. All the other code ought to do the same check, really.

[freddie]

Maybe Cumulus could flag an error if no data is available despite successfully connecting?

It has a facility already for reporting 'data stopped', but that probably doesn't work for Davis stations. I could possibly look at making it work, but I don't know when I'll find time for that.

I use the 'Restart if data stops' setting - is that what you mean? If so, it does work for Davis stations then.

I still don't understand why it is that the web pages don't update - yet the realtime.txt and other data files do...

You've probably chosen an update interval which is a factor of 60, and the code that handles 'synchronised' web updates happens to check that valid data has been received. All the other code ought to do the same check, really.

Yes - I use a 5-minute update interval, so that fits what you are saying.

[steve]

I use the 'Restart if data stops' setting - is that what you mean? If so, it does work for Davis stations then.

Ah, yes, I can't read my own code. If the call to download the entire set of current data fails, then the 'last updated' timestamp doesn't get updated, and after a minute a 'data stopped' error is reported, unless you have told it not to report them, or if you have 'restart if data stopped' set, it attempts to restart itself at that point.