Re: Replacement for Heavyweather.
- --- In email@example.com, "Scott Thorne"
See comments below...
> Some ideas for consideration.that
> Openess, multiplatform support good.
> Closed software and software developed for one platform ... bad,
> is part of the existing problem.That's
> Reliance on HeavyWeather, developing MS VB code, etc. thus have
> disadvantages. Using Java instead of VB for a top layer would be
> better, but WUHU already does that. Use VB for bottom layer?
> really not good.station
> The existing Open 2300 stuff (http://open2300.sourceforge.net/) is
> multiplatform and being developed in an open environment, and if I
> understand the literature there, reads directly from the base
> (read: not dependent on La Crosse HeavyWx sw). That seems like onewith
> good option for a good base to build on. Is this off topic for this
> WUHU seems to be great product, given its dependence on the HeavyWx
> base. But we could do better. I'd say discussing pros and cons of
> alternatives to WUHU is on topic.
> A software better model might be ... Read directly from hardware
> well designed open software designed for the task (something likeOpen
> 2300, but wouldn't have to be that) to act as a software foundationshould
> (base). Build modular cross platform components that use and build
> upon that base. Java would be good for the applications. There are
> various existing products out there that could be easily utilized as
> components (reused) for the application(s). For example, various
> graphing products exist that could be adapted, elminating need to
> develop that functionality.
> Openess facilitates troubleshooting and feature changes. Modularity
> makes codes reuse easier. Choosing both openess and modularity
> maximize the number of possible developers. It certainly would drawCrosse)
> much interest of analysts, developers, users, and software
> distributions (Fedora, etc.).
> You know, if any of these Wx station HW companies (not just La
> were to be completely open with their interface specs and were toprotect
> actively cooperate with and support an open software development
> effort, it seems their products would soon emerge as frontrunners in
> product popularity (read "competative advantage"). They could
> their hardware IP while supporting open software development. Win-win
> for all. Company gains recognition and brand awarenes for theirourselves.
> support for open software development. Company builds market share
> and profits. Users benefit from much better software and ability to
> enhance it.
> We wouldn't be complaining about about our inability to overcome 1
> minute data increments. We'd already have implemented the fix
Creating an application that can collect data from any weather
station and run on any platform would definitely be desirable. In the
case of the WS2300, I think reading directly from the interface would
be very desirable. The data would definitely be more interesting in
rapidly changing conditions.
There are two problems I see with directly interfacing. The first is
that interface is not completely known. What has been learned about
the WS2300 was done so with great effort by one person reverse
engineering the protocol. According to posts in the open2300 forum,
there are still large holes in the understanding of the memory maps.
Given that we accept the current limitations in our understanding of
the WS23xx models, and we chose to implement the direct interface
only, this would leave other Lacrosse users out of the picture
(WS36xx) for instance. LaCrosse has not released any information
about the interface and from what I gather from the open2300 forum,
it is not a simple TX/RX serial protocol.
As you mentioned, LaCrosse including other manufacturers are not
opening their hardware interfaces to the public. This being the case,
whatever solution is chosen, the framework should be able to support
these units as well.
Most 'professional' stations have some method for archiving the
weather data. A weather station without this capability is pretty
much useless in the context of what we are interested in. Therefore
we can usually find some way to extract the data from the stations.
In the case where the collection capabilities are limited (1 minute
updates) I am afraid the only option we have is to appeal to the
manufacturer to update their code.
I agree that it would definitely be advantageous for the
manufacturers to support an open software development community. For
the life of me, I do not understand why these and other manufacturers
to not get this concept. In a different market, home automation, the
case is the same. I am sure that one day it will become obvious to
them, but until that time, we will have to find alternatives.
Excluding the programming languages or operating systems, there are a
few basic features that should be supported:
1) Modular data collection. The method of data collection should be
isolated so that the rest of the framework is insulated from changing
hardware/software implementations. This would allow for direct and
indirect interfacing to the stations. New protocols and
implementations can easily be added with minimal effort.
All types of sensors should be supported including multiple
temperature/humidity sensors, soil sensors, luminosity, and even
maybe other weather related sensors such as lightening detectors,
wind sheer dectors, cloud cover detection. Multiple devices from
multiple vendors should be easy added.
2)Flexible data exporting. Regardless of how the data is collected,
there should be any number of options (including user written) for
exporting data. Weather stations could be used for many different
systems from agriculture to HVAC to safety systems. The software
should be able to facilitate any system that might use weather
3) Upload capability via Internet or HAM radio. Support for Weather
Underground, CWOP, and yet to be developed websites.
4) Weather data presentation.
a) Remote presentation via the web: When the data can be uploaded,
the presentation of the data could be done via the web. The
presentation may be at a central weather station website (like WU) or
personal WebPages. More on this in a minute.
b)Local presentation. Pretty graphs, charts, gauges, ect. For users
without an Internet connection.
I suppose on item #4 I am a bit undecided. While it would be nice to
have a pretty local user interface with lots of features, I think
that the same can be accomplished by creating a website. I noticed
the more I use Weather Underground, the less I looked at the
Heavyweather interface. If a method could be devised to support both
(maybe local web server), then all the better.
One more point I think is worth considering is that a centralized web
data collection center could have some interesting features that are
not available at the current websites. While data is collected and
displayed, graphed, there is not much else going on. We can discuss
that topic at a later time.