Cumulus Support

MX sometimes loses communication with the weather station which I handle by shutting down MX then restarting weather station - the reload of archived data seems to load some very bad values which should be totally ignored - the corrupted data of course then corrupts all the various data files and it is a long job to correct them all by hand.

I have attached the logfiles of the latest problem on 14-04-21

Regards George

I see you are already using spike removal and I thought that should have helped.

I believe a future MX release will handle the loss of communication better, see this topic.

Thanks, I found an issue with the processing of historic data from FineOffset stations that allowed spikes through. I'll add a fix to the next release.

Sorry there still seems to be a problem on rainfall as well. I attach the webpage as text data and the logs of the failure. Things which I have noted the last rainfall is on 18/05/21 but 0.4 mm has been recorded today 19/05/21 and the total rainfall would indicate that the oceans levels have probably risen!

Hope you can track down what is going wrong

Regards

George

Your station keeps locking up, and sending odd data. Cumulus is coping the best it can, but with rubbish input you tend to get rubbish output.

On the 18th CMX was started at 19:19, there was no history to read. It started running OK..
Until 19:33, when CMX received bad data that it ignored... After that from 19:34 onwards there was no response from the station until you stopped CMX at 09:09 in the 19th.

BUT, because the station was locked up and no data coming in, the midnight rollover processing for the 18th never happened.


On the 19th, when you started MX at 09:11, the station was reporting a rain counter value of 211.5. The counter value is read from the previous midnight entry in the dayfile. But because the rollover did not happen on the 18th, the only one it could use was the value from the 17th (which was 211.2), so 0.3mm from the 18th was recorded again on the 19th.

As the normal reading of the station stared, the rain counter jumped up 51816 ticks (15544.8 mm), it then stayed at this value, after 6 readings CMX adjusted it's internal counter to this new value until the log ends at 19:09.


What you need to do when you get a lockup is to perform a rollback to either the previous successful midnight backup, or the last time CMX was started. Then the missing rollovers will be completed using historic data from the station logger.

What might help you would be an option to shutdown CMX if it is in a Data Stopped condition for a period. I'll have a think about adding that capability.

However your station is locking up so frequently I think you need to seriously consider replacing it.

The lock ups seemed to be related USB data transfers which although the cable is shielded seem to happen at random intervals - This is a known problem with this type of station according to the suppliers - a previous verison did the same a couple of years back. I ran the cumulus version 1.0 during that time and the setting to stop data collection on any bad USB transfer worked for me and such an option would be great.
In relation to the rain counter. The station is set to five minute intervals but the software to 1 min. (A 1 min interval on the station would fill tothe memory too quickly in the event of a hangup). It would appear the bad data would be there for five mins and would eventually clear? Not sure how this works - is the counter reset at midnight? In any event such a large jump in counters is bad data and should also be removed on spike supression? The other supressions seem to be working fine in the latest versions. In fact you have highlighted the warning about the rain counter?
I will try to roll back the data as a work around but a dead stop on data collection would help a lot. What I don't know is if the bad data is actaully in the station memory - can I set flag to see this in a log?

Regards

George