I recently picked up an Ambient Weather WS-2080 weather station for the backyard. It's been working great outside of a little quirk with the USB console. Every once in a while the console would drop its USB connection and stop communicating with my Debian Linux machine. The console's display would work fine and still show relevant data. After some log digging I found this nifty little error:

wviewd[6885]:  : WH1080: readFixedBlock bad magic number 46 00`

The hex values would change but the error remained the same. I found this was typical behavior for this hardware and the EasyWeather software (Windows only) provided by the manufacturer seems to not check for the correct magic numbers in memory, at least according to some USB sniffing. The console kept working otherwise, it would display the correct data and accept inputs, the drive just refused to connect to it via USB. Clearing the console's memory fixes the issue. Ambient Weather kindly provides memory maps of the console on their wiki for open source developers. As an aside, that's pretty awesome, not many hardware manufacturers do that anymore. However, it seems either the memory maps don't include all of the values indicating a successful initiation or newer consoles have different map than they've posted.

After looking at the WH1080 drivers in the source code for WView I found an if statement in the function in the wh1080Protocol.c file that actually does the checking:

// Check for valid magic numbers:
// This is hardly an exhaustive list and I can find no definitive 
// documentation that lists all possible values; further, I suspect it is
// more of a header than a magic number...
if ((block[0] == 0x55) ||
        (block[0] == 0xFF) ||
        (block[0] == 0x01) ||
        ((block[0] == 0x00) && (block[1] == 0x1E)) ||
        ((block[0] == 0x00) && (block[1] == 0x01)))
    {
        return OK;
    }
    else
    {
        radMsgLog (PRI_HIGH, "WH1080: readFixedBlock bad magic number %2.2X %2.2X",
                   (int)block[0], (int)block[1]);
        radMsgLog(PRI_HIGH,
                  "WH1080: You may want to clear the memory on the station "
                  "console to remove any invalid records or data...");
        return ERROR_ABORT;
    }

This bit of code returns an error and causes the driver to fail if the correct magic number isn't detected. From the comments it appears that even the WView developers are unsure as to whether or not these magic numbers are actually what Ambient Weather claims to be and not more of a header. At any rate this behavior is a bit frustrating. You can't really leave the console unattended for a long period of time and from what I can tell the data isn't junk and there doesn't seem to be any major issues with the console's readings. So far the fix seems to work as intended, now it just reports the magic numbers to the log:

wviewd[23990]:  : WH1080: readFixedBlock unknown magic number 44 BF

or

wviewd[17036]:  : WH1080: readFixedBlock known magic number 55 AA

EDIT:

I forgot to post my modifications to the WView WH1080 driver in the original post, it is as follows:

    // Check for valid magic numbers:
    // This is hardly an exhaustive list and I can find no definitive 
    // documentation that lists all possible values; further, I suspect it is
    // more of a header than a magic number...
    if ((block[0] == 0x55) ||
        (block[0] == 0xFF) ||
        (block[0] == 0x01) ||
        ((block[0] == 0x00) && (block[1] == 0x1E)) ||
        ((block[0] == 0x00) && (block[1] == 0x01)))
    {
        radMsgLog (PRI_HIGH, "WH1080: readFixedBlock known magic number %2.2X %2.2X",
                   (int)block[0], (int)block[1]);

        return OK;
    }
    else
    {
        radMsgLog (PRI_HIGH, "WH1080: readFixedBlock unknown magic number %2.2X %2.2X",
                   (int)block[0], (int)block[1]);
        return OK;
    }

The data being reported by the console over USB doesn't look bogus and matches it shows on its LCD display. So far so good.

Addendum: Since I originally wrote this fix I've found another bug. I'm not sure if I've got a bad console or if Ambient Weather changed their memory maps and didn't update their documentation, given the amount of reports on the WView mailing lists of errors like this I'm guessing it's the latter. It seems to be a more recent development going by the posts. Again the console is still displaying and reading data from the sensors fine. It's just the USB communication that is borked. At any rate I've added an adjusted the behavior around line 212 in the wh1080Protocol.c file. Right now I'm just doing this to debug the console output and see if it really is junk or if the memory map is just different. I wouldn't use this is a serious production setup:

        // Read 32-byte chunk and place in buffer:
        // lgh edit: not sure if this is a good idea or not, having it continue on
        // if the retVal isn't as expected, mostly for debugging the console.
        // I want to see what data it's giving back, even if it is junk.

        retVal = (*(work->medium.usbhidRead))(&work->medium, newBuffer, 32, 1000);
        if (retVal != 32)
        {
            radMsgLog (PRI_HIGH, "WH1080: read data block error, continuing ...");
            return OK;
        }

I changed out a return ERROR_ABORT for a return OK so the driver will still download the data from the console even if it returns more than a 32-byte chunk. This seems to be related to the amount of data points stored in the consoles memory. My guess is it's trying to return more than one data point at once to catch up whatever logging software is on the other end of the USB connection. This is just a guess though. Hopefully I'll know more later once the error crops back up.