Aecrus 3083 hardware/history fault afterCumulus data logger?

[EdE]

Steve,

I can do that. Where do I find the Drift figures in the Cumulus 1 files.

Thanks,

Ed

[EdE]

I found the diagnostics files for Cumulus 1.9.4. As requested, here are the messages concerning drift between the 23rd April and the 3rd May whilst running Cumulus 1.9.4. During this time the Weather Station (Aercus WS3083) was connected to the same USB port on the same Windows 7 computer using the same USB cable as it was when running Cumulus MX from 3rd May under Cumulus MX when it produced the drift messages previously posted.

...
24/04/2016 17:02:53.482 : 17:02:53 Start Synchronising
24/04/2016 17:07:27.904 : Address changed
24/04/2016 17:07:27.904 : addr=FFFFprevious=2360
24/04/2016 17:07:27.904 : Sensor clock 17:03:28 drift = 8 seconds
24/04/2016 17:07:27.904 : Station clock 17:07:27
24/04/2016 17:07:32.904 : 17:07:32 Stop Synchronising
...
25/04/2016 17:03:35.173 : 17:03:35 Start Synchronising
25/04/2016 17:15:00.226 : Writing today.ini, LastUpdateTime = 25/04/2016 17:15:00 raindaystart = 500.700012207031 rain counter = 501
25/04/2016 17:15:00.226 : Latest reading: 2720: Data: 11 22 E2 00 32 8A 00 62 27 14 1F 00 0C 86 06 00
25/04/2016 17:17:30.973 : Address changed
25/04/2016 17:17:30.973 : addr=FFFFprevious=2720
25/04/2016 17:17:30.973 : Sensor clock 17:04:15 drift = 1 seconds
25/04/2016 17:17:30.973 : Station clock 17:17:30 drift = 3 seconds
25/04/2016 17:17:35.974 : 17:17:35 Stop Synchronising
...
26/04/2016 17:04:17.769 : 17:04:17 Start Synchronising
26/04/2016 17:14:38.042 : Address changed
26/04/2016 17:14:38.042 : addr=F855previous=2AE0
26/04/2016 17:14:38.042 : Sensor clock 17:05:01 drift = 2 seconds
26/04/2016 17:14:38.042 : Station clock 17:14:38 drift = 7 seconds
26/04/2016 17:14:43.042 : 17:14:43 Stop Synchronising
...
27/04/2016 17:05:05.020 : 17:05:05 Start Synchronising
27/04/2016 17:15:00.589 : Writing today.ini, LastUpdateTime = 27/04/2016 17:15:00 raindaystart = 501.600006103516 rain counter = 504
27/04/2016 17:15:00.589 : Latest reading: 2EA0: Data: 11 1E D6 00 49 3C 00 9D 27 07 0A 00 0E 90 06 00
27/04/2016 17:26:59.559 : Address changed
27/04/2016 17:26:59.559 : addr=2EB4previous=2EA0
27/04/2016 17:26:59.559 : Sensor clock 17:05:49 drift = 1 seconds
27/04/2016 17:26:59.559 : Station clock 17:26:59 drift = 21 seconds
27/04/2016 17:27:04.560 : 17:27:04 Stop Synchronising
...
28/04/2016 17:05:50.062 : 17:05:50 Start Synchronising
28/04/2016 17:15:00.764 : Writing today.ini, LastUpdateTime = 28/04/2016 17:15:00 raindaystart = 504.600006103516 rain counter = 504.899993896484
28/04/2016 17:15:00.764 : Latest reading: 3260: Data: 11 1D E4 00 33 7D 00 93 27 1F 36 00 06 93 06 00
28/04/2016 17:18:41.494 : Address changed
28/04/2016 17:18:41.494 : addr=FFFFprevious=3260
28/04/2016 17:18:41.494 : Sensor clock 17:05:53 drift = 3 seconds
28/04/2016 17:18:41.494 : Station clock 17:18:41 drift = 19 seconds
28/04/2016 17:18:46.494 : 17:18:46 Stop Synchronising
...
29/04/2016 17:05:58.325 : 17:05:58 Start Synchronising
29/04/2016 17:15:00.092 : Writing today.ini, LastUpdateTime = 29/04/2016 17:15:00 raindaystart = 505.200012207031 rain counter = 505.5
29/04/2016 17:15:00.092 : Latest reading: 3620: Data: 11 1F D0 00 36 6A 00 8D 27 1B 30 00 09 95 06 00
29/04/2016 17:25:46.587 : Invalid first block of memory
29/04/2016 17:27:02.667 : Address changed
29/04/2016 17:27:02.667 : addr=3634previous=3620
29/04/2016 17:27:02.667 : Sensor clock 17:06:41 drift = 1 seconds
29/04/2016 17:27:02.667 : Station clock 17:27:02 drift = 21 seconds
29/04/2016 17:27:07.668 : 17:27:07 Stop Synchronising
...
30/04/2016 17:06:49.103 : 17:06:49 Start Synchronising
30/04/2016 17:15:00.937 : Writing today.ini, LastUpdateTime = 30/04/2016 17:15:00 raindaystart = 505.5 rain counter = 505.5
30/04/2016 17:15:00.937 : Latest reading: 39E0: Data: 11 1C D5 00 23 7E 00 02 28 0A 14 00 00 95 06 00
30/04/2016 17:27:02.216 : Address changed
30/04/2016 17:27:02.216 : addr=39F4previous=39E0
30/04/2016 17:27:02.216 : Sensor clock 17:07:28 drift = 1 seconds
30/04/2016 17:27:02.216 : Station clock 17:27:02 drift = 1 seconds
30/04/2016 17:27:07.216 : 17:27:07 Stop Synchronising
...
01/05/2016 17:07:28.685 : 17:07:28 Start Synchronising
01/05/2016 17:15:00.236 : Writing today.ini, LastUpdateTime = 01/05/2016 17:15:00 raindaystart = 505.5 rain counter = 505.5
01/05/2016 17:15:00.236 : Latest reading: 3DA0: Data: 11 1F E4 00 43 79 00 27 28 22 30 00 08 95 06 00
01/05/2016 17:15:01.109 : Invalid first block of memory
01/05/2016 17:15:26.989 : Address changed
01/05/2016 17:15:26.989 : addr=1D88previous=3DA0
01/05/2016 17:15:26.989 : Sensor clock 17:08:15 drift = 1 seconds
01/05/2016 17:15:26.989 : Station clock 17:15:26 drift = 24 seconds
01/05/2016 17:15:31.989 : 17:15:31 Stop Synchronising
...
02/05/2016 17:08:23.560 : 17:08:23 Start Synchronising
02/05/2016 17:15:00.571 : Writing today.ini, LastUpdateTime = 02/05/2016 17:15:00 raindaystart = 505.5 rain counter = 506.399993896484
02/05/2016 17:15:00.571 : Latest reading: 4160: Data: 11 2E D0 00 54 77 00 D1 27 11 18 00 0C 98 06 00
02/05/2016 17:27:00.842 : Address changed
02/05/2016 17:27:00.842 : addr=4174previous=4160
02/05/2016 17:27:00.842 : Sensor clock 17:09:02 drift = 2 seconds
02/05/2016 17:27:00.842 : Station clock 17:27:00 drift = 27 seconds
02/05/2016 17:27:05.842 : 17:27:05 Stop Synchronising

Hope this information is useful and thanks for you help.

Ed

[steve]

I compared the code in MX and C1 and couldn't see any difference, other than a minor error in the drift reporting, which is why sometimes it doesn't report the sensor clock drift, and why it doesn't convert larger drifts into the equivalent smaller ones. But the mechanism appears to be the same. I'll try to find some time to plug in my Fine Offset station to give it a try, but not much of it still works - I'm not sure any external reading is received. If I can't get anywhere, I'll add some more debug logging into the sync process for the the next build, so we can see what's going on. It may just be something to do with the stations which have solar sensors, maybe the sync mechanism doesn't work so well for them. The fact that the console locks up sooner with MX may just be coincidence, or may be something to do with the underlying system USB code and the way it accesses the USB.

Can you confirm that with debug logging on, MX does occasionally log the message "Within 3 seconds of sensor data change, skipping read"?

[EdE]

Steve,

Can you confirm that with debug logging on, MX does occasionally log the message "Within 3 seconds of sensor data change, skipping read"

There are lots of these message in the diagnostics file when enhanced logging turned on.

A thought. It seems like Cumulus MX/Aercus 3083 freezes every three or four days and needs to be reset. I don't think I have ever known it happen in the first 24 hours of operation. Would it be possible to modify the day rollover code so that it reinitializes the synchronization timing in the same manner as it must do when Cumulus MX is first started - in this way every day would be like the first 24 hours from a syncing perspective.

In the meantime, I am going to switch back to Cumulus 1 and see if I get an equal number of "Within 3 seconds of sensor data change, skipping read" with that.

Best wishes and thanks for your work on Cumulus.

Ed

[steve]

A thought. It seems like Cumulus MX/Aercus 3083 freezes every three or four days and needs to be reset. I don't think I have ever known it happen in the first 24 hours of operation. Would it be possible to modify the day rollover code so that it reinitializes the synchronization timing in the same manner as it must do when Cumulus MX is first started - in this way every day would be like the first 24 hours from a syncing perspective.

It reinitialises the synchronisation every 24 hours - that's what it's doing when it prints the 'drift' messages.

I think I saw that in one case, the console had actually locked up while Cumulus was doing the synchronisation, and this is always a risk, it has to read the data more frequently in order to re-sync. Can you tell me whether it always (or more often) locks up during the re-sync, or does it happen equally at other times?

[EdE]

Steve,

Can you tell me whether it always (or more often) locks up during the re-sync, or does it happen equally at other times?

Of the three diagnostic files I have at present with lock ups in them, one of the lock ups occurred during a re-sync. Frequently the lock ups occur after a message in the log file about bad data from the station, e.g.

2016-05-11 06:20:20.731 New monthly record, month = 5: 2016-05-11 06:20 2.700 "High daily rain" 2016-05-11 00:00 2.400
2016-05-11 06:20:20.738 New monthly record, month = 5: 2016-05-11 06:20 8.400 "Highest monthly rainfall" 2016-05-11 00:00 8.100
2016-05-11 06:21:00.325 New monthly record, month = 5: 2016-05-11 06:21 2.700 "High hourly rain" 2016-05-11 06:04 2.400
2016-05-11 06:24:00.909 Ignoring bad data: pressure = 6553.5
2016-05-11 06:24:00.909 offset = 0
2016-05-11 06:24:00.944 New monthly record, month = 5: 2016-05-11 06:24 42.765 "High gust" 2016-05-02 15:33 17.106
2016-05-11 06:24:00.949 Ignoring bad data: outtemp = -1613
2016-05-11 06:24:00.949 Warning: large difference in rain gauge tip count: 1713
2016-05-11 06:24:00.949 Ignoring reading 1
2016-05-11 06:24:13.755 Operation timed out.
2016-05-11 06:24:13.755 Error reading data from station - it may need resetting
2016-05-11 06:24:16.755 Operation timed out.

Hope this helps,

Ed

[ConligWX]

Locks on these devices can happen from time to time as I had previous experience with other weather software like weewx.

Not sure if it is related but worth a look here

https://github.com/weewx/weewx/wiki/Fin ... USB-lockup

I found putting a ferrite core magnet on either end of the USB lead helped.

[EdE]

Steve,

I don't know if this helps. As I said above I switched back to Cumulus 1 to see how that went. At 17:46 yesterday it had a problem but seems to have recovered from it in a way MX does not.

The error light in the Cumulus 1 app was flashing - when I clicked it, this is what it showed...

16/05/2016 22:25:41 : Lost sensor contact!!! 73EC: Data: 12 25 DA 00 02 BF 9D FF 01 DF FF FF FF FF FF FF
17/05/2016 11:07:40 : Lost sensor contact!!! 75F4: Data: 00 2A E8 00 37 9B DD FF 01 E1 7F E6 FF 0D C0 7F
17/05/2016 17:46:23 : Data input appears to have stopped - check your station and connections

I looked in the diagnostics file for around the same time and it showed...

17/05/2016 17:30:00.936 : Writing today.ini, LastUpdateTime = 17/05/2016 17:30:00 raindaystart = 522.299987792969 rain counter = 522.299987792969
17/05/2016 17:30:00.936 : Latest reading: 76E4: Data: 16 29 F1 00 53 8E 00 AD 27 0A 1B 00 0A CD 06 00
17/05/2016 17:45:00.916 : Writing today.ini, LastUpdateTime = 17/05/2016 17:45:00 raindaystart = 522.299987792969 rain counter = 522.299987792969
17/05/2016 17:45:00.916 : Latest reading: 76F8: Data: 07 29 F1 00 51 8E 00 AB 27 11 25 00 04 CD 06 00
17/05/2016 17:46:23.494 : *** Data input appears to have stopped
17/05/2016 18:00:00.704 : Writing today.ini, LastUpdateTime = 17/05/2016 18:00:00 raindaystart = 522.299987792969 rain counter = 522.299987792969
17/05/2016 18:00:00.704 : Latest reading: 76F8: Data: 16 29 F2 00 51 8F 00 A8 27 18 2C 00 06 CD 06 00
17/05/2016 18:15:00.844 : Writing today.ini, LastUpdateTime = 17/05/2016 18:15:00 raindaystart = 522.299987792969 rain counter = 522.299987792969
17/05/2016 18:15:00.844 : Latest reading: 770C: Data: 07 29 F5 00 50 90 00 A7 27 0A 14 00 08 CD 06 00

Don't know if this is of any help.

Ed

[steve]

Cumulus has no way of recovering from the well-known Fine Offset USB lockup problem, it requires a reset of the console. "Data input appears to have stopped" indicates that the console has not supplied new data for over a minute - this does not necessarily mean that a USB lockup has occurred.