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

Re: Replacement for Heavyweather.

Expand Messages
  • wuhu_software
    As far as I know, they are not really responsive to requests for updates / bugs. I am not sure what the history is since I began using their products in
    Message 1 of 7 , Aug 2, 2005
    • 0 Attachment
      As far as I know, they are not really responsive to requests for
      updates / bugs. I am not sure what the history is since I began using
      their products in January.

      The problem with the gust data is that they are not saving the peak
      gust speed every 9 seconds, then writing that to the currdat.lst.

      I suspect they take the last update that occurs when the 5 minute
      period expires, then writing that data to currdat.lst.

      This is not desirable as all of the real gust data is lost.


      --- 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.
      >
      > What history does LaCrosse have for making mods at users request?
      If they
      > don't do it as a matter of course then waiting for them is likely
      to be a
      > waste of time (I use a Meade LX200GPS scope in my observatory and
      the
      > company does listen to users and makes changes to the scopes
      > software/firmware on a regular basis)
      >
      > Writing the file once a minute isn't really the problem is it?
      It's the
      > Maximum Gust speed that seems to have been ignored (unless the gust
      occurred
      > inside that 9 second update time) or was it rejected as eronious
      data?
      >
      > Cheers
      >
      > David
      >
      > -----Original Message-----
      > From: wuhu_software_group@yahoogroups.com
      > [mailto:wuhu_software_group@yahoogroups.com] On Behalf Of
      wuhu_software
      > Sent: Tuesday, 2 August 2005 11:17 PM
      > To: wuhu_software_group@yahoogroups.com
      > Subject: [wuhu_software_group] Re: Replacement for Heavyweather.
      >
      >
      > David,
      >
      > Unfortunately WUHU is currently only able to collect the weather
      data
      > from the station via HeavyWeather output. The Heavyweather
      > application is currently writing the currdat.lst file once per
      minute
      > (even in wired mode that updates the Heavyweather display every 9
      > seconds). It may update the data on the screen, but that
      > is not available to us. This is a horrible limitation to have,
      > especially when we are interested in events of a very short
      duration
      > like wind gust data.
      >
      > As an example I experienced a severe storm last month. The winds
      were
      > calm prior to a wind gust that came through the area. I would
      > estimate the winds were at least 50-60 mph. Many large trees in the
      > area fell, including a large one that narrowly missed my home. When
      I
      > checked the recorded weather gust data, the highest wind that I was
      > able to catch was 25 mph. Very disappointing.
      >
      > For this reason I posted a message about writing a replacement for
      > Heavyweather. Ideally, it would be able to read the weather data
      > every 9 seconds or so (as Heavyweather does), and also output this
      > data to currdat.lst. It would also be desireable to have a nice
      user
      > interface with gauges, graphs, and so on.
      >
      > The only road block I see with writing a replacement is the support
      > for the 36xx series. The 23xx series protocol has been successfully
      > decoded and the source code is available in C from the open2300
      > source code project (see links).
      >
      > The alternative to re-writing Heavyweather is to contact LaCrosse
      and
      > ask them for a couple of updates.
      >
      > 1) Faster update rates for currdat.lst. As mentioned, Heavyweather
      is
      > writing this file only once per minute. I have already requested
      this
      > modification myself.
      >
      > 2) Better error checking on the weather data. The data sent to
      > currdat.lst may or not be checked for errors. My guess is that it
      is
      > not checked.
      >
      > I am a bit leery of waiting for LaCrosse to modify their
      application.
      > If the weather enthusiasts are not complaining, there is little
      > motivation to do so.
      >
      > Thoughts?
      >
      > --- In wuhu_software_group@yahoogroups.com, "David Higgins"
      > <higginsdj@b...> wrote:
      > > I have very limited programming skills (I can program in MS VB)
      but
      > > would like to assist anyway I can. I am most interested in
      > accurate
      > > and timely wind gust information whether it be graphical or not
      but
      > > a line chart is perhaps the most useful for me - one line for
      > > average and one line for gust (or any other means of indicating a
      > > trend)
      > >
      > > Cheers
      > >
      > > David Higgins
      > > E14
      > > Canberra, Australia
      > > http://users.bigpond.com/higginsdj
      > >
      > > --- In wuhu_software_group@yahoogroups.com, "wuhu_software"
      > > <wuhu_software@y...> wrote:
      > > >
      > > > All,
      > > >
      > > > I am interested in writing a replacement for Heavyweather for
      the
      > > > Windows platform. The current heavyweather software writes to
      the
      > > > currdat.lst file only once per minute, even though the data is
      > > > collected every 8 seconds in wired mode. This can result in a
      > loss
      > > of
      > > > wind gust data.
      > > >
      > > > I had submitted a request to the authors of Heavyweather asking
      > > them
      > > > to write the currdat.lst file whenever the weather data changes
      > > > rather than once per minute although I do not have much
      > confidence
      > > > that they will do so.
      > > >
      > > > The other day I experienced a severe storm with high winds. I
      > > would
      > > > estimate that the wind speed was at least 60 mph at it's peak.
      > The
      > > > unit was only able to capture speeds at 25 and 22 mph over a 10
      > > > minute period. If the station were updating at 8 seconds, I
      would
      > > > have probably accurately captured the peak windspeed.
      > > >
      > > > Since the Heavyweather application cannot accurately capture
      > > rapidly
      > > > changing wind speeds, I would like to write a replacement for
      the
      > > > Heavyweather application.
      > > >
      > > > Although I could use open2300 to extract data from the unit, the
      > > > consequence would be a loss of the graphical user interface
      with
      > > > gauges and controls.
      > > >
      > > > The other possibility is to just display the weather data in a
      > > plain
      > > > jane text form on WUHU. This would not be as pretty as
      > > Heavyweather
      > > > but it would get the job done.
      > > >
      > > > If anyone has some programming experience and would like to help
      > > me
      > > > writing a replacement for Heavyweather, let me know.
      > > >
      > > > Thanks.
      >
      >
      >
      >
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      > --
      > No virus found in this incoming message.
      > Checked by AVG Anti-Virus.
      > Version: 7.0.338 / Virus Database: 267.9.8/61 - Release Date:
      1/08/2005
    • Scott Thorne
      see below ... [snip] ... [snip] ... [snip] ... Some ideas for consideration. Openess, multiplatform support good. Closed software and software developed for
      Message 2 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 3 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.