Cumulus Support

davidrg wrote:My guess is that the problem is caused by the device trying to write to a memory address while the PC is busy reading from it. Perhaps the USB chip and microcontroller are deadlocked. Or the microcontroller trying to write puts the USB chip in some invalid state while the microcontroller writes garbage to memory preventing its own memory functions from working.

I think this is the theory that Jim and his users have.

Cumulus reads every 10 seconds, so I don't have to bother synchronising with the data being updated, so if it is a clash between the PC reading and the console writing, then Cumulus is going to hit the problem more often. I guess I could look at reading the data less often.

steve wrote:

davidrg wrote:My guess is that the problem is caused by the device trying to write to a memory address while the PC is busy reading from it. Perhaps the USB chip and microcontroller are deadlocked. Or the microcontroller trying to write puts the USB chip in some invalid state while the microcontroller writes garbage to memory preventing its own memory functions from working.

I think this is the theory that Jim and his users have.

Cumulus reads every 10 seconds, so I don't have to bother synchronising with the data being updated, so if it is a clash between the PC reading and the console writing, then Cumulus is going to hit the problem more often. I guess I could look at reading the data less often.

Given that these are two completely independent processes, If this truly is the root cause, no change to Cumulus will completely prevent it, and the problem will exist for Easy Weather too. Such an obvious bug in firmware will be found and corrected shortly - it seems a shame to hobble Cumulus to possibly reduce (not eliminate) what will be a short lived problem for a few users. Easy to say when I'm not one of those users, granted, but I like (and leverage) the 10 second updates.

Charlie wrote:Given that these are two completely independent processes, If this truly is the root cause, no change to Cumulus will completely prevent it, and the problem will exist for Easy Weather too. Such an obvious bug in firmware will be found and corrected shortly - it seems a shame to hobble Cumulus to possibly reduce (not eliminate) what will be a short lived problem for a few users. Easy to say when I'm not one of those users, granted, but I like (and leverage) the 10 second updates.

It's not short lived - the firmware in these stations is not upgradable, and the manufacturer is not persuaded a problem exists, as far as I know. It's possible future stations won't have the problem, but I wouldn't hold your breath.
I doubt there's large numbers of rejected stations finding their way back to China. Retailers will test the customer return, find it's working and sell it as "reboxed" or similar discount stock.

Maybe a stupid remark, but if the hangup depends on the timing that you read from the USB port, couldn't it be prevented then by chosing a different timing, one that does not conflict with the unit itself accessing memory?

So if the unit writes to the memory every 48 seconds, to avoid a crash you should try to figure out the time the unit writes (I think Jim does this in pywws to minimize USB traffic). But instead you first wait 24 seconds and then start to read every 48 seconds.
So you have a 24 seconds margin on both sides to be safe.
It will normally take a while before two clocks get as much as 24 seconds out of sync?

TomV wrote:Maybe a stupid remark, but if the hangup depends on the timing that you read from the USB port, couldn't it be prevented then by chosing a different timing, one that does not conflict with the unit itself accessing memory?

So if the unit writes to the memory every 48 seconds, to avoid a crash you should try to figure out the time the unit writes (I think Jim does this in pywws to minimize USB traffic). But instead you first wait 24 seconds and then start to read every 48 seconds.
So you have a 24 seconds margin on both sides to be safe.
It will normally take a while before two clocks get as much as 24 seconds out of sync?

This is, roughly, what I'm experimenting with at the moment. I'm avoiding both the 48 second outside sensor clock and the one minute console clock (as this controls writing of logged data every 5 minutes). I've set the margin at 3 seconds either side of the expected time, and remeasure the time every day. It's too soon to say if this cures the problem, but I live in hope.
A side effect is that I'm getting a measure of how stable the clocks are. My outside sensors are losing about 1 second a day and the console clock is gaining about 1 second a day.

Just wanted to comment and report that I got an Ambient 2080 2 weeks and was loving the Cumulus software.

I recently have encountered the above problems and I am trying to find a solution as well. So far, the only thing that works is a reset, which is unfortunate since i lose all my date. Luckily the data is backed up on weather underground.

I will be following the thread for advice.

Thanks!

Just tried clearing memory on Easyweather and Cumulus started up and loaded...maybe a good fix here, for the symptoms anyway.

PSV88 wrote:Just tried clearing memory on Easyweather and Cumulus started up and loaded...maybe a good fix here, for the symptoms anyway.

If EW was able to talk to the station, it may not be the same problem. Please could you zip up the diags folder and attach it.

jim-easterbrook wrote: This is, roughly, what I'm experimenting with at the moment. I'm avoiding both the 48 second outside sensor clock and the one minute console clock (as this controls writing of logged data every 5 minutes). I've set the margin at 3 seconds either side of the expected time, and remeasure the time every day. It's too soon to say if this cures the problem, but I live in hope.

Allright I see the software change you did now - I'm going to upgrade to the latest pywws version, connect my wh1080 again, run the livelog and let you know when/if it hangs.

steve wrote:

PSV88 wrote:Just tried clearing memory on Easyweather and Cumulus started up and loaded...maybe a good fix here, for the symptoms anyway.

If EW was able to talk to the station, it may not be the same problem. Please could you zip up the diags folder and attach it.

Thanks for the reply.

It turns out that was short-lived and i had to reset the console in the end.

Not sure how to send the diags folder...

Not sure how to send the diags folder...

On the link at the top of the page "Please click here before posting. Help me to help you!" you will find the details in the 9th paragraph.

Paul

I've been having this problem ever since I got my WS-2080 unit back in March. I've read all the postings and tried pretty much everything here. Running version 1.9.2. I have my base station hooked up full time to a computer I also use to record TV, which stays on 24/7. The base station sits on the stand that has the TV, Stereo, DVD Player, game consoles, etc. So far, I've tried:

• A new USB cable (tried 3 of them actually)
• Putting clamp on ferrite filters on both ends of the USB cable
• Turning off the power saving setting on the USB ports
• Set the disableInit setting in Cumulus (I can't remember the exact parameter)
• Yesterday I tried to route the USB cable away from all the other cables and moved the base station to a wall mount, in an effort to reduce any interference issues - too early to tell if that would make any difference.

As of now, it seems like the station locks up between 5 and 10 days. The only resolution that seems to work is to do the hard reset (shutdown Cumulus, remove battery from the base station, remove USB cable, put battery back in, wait for it to talk to station and then restart cumulus). Although I've had a few instances where I could get communication going again by restarting Cumulus, it doesn't really seem to work, as it seems to have lost contact with the station and I end up doing a hard reset anyway.

While I love all the functionality of the station and this software, this issue is frustrating, as it causes me to lose data every time I have to reset it. I wish FineOffset would fix the issue, but it doesn't look like that will be forthcoming.

Are there other things I can/should try? Should I try and load the beta version (1.9.3)? I've not seen anyone have any permanent success with any fixes.

Thanks for all your hard work.

rwilliam99 wrote:Should I try and load the beta version (1.9.3)?

That won't help, unfortunately. The best we can hope for is that someone devises a work around for what is apparently a problem with the station hardware/firmware.

rwilliam99 wrote: it seems like the station locks up between 5 and 10 days.

Hi,

Using what logging interval? Some members have suggested (that their Console has) a "bad" memory location, but perhaps more likely is "poor software behaviour" at some particular (memory) locations.

With the low price of these stations (compared with others) and the general (un)reliability of the sensors, perhaps the best solution is to run two Consoles (buy a second complete kit for the spares) or even run two separate systems. Unfortunatelly Cumulus can only connect to one at a time, but if that fails you should be able to recover any lost data from the log in the second Console. Using different logging intervals might even give a little more insight into the nature of this issue.

Cheers, Alan.

AllyCat wrote:

rwilliam99 wrote: it seems like the station locks up between 5 and 10 days.

Hi,

Using what logging interval? Some members have suggested (that their Console has) a "bad" memory location, but perhaps more likely is "poor software behaviour" at some particular (memory) locations.

It is now using the default logging interval (30 mins?). After re-setting the console so many times, I gave up resetting any non standard defaults. Like the time zone - the time on the console is now 3 hours off, since it defaults to eastern time.

The time between lockups is variable - I've been unable to find any commonality between them or any pattern.