Cumulus Support

Hi - new member here from Western Australia

Sorry about the long post, but hopefully I can add some useful info to the discussion.

I bought a Digitech XC0348 weather station a coule of days ago to replace my failing Oregon Scientific unit which has up til recently given me six years of unfailing service. The Digitech seems to be a rebadged WH1080 - lsusb shows it as "ID 1941:8021 Dream Link WH1080 Weather Station".

Yes, I'm running Linux, of the Debian variety

I installed wveiw from http://www.wviewweather.com/ and immediately had major problems with the Digitech data format, initially with the '55 AA' bytes seeming to be corrupted. Resetting the station fixed the problem, but only for several minutes then it stopped again. Repeatably, every time.

This showed up as no USB communication, so I guess this fits as 'USB locks up completely', although under the surface it hasn't really locked up, just can't synchronise because the received data is not what is expected.

So, being a programming type, I modified the wview code to print out some diagnostics and came up with somr VERY interesting results - on this version of the station, supposedly a WH1080, the second byte of '55 AA' seems to be used for another purpose. First some lines from my log, then I'll attempt to explain what might be happening:

Sometimes after a reset, this happens. It is unrecoverable, and needs another reset:
Dec 9 14:49:16 WH1080: write data request - offset 0
Dec 9 14:49:16 WH1080: Magic Number 00 0aa
Dec 9 14:49:16 WH1080: readFixedBlock bad magic number 00 AA
Dec 9 14:49:16 WH1080: You may want to clear the memory on the station console to remove any invalid records or data...
Dec 9 14:49:16 WH1080: Initial fixed block read failed

After another reset:
Dec 9 14:52:51 WH1080: Waiting for the next weather record to be ready in the console to populate initial wview sensor
readings (this could take some time);
Dec 9 14:52:51 WH1080: While waiting be sure you are receiving all sensors on the console;
Dec 9 14:52:51 WH1080: if not, you may need to relocate the sensors or the console.
Dec 9 14:52:51 WH1080: write data request - offset 0
Dec 9 14:52:51 WH1080: Magic Number 57 0aa
[...]
45 seconds later notice the change from '0aa' to '003' (ignore my bad 3-digit format
Dec 9 14:53:26 WH1080: write data request - offset 0
Dec 9 14:53:26 WH1080: Magic Number 57 0aa
Dec 9 14:53:28 WH1080: write data request - offset 0
Dec 9 14:53:28 WH1080: Magic Number 57 003
[...]
1.5 minutes later '003' changes to '004'
Dec 9 14:55:01 WH1080: write data request - offset 0
Dec 9 14:55:01 WH1080: Magic Number 57 003
Dec 9 14:55:03 WH1080: write data request - offset 0
Dec 9 14:55:03 WH1080: Magic Number 57 004
[...]
45 seconds later
Dec 9 14:55:49 WH1080: write data request - offset 0
Dec 9 14:55:49 WH1080: Magic Number 57 004
Dec 9 14:55:51 WH1080: write data request - offset 0
Dec 9 14:55:51 WH1080: Magic Number 57 005
[...]
1.5 minutes later
Dec 9 14:57:25 WH1080: write data request - offset 0
Dec 9 14:57:25 WH1080: Magic Number 57 005
Dec 9 14:57:26 WH1080: write data request - offset 0
Dec 9 14:57:26 WH1080: Magic Number 57 007

The second byte of '55 AA' is now being incremented about multiples of 45 seconds, but not every time.

During this time data was not being retrieved as the code was failing because the '55 AA' magic number was not found, which is exactly what I would have expected to happen. But what does the new value of the second byte mean?

All I can think of is that it is indicating the number of unread records available in the station.

Any comments?

I moved this post from the 'USB lockup' thread as it's about a different issue.

What you've observed is interesting. But I've never seen the first two bytes changing, and it's my belief that they are supposed to go to 55 AA and stay there. I suspect that what you're seeing is the firmware going through some kind of attempt to initialise the station, using that byte as a status value to control the process. It can't be a counter of unread records, as that would only increase every few minutes when the data pointer moves on.

Hi Steve

No worries about the moved post - I'll keep testing and see if I can come up with any more ideas.

I read the (entire 22 pages) of the USB lockup thread, and several times it was mentioned that some of the newer firmware seemed to be behaving differently in the last 12 months or so, and I thought this might be an indication of that.

But now I've got a new thread - I'll that that as a bonus

Steve

sboak wrote:I'll keep testing and see if I can come up with any more ideas.

That'll be great, thanks.

But now I've got a new thread - I'll that that as a bonus

Like the complete USB lockup problem, this is another issue that causes people problems. It'll be good to have this parallel thread about this issue, and hopefully you/we can come up with some ideas about these two bytes and what Cumulus might be able to do about it.

After a delay for the Christmas Holidays, I've finally got back onto testing my weather station.

Unfortunately my first post seems to have been the result of a spurious glitch in resetting of the station - in a couple of weeks of testing I have not seen that situation arrise again. I'm not sure what that means, except that it and my current testing is pointing to the device firmware being extremely dodgy!

To really investigate my USB comms issues I could think of no way to really get to the meat of the problem other than write my own testing program so that I can play with everything from command packets to timing. The output of my test program is in the code section below.

Some explanation:

The loop runs once per second, reading 32 bytes from eeprom offset 0 (base system data), then 32 bytes from offset 0x100 (first two weather records). As shown below, that's 2 packets sent and received per loop, this time ruuning for about 1100 seconds.

The first two bytes of memory are currently read as 0x77 and 0xAA, and have that value for probably 95% of the time. Occasionally I get 0x57, 0xAA. The first weather data record still seems to be valid with either of these values, but never seems to be completed and never moves on to record 2. Also, I have never seen the 'memory circle' on the display change from zero or empty. The first 16 bytes of the base data do not change, but the second 16 bytes (0x10 to 0x1F) are changing all the time and seem to be mostly random rubbish. For example the data record count (0x1B,0x1C) and current data pointer (0x1E,0x1F) are completetly wrong.

I have done numerous (hundreds) of USB disconnects and battery removals but to no avail in getting data to read out correctly. I have also tried several different lengths and qualities of USB cables, and runing the station with and without batteries.

I have tried running Cumulus (admittedly on a virtual machine running XP so it might not be a valid test) but it will not accept data from the station either, I assume because of the 0x77 byte.

I will shortly have a go at monitoring the data on the USB bus and check that it matches what I am receiving in my program, but I'm not expecting to see any problem there.

If I get time, I might pull the display station apart and see if there are any hardware fixes that can be done to make it work. Two that come to mind are better power supply bypass caps on the processor, USB and memory chips, and perhaps a more robust reset to hold off startup until the power supply is stable. This isn't a priority at the moment, so it might be a while until I get round to these tests.

I can't think of anything else to test, so it might be time to return the station for a replacement. But I hate giving up without knowing what is wrong or being able to fix it!


Steve

Your logger interval (the 16th byte) has become zero, which will be why it never moves on from the first entry. But it does look like your station has some issues!

Hello,

maybe, my problem is similar:
I recive no data from my PCE-FWS 20 after it ran mor then 12 month without any trouble. I get the "Station not initialised" Message.

I use Cumulus 1.9.2 build 1032 .

After reading the FAQs, I added the "EWdisablecheckinit=1" parameter ... without success. The only thing, that changed is, that I get the message "Data input appears to have stopped - check your station and commections".

Then I started the debug.log. It shows the following block:
So it seems, that the first byte is not as expected.
If I connect to the station with "Easy Weather" (which was delivered together with the station) it shows the actual data. But I will not give up using Cumulus.

Is there any way to get Cumulus work again as it used to without resetting the Station (as I have no physical access the next weeks)?

Yours,

Peter

Please zip up the diags folder and attach it.

Hello,

here it is. I also added the last debug.log.

Thank You in advance

Peter

It's a bug with the 'EWdisablecheckinit' setting in 1.9.2 which I fixed in the second build of 1.9.3; the FAQ does mention this. You can download and try that, if you want. See this thread: https://cumulus.hosiene.co.uk/viewtopic.php?f=2&t=7341