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

Re: Replacement for Heavyweather.

Expand Messages
  • Scott Thorne
    see below ... [snip] ... [snip] ... [snip] ... Some ideas for consideration. Openess, multiplatform support good. Closed software and software developed for
    Message 1 of 7 , Aug 2, 2005
    • 0 Attachment
      see below

      --- In wuhu_software_group@yahoogroups.com, "David Higgins"
      <higginsdj@b...> wrote:

      > As I said, my skills are limited and C/C++ is not a strength.
      [snip]

      > Writing the file once a minute isn't really the problem is it?
      [snip]

      >
      > -----Original Message-----
      > From: wuhu_software_group@yahoogroups.com
      > [mailto:wuhu_software_group@yahoogroups.com]
      > Sent: Tuesday, 2 August 2005 11:17 PM
      > To: wuhu_software_group@yahoogroups.com
      > Subject: [wuhu_software_group] Re: Replacement for Heavyweather.
      >
      > Unfortunately WUHU is currently only able to collect the
      > weather data from the station via HeavyWeather output.
      [snip]
      >
      > --- In wuhu_software_group@yahoogroups.com, "David Higgins"
      > <higginsdj@b...> wrote:
      >> I have very limited programming skills (I can program in MS VB) [snip]

      >> --- In wuhu_software_group@yahoogroups.com, "wuhu_software"
      >> <wuhu_software@y...> wrote:
      >>>
      >>> I am interested in writing a replacement for Heavyweather

      Some ideas for consideration.

      Openess, multiplatform support good.

      Closed software and software developed for one platform ... bad, that
      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? That's
      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 station
      (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 with
      well designed open software designed for the task (something like Open
      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 should
      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 Crosse)
      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 protect
      their hardware IP while supporting open software development. Win-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 ourselves.
    • wuhu_software
      ... wrote: See comments below... ... that ... That s ... station ... with ... Open ... should ... Crosse) ... protect ... win ... ourselves.
      Message 2 of 7 , Aug 3, 2005
      • 0 Attachment
        --- 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,
        that
        > 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?
        That's
        > 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
        station
        > (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
        with
        > well designed open software designed for the task (something like
        Open
        > 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
        should
        > 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
        Crosse)
        > 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
        protect
        > their hardware IP while supporting open software development. Win-
        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
        ourselves.

        Scott,

        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.