Topic: Weatherlink/Davis programming question.

[wuhu_software]

I was wondering if someone could tell me whether or not there is a way to poll the current weather conditions from the VP2 while running the WeatherLink for Windows software?

I saw the VP2 DLL on the Davis site, that allows you to communicate with the console directly. That would be nice for a stand alone weather application however I would like to run along side Weatherlink.

There is also the WeatherLink Module SDK that would seem to be a logical choice for exporting current weather data. Does any such add on already exist?

Ideally the add-on would provide shared memory or some other real-time mechanism.

I am looking for something that is either freeware or open source.

Thanks in advance!

[SLOweather]

The best way to do what you want is with VirtualVP,

http://www.wxforum.net/viewforum.php?f=45

although it's not free or open-source. I'm using it with VWS, WD and occasionally Weatherlink, and then also Tinplate's VPLive on one of the TCP/IP ports

[tinplate]

You don't need to use the Davis dll to talk to the console. The console uses a fairly straightforward and well documented communications protocol over the serial port. There is an open source application written in C or C++ that talks to the console. You could look at that code to see how someone has done it.

However, because of the nature of the two-way communications protocol, your choices are limited for having more than one program talking to the console. You can:

1) Use VirtualVP which splits the serial data, and importantly, acts as a broker so that multiple programs can interact with the console as if they were the only program connected to the console,

or 2) use a straight serial splitter like GPSGate, but in this case only one program can send commands to the console. The other program would only be able to listen in on the traffic between that program and the console. So, to get live data for example, WeatherLink would have to be in bulletin mode for the second program to get any data,

or 3) write an add-in module to WeatherLink. Not a lot of people have gone this route, and there are some limitations on what you can do.

[SLOweather]

or 2) use a straight serial splitter like GPSGate, but in this case only one program can send commands to the console. The other program would only be able to listen in on the traffic between that program and the console. So, to get live data for example, WeatherLink would have to be in bulletin mode for the second program to get any data,

I did 2 for quite a while with a hardware B&B Electronics DataTap on my old WMII and then with my VP2. It's a kludge at best. I was very pleased when VVP was developed.

[Anole]

I'll second that.

VVP Rocks!

 

[wuhu_software]

You don't need to use the Davis dll to talk to the console. The console uses a fairly straightforward and well documented communications protocol over the serial port. There is an open source application written in C or C++ that talks to the console. You could look at that code to see how someone has done it.

However, because of the nature of the two-way communications protocol, your choices are limited for having more than one program talking to the console. You can:

1) Use VirtualVP which splits the serial data, and importantly, acts as a broker so that multiple programs can interact with the console as if they were the only program connected to the console,

or 2) use a straight serial splitter like GPSGate, but in this case only one program can send commands to the console. The other program would only be able to listen in on the traffic between that program and the console. So, to get live data for example, WeatherLink would have to be in bulletin mode for the second program to get any data,

or 3) write an add-in module to WeatherLink. Not a lot of people have gone this route, and there are some limitations on what you can do.

Thanks for the info.

Although I could get in to the details of the protocol or use the high level DLL to communicate with the console (using VP Live to share access), I am really only interested in a very small subset of the available data (current temp, wind, rain, etc). I am not interested in the historical data, I just want to know what the current conditions are.

As far as option 3 goes, are the add-on modules so limited that they cannot access the current weather data and post it to a shared memory location?

Thanks!

[tinplate]

The module SDK does have functions for accessing the live data elements, so it should be possible. I think WeatherLink will have to be in bulletin mode for it to work. There is an example module project included in the SDK.

[wuhu_software]

The module SDK does have functions for accessing the live data elements, so it should be possible. I think WeatherLink will have to be in bulletin mode for it to work. There is an example module project included in the SDK.

Thanks for the advice.

One last question, do you know of any open source project or freeware related to the module SDK that I might be able to use as a starting point?

Are there any C++ developers here in the forum that have made modules using the SDK?

[jaded]

I was wondering if someone could tell me whether or not there is a way to poll the current weather conditions from the VP2 while running the WeatherLink for Windows software?

I saw the VP2 DLL on the Davis site, that allows you to communicate with the console directly. That would be nice for a stand alone weather application however I would like to run along side Weatherlink.

There is also the WeatherLink Module SDK that would seem to be a logical choice for exporting current weather data. Does any such add on already exist?

Ideally the add-on would provide shared memory or some other real-time mechanism.

I am looking for something that is either freeware or open source.

Thanks in advance!

I also wanted realtime access to the WeatherLink data, because I wanted my own copy of the GUI.  I run Windows XP and I despise having to be "logged in" in order for WeatherLink to run.  I would much rather have WL be running as a service with a user-independent GUI application so that I won't lose my internet feeds or data collection if my machine is rebooted without me logging in.

I was very excited when the SDK came out.  I immediately started work on a COM interface that would fire events as they occurred.  (I'm a big fan of providing COM interfaces as VB programmers everywhere can use the components, and it makes writing unit tests a snap.)  However, I quickly ran into a snag:  I could register an event for WeatherLink to "officially" call into my SDK module only once per minute at its most frequent.  That makes visually interesting screens like the Bulletin impossible to duplicate using only the SDK's API.

There is another way to approach this, though, and that is with an inelegant hack.  Before the SDK was made available, I sniffed around in the debugger and identified enough of their API to at least load some of my own code.  I used Spy++ to identify the annoying Update Progress popup dialog, and wrote a window hook that resizes it to 0 by 0 pixels, rendering it invisible.  I also have an "at startup time" routine that fires a message to open the Bulletin window when the application is launched.

By forcing the bulletin window to open and hooking the interesting messages that update the various displays, it should theoretically be possible to get a copy of the data in real time, and maybe even fire it off as real events.  IF the data is updated via messages, that is.

If you are interested in my pre-SDK approach, the original code is available at http://home.comcast.net/~jadeters/WxLinkGUIfixerSrc.zip
and the compiled DLL is at http://home.comcast.net/~jadeters/WxLinkGUIfixer.zip  It's not pretty, but it's simple.

[wuhu_software]

I was wondering if someone could tell me whether or not there is a way to poll the current weather conditions from the VP2 while running the WeatherLink for Windows software?

I saw the VP2 DLL on the Davis site, that allows you to communicate with the console directly. That would be nice for a stand alone weather application however I would like to run along side Weatherlink.

There is also the WeatherLink Module SDK that would seem to be a logical choice for exporting current weather data. Does any such add on already exist?

Ideally the add-on would provide shared memory or some other real-time mechanism.

I am looking for something that is either freeware or open source.

Thanks in advance!

I also wanted realtime access to the WeatherLink data, because I wanted my own copy of the GUI.  I run Windows XP and I despise having to be "logged in" in order for WeatherLink to run.  I would much rather have WL be running as a service with a user-independent GUI application so that I won't lose my internet feeds or data collection if my machine is rebooted without me logging in.

I was very excited when the SDK came out.  I immediately started work on a COM interface that would fire events as they occurred.  (I'm a big fan of providing COM interfaces as VB programmers everywhere can use the components, and it makes writing unit tests a snap.)  However, I quickly ran into a snag:  I could register an event for WeatherLink to "officially" call into my SDK module only once per minute at its most frequent.  That makes visually interesting screens like the Bulletin impossible to duplicate using only the SDK's API.

There is another way to approach this, though, and that is with an inelegant hack.  Before the SDK was made available, I sniffed around in the debugger and identified enough of their API to at least load some of my own code.  I used Spy++ to identify the annoying Update Progress popup dialog, and wrote a window hook that resizes it to 0 by 0 pixels, rendering it invisible.  I also have an "at startup time" routine that fires a message to open the Bulletin window when the application is launched.

By forcing the bulletin window to open and hooking the interesting messages that update the various displays, it should theoretically be possible to get a copy of the data in real time, and maybe even fire it off as real events.  IF the data is updated via messages, that is.

If you are interested in my pre-SDK approach, the original code is available at http://home.comcast.net/~jadeters/WxLinkGUIfixerSrc.zip
and the compiled DLL is at http://home.comcast.net/~jadeters/WxLinkGUIfixer.zip  It's not pretty, but it's simple.

Thanks for the information.

Now that you have pointed out that major flaw (the one minute update - intentional?) I doubt that I will invest time in the SDK solution. As mentioned before, I wanted to run along WL, without requiring the user to buy additional software to run my software but the one minute updates are unacceptable.

Now it seems that the only viable path to go down is to use VP live and the using the Davis DLL API since it should support both the serial and USB protocols.

I do not have a Davis VP2 yet, but was hoping I could learn about the potential interfaces before I attempted to implement an interface.

I will take a look at your code, and thanks again for the invaluable info!

If there is anything you can add, I would appreciate it!