Cumulus Support

Yes, I can see from the other thread that these stations can be powered via USB.
The specification for example the WS-2080 says: "Base Station, minimum 12 month on 2xAA Alkaline batteries".
So the current required is lower then: 2500mAh / (24 hours * 365 days) = 0.285mA

I've done some tweaks to the timing of the data reading which may make the problem go away. I'll test it over the next few days.

madsandrup wrote:Yes, I can see from the other thread that these stations can be powered via USB.
The specification for example the WS-2080 says: "Base Station, minimum 12 month on 2xAA Alkaline batteries".
So the current required is lower then: 2500mAh / (24 hours * 365 days) = 0.285mA

Ah, but some stations (mine at least) use a mechanical relay powered from the USB to switch the power feed over, I'm guessing that relay uses far more current than the station does on batteries.

Yes, that is correct, A small relay will normally draw around 30mA coil current.

I may be way out in left field but I had a thought because it does it at the same time every day what else happens at the same time every day. The error happens at the time that I started the system the first time. After rebuilding OS this week I started at 9:35 pm and that give or take a minute is the same time the error shows.

To come to the point as far as I can find out RPI2 goes out to NTP server every 24 hours. There have been reports of it locking up the system for just a few seconds if none of the servers are found.

I changed the NTP servers to US servers so far it has run for 27 hours and no errors.
Just a thought

Don

It happens at the same time every day because the synchronisation is done at the same time every day. I think the NTP server change you've done is probably not related, but perhaps it is masking the problem.

I have come to the conclusion that it's an issue with the timing of the USB reads rather than a power issue, and the changes that I made and am testing seem to be working OK so far, but I will need to test for a few more days.

Do you still have 'synchronise Fine Offset reads' turned on, having rebuilt your system?

At the present time it is off

Don

You shouldn't see the problem at all with it turned off.

The error happened Friday and Saturday with the check off. That is why I was looking at other reasons for the errors.

Don

Could you zip up the mxdiags folder and attach it, please, so I can look at those?

MXdiags files attached

Friday has gone from the logs now, but the error on Saturday could well be related to the issue you mentioned, as there were problems with updating the internet at the same time:

2015-04-18 21:34:55.111 Error uploading realtime.txt to realtime.txt : Could not resolve host 'www.qsl.net'
2015-04-18 21:35:00.060 Writing log entry for 4/18/2015 9:35:00 PM
2015-04-18 21:35:00.062 Written log entry for 4/18/2015 9:35:00 PM
2015-04-18 21:35:00.067 Writing today.ini, LastUpdateTime = 4/18/2015 9:35:00 PM raindaystart = 19.75984249953 rain counter = 19.78346454675
Latest reading: 18F0: 19 24 C3 00 4C 38 00 BE 20 00 07 00 0E 8B 06 00
2015-04-18 21:35:00.075 Updating CWOP
2015-04-18 21:35:00.179 WU update: An error occurred while sending the request.
2015-04-18 21:35:11.069 The operation has timed-out.
2015-04-18 21:35:11.070 Error reading data from station - it may need resetting

There was another problem with communication with the station in the early hours of this morning:

2015-04-20 00:35:00.761 Updating CWOP
2015-04-20 00:35:06.482 WU Response: OK: OK
2015-04-20 00:37:00.743 *** Data input appears to have stopped
2015-04-20 00:38:00.745 *** Data input appears to have stopped
2015-04-20 00:39:00.748 *** Data input appears to have stopped

Yes I saw that I stopped MX and restarted and it has been running ok after that.

Don

Just a little update I ran MX for 48 hours with no errors. Checked the "Synchronize Fine Offset reads" and 24 hours later "Error Reading data from station" was back along with 32 deg F for low temp.

Don