Loading ...
Sorry, an error occurred while loading the content.

Re: Replacement for Heavyweather.

Expand Messages
  • wuhu_software
    ... wrote: See comments below... ... that ... That s ... station ... with ... Open ... should ... Crosse) ... protect ... win ... ourselves.
    Message 1 of 7 , Aug 3, 2005
      --- In wuhu_software_group@yahoogroups.com, "Scott Thorne"
      <thornesa@n...> wrote:

      See comments below...

      > Some ideas for consideration.
      > Openess, multiplatform support good.
      > Closed software and software developed for one platform ... bad,
      > is part of the existing problem.
      > 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.
      > 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 one
      > good option for a good base to build on. Is this off topic for this
      > forum?
      > 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 like
      > 2300, but wouldn't have to be that) to act as a software foundation
      > (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 draw
      > 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 to
      > 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-
      > for all. Company gains recognition and brand awarenes for their
      > 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
      related data.

      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.

      Ideas, thoughts?
    Your message has been successfully submitted and would be delivered to recipients shortly.