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?
