Aecrus 3083 hardware/history fault afterCumulus data logger?

[leforthomas]

I have a Aercus w3083

I use Cumulus MX v.3.0.0 build 3036 on the raspberry pi

I have set up cumulus with the data logger enabled to get history data when the pi is off, it is set up with with fine offset work around.

Since I got the station in january I have had lots of problems with the pi-off-time catch up. After working for a few days it stops and I get the error message below from the MXDIAG

This seems to correspond to a history problem on the station itself (browsing history becomes no longer possible on the console unit). I have sometimes got it back working again, by resetting the station (removing batteries/power) or a complete manufacturer's reset. I have been in contact with the distributer, who sent me a new console, and although it worked ok for a few days, after setting up the data logger, I have the exact same problem on the new unit (console history blocked and communication blocked with cumulus). The distributer (greenfrog scientific) says this is the first time they have had this problem.

May/may not be relevant I changed the interval time on the station at some some point (after which it worked ok, at least for a couple of days).


Thanks for any help!

2016-04-27 22:40:12.182 22:40:12 Read logger entry for 27/04/2016 22:10:35 address FFFFF4C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2016-04-27 22:40:15.340 The operation has timed-out.
2016-04-27 22:40:15.340 Error reading data from station - it may need resetting
2016-04-27 22:40:18.342 The operation has timed-out.
2016-04-27 22:40:18.342 Error reading data from station - it may need resetting
2016-04-27 22:40:21.344 The operation has timed-out.

[water01]

Have you tried setting Synchronise Fine Offset reads in the Station Settings Options as this was designed to help to overcome this problem.

[stephenmh]

Hi leforthomas.

What a coincidence! I have exactly the same issue, same weather station and a Raspberry Pi 2.

I purchased it from the same distributor at Christmas who to be fair, have been most helpful and have just swapped the unit. I've tried the setting that David suggested, tried different USB ports, ferrite rings on the USB cable and a powered USB hub, but still see the same problem. With the 1st unit, I had the error every week or so, but sometimes it only lasted a couple of days before it needed a reset. To get it back up and running is fairly straightforward and usually involves removing the batteries and resetting the clock, calendar and relative humidity etc. But... I have had some loss of data where the logs have got corrupted when I didn't get chance to reset it quickly. The console sometimes records spurious data like 3000mm of rain after a lock up too! This new unit lasted 7 days before crashing, I've reset it and have fingers crossed but I'm not too optimistic now.

I have been really disappointed by this station, I only upgraded from my WS1081 to get the Solar features but never had anywhere near as many lockups with that one.

As with yourself, I would also be grateful if anyone has any other suggestions

Thanks, Steve

[EdE]

...and a third! I have the same issue with an Aercus WS3083 since Christmas. Mine is connected to an original Raspberry Pi.

It ran alright to begin with but then began to hang up in the way the original poster describes, seemingly on an increasingly frequent basis. I followed the advice on a the GreenFrogScientific website and fitted a ferrite to the USB cable to reduce any chance of that causing noise problems but this had no effect.

When it got to the point where I was resetting the station every two to three days, I switched to using Cumulus 1.9.4 on my Windows Desktop PC and leaving the PC on all the time. In the two weeks since I have done that there has not been one failure or error. I have been using the same WS3083 and USB cable. From this I conclude the problem is not the Weather Station or the cable - it must be the Raspberry Pi or the Cumulus MX software.

In order to try and determine which of these it is, I have just switched from using Cumulus V1.9.4 to using Cumulus MX V3.0.0 build 3038 on my Windows PC - if that runs without problem it will point to an issue with the Raspberry Pi, if it doesn't I will be forced to conclude the issue is with the CumulusMX software. We shall see...

Ed

[steve]

Presumably you are using the "synchronise Fine Offset reads" setting? Have you looked in the MX diags file to see how far apart the clocks are drifting (search for the word "drift")? The default that Cumulus allows is 3 seconds, if you are getting a drift of more than that, the synchronise setting will be less effective. You can increase the value by adding a FOReadAvoidPeriod setting (in seconds) to the [Station] section of Cumulus.ini (with Cumulus stopped).

[stephenmh]

Hi Steve,

I can confirm that I have selected the "synchronise Fine Offset reads" setting.

However, I checked the logs as you suggested prior to the last lock up and if I am looking at the correct entry, it would suggest that it drifted much further out than the default 3 seconds you mention?

2016-04-28 17:48:32.359 Sensor clock 17:47:42 drift = 34 seconds
2016-04-28 17:48:32.360 Station clock 17:48:32 drift = 0 seconds
......
2016-04-29 01:19:21.204 The operation has timed-out.
2016-04-29 01:19:21.205 Error reading data from station - it may need resetting

Looking at some of the latest log entries with the station still running, it may have drifted even further at times so would it be worth changing the "FOReadAvoidPeriod" setting to 50 seconds, or could there be an underlying issue somewhere?

2016-05-02 17:52:41.520 Sensor clock 17:50:20 drift = 47 seconds
2016-05-02 17:52:41.521 Station clock 17:52:41 drift = 20 seconds

Thanks, Steve

[steve]

That's a very large drift, and it will mean that the synchronise function is only able to work for a short time after each synchronisation. The interval is applied before and after the 'danger point', so if you set it to 30 seconds or more, it will never read any data. I suspect this is down to the Pi not having a RTC. I'm not sure how the clock is supposed to keep itself correct - I assume it reads the time from the internet periodically. Perhaps it can be made to do it more often? You can also buy a proper RTC module quite cheaply. You would need to verify that it is actually the Pi clock and not the console that is to blame.

[stephenmh]

Steve,

Thanks for the detailed response, much appreciated

I have a lot to learn with the Pi, and was not aware that there was no RTC. After reading up, I have ordered a module for £5.49 so it's certainly worth a try. Ed mentioned that the console seems to have worked for a while now connected to a PC, so it could well be something to do with the Pi not syncing with NTP often enough as here are all the drift checks from my recent logs:

2016-04-29 17:59:40.362 Station clock 17:59:40 drift = 8 seconds
2016-04-30 17:52:40.503 Station clock 17:52:40 drift = 0 seconds
2016-05-01 17:50:20.912 Station clock 17:50:20 drift = 20 seconds
2016-05-02 17:52:41.520 Sensor clock 17:50:20 drift = 47 seconds
2016-05-02 17:52:41.521 Station clock 17:52:41 drift = 20 seconds
2016-05-03 17:52:41.838 Station clock 17:52:41 drift = 0 seconds

I'll let you know how I get on, thanks again!

[steve]

Actually, 47 seconds may not be as bad as it seems, it could be 1 second, there's no way of knowing, because the updates are every 48 seconds. But some of the others are quite bad.

[stephenmh]

Thanks for the feedback Steve.

I've installed the RTC now, and the station is back up and running so I'll monitor for a few days and see if the drift has improved.

As I said earlier though, I've still got a lot to learn on the Pi but from what I gather, you have to check HWCLOCK for the module and DATE for the Pi clock so I'm not sure if they sync through the day? If they run separately, I'm not sure if it's going to help but hopefully it will

[mcrossley]

From what I remember the RTC is only read at boot, the OS then periodically sets the RTC to OS time so it will be correct for the next boot. NTP should be keeping the OS clock accurate, if it isn't then it sounds like a failing rPi board.

But first determine if the pi clock or the station is drifting.

[stephenmh]

From what I remember the RTC is only read at boot, the OS then periodically sets the RTC to OS time so it will be correct for the next boot.

Thanks Mark, I think you are right, Jessie has support for the RTC but everything I saw last night suggests it only syncs at boot and possibly shutdown.

I'll keep am eye on the two clocks anyway as it should give a clue to whether the Pi clock is drifting I suppose, but I'm not sure how I could definitively prove if it's the Pi or console?

As it's affecting 3 of us with similar setups, I am beginning to wonder if the console just isn't compatible with the Pi but I don't really want to leave a pc running 24 hours a day for the website

[steve]

One possible check would be to use the ntpdate command to force a clock update. I think the command output tells you by how much the clock was off.

[EdE]

The mystery deepens. I suspect this problem is not associated with the Raspberry Pi. As I said in my earlier response above having had the problem with MX on my Raspberry Pi, I switched back to Cumulus 1.9.4 on a Windows PC and it ran without any errors from 23rd April to 3rd May (10 days), I then switched to Cumulus MX Build 3038 on Windows - it has just failed after 4 days. The clock drift entries in MXDiags are as follows:

...
2016-05-04 11:57:00.006 Station clock 11:57:00 drift = 0 seconds
...
2016-05-05 11:56:59.348 Station clock 11:56:59 drift = 1 seconds
...
2016-05-06 11:27:58.970 Sensor clock 11:27:58 drift = 35 seconds
2016-05-06 11:27:58.970 Station clock 11:27:58 drift = 1 seconds
...
2016-05-07 11:28:06.927 Start Synchronising
2016-05-07 11:30:00.215 Writing log entry for 07/05/2016 11:30:00
2016-05-07 11:30:00.216 Written log entry for 07/05/2016 11:30:00
2016-05-07 11:30:00.216 Writing today.ini, LastUpdateTime = 07/05/2016 11:30:00 raindaystart = 506.7 rain counter = 506.7
2016-05-07 11:30:00.217 Latest reading: 5344: 01 2D E9 00 38 CF 00 49 27 0A 11 00 06 99 06 00
2016-05-07 11:40:12.242 Operation timed out.
2016-05-07 11:40:12.242 Error reading data from station - it may need resetting
2016-05-07 11:40:15.243 Operation timed out.
2016-05-07 11:40:15.243 Error reading data from station - it may need resetting
2016-05-07 11:40:18.243 Operation timed out.
2016-05-07 11:40:18.243 Error reading data from station - it may need resetting
2016-05-07 11:40:21.243 Operation timed out.
2016-05-07 11:40:21.243 Error reading data from station - it may need resetting
2016-05-07 11:40:21.243 Station clock 11:40:21 drift = 22 seconds
2016-05-07 11:40:26.243 Stop Synchronising
2016-05-07 11:40:39.388 Operation timed out.
2016-05-07 11:40:39.388 Error reading data from station - it may need resetting
2016-05-07 11:40:42.388 Operation timed out.

As you can see the most recent drift message was just after it started having difficulties and this happened with Cumulus MX on a Windows 7 PC.

Help and advice most welcome.

Thanks,

Ed

[steve]

If those drift figures are correct, that would explain why the console locks up. But it's possible that the synchronisation code in MX isn't working correctly. I'll have a look at the code when I get home.

It would be interesting to see the drift figures reported by Cumulus 1 with the same station.