Well, I think I have a fix for VVP when used with WL 5.9.x. I haven't tested other parts of WL yet, but have concentrated on the bulletin mode (live data). There seem to be two important changes that Davis made in the bulletin mode initialization. The sequence used to be to get the firmware version date and some of the configuration values out of EEPROM, then download the archive data, then start getting loop (live) data. Now, right after downloading the archive data, it sends the command to the console to get the firmware version number (NVER). This is a command added to the firmware a couple years ago. Consoles with earlier firmware will treat this as an unknown command, and just send back <LF><CR>. But consoles with the newer firmware will send back <LF><CR>OK<LF><CR>1.73<LF><CR> (with 1.73 replaced with whatever the firmware version is). The problem for WL, or any program using this command, is that after getting back the first <LF><CR>, you may or may not get the rest of the data, depending on whether the firmware supports NVER. So you have to set a relatively tight timeout, and either get the additional data or timeout. That's fine, and I've added NVER support to VVP to send that along from the console. The next thing that Davis changed though, was more problematic for VVP. After getting the NVER response, WL then sends a LOOP 1 and has a very tight timeout on that. If it doesn't get an immediate loop packet back, then it times out, and then goes back and resends NVER command followed by the LOOP 1 (with the very short timeout again). If there is another program connected to VVP, then VVP will already be getting loop data from the console, and will send the loop packet to WL, making it happy. But if there are no other programs getting loop data, then VVP will not be getting frequent loop data either, so when WL asks for the loop data, VVP has to start up the looping with the console, and this little bit of extra processing is enough to go over the very short timeout. So then WL timesout and starts over, just as VVP is sending the loop packet that was just requested, and the two programs get in dance where they don't sync up. The error that you eventually see in WL is that the station isn't responding. If people are getting this station not responding error sometimes with WL 5.9 connected direct to the console, I think it may be the same problem of WL now having much tighter timeouts for the serial communications. I'd like to hear if any of the people reporting these station not responding problems are getting them even without using VVP.
Anyway, as a workaround, I'm just going to have VVP go right into loop mode right when it starts, and just stay in it, even if no programs are connected. I need to test it some more, but I should have a new version of VVP out later today.