I am using WeatherLinkIP and VirtualVP to allow my VantagePro to talk to WeatherLink 5.8 and Ambient Software’s Virtual Weather Station.
I also need to save periodic data to the download.txt file produced by WeatherLink for other purposes.
I get regular and very frequent failures in writing the download.txt file, the Weatherlink log reports various messages :-
Sometime, it just says “Download of (station name) was cancelled.”, on other occasions, it says :-
(station name) GetAcknowledge () response: 0xOA (should be 0x06 ), followed by,
Download of (station name) was cancelled
This has been a problem for me since the first version (1.2.0) of VirtualVP with WeatherLinkIP support.
I had hoped that the latest version (1.2.3) might fix it, but it has not.
Does anyone else have the same problems with failures to write download.txt with WeatherLinkIP and VirtualVP ?
Steve, we talked about this problem a while ago, but I did not push it then.
It’s a real pain for me, do you have any idea where the problem might be ?
I too have ongoing comm issues using Virtual VP with the WeatherLink IP datalogger. I run a few different weather station programs simultaneously (WeatherLink, VPlive, Cumulus) with OK results. But I frequently get timeout errors reported by all three of these programs, not just WeatherLink. I have used VWS in the past with Virtual VP, and also had comm “hang ups” where VWS would have to restart.
So, I don’t think your problem is with the WeatherLink software itself. Rather it appears to me that Virtual VP does not play well together with the WeatherLink IP datalogger. Perhaps it’s because I’ve set Virtual VP to disconnect every minute to allow the IP datalogger to upload data to the Davis site, which of course disrupts the data flow and causes the weather programs to essentially time out with certain commands. OR perhaps it’s a problem inherit to the TCP/IP communications itself. Don’t know.
Steve, do you have any insight to these comm issues we are getting? Perhaps Virtual VP needs more robust methods of handling communications with the WeatherLink IP datalogger in order to prevent comm errors?
I, also, have this communication problems with VVP & WeatherLinkIP. It was so bad I had to resort to switching back to my serial data logger. I wish it could be resolved because I would rather be using the IP data logger.
So, switching to the serial version of the data logger fixes this issue? I’ve been considering biting the bullet and getting either or serial or USB version of the data logger, but not excited about having to spend the extra cash for something I already have.
The communication problem Dave started this thread with, as I read it, only occured for me using the IP logger, so switching to the serial logger did eliminate the (station name) GetAcknowledge () response: 0xOA (should be 0x06 ) error messages.
thanks for the info. Using the serial logger is not an option for me, but hopefully, the info will give Steve a pointer on where to look to fix the errors in the IP version (if it is a VirtualVP problem),
Yea, I’m not really excited about the prospect of purchasing a second data logger as the IP version was quite pricey enough. For me, the comm issues are more an annoyance, as once I get all the weather station programs up and running (sometimes takes multiple tries due to the comm errors), generally it all works fine with just an occasional snafu.
I’ve tried both the com0com and the N8VBvCom virtual com port drivers with the same results. I’ve tried the same setup on a fairly new, high end Vista machine, and also on an older Windows XP machine. Same results. I’ve accessed the IP data logger setup screen directly and disabled the feature of sending one minute data to the WeatherLink Network site, then disabled VirtualVP’s one minute disconnect feature. No change.
Still think the problems might be related to slow communication with the logger itself through the TCP/IP interface, because when I directly access the data logger using a web browser, the logger setup screen loads slooooowwwly. If a couple of weather programs are simultaneously waiting for a command response from the logger, I can envision the programs “timing out” and prompting an error. If that’s the case, seems that Virtual VP may need a more robust way to “feed” data to the weather programs faster.
I might try playing around with some TCP/IP settings or even some firewall settings to see if I can speed things up a bit.
Not having used the IP thingy but tcp/ip traffic should be reasonable fast. When you load the logger setup screen i assume it is a HTML thingy.
Few things to check:
- IP addresses ensure they are not duplicate, I guess the ip logger is not clever enough to tell you about duplicates.
- If using DHCP either check that the lease time is long enough (this to prevent reissue of IP). Better turn it off and use fixed ip addresses.
- With HTML thingy, ensure that if you use it your DNS etc is configured correctly. Subnets etc the usual stuff
- Not knowing about your network setup, but packet size might be something to look at.
Just a few thoughts, they might not be relevant at all.
Best is to plug in the logger into small network segment without any firewalls, virus scanners and the like just your weather PC see if the problem is related to the IP logger or something else in your network.
I agree, the tcp/ip traffic should be fast. I think part of it is just the fact the datalogger technology is notoriously slow to begin with…if the info I’ve read (on the internet) about the technology is accurate. But that doesn’t explain why the serial and usb versions seem to be fine from what I can tell on this forum.
In any event, I’ll check out some the things you recommend. I’ve set the datalogger to use a static IP address and I know it does not conflict with any other devices on the network, according to my routers info page.
But I must admit I’m a bit confused. If the weather programs are talking to Virtual VP, when they “think” they are talking to the console, why would communication issues between VirtualVP and the console even matter? Seems that Virtual VP would simply dish out it’s cached info no matter what. Or does the problem stem from when these programs request specific info that Virtual VP does not have (say a time check, or console diags, etc)? If so, perhaps VirtualVP should periodically request and cache these common items.
A follow-up to my last post…
Just to add more confusion and another symptom to this comm problem. Often when the Davis WeatherLink program goes to download data from the logger (which is really VirtualVP), it just sits for about 30 seconds and finally gives up. Often I have to click “download” 2, 3, or more times to finally get the data to actually download from VirtualVP :x
Again I ask, if the data is already cached by VirtualVP, why the delay and/or failure? Seems that a data download to any weather program would be almost instantaneous. But it is not.
Steve, do you have any insight as to what the problem might be!!!
Do you have weatherlink configured to talk to VirtualVP via serial or tcp/ip?
You are right that since VirtualVP caches the archive data, the downloading of archive data should just involve VirtualVP and the connected weather program (like WeatherLink) without the need to go to the console itself.
During testing of WeatherLink 5.9, which appears to have very tight timeouts set, I did see the “Get Acknowledge” error you mention. When that error occurred it was usually because of this scenario… The command to download archive data is a multi step command where there is several back and forth communications. If WeatherLink and VirtualVP get out of sync, particularly if WeatherLink thinks it needs to restart the conversation from the beginning but VirtualVP still thinks things are progressing fine, then you can see this error. I put additional code in VVP 1.2.3 to make this occurrence less likely.
Other than WeatherLink 5.9.x though, I do not see this happening, and I have VirtualVP and WeatherLink running together 24 hours a day. I’m not saying that to infer you aren’t having the problem, but to let you know that it’s hard to work on the problem since I don’t see it on my own system.
just to confirm, I get this problem with WeatherLink 5.8 under WindowsXP.
As everyone knows now ! - I’m just about to upgrade (?) to Windows 7 - I’ll let you know if that makes any difference
Do you have weatherlink configured to talk to VirtualVP via serial or tcp/ip?
I’ve tried WeatherLink configured both ways, and I still get occasional comm problems. I have WL running constantly (without the weather bulletin running) and configured to auto download the archive data every hour. Subjectively, I’d say it successfully downloads the archive data about 1/3 to 1/2 of the time.
I currently have WL and 2 other weather programs (VPLive and Cumulus) configured to all use serial communication. Each of those programs have comm errors at times, most commonly at startup when the programs are downloading data from the console (that is…Virtual VP). Once everything is up and running, live data stream problems are more rare. So, it seems to be primarily the initial startup process where many of the errors occur. Exception to that is a program called WUHU. When I try to use that program with Virtual VP it will constantly drop offline for seconds at a time and log a communications error in it’s log, which leads me to think there is something about VVP that causes hiccups in the data flow, at least when used with the IP data logger.
Are there any configuration tweaks that you can think of that we could try…either in WeatherLink, VirtualVP, the virtual comm port driver (I’m currently using com0com), or Windows firewall (comms between the IP datalogger and VVP)?
Followup to this issue:
Ended up biting the bullet and purchasing the Davis serial datalogger…installed a second serial port into an XP machine…and directly connected the two. Still using the same setup…Virtual VP and various weather station programs (VPLive, Cumulus, WeatherLink)…but the comm errors discussed in this thread completely vanished. Everything, thus far, is running smoothly. In fact making configuration changes to the console through software, and the real time data flow itself is substantially smoother and more robust versus the using the IP datalogger…even when I directly connect (i.e. no VVP) to the logger using the WeatherLink software.
So…for whatever reasons…it does appear the IP datalogger has comm issues when talking with PC’s on the network. Might be the design of the IP datalogger, could be a router thing, or other issues entirely. At the very least, communication is substantially slower with the IP datalogger, which becomes a problem when used with VVP and multiple weather software programs all trying to talk with and pull data from the console. The IP datalogger might be best suited as a stand alone internet appliance, used with just the WeatherLink program (in all fairness, what it was designed to be).
thanks for the info - not the answer that we all wanted, but good to have this update.
Personally, I don’t want to have to ditch the IP Datalogger - I quite like the automatic web posting to WeatherLink in parallel with my local weather programs.
Did you test with just WeatherLink (on the local PC) talking to the IP Data Logger ? Did that cure the comms problems ?
If not, then the obvious answer is that Davis should fix this apparent problem with the IP Data Logger.
Have you reported your findings to Davis ?
Maybe they can be persueded to come up with a firmware upgrade to fix the problem.
Is your IP Logger still under warranty ?
Maybe you can get Davis to refund the cost if you can demonstrate that it does not work as advertised ?
Just to clarify my situation.
I had NO problems with the communictaions between the IP data logger and a computer running WeatherLink. I never tried it with other software (WD, VWS, etc.). The problems I had occured only when communicating with VirtualVP.
I’m with you, I also like posting the data to the Davis WeatherLink site in parallel to the other stuff. Fortunately in my case, I have both a VP2 console and a Weather Envoy, and will eventually end up using both loggers…with the serial logger taking care of all the PC comm stuff.
When I use the WeatherLink software alone and connected directly to the IP datalogger (no VVP), communications are slower as compared to the serial logger, but error free. It’s only when I add the additional layers of software (Virtual VP and multiple weather programs) that it appears to be to much for the IP datalogger to handle, which in turn causes program timeout/comm errors. As such, I’m not even sure this would fit into the realm of a warranty return, since the IP data logger does work as it was designed and advertised to do.
Nonetheless, I should probably report this to Davis. But again, since I’m trying to use the logger in a way not designed by Davis (VVP and multiple programs simultaneously), I doubt they will do much. These days their support side seems to be having a hard enough time keeping up with the stuff they need to be doing.
Thanks for the update - it’s almost a shame that it DOES seem to work with just WeatherLink connected !
As you say, Davis may not be too interested, but I think that it is probably still worth asking them ?
It seems like quite a few of us don’t want to be restricted just to WeatherLink and it would seem to be easy enough to provide some flexibility.
I guess part of the problem might be the priority that WeatherLinkIP gives to updating the internet site, maybe if there was the ability to set a variable update rate rather than every minute, it would give other stuff time to get a look in. Maybe that’s something that Davis could easily enough do at the next firmware update (if there is one).
Agreed, I should bring this to the attention of Davis. Perhaps they are unaware of any comm problems.
As far as WLIP giving priority to uploading to the internet site. One thing I did try was to completely turn off the website upload feature of the data logger (using it’s html configuration screen). This made no discernable difference as I still had comm errors. So, I don’t know what the deal is. Again, could be a design issue with the logger, could be with certain routers holding things up, or with Windows TCP/IP layer itself. Wish I knew where to start looking.