Cumulus Support

Hi Steve,

I had an intermittent “sensor lost” problem which resulted in a corrupt transmission of rain data at 04:19 (see attached diags file). The transmission fault also resulted in various data being ignored based upon my spike removal settings, which I quite understand as it’s doing what it is designed to do. However, it did occur to me that it would be helpful if the spike removal settings also encompassed the rain counter as at the moment the “Six consecutive readings; accepting value” means one has to go in and start editing values to correct the error. It would also be helpful if the diags also recorded when the sensor is lost, it would aid research and understanding the scope of the fault.

I hope my logic makes sense.

The reply I've just given in another thread pretty much applies here. If it was easy, I'd have already done it. The problem is deciding whether the rain counter has changed permanently and adjusting all the values to cater for it. Sometimes the counter does go up permanently; sometimes it comes back down again; sometimes it goes down for a while and then comes back up again. I don't know what the solution is.

I suppose one possibility would be, instead of 'accepting' the new value after six reads, would be to accept it but adjust the start of day figure by the same relative amount, effectively ignoring the increase, and hope that the increase was indeed permanent. That would at least cope (to a certain extent) with the simple case where the counter goes up permanently.

steve wrote:The reply I've just given in another thread pretty much applies here.

Yes I did read it, unfortunately after I had posted my question, odd coincidence. (My post has not taken account of your recent update, you're just too quick but I think it might still stand)

I do see your point that it’s not easy. If I understand it, when recording data in real time then Cumulus will accept the value after 6 mins. If using the logger is set at 5 mins this would mean an interval of 30 mins (and so on).

Would it work (or be easier?) if the spike removal were based upon a time i.e. only accept the large difference in rain gauge tip count after x number of mins. Rather than number of times read?

Is there any where in Cumulus that lost sensor times are permanently recorded for historical review?

Many thanks

nking wrote:I do see your point that it’s not easy. If I understand it, when recording data in real time then Cumulus will accept the value after 6 mins. If using the logger is set at 5 mins this would mean an interval of 30 mins (and so on).

Would it work (or be easier?) if the spike removal were based upon a time i.e. only accept the large difference in rain gauge tip count after x number of mins. Rather than number of times read?

It's six reads of the data, i.e one minute. This is to make sure that the station has had chance to do at least one 48-second update.

Is there any where in Cumulus that lost sensor times are permanently recorded for historical review?

No, it just outputs the messages, it doesn't record any details anywhere.

steve wrote: It's six reads of the data, i.e one minute. This is to make sure that the station has had chance to do at least one 48-second update.

What’s the effect if someone only downloads from their logger once a day? Is it still six reads of data? Just trying to get my head around the elapsed time issue.

steve wrote:I suppose one possibility would be, instead of 'accepting' the new value after six reads, would be to accept it but adjust the start of day figure by the same relative amount, effectively ignoring the increase, and hope that the increase was indeed permanent. That would at least cope (to a certain extent) with the simple case where the counter goes up permanently.
I suppose one possibility would be, instead of 'accepting' the new value after six reads, would be to accept it but adjust the start of day figure by the same relative amount, effectively ignoring the increase, and hope that the increase was indeed permanent. That would at least cope (to a certain extent) with the simple case where the counter goes up permanently.

As you mention in the other thread - it certainly isn't an easy one to resolve!

steve wrote: No, it just outputs the messages, it doesn't record any details anywhere.

Do you think it might be useful, if so I'll raise an enhancement request?

nking wrote:What’s the effect if someone only downloads from their logger once a day? Is it still six reads of data? Just trying to get my head around the elapsed time issue.

It doesn't do any of this for logger data, just live data.

nking wrote:

steve wrote: No, it just outputs the messages, it doesn't record any details anywhere.

Do you think it might be useful, if so I'll raise an enhancement request?

I'm not sure it would be useful to me, but if you think it would be useful to you, then please do