Data "shift" with reboot

[philpugh]

Been having one or two USB lockups with the WS3083/RaspberryPi/CMX combination over the last week - after running OK since install in April this year.

I had closed the console down at the last problem - Saturday - and I suddenly thought does this reset the logger interval I had set with Steve's SetLogger utility so I closed down CMX (Debian still running) and plugged the 3083 console into the PC and checked - it doesn't change it. Good.

So ... I re plugged the 3083 console into the Pi and restarted CMX. No problems but when I checked the temperature graph there was a step change of a few degrees in the readings at the time of CMX being off- see image.

Temp.jpg

CMX was down fo no more than 3-5 minutes so I wouldn't expect this to happen to temp. There is also a change (obviously?) in the humidity graph. No other data values were noticeably altered. More interestingly the temp/humidity figures are now very close to the Davis VantageVue system whereas they are usually quite different - temp higher and humidity lower usually.

Any ideas as to why this might have happened?

[philpugh]

debug log for the restart.

getting a lot of the "Within secs.." and "*** Data input appears to have stopped" type messages.

debuglog.zip

[steve]

All I can tell you from the attached file is that at startup it downloaded one archive entry which it timestamped 15:31

2016-06-07 15:39:51.348 15:39:51 Read logger entry for 07/06/2016 15:31:50 address C0CC: 0A 30 16 01 3E E6 00 AA 27 0A 0E 00 0C 28 00 00 3C A7 06 03

This had an outdoor temperature reading of 23.0C.

At 15:50, the current data was

2016-06-07 15:50:00.702 Latest reading: C0F4: 08 2F 1C 01 3E E4 00 A8 27 0E 14 00 0C 28 00 00

which has 22.8C, then

2016-06-07 16:00:00.798 Latest reading: C108: 07 2F 1D 01 40 E4 00 A8 27 14 1B 00 0C 28 00 00 temp = 22.8C
2016-06-07 16:10:00.923 Latest reading: C11C: 08 2F 1D 01 3E E1 00 A8 27 14 18 00 0E 28 00 00 temp = 22.5C

I can't tell you anything about what went on before any of this, that would be in the previous diags file - if you would like to upload that, I can take a look at it. It looks like your temperature was falling rapidly at the time anyway, so it's quite likely correct. There was a period of nearly 10 minutes from the last logged entry to the point where you started Cumulus up again. Restarting Cumulus with a Fine Offset station is always likely to cause slight anomalies in the shape of the graphs because the console doesn't timestamp logger entries, and there are fewer data points available for the graphs.

The "skipping read" messages are normal if you have the "synch Fine Offset reads" turned on, you will get more of them with larger "read avoid period" settings. Larger values will also tend to cause "data stopped" messages if it has had to avoid reading data for more than a minute (they should probably be suppressed).

[mcrossley]

Note that the graph time scale is not linear (iirc) the 'missing' time plots are just skipped so you get the 'jump'. If you configure the x-axis to show regular time ticks, then you would have got a slope rather than a step which would probably look more natural. From what I (vaguely) recall doing that introduced other issues and I thought just plotting the available data was the best compromise.

[philpugh]

Mark,

The system was down for less than the logging period and as the extract from the Monthly MySQL database below shows there was a 3 degree drop in the one minute.

2016-06-07 15:00:00 28.2
2016-06-07 15:10:00 26.8
2016-06-07 15:20:00 26.0
2016-06-07 15:30:00 26.0
2016-06-07 15:31:00 23.0
2016-06-07 15:40:00 23.0
2016-06-07 15:50:00 22.8
2016-06-07 16:00:00 22.8
2016-06-07 16:10:00 22.5
2016-06-07 16:20:00 22.7
2016-06-07 16:30:00 22.7
2016-06-07 16:40:00 22.4

Which, while showing a gradual temp decrease, shows a 3 degree drop in the one minute period 15:30 to 15:31

I am not suggesting it's a problem with CMX but possibly another 'feature' of the FO group of stations? This one seems to be very susceptible to direct sun on the temp sensor "shield" which usually causes it to read a few degrees higher then the Vantage Vue and give much lower humidity figures. When cloudy the figures are usually not as far off.

FWIW the prior CMX diag log shows it logging the 26 degree reading at 15:30 just before I closed CMX down.

[mcrossley]

Very odd.

[steve]

The time stamp for the 1531 entry is approximate because there is no actual time available. It could be that MX is not estimating it very well. If that were so, then worst case is that value was closer to 1540 than 1530, and the other figures bear that out. That would mean a three degree drop in ten minutes. Still quite a large drop, but it's hard to see how MX could have been getting the live readings wrong before the restart.

[philpugh]

Looks like it was a precursor to possible failure - but not sure what failed!

At 11:45 this morning it seems to have failed - in a strange way. The Solar unit still appears to be working but I was not getting any data on the 3083 console for wind/rain/external temp/humidity! There was also another temp glitch showing - this time a 3 deg rise between successive 10 minute logs at 7am - no sun has been out today as yet.

CMX had detected a sensor loss and was ignoring external data

Managed to get it back up by changing the batteries and also unplugging and re-plugging the sensors. It didn't come back just changing the batteries - although the solar values were still being reported. If it was the batteries then almost 2 months for good quality AA batteries (Duracell Power Plus) seems a little excessive! Have to see how it goes. Having to climb ladders up to about 7 meters is not something I want to be doing regularly.

It's a good job this station is only an experiment (which will NOT be repeated )

It has also just started to rain heavily - it's picked up that at any rate! - but I've left the ladders up outside

Thanks all.

[AllyCat]

Hi Phil,

These (308x) stations transmit two separate data packets (from two separate microcontrollers) so the loss of only "Solar" or only "External" (Temp/Hum'Wind/Rain) Data is quite possible and commmon.

It didn't come back just changing the batteries - although the solar values were still being reported.

For any "Loss of Contact" with these stations (and certainly after changing the batteries), the first thing to try is to "resynchronise" the Console by holding in the <Down-Arrow> button for at least 8 seconds.

AFAIK, the external temperature is derived from the Humidity sensor (which is perhaps the most "unreliable" of the sensors) so I would expect the Humidity values also to be jumping? If not, the probable "glitch" in the synchronisation of the (External) transmitter suggests a rather more fundamental failure of the controller, perhaps fatal.

Cheers, Alan.

[philpugh]

Thanks Alan,

Since changing the batteries it seems to be behaving itself (touch wood). It wouldn't respond to the down arrow key - which it did on other occasions.

With regard to the two micro-controllers - doesn't the one associated with the solar sensors also handle the rain gauge? This, like temp/ humidity/wind etc were all displaying --- on the console.

[AllyCat]

Hi Phil,

With regard to the two micro-controllers - doesn't the one associated with the solar sensors also handle the rain gauge?

No, the rain cable just "loops through" the Solar Pod and down to the external transmitter.

To minimise the physical changes for Solar versions, Fine Offset simply changed the 2-contact "Rain" socket (RJ11) to a 6-contact (RJ12) socket on the transmitter. The two centre contacts still carry the Rain sensor (reed switch) and Ground signals (from the RJ11 socket on the underside of the Pod). So the rain sensor can still be plugged directly into the transmitter if the Solar Pod is not required or defective. Of the four additional wires/contacts, one is not used, one carries the (encoded) solar data to the radio transmitter, one is for (charging) the battery and the last is described as "Reset".

The two controllers "communicate" in some way (so that they don't both transmit at the same time) and each has been known to crash on occasions. A crash may then overload the battery, so it can be dfficult to identify the root cause of any particular failure. But it's possible that your original batteries are still fine and the transmitter microcontroller just needed a reset/restart.

Cheers, Alan.

[philpugh]

Thanks Alan - I will have to check the batteries next time this happen.