RE: [wuhu_software_group] Re: WS36xx history.dat file.
- Re resetting rainfall totals... I wonder if their thinking is that you start
a new history file and that file starts with an implied zero in rainfall
total. There is a place to define the file name for the history data.
Memory leak... hmmm is all I can say.
CPU time: The WS36xx, apparently unlike the prior generation (23xx?)
products, has an RS232 serial interface, but it is used totally differently.
I used a serial data sniffer to confirm my suspicions: The serial port
handshaking signals are used to transfer data; the usual serial TX and RX
data lines are simply not used. Why would they do this? Well, perhaps the
WS36xx microprocessor has no serial UART or someone thought using the
control lines would be faster or allow longer cables. I do know I've never
seen this done on any other product. So the sensing and toggling of these
lines every few seconds is why HeavyWeather is such a CPU hog. For that
reason alone, I don't want it running all the time.
[mailto:firstname.lastname@example.org] On Behalf Of jjantti2
Sent: Monday, October 17, 2005 11:30 PM
Subject: [wuhu_software_group] Re: WS36xx history.dat file.
--- In email@example.com, "stevech" <stevech@s...>
> Lastly, when I reset (zero) the rain total using the WS3610's LCD,This seems to be a problem in the WS3600-series weather stations
> this does not change the total in history.dat. I'm a bit confused
> by this too. Maybe I'm supposed to use their PC software to zero
altogether. For my part, the weekly rain amount refuses to zero itself
from both LCD and HeavyWeather. Trying to reset the value in
HeavyWeather only seem to refresh the date and time of the "new" high
record. I suspect this is bug in HeavyWeather.
> I have my PC arranged to run the HeavyWeather software onceThat's strange. I haven't encountered any memory leakage in my server,
> an hour for a minute or so and then cause it to stop. I've found
> that it has a memory leak and I can't let it run 24/7 on my home
> automation server PC.
where HW is running. HeavyWeather relies on some system DLLs to
function. If one of them is replaced by another program, it's likely
that the memory leak is caused by a faulty DLL. Another option is that
the problem was found and fixed on the European version of HW, but not
in the US version. (A bit far fetched thought, but a possible one).
> Moreover, it eats a tremendous amount of CPU time doing the reallyThat's normal (at least for La Crosse). The reason is that
> weird I/O protocol to/from the WS3610 (not really serial I/O).
> So I find it best to automatically run it briefly once an hour.
HeavyWeather is actually responsible for all COM-port transactions.
One thing you could try is to obtain a USB->COM converter. It might
lower CPU consumption a bit.
Yahoo! Groups Links
- --- In firstname.lastname@example.org, "cgrosby" <cgrosby@h...>
> --- In email@example.com, "wuhu_software"
> <wuhu_software@y...> wrote:
> > WS36xx history.dat findings (does not apply to VWS or WS32).
> > I viewed the history.dat file sent to me by Craig who had also
> > this defect.
> > The values for that field (wind gust) are changing over time
> > this field often contains the value 51.0 (meter per second).
> > After reviewing the data, it appears that 51.0 is used as
> a "sentinel
> > value". When the wind speed is low (~2.0 m/s) the gust speed is
> > reported as 51.0. I can only assume that gust data is not
> > I have also found several instances where the wind speed value
> > contains 51.0. I can only assume that the station experienced an
> > when collecting the wind speed data from the sensor. When the
> > speed is reported as 51.0, I make the assumption that the winddata.
> speed is
> > zero (what else can you do?).
> > Since there is no clear definition for wind gust reported via
> > Heavyweather, I have decided to use the gust data when it is
> > The wind gust data, when valid, will override the wind speed
> > wind gust uploaded to the server will then be the highest wind
> > found over the past 10 minutes (as defined by CWOP). This is the
> > method used when using the currdat.lst that does not contain
> > If someone who is attempting to use the WS36xx history file
> > would kindly install version 134 and send me some feedback, I
> > appreciate it.
> > If you have any other recommendation for using this somewhat
> > wind gust value, let me know.
> > --- In firstname.lastname@example.org, "jjantti2"
> > wrote:
> > >
> > > --- In email@example.com, "wuhu_software"
> > > <wuhu_software@y...> wrote:
> > >
> > > > Also, if anyone else is using the WS36xx history file please
> let me
> > > > know if your station is uploading normally or not.
> > >
> > > Hands up here!!
> > >
> > > I was using history.dat for a while, but eventually gave up and
> > > started using currdat.lst because the gust display was showing
> > > constant 125mph for me. I once thought it was the maximum windfindings,
> > > it could show, but after hours of contemplation I came to a
> > > this was an error condition. So, in the light of these
> > > station is likely to upload data all OK only when using the
> > > currdat.lst file.
> > >
> FROM Craig:
> I just uploaded v136 and am using histoty.dat and everything
> to work, but I want to spend a few hours uploading data and see.Got some good wind today. The wind speed is displaying the same as
> I'll keep you posted.
wind gust? I'll try v137 and see if that works.
- --- In firstname.lastname@example.org, "stevech" <stevech@s...>
> Re resetting rainfall totals... I wonder if their thinking is thatWell, for my part making a new history file will only come in question
> you start a new history file and that file starts with an implied
> zero in rainfall total. There is a place to define the file name for
> the history data.
on 01.01.2006 the earliest. Interesting thing is that I was able to
zero the rainfall total from the weather station, but the weekly rain
value just doesn't go anywhere no matter how many times I attempt to
clear the record.
> Memory leak... hmmm is all I can say.I think (and hope) that La Crosse is aware of the possibility of that
and considering releasing an updated version of the program with the
> So the sensing and toggling of these lines every fewGood point, especially if you do something else with the computer and
> seconds is why HeavyWeather is such a CPU hog. For that
> reason alone, I don't want it running all the time.
don't want any slowdowns. I'm getting 10-25% CPU usage spikes when HW
communicates with the station, but I don't consider that very high. I
have changed the priority of HW from Normal to Above Normal so that no
interruption in communication would occur if another (Normal priority)
process takes most of the processing power.