Cumulus Support

I recently acquired my Fine Offset from Maplin (special offer £60 at beginning of October '12) and have had all of the problems mentioned in this topic, with frequent loss of contact between my laptop and the base unit, and between the base unit and the sensors. My aim is to have the station running 24/7. I have often reset the base unit by removing USB and batteries - this messes up the data, but at least it unfreezes things. I then tried changing things:

Firstly I tried changing to a different laptop. No better.
Secondly I tried moving the base unit nearer the window. I used a USB extender cable for this. No better.
Thirdly I tried changing Windows device manager to force it to maintain power to USB ports, even when not in use. This ran for nearly 24 hours before locking up but, No better.
Finally, looking at advice on this forum, I bought a fully shielded USB cable (Male A to Male A) from Maplin (£9), plugged it in and restarted everything. That was about 10 days ago now and so far the problems HAVE NOT RECURRED (he said, touching the wood of his desk).

Maybe this will give some of you hope. Until it all goes horribly wrong again,

Cheers

Sandy

Sandy wrote: Finally, looking at advice on this forum, I bought a fully shielded USB cable (Male A to Male A) from Maplin (£9), plugged it in and restarted everything. That was about 10 days ago now and so far the problems HAVE NOT RECURRED (he said, touching the wood of his desk).

Do you have a link for that cable? I've tried 3 different cables and my current cable is a high quality cable with two clamped on ferrite filters on it. It did not make any difference.

Rob

rwilliam99 wrote:

Sandy wrote: Finally, looking at advice on this forum, I bought a fully shielded USB cable (Male A to Male A) from Maplin (£9), plugged it in and restarted everything. That was about 10 days ago now and so far the problems HAVE NOT RECURRED (he said, touching the wood of his desk).

Do you have a link for that cable? I've tried 3 different cables and my current cable is a high quality cable with two clamped on ferrite filters on it. It did not make any difference.

Rob

I picked the shortest cable (1.5m) Here's the link:
http://www.maplin.co.uk/usb-2.0-a-to-a-leads-97265

Cheers

Sandy

Sandy wrote:

rwilliam99 wrote:

Sandy wrote: Finally, looking at advice on this forum, I bought a fully shielded USB cable (Male A to Male A) from Maplin (£9), plugged it in and restarted everything. That was about 10 days ago now and so far the problems HAVE NOT RECURRED (he said, touching the wood of his desk).

Do you have a link for that cable? I've tried 3 different cables and my current cable is a high quality cable with two clamped on ferrite filters on it. It did not make any difference.

Rob

I picked the shortest cable (1.5m) Here's the link:
http://www.maplin.co.uk/usb-2.0-a-to-a-leads-97265

Cheers

Sandy

Sandy, this is interesting but I'd like to see how you get on with this over a longer period of time as mine (Maplin special bought dec 11) seems to lock up at fairly regular intervals around once very 2 months.

You could be on to something though.

jim-easterbrook wrote: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.

The recent colder weather has increased the drift rate of the outside sensors, but it's still less than 3 seconds per day.

nikkidev wrote:I have a Fine Offset (N96GY from Maplin) frequency 433.9MHz purchased this year. I'm not running continuously, probably at most for a couple of hours a day. It locked up for the first time 2 days a go, I never had this problem with my old Fine Offset. I disconnected the USB lead and removed one battery which I replaced after 5 s. I was expecting to lose data since the last upload of data the previous night but I don't appear to have done. I did however need to reset my relative pressure and I got a massive rain rate/rain spike at the time of reset which I think I've mainly managed to remove from the data files now.

The only thing I might have done differently the previous night, was to shut my computer down quickly without exiting from Cumulus properly.

(related but not really to do with this thread: The only record I can't seem to get rid of is the all time high hourly rain which was generated at the time of the reset. I can't see which file I need to edit to get rid of this and what to replace it with. Anyone got any ideas?)

It's gone and done it again following me forgetting to shut down Cumulus before shutting down my computer (may be a coincidence). Prior to this I was getting rainfall readings during the day when there wasn't any. I reset the console as before as well as deleting its memory. On loading cumulus and viewing graphs, there were big jumps in readings for outside temperature, pressure, rainful and humidity at the time the computer shut down and then readings which gradually decreased/increased to the current readings when the station was reset. I guess these are some sort of interpolated reading which I now need to delete.

That looks OK to me for what you have done.

You shutdown Cumulus at around 21:45, cleared the station memory, restarted Cumulus just before midnight.

So the readings from 21:45 flat line to restart when the current reading takes over. You have cleared the station memory so there is no data for Cumulus to read from the logger to 'fill in the gap'

One thing that might happen when you reset the station is that the 'current data pointer' gets reset to the beginning of memory, but the memory itself doesn't get cleared. Cumulus will then happily download the logger entries it needs to catch up from when it last ran, without knowing that those entries do not actually correspond to the period for which it needs data; it is actually 'old' data.

I don't know how you clear the actual data, perhaps you need to wait a while with the batteries out and USB cable unplugged. I seem to remember one of our hardware experts saying that Fine Offset changed the type of memory they use for the logger at some point, so maybe they are now using some kind of non-volatile memory?

If you know that this is likely to happen (i.e. you have just had to reset the station), you can force Cumulus to ignore the logger data at start up by editing cumulus.ini and changing the line:

UseDataLogger=1

to

UseDataLogger=0

Then as soon as Cumulus has finished starting up, go into the station settings and turn 'Use Data Logger' back on again.

Note that you will have a gap in your data (unavoidable after a reset) and today's rainfall etc may need adjusting, depending on how long it's been since Cumulus last had valid data.

mcrossley wrote:That looks OK to me for what you have done.

You shutdown Cumulus at around 21:45, cleared the station memory, restarted Cumulus just before midnight.

So the readings from 21:45 flat line to restart when the current reading takes over. You have cleared the station memory so there is no data for Cumulus to read from the logger to 'fill in the gap'

Actually I shut down the computer just before midnight (and hence Cumulus) and reset the station after 10 am the next day. I see what you mean by the flat lining before I shut down, maybe the station wasn't receiving data from the sensors before I shut down.

steve wrote:One thing that might happen when you reset the station is that the 'current data pointer' gets reset to the beginning of memory, but the memory itself doesn't get cleared. Cumulus will then happily download the logger entries it needs to catch up from when it last ran, without knowing that those entries do not actually correspond to the period for which it needs data; it is actually 'old' data.

I don't know how you clear the actual data, perhaps you need to wait a while with the batteries out and USB cable unplugged. I seem to remember one of our hardware experts saying that Fine Offset changed the type of memory they use for the logger at some point, so maybe they are now using some kind of non-volatile memory?

If you know that this is likely to happen (i.e. you have just had to reset the station), you can force Cumulus to ignore the logger data at start up by editing cumulus.ini and changing the line:

UseDataLogger=1

to

UseDataLogger=0

Then as soon as Cumulus has finished starting up, go into the station settings and turn 'Use Data Logger' back on again.

Note that you will have a gap in your data (unavoidable after a reset) and today's rainfall etc may need adjusting, depending on how long it's been since Cumulus last had valid data.

Thanks, I'll have a look at these suggestions. If I go back and delete data, do I take out all the lines corresponding to the bad data including the date/time ie. leave a complete gap?

nikkidev wrote:If I go back and delete data, do I take out all the lines corresponding to the bad data including the date/time ie. leave a complete gap?

Delete the entire line, yes, but make sure not to leave any blank lines in the file.

OK, I have been infected by the lockup on a brand new WS-2080. I ran EasyWeather for the first couple of hours, then switched to Cumulus; I uninstalled EasyWeather before installing Cumulus.

Cumulus came up just fine, ran for about 36 hours or so, after that the only thing that changed on the display was the blinking Error indicator.

Restarted the computer, restarted Cumulus; same thing...just the Error indicator.

Uninstalled Cumulus, deleted directory

Reinstalled EasyWeather...works just fine

Uninstalled EasyWeather

Re-installed Cumulus...same thing...just the Error indicator

Re-installed EasyWeather...works just fine

I have both installed now, only EasyWeather is running and it works. I don't have the log files right now, but I can upload them if that helps.

I don't think resetting the 2080 is a fix, apparently it works just fine. Resetting it to get Cumulus to work isn't doing anything other than masking the real issue (whatever that might be); since EasyWeather works in all cases.

Any specific settings or config entries that would be useful to debug the issue?

This is all running on Microsofts second worse OS (Vista 64bit...second only to Windows 8)

ron

If you zip up the diags folder and attach it, I can see if it's the same problem. Note that uninstalling/reinstalling Cumulus is unlikely to ever have any effect, and that clicking on the error light will show you the reason for the error light flashing.

zipped log files attached...


EasyWeather is still working like a charm. Cumulus will not read data still.

It's not the "USB lockup" problem, which is why EW will read data from the station.

According to the manufacturer, the first two bytes of memory have to be set to 55 and AA (in hex) to indicate that the firmware has initialised correctly. Your second byte is zero:

12/6/2012 18:29:31.301 : Request EW data block, addr = 000000
12/6/2012 18:29:31.321 : EWUSB: EW startup data line 01 55 00 00 2A 00 F5 43 04
12/6/2012 18:29:31.329 : EWUSB: EW startup data line 02 60 E1 0A FB 9F 1E F5 FF
12/6/2012 18:29:31.337 : EWUSB: EW startup data line 03 05 47 08 25 09 00 00 04
12/6/2012 18:29:31.345 : EWUSB: EW startup data line 04 86 00 00 9B 04 00 A0 4A
12/6/2012 18:29:31.345 : EWUSB: Bad startup block 0, discarding. Byte 0 = 55 Byte 1 = 00

Cumulus checks this and won't proceed if the station hasn't initialised properly. Normally, clicking on the flashing error light will show you an appropriate error message, and information on this problem can then be found in the FAQ:http://wiki.sandaysoft.com/a/FAQ#When_I ... ialised.22

For reasons known only to whoever wrote Easyweather, it doesn't perform the specified check.