|
Wednesday, January 18, 2006
WxService Update
I have been fighting a well-known problem with the anemometer since I first bought it. It randomly records insanely high
wind gusts (100+ MPH). It was a problem when I was using the AAG software, it was a problem with the WService software, and
it is still a problem with my 1-Wire Weather Service for Java. Except that I might finally have an answer.
What I thought might be contact bounce in the magnetic reed switches, or problems with the MicroLan, or problems with
the power supply, or radio interference, might just be a timebase problem. I had written my software to detect and filter
out the insanely high gusts, but I was never satisfied with that solution, particularly since my filter could lop off some
legitimate gusts in the process. So I built a "flight recorder" that would record 10 samples, along with collection times,
5 samples before and 5 samples after the filter detects an out-of-range sample.
I captured a few of these events, and what I found was not an unusual jump in the spin counter data, but rather a gap
in the timebase. If the anemometer task thread happens to get suspended at a critical time (like between when it reads the
anemometer spin counter and when it reads the current time), then what happens is this: We read a count, the thread is suspended,
then we read the time. While the thread is suspended, the anemometer continues to spin, and the counter continues to count.
We calculate the RPM, which reads low because we have a long time interval and a low count. But look out for that next sample!
It will be shorter than usual, but the count will include all the rotations that occurred while the thread was suspended.
Here is an example:
Spin Counter History Buffer 8: 1137475009667 5662 5664 9: 1137475014283 5667 5668 0: 1137475018309 5707 5710 1: 1137475018960 5747 5749 2: 1137475019150 5752 5752 3: 1137475019381 5754 5754 4: 1137475019461 5755 5755 5: 1137475019551 5756 5755 6: 1137475019641 5757 5756 7: 1137475019741 5758 5757
Note the interval between index 9 and 0. The elapsed time is nearly 4000 milliseconds (4 seconds), while the count
increased by only 40. The thread was suspended for nearly 4 seconds. The interval between 0 and 1 was a mere 651 milliseconds,
but the count increased by 40 again. Since the rotor RPM is expressed as
rotorRPM = (((count – prevCount)
* 60000 / n) / (msec – prevMsec))
where n is the number of magnets in the instrument (2), the RPM for the first interval was calculated as 300,
whereas the RPM for the second interval was calculated as 1843. Those correspond to wind speeds of 12 MPH and 75 MPH, respectively.
The average wind speed at that time was about 11 MPH.
The wind speed obtained by plugging in the times and counts from the first and last entry calculates to about 12 MPH,
so the overall counts and overall times are correct. If the anomaly had been due to contact bounce, the overall calculation
would have been much higher.
My proposed solution (as yet untested) consists of two things:
- Detect thread suspension by reading the system time before and after reading the anemometer spin counters. I know it takes
approximately 80 milliseconds to read the device, so if the difference between the starting and ending time exceeds 100 milliseconds,
I know the thread was suspended.
- Reduce the likelihood the thread will be suspended. I increase the thread priority just prior to checking the starting
time, and return it to normal just after reading the ending time.
Now I just have to wait for the next really windy day to see if I get any more insane readings.
10:26 pm pst
Saturday, January 14, 2006
WxService Performance Update
I improved the 1-Wire performance by shortening the time I keep an exclusive lock on the MicroLan.
8:04 pm pst
WxService JavaDocs Update
I added or improved a couple of sections in the 1-Wire Weather Service for Java JavaDocs: A new section on Event Logging explains how to configure the service event logger. I have also expanded the configuration
instruction pages, since the majority of the settings are rarely used, I highlighted the frequently used settings. The large
number of settings makes the service extremely flexible, but it also makes it overwhelming for the newcomer with a plain-vanilla
setup.
8:01 pm pst
Monday, January 9, 2006
Low-Pass Filter Underrated
After trying everything else -- from parasitic power to dedicated power, Cat-5 end-to-end, in a fruitless attempt to
make my 1-Wire MicroLan reliable, I finally bit the bullet and installed a low-pass filter, and all of my communication problems
instantly disappeared.
I had seen the low-pass filter mentioned from time to time in relation to 1-Wire MicroLan reliability, but no one ever
sang the praises of the near miraculous effect it can have. It makes me wonder why it isn't an integral part of the USB to
1-Wire MicroLan bridge, or (best case) software settable.
I had been thrown off the trail somewhat by the fact that my MicroLan becomes "clean" when my laptop is running
on batteries, or when the charger is un-grounded (it is the only ground in the system, so it isn't a ground loop). I had suspected
RF.
Anyway, the principle is simple: The low-pass filter attenuates reflected signals bouncing off of the far end of the
cable, which is not (and cannot be, due to the 1-Wire architecture) terminated in its characteristic impedance.
Looking into the filter, the controller sees a 4700pf shunt capacitor and a 100-ohm series resistor, whereas the reflected
signal sees a 100-ohm series resistor and a 4700 pf shunt capacitor. The controller can source enough current to drive the
capacitive load, but the reflected signals don’t get much past the R/C voltage divider. The responses from the remote devices
evidently do, however.
As a testament to the effectiveness of this approach, my filter is currently built using a 470pf capacitor because it
was the closest value I had in my junk box. Yet, without the filter, I could see all of the devices constantly hopping on
and off the network in the OneWire Viewer. As soon as I installed the series resistor, the devices stayed online, and the
only symptoms were the occasional misread with CRC errors. Adding the 470pf capacitor eliminated the misreads as well. I am
confident that a 4700pf capacitor will further improve the margins and the reliability.
11:20 pm pst
Monday, January 2, 2006
Weather Station Update
I enhanced AnemometerTask to record gust data according to the World Meterological Organization (WMO). You can now set
your sampling interval to 1 second (anemometer.task.sampling.interval=1000), and your history interval (anemometer.task.history.interval=3000).
This will post gust information sampled every second and averaged over a 3 second window. This provides a nicely animated
display that updates every second. To reduce network traffic and computational overhead (increase scalability), you can set
the sampling interval to 3 seconds and your history interval to 3 seconds.
8:00 pm pst
|
|
Contact Us
Use the form below to send comments about this site.
|
![](/imagelib/sitebuilder/layout/spacer.gif) |
|
|
![](/imagelib/sitebuilder/layout/spacer.gif) |
Welcome!
This site is dedicated to my interest in engineering. I use it as a place to just put stuff "out there" for anyone who
might be interested, as well as a job search tool. This page contains my engineering web log (to your left). Anything that
seems timeless enough, or too involved for a log entry may get it's own page as a full-blown article. And, of course, my resume
is here for anyone who might be considering hiring me to do something. Email me.
About Me
I have worked as a broadcast engineer, electronics designer (analog and digital) and software developer. I especially
enjoy audio engineering, although I've been writing software for the last several years, since that's where the opportunities
are in the Pacific Northwest (this is Microsoft country after all). I'm currently working as a Senior Staff Engineer -- Resume at another large independent software vendor in Washington State.
I majored in mathematics and physics in college. Other interests include music appreciation (baroque, classical and early
romantic, ragtime, and 60's and 70's rock & roll), high fidelity audio electronics, meteorology and of course, computing
hardware and software. I tend to think a lot like this guy.
|
![](/imagelib/sitebuilder/layout/spacer.gif) |
|
|