Cumulus MX 3038 and Error reading data from station

[icnmfabro]

Hi ... I have a Froggit weather station WH3080 just bought on ebay. I'm being used Cumulus MX 3038 on raspberry PI and USB 2.0 powered hub , to store data and record them on the internet , after a day and a half of Cumulus MX operation no longer captured the data and gave this error:
Error reading data from station - it may need resetting .
I reset the monitor, detached and riattacato the original USB 2.0 cable from the hub and done ravviare raspberry pi. Now it seems reoperation but I need to know the cause of this error and how to correct it permanently if possible.

[steve]

It's a common problem with Fine Offset stations, there are hundreds of posts about this in the forum. It does seem that the Solar models are more susceptible. You can use the 'Synchronise Fine Offset Reads' setting to get Cumulus to try to work around the station's design fault. There is a suggestion that this does not work as well with MX as it did with Cumulus 1, but the reasons for this are unclear.

[ConligWX]

lockups are common on some models, try adding a ferrite core/sleeve to each end of the USB lead.

[icnmfabro]

The ferrite filter on the end of the USB cable does not solve anything ...
any other ideas ? you can solve the problem of this bug in the WH3080 ?

[steve]

Presumably you are using the "Synchronise Fine Offset Reads" setting - have you set a FOReadAvoidPeriod in Cumulus.ini? See this thread - https://cumulus.hosiene.co.uk/viewtopic.php?f=27&t=15190

[icnmfabro]

I tried the option "Synchronise End Offset reads", but with this option enabled Cumulus MX does not display data, at least for that moment I tried it. Now I adjusted better to the NTP client on Raspberry PI and Cumulus.ini is configured with:
SyncFOReads = 0
FOReadAvoidPeriod = 60.
I try and let you know.

[steve]

SyncFOReads = 0

This means it is turned off, so will have no effect.

FOReadAvoidPeriod = 60

With this value (60 seconds), if you do turn it on, Cumulus won't attempt to read data for 60 seconds either side of the station updating its data. The station does this every 48 seconds and every 60 seconds. So Cumulus will never attempt to read any data.

[icnmfabro]

Cumulus seems to accept the control activation SyncFOReads = 1. reading of wh3080 stations manually sending data occurs every 48s. seconds that I should put in FOReadAvoidPeriod command?
For the moment I left FOReadAvoidPeriod = 3.

[steve]

As described in the thread that I linked to, if the default setting apparently doesn't help, you need to look at the MX diags files to see what 'drift' values you are getting, and adjust the period to suit.

[icnmfabro]

I found this value in the last format files into the directory MXdiags .
so that I could add value in FOReadAvoidPeriod command ?

2016-06-03 17:52:00.443 Station clock 17:52:00 drift = 0 seconds

[steve]

That's good, that says that the console clock and the Pi clock are in step. There is a bug in build 3038 where it doesn't always log the transmitter clock drift, so you can't tell how far that's drifting compared to the Pi. Just stick with the default for now and see how it goes.

[icnmfabro]

Ok!!

[stephenmh]

Just a quick update, may be a complete coincidence but I have disconnected the LAN cable and have been running the Pi with a Wi-Fi dongle for 18 days. During this time, I have not experienced a single lockup. I'll continue to monitor, but this is by far the longest period that the station has worked without a reset.

Steve

[steve]

I believe the ethernet and the USB interface go through the same hardware at some point on the Pi? So perhaps use of the ethernet interface was somehow affecting the timing (or whatever) of the USB interface and causing the station's interface to lock up. Who knows - but that's an interesting discovery.

[jpsc]

I believe the ethernet and the USB interface go through the same hardware at some point on the Pi? So perhaps use of the ethernet interface was somehow affecting the timing (or whatever) of the USB interface and causing the station's interface to lock up. Who knows - but that's an interesting discovery.

Very plausible, I have both USB and ethernet on a Pi 2 and still get the odd lockup, even with the avoidance settings.