Changing the rainfall multiplier

[mcrossley]

I modded my FO rain collector this weekend to 4x the area. In Cumulus I put in a multiplier of 0.25. This morning the frost has melted and I have had what I think is a single bucket tip (from the website graphs). However Cumulus has registered this as 69.6mm of rain!

Is there something else I have to change in the log files to make the change to rainfall multiplier? I'm at work at the moment so I cannot check the data files until this evening.

Thanks
Mark

[steve]

I've just tried it with mine, and one tip came out at 0.1 mm, which is correct (with rounding). And I know that others are using the rain calibration OK. What did you do to stop the rain gauge registering false rain while you fitted the funnel?

When you get chance, could you please upload your mar10log.txt and the current diags file?

[mcrossley]

Steve, I unplugged the rain collector from the transmitter whilst I worked on it. That was on Saturday morning, there has been no rain registered since.

As soon as I get home I'll collect the log files for you.

Thanks
Mark

[mcrossley]

Here are the log files.

A couple of things to note. Cumulus was reporting sensor contact lost from 09:07 to 09:12. At this time the FO got a reading of 14.1 for the rain, then it went back to the previous value of 87.3. Both the base station and Cumulus reset their counters to the spurious low value and counted loads of rain for that interval.

Cumulus has 'lost' my rainfall multiplier of 0.25 and is back at 1.0 ? I have set it again and this is surviving Cumulus stop/starts.

Mark

[steve]

It ignores all of the outside data when the 'sensor lost' flags is set, so at the time this happened, the flag must not have been set:

08/03/2010 09:12:52.488 : Writing todayfile, LastUpdateTime = 08/03/2010 09:10:00 raindaystart = 83.6999969482422
08/03/2010 09:19:12.645 : 09:19:12 ****Rain reset? First chance: raindaystart = 83.6999969482422, raintotal = 14.1000003814697
08/03/2010 09:19:12.665 : Writing todayfile, LastUpdateTime = 08/03/2010 09:10:00 raindaystart = 83.6999969482422
08/03/2010 09:19:22.649 : 09:19:22 ****Rain counter reset: raindaystart = 83.6999969482422, raintotal = 14.1000003814697
08/03/2010 09:20:00.153 : Writing todayfile, LastUpdateTime = 08/03/2010 09:20:00 raindaystart = 14.1000003814697

And then shortly afterwards, the rain counter returned to its correct value:

08/03/10,09:10,0.5,90,-0.9,0.0,0.7,37,0.0,0.0,1033.0,83.7,16.0,44,0.7,0.5,0.5
08/03/10,09:20,1.4,87,-0.8,0.0,0.7,38,0.0,0.0,1033.1,14.1,16.0,44,0.7,1.4,1.4
08/03/10,09:30,2.0,83,-0.6,0.0,0.7,38,0.0,69.6,1033.0,83.7,15.9,44,0.7,2.0,2.0

So Cumulus recorded that as actual rainfall.

Cumulus has 'lost' my rainfall multiplier of 0.25 and is back at 1.0 ? I have set it again and this is surviving Cumulus stop/starts.

It doesn't actually save the cumulus.ini file immediately when you OK the calibration settings screen. I'll change it so it does, but the settings get saved anyway at close down, so it's only if it crashes that they wouldn't get saved. The only other way I can think of that it would lose the setting would be if you inadvertently entered an invalid value, which it silently rejects. But you would normally see that, as it then takes two clicks to close the dialogue.

[mcrossley]

Thanks Steve, so it looks like one of the data packets from the remote got corrupted somehow and the base station didn't detect it. I would hope the system would perform some sort of checksum checking given the vulnerability of radio data.

Cheers
Mark

[steve]

There doesn't seem to much in the way of checksums at all anywhere (there certainly isn't any in the data as read by Cumulus). What I can look at, at some point, is improving the 'second chance reset' code specifically for these stations. Currently, it just caters for a single reading going awry, but of course Cumulus is reading the data every 10 seconds and it's only changing every 48 seconds, so it often won't cope with the situation where the memory really has been written with a duff value.

[Charlie]

Just a thought... if the rain detector was unplugged for awhile then reconnected, with the batteries in place, there is a good chance of "contact bounce". During the fraction of a second when the connections are made and broken, it can appear to be made and broken many times. If there is no de-bounce (either in hardware or software) this can appear the same as a large number of magnetic reed switch closings, and hence a large amount of rain.

Speculation, but based on experience in other projects...

[mcrossley]

Hi Charlie, good thought, but what happened was that the station recorded an erroneous rainfall total that was much lower than the previous reading. Both the base station and Cumulus reset to this lower total, then the reading returned to its correct value, both the base station and Cumulus saw this as a massive downpour!

Mark

[steve]

Yes - it seems that the unplugging of the gauge and the setting of the multiplier were actually unrelated to the problem; just a coincidence. Unless somehow the unplugging had an effect which didn't manifest itself until a short time later.

[mcrossley]

Steve, I had another odd one this morning.

Again after a sensor contact lost, Cumulus registered 144mm of rain in one hit, but then this time reset itself back to 0.4mm.

Funny thing is there is nothing spurious in the Mar10log.txt file this time, nor in the diags file!

The only record of the event is that the All time records shows it in the rate values, but not in the daily or monthly totals (are these only updated at the end of each day?)...
[Rain]
highrainratevalue=144
highrainratetime=12/03/2010 04:33:00
highdailyrainvalue=16.5
highdailyraintime=26/02/2010 17:59:00
highhourlyrainvalue=12
highhourlyraintime=12/03/2010 04:33:00
highmonthlyrainvalue=60.5999984741211
highmonthlyraintime=01/02/2010

And there were big spikes on the rainfall total and rate graphs. These spikes disappeared when I restarted Cumulus. I have manually reset my all time rain records back to yesterdays values. I haven't had to patch the Mar10log.txt file.

I suspect some interference, since I have stretched out the cable to the rain sensor since changing it. I'll add some ferrite cores to the cable when I get a chance.

Any thoughts?
Mark

PS: The base station has also recorded this deluge.

[steve]

Again after a sensor contact lost, Cumulus registered 144mm of rain in one hit, but then this time reset itself back to 0.4mm.

Funny thing is there is nothing spurious in the Mar10log.txt file this time, nor in the diags file!

It's odd that the rain counter apparently went down and back up again without anything being logged in the diags file - could you zip them up and attach, so I can see if I can spot anything.

The only record of the event is that the All time records shows it in the rate values, but not in the daily or monthly totals (are these only updated at the end of each day?)...
[Rain]
highrainratevalue=144
highrainratetime=12/03/2010 04:33:00
highdailyrainvalue=16.5
highdailyraintime=26/02/2010 17:59:00
highhourlyrainvalue=12
highhourlyraintime=12/03/2010 04:33:00
highmonthlyrainvalue=60.5999984741211
highmonthlyraintime=01/02/2010

A high rain rate of 144 corresponds to 12 mm of rain in 5 minutes, hence your highhourlyrainvalue. The daily totals etc will have been adjusted when the rain counter apparently reset.

And there were big spikes on the rainfall total and rate graphs. These spikes disappeared when I restarted Cumulus. I have manually reset my all time rain records back to yesterdays values. I haven't had to patch the Mar10log.txt file.

If the rain totals had already been adjusted at the time the log entries were made, they won't appear in the logs, hence them not appearing on the graphs when you restart.

I suspect some interference, since I have stretched out the cable to the rain sensor since changing it. I'll add some ferrite cores to the cable when I get a chance.

Yes, the fact that the station has recorded it suggests that the sensor actually sent the data, rather than it being a 'local' corruption between the station and Cumulus.

I've been mulling over the '2nd chance reset' code and I'm thinking of trying to improve it so that it copes with the actual data changing for one cycle (i.e. 48 seconds), rather than it just being corrupt when Cumulus reads it, but Ok 10 seconds later on the next read. It's a bit tricky as Cumulus doesn't know for certain when the data has changed, so it would have to do a kind of '5th chance reset' or something like that. If the problem is simply that the counter goes down for 48 seconds and then returns to normal, that should effectively ignore the lower value and hence avoid the large increase when it returns to normal.

[mcrossley]

Here are all the relevant files Steve. I missed the dayfile - I had to edit out the 144mm from that too.

I've noticed that the rain graph actually goes down a bit now - presumably some rounding error as the 'select-a-graph' doesn't show this small dip.

[mcrossley]

Yes, the fact that the station has recorded it suggests that the sensor actually sent the data, rather than it being a 'local' corruption between the station and Cumulus.

I'm not sure the remote sensor sent the data as it reverts back to the previous value, more a case of it getting corrupted 'in transit' I think? If the transmitter had actually recorded this as 'bucket tips' I would have thought it would have updated its own total, but this doesn't seem to be happening. What does puzzle me if that is true is why it is only the rainfall data that is getting corrupted.

Also both times this has happened coincided with sensor contact lost events which points to interference. I also noticed that the remote sensor has lost DFC sync on both occasions.

Mark

[steve]

I've noticed that the rain graph actually goes down a bit now - presumably some rounding error as the 'select-a-graph' doesn't show this small dip.

Yes, it's presumably down to your rain multiplier and the calculation coming out slightly differently after a restart.

It's odd that there's no indication of a 'reset' in Cumulus as there was with your previous problem, and no sign of the counter just going up and staying there. You could almost think it was a bug in Cumulus - in the multiplier calculation or something - were it not for the fact that you say the console shows it too.

Which figures exactly did you need to edit in Cumulus, and what values in the console are/were wrong?