117Re: Bad upload data
- Jul 30, 2005I was running an earlier version (maybe 127 or 126). I have just
installed the 129 version, so I'll see if anything changes with
respect to this problem.
If you are experiencing wind-related errors, consider using PVC pipe
for the mast. I was using metal pipe up until a few weeks ago. On
days above 90, the metal would get hot and cause siginificant errors
in the wind data, even in wireless mode. After switching to PVC, I
was able to run the unit cabled, and now even on 90-degree days my
data is error-free.
Thanks for you help and suggestions with my problem.
--- In email@example.com, "wuhu_software"
> On my system, I seem to run for weeks without a single bad
> Other times, I will have windspeed errors combined with othererrors
> in rapid succession. I have not been able to find a pattern to it.bogus
> The other possibility for these bad reading being written to
> currdat.lst and not to the history file might possibly be a bug in
> Heavyweather itself. It is difficult to say.
> One thing that is for certain is that Heavyweather is writting
> Here is an example of a bad reading put out by Heavyweather:
> mm = "15370.0"
> inch = "605.11"
> This was found in the currdat.lst file. As you can see,
> is writing bogus data for both mm and inch measurements. The sameis
> true for bad temps and windspeed data as well.performed
> These bogus readings will be overwritten on the next update
> by Heavyweather (which updates the currdat.lst file once perminute).
> As I mentioned before, I attempted to catch some of these errors.
> instance, when reading temperature, if the current reading is notpast
> within 10 degrees of the average temperature readings over the
> ten minutes, then the software will use the last valid temperaturepipe
> reading (that passed the above test) as the current temperature
> These features were added in one of the later versions and is
> definetly in version 129.
> Which version are you running? If you are running version 129 and
> still seeing these bogus temperature readings when running version
> 129 let me know. I can look over the code to see if there is a
> --- In firstname.lastname@example.org, "Mike Frerkes"
> <mfrerkes@m...> wrote:
> > There are no sources of EM interference I'm aware of. I have
> > learned that you should never use a metal pole as a mast for the
> > anemometer, however. A couple of weeks ago, I switched to PVC
> > and the wind readings are now flawless, even with a cabledshow
> > connection. Before the switch, I couldn't use the cabled
> > because the wind readings would be horribly inaccurate.
> > I'm puzzled why the bad readings (i.e zero degree temp) DO NOT
> > up on my HeavyWeather program under the min/max tabs foror
> > and dewpoint, or on the base unit's display. There is no rhyme
> > reason to their occurence. Sometimes I may go an entire weekdoes
> > without a false reading. There have been a few instances where
> > registered two in the same day. The only common thread is that
> > occur within the first five minutes of each hour AND they always
> > take place between 12am and 5am.
> > --- In email@example.com, "wuhu_software"
> > <wuhu_software@y...> wrote:
> > >
> > > Mike,
> > >
> > > What is interesting is that the Heavyweather application is
> > > writing bogus data to the currdat.lst file but somehow this
> > notthe
> > > make in to the history.dat file.
> > >
> > > There are a couple of theories why this is the case. Firstly,
> > > currdat.lst file is written once per minute by Heavyweather,no
> > oncesamples
> > > per update (9 seconds in wired mode). Since it reading 5
> > peris
> > > history file save, it might just be random. The other theory
> > thatis
> > > somehow it can detect bad data and rejects it internally.
> > >
> > > A way to catch the Heavyweather application writing bad data
> > use
> > > the alarms/events. You can set an alarm for low temperature
> > > instance. When you hear the audio, open currdat.lst withnotepad
> > withinby
> > > 1 minute. You can see that the bogus data is being generated
> > > Heavyweather.eliminate
> > >
> > > From what I gather from these forums, the best way to
> > boguswiring,
> > > data is to build a shielded cable. I have not modified my
> > butand
> > > it will be interesting to see if this corrects the problem. If
> > anyone
> > > has modified the cable, please post your results.
> > >
> > > I have attempted to detect and eliminate bogus wind readings
> > > others. I am not sure if I had done the same on version 129that
> > isposted
> > > available from the alternative download page. I believe I
> aalways a
> > > message on the rules I used to attempt to detect bad data
> > previously.
> > >
> > > If you have any idea or rules that can be applied to the data,
> > me
> > > know. I am willing to modify the application if we can find
> > > rules to detect bogus data.
> > >
> > > P.S. Are there any source of EM radiation, power dips, or
> > else
> > > that happens at that time around your home? Just wondering.
> > >
> > > --- In firstname.lastname@example.org, "Mike Frerkes"
> > > <mfrerkes@m...> wrote:
> > > > I have also experienced erroneous data uploads, almost
> > > > temperature and dew point reading of 0. I've traced thereadings
> > defective
> > > > data to the WUHU program itself, because those extreme
> > areminutes
> > > > not registered on HeavyWeather or the La Crosse base unit.
> > > >
> > > > My false readings always seem to appear in the early morning
> > hours
> > > > between 12am and 5am, and always within the first five
> > of theset
> > > > hour (e.g. 1:03am or 4:05am). I have the upload interval
> > five
> > > > minutes, so it might be related to that in some way. There
> > neverthe
> > > > been a bad reading after the first five minutes of each hour.
> > > >
> > > > These incorrect readings are uploaded to both Weather
> > Underground and
> > > > CWOP, so I've ruled out any data glitches on their end.
> > Hopefully
> > > > this information may assist you in isolating the cause of
> > problem.
- << Previous post in topic Next post in topic >>