Cumulus Support

Hi,

AFAIK the date and time, etc. set on the Console has no bearing on the data received by Cumulus (either from the Log or real time) because Cumulus "works back" from the current time.

There are work-arounds if the barometric pressure needs calibration and it's now very easy to reset the logging interval of the Console (for when Cumulus is not logging directly) using Steve's excellent additional utility.

Cheers. Alan.

Well - sad to say I have joined the ranks of the people with this problem.
I love the system - it is interfaced with my house so I get all that lovely data that I can program my house with as well.
The problem is that every 5-10 days (it seems) I have to RESET the console.

UGH.

Sure would love a fix for this.
Bill

So I have what might be a stupid question - In the configuration for Cumulus there is a station type of "EasyWeather". I see the help for this says it is an obsolete type but you must use it if you are using EasyWeather in conjunction with Cumulus. I'm curious if people who are running EasyWeather are having the same lockup issues? In reading through this thread, it kind of seems that EasyWeather has the same issues as Cumulus (locking up, requiring a console reset to clear), but I'm not quite sure that is true. It is a little hard to determine conclusively from the postings.

Switching to EasyWeather doesn't sound like it will fix the problem, right?

rwilliam99 wrote:So I have what might be a stupid question - In the configuration for Cumulus there is a station type of "EasyWeather". I see the help for this says it is an obsolete type but you must use it if you are using EasyWeather in conjunction with Cumulus. I'm curious if people who are running EasyWeather are having the same lockup issues? In reading through this thread, it kind of seems that EasyWeather has the same issues as Cumulus (locking up, requiring a console reset to clear), but I'm not quite sure that is true. It is a little hard to determine conclusively from the postings.

Switching to EasyWeather doesn't sound like it will fix the problem, right?

Switching to Easy Weather does not solve my problem - I need to post automatically to the internet so that my house can know the wind speed and other parameters available from Cumulus.

Bill

BillTexas wrote:

rwilliam99 wrote:So I have what might be a stupid question - In the configuration for Cumulus there is a station type of "EasyWeather". I see the help for this says it is an obsolete type but you must use it if you are using EasyWeather in conjunction with Cumulus. I'm curious if people who are running EasyWeather are having the same lockup issues? In reading through this thread, it kind of seems that EasyWeather has the same issues as Cumulus (locking up, requiring a console reset to clear), but I'm not quite sure that is true. It is a little hard to determine conclusively from the postings.

Switching to EasyWeather doesn't sound like it will fix the problem, right?

Switching to Easy Weather does not solve my problem - I need to post automatically to the internet so that my house can know the wind speed and other parameters available from Cumulus.

Bill

But it sounds like if you change the configuration of Cumulus, you can use both - EasyWeather to communicate to the console, and Cumulus to do all the data mapping/logging/posting, etc.

I'm just not sure that will fix the console communication issue. It sounds kind of like it is some sort of hardware issue.

rwilliam99 wrote:

BillTexas wrote:

rwilliam99 wrote:So I have what might be a stupid question - In the configuration for Cumulus there is a station type of "EasyWeather". I see the help for this says it is an obsolete type but you must use it if you are using EasyWeather in conjunction with Cumulus. I'm curious if people who are running EasyWeather are having the same lockup issues? In reading through this thread, it kind of seems that EasyWeather has the same issues as Cumulus (locking up, requiring a console reset to clear), but I'm not quite sure that is true. It is a little hard to determine conclusively from the postings.

Switching to EasyWeather doesn't sound like it will fix the problem, right?

Switching to Easy Weather does not solve my problem - I need to post automatically to the internet so that my house can know the wind speed and other parameters available from Cumulus.

Bill

But it sounds like if you change the configuration of Cumulus, you can use both - EasyWeather to communicate to the console, and Cumulus to do all the data mapping/logging/posting, etc.

I'm just not sure that will fix the console communication issue. It sounds kind of like it is some sort of hardware issue.

Everything I have read in CUMULUS says that you should NEVER run the two programs together.

Bill

The evidence for this problem occurring with Easyweather does seem inconclusive; some people say they have experienced the problem with Easyweather and some others have said not. However, in general, people have been confusing this particular problem with other problems (as shown in this very thread) so that makes it harder to say definitely one way or the other.

You can run Easyweather and Cumulus at the same time if you chose to run Cumulus from the easyweather.dat file which EW produces, which is what rwilliam99 is referring to. This is not a very good way of using Cumulus in normal circumstances as you have to run EW and Cumulus 24 hours a day, and the resolution of the data input to Cumulus is not as good. But if someone was prepared to do this for a while as an experiment, the results might be interesting. Of course, if it turns out that EW doesn't get the lockup, it doesn't really help fix the problem in Cumulus and other software, because we still won't know why. As mentioned earlier, EW reads the data in an odd sequence, but I believe Jim has tried emulating this with his software, and still got the lockup.

Well, I'm trying one last thing - I re-arranged my USB cable and put the console on the wall, trying to reduce any interference from the TV and other associated electronics. If I still have to reboot my console after this, I will try and run it from EasyWeather and see what happens then.

Rob

rwilliam99 wrote:Well, I'm trying one last thing - I re-arranged my USB cable and put the console on the wall, trying to reduce any interference from the TV and other associated electronics. If I still have to reboot my console after this, I will try and run it from EasyWeather and see what happens then.

Rob

1. I have a shielded USB cable
2. There is nothing between the console and the weather stations except glass
3. there are no electronics other than the laptop that is connected to the console anywhere NEAR the console
4. The console is about 50 feet from the weather stations
5. I have 2-10 loss of connections to the weather station per day

Bill

I am not concerned with the occasional "lost contact" with the station itself. What I don't want to keep doing is rebooting/resetting the console every 5-10 days (which loses all the data since the lockup, depending on how quick I notice it has stopped receiving). I get 1-3 messages of "lost sensor contact" in Cumulus per day typically, but that doesn't bother me too much. As long as they are sporadic, it doesn't seem to make much difference. I'm hoping my latest attempt will be more successful.

I'm almost 100% convinced interference has nothing to do with it.

Interference on USB communication is handled by the USB controller, it will cause slower transfer rates and in worst case loss of connection as result. But never a lockup of the entire device.

Reading the above I think people are still confusing the USB lock with UHF interference issues. Interference on UHF is perfectly normal, you'll have to live with packet loss once and a while. And moving around your sensors/console/TV/furniture and wearing a tinfoil hat can reduce packet loss, but it hasn't anything to do with USB/lockup...
which imho still is a firmware bug, that pops up when doing USB communication at a bad moment.

The experiment of Jim in his pywws software so far let's me running livelogging for 7 days without lockup now. Previously lockups occured after 3hours to 14 days. So still 7 days to go to tell he might have found the workaround...

If it's looking promising, then perhaps I should do the same in Cumulus now, so we can join the validation effort.

Someone did propose doing the 'inverse' fix, i.e. only polling during the potentially 'critical' period and seeing if that caused lock ups to happen much more frequently. Not sure if it ever happened though.

TomV wrote:I'm almost 100% convinced interference has nothing to do with it.

Interference on USB communication is handled by the USB controller, it will cause slower transfer rates and in worst case loss of connection as result. But never a lockup of the entire device.

I'm pretty convinced it won't help either, but I'm just grasping at straws.....If I get another lockup with this, my next plan was to try the EasyWeather.dat file idea, to see if it locked up with EasyWeather too.

The experiment of Jim in his pywws software so far let's me running livelogging for 7 days without lockup now. Previously lockups occured after 3hours to 14 days. So still 7 days to go to tell he might have found the workaround...

That would be awesome if a workaround was found. This is annoying in what is otherwise a decent weather station (for cheap).

steve wrote:If it's looking promising, then perhaps I should do the same in Cumulus now, so we can join the validation effort.

To save you struggling to understand my software, here's a description of the algorithm:

1/ Fetch current data every half second until it changes. Store the timestamp this happens at as "sensor clock time".
2/ Wait until less than a minute before logging is due (based on the data item that says how many minutes since the last logging time), then fetch the data pointer every half second until it changes. Store the timestamp this happens at as "station clock time".
3/ Fetch data as normal, but avoid any USB reads or writes when (current time - sensor clock time) mod 48 is less than 3 or greater than 45, or when (current time - station clock time) mod 60 is less than 3 or greater than 57. If the data or pointer changes at an unexpected time, repeat steps 1 or 2.
4/ After 24 hours, repeat steps 1 & 2.

My measurements (of just one station!) show both clocks drift by less than 2 seconds in 24 hours, so with a +-3 second avoidance zone I need to remeasure the clock times every 24 hours. This may need adjusting in light of others' experiences. There is still a chance of lock ups during this measuring process. (I store the clock times in a file so measurements aren't required every time the software runs.)

All the above is in the context of a Linux computer with NTP synchronised clock. I don't know how Windows PCs set their clock these days, but if it jumps rather than drifts there could be problems.