Cumulus Support

[Cumulus 1.9.2 build 1030 on a Win2k Pro SP4 PC from a Davis Vantage Vue with RS-232 logger.]

A visitor to my weather website alerted me to a false all-time record today. The attached file Rain_records.JPG shows a record hourly fall for yesterday (3 March). But the other attachment (C_summary.JPG) shows the Cumulus main page for today (4th) indicating no rain yesterday. This accords with reality - there was no rain yesterday.

Can anyone suggest what might have caused this strange spurious record to appear? And what can be done to prevent future repeats of this behaviour?

It's unusual for Davis stations to give bad rainfall data. Please zip up the diags folder and attach it, and I'll take a look. Please also include your Mar13log.txt file.

If you look at the alltimelog.txt (format here: http://wiki.sandaysoft.com/a/Alltimelog.txt), you'll see an entry for when this record was broken, which will tell you what the previous correct record was. You can then use the all-time record editor to correct it.

Note that you're using a very old, superseded version of Cumulus. It's possible there was a bug which has since been fixed.

Steve,

But surely if the Davis AWS generated the error there would be some rainfall recorded for the 3rd? Requested files attached. (It's possible cumulus.009 is corrupt, as it was open by Cumulus at the time I zipped all those files.)

Thanks for the tip about alltimelog.txt. I've found the correct record, and will fix my data with the editor. I'll also download the latest version and see how it runs on my Win2k system.

Ah yes, I hadn't spotted that you're using an unsupported version of Windows. I'll look at the files and get back to you.

When you started Cumulus at 10:38, it read the total rain counter from the station (it uses the annual total so far as the counter), and got 279:

3/03/2013 10:38:37.129 : VP2: Setting raintotal from current station value: 279

When you closed it down at around 16:30, no rain had been added:

3/03/2013 16:30:00.223 : Writing today.ini, LastUpdateTime = 3/03/2013 4:30:00 PM raindaystart = 279 rain counter = 279

When you started it up again shortly afterwards, the total was now given as 354.3:

3/03/2013 16:47:08.730 : VP2: Setting raintotal from current station value: 354.329986572266

When you closed it down at around 19:00, no further rain had been added:

3/03/2013 19:00:00.948 : Writing today.ini, LastUpdateTime = 3/03/2013 7:00:00 PM raindaystart = 279 rain counter = 354.300018310547

When you started it up again shortly afterwards, the total had reverted to 279:

3/03/2013 19:09:32.064 : VP2: Setting raintotal from current station value: 279

And it has stayed that way since then:

4/03/2013 22:40:00.793 : Writing today.ini, LastUpdateTime = 4/03/2013 10:40:00 PM raindaystart = 279 rain counter = 279

So no rain for the day was recorded, as the annual total was back to (presumably) where it should be, but that period where the counter was somewhat higher for some reason, caused the hourly calculation to come out at 75.3.

Note that you have the Cumulus logger interval set to 10 minutes, but the station set to 30 minutes, against recommendations. So you are hitting this issue: http://wiki.sandaysoft.com/a/FAQ#Cumulu ... t_start_up

In theory, Cumulus copes with this, and it doesn't appear to be related to the rainfall counter issue, but it's not an ideal situation to be in, particularly when you start and stop Cumulus as often as you seem to.

Steve,

OK, thanks for the explanation. As I understand you, the spurious record was the result of a 'glitch' in the rain counter reading, though we'll never know whether it was caused by the AWS or some momentary communication problem.

Regarding the frequent start/stops, I've been doing some PC debugging that involved trying various different software and drivers to fix a specific problem (unrelated to Cumulus), which required a number of reboots over a period of a day or so. Doesn't happen often, especially now that particular (audio) problem has been fixed.

As for the mismatch between Cumulus and my AWS lgging periods, I don't recall seeing any setup item in the Davis instructions for changing the logging interval. So perhaps I should just change Cumulus's interval?

Incidentally, I downloaded and installed Cumulus 1.9.3, and it seems to be running fine on my Win2k system.

DanielF wrote:I don't recall seeing any setup item in the Davis instructions for changing the logging interval.

The easiest way is using Weatherlink, if you have it installed. You can also connect to the station using a terminal emulator and just type the command (SETPER 10 sets it to 10 minutes). When I get chance, I'm going to enhance my SetLogger program so it handles Davis stations. Note that setting the logger interval clears the logger memory.

I think the problem was unlikely to be a communications glitch, because Cumulus continues to read the total all the time it's running, and it was getting the same value. So either a problem with the Davis DLL which Cumulus uses to read the data, or the console itself. My money would be on some kind of initialisation problem in the DLL.

steve wrote:

DanielF wrote:I don't recall seeing any setup item in the Davis instructions for changing the logging interval.

The easiest way is using Weatherlink, if you have it installed. You can also connect to the station using a terminal emulator and just type the command (SETPER 10 sets it to 10 minutes). When I get chance, I'm going to enhance my SetLogger program so it handles Davis stations. Note that setting the logger interval clears the logger memory.

Steve,

Thanks for the further explanations. I don't have Weatherlink installed (didn't see the point, since Cumulus handled the data just fine without it). So I'll try the terminal/SETPER method.

Does Cumulus download the entire logger memory contents when Cumulus starts? In which case, I presumably should do the SETPER while Cumulus is running, so no data is lost? But I suspect Windows won't allow me to access the COM port while Cumulus has it 'open'.

You can't do it while Cumulus is running. Stop Cumulus, change the setting, start Cumulus again.

Thanks Steve. I did this and eventually got an 'OK' response from the Vantage Vue logger, so I presume it has been changed correctly (to 10 seconds, to match my Cumulus logging period).

And Cumulus now downloads the data quicker (when restarting Cumulus), an added advantage!