The
new weather vane had to be completely electronic.
I didn’t want any reed switches (like the old
one) or brushes (like in a continuous pot).
Initially, I thought I’d have to use an absolute
optical encoder because I wanted the position
to be known at power-up. But buying a new one
was out of the question because they cost around
$500. So, I began working on the mechanical
design of a 4-bit unit even though I knew it
would be a challenge.
Around
this same time, I received some resolvers from
a mill that was being scrapped. I had learned
about these transducers long ago, but I hadn’t
ever used one, so I figured there was no reason
why I shouldn’t play a little. Thanks to Analog
Devices and its generous sample policy, I soon
had some 12-bit AD2S90 resolver-to-digital converters
to work with. They only came in a PLCC package,
so I had some tedious work to do. I had to connect
wire-wrap pins to a PLCC socket before testing,
but things were working soon enough.
The
AD2S90 can use the signals from a resolver and
produce the relative position signals of an
incremental optical encoder. This enables you
to test for circuit operation prior to the creation
of any code. But, if you need absolute position
measurement (as I did), you have to interrogate
the device via its serial communication system.
Analog Devices doesn’t refer to it as a SPI-type
system, but that’s how it behaves. So, for testing
purposes, I modified some old code to simply
interrogate the AD2S90 for the current position
result and to display it repetitively. (Now
I need another microcontroller on the weather
tower.) Because I didn’t have a datasheet for
these resolvers, I had to disassemble one to
identify the wires for excitation and signals.
When I had one apart, I learned it was brushless,
which made it an excellent acquisition.
I
didn’t use one of these resolvers in the weather
vane, even though I had initially planned to
do so. The difficulties involved with connecting
the resolver shaft to the weather vane’s shaft
led me to a cleaner method. By selecting a two-piece
resolver, the mounting issues would be simplified,
I thought. I just needed to buy one, and I didn’t
think it would be too expensive. Wrong! What
I needed would cost $500. No, I couldn’t justify
that for my little weather station. So, I began
searching ’Net for surplus units. I came across
a lot of resolvers, but most of them were the
brush type. Fortunately, I eventually found
someone selling the two-piece units for $50
each. I bought two so I’d have a spare. I was
pleased when they arrived. They were unused
Tamagawa units, which I knew to be high quality.
|
(Click
here to enlarge)
|
Photo
3—A two-piece resolver is the heart of the
weather vane. Here the rotor is shown removed
from its normal location inside the stator. |
A
two-piece resolver is shown in Photo 3. My happiness
faded, however, when I tested the resolvers.
They were 2X units, which means they produce
two cycles of electrical variations for every
complete mechanical revolution (see Figure 1).
This highlights one of the dangers of buying
surplus parts. The data from the supplier didn’t
indicate the resolvers were 2X, but the company
may not have tested them. So, what was I to
do? The absolute position transducer for my
weather vane had just become “un-absolute”!
|
(Click
here to enlarge)
|
Figure
1—Rotating the resolver rotor one complete
revolution produces this plot of converter
codes against a mechanical angle. There
are two repetitions of the code in one revolution. |
The
first thing I considered doing was adding an
optical sensor to determine which semicircle
was appropriate. If I were to use an optical
interrupter approach, then two major issues
would have to be addressed: mounting the opto
unit and allowing for some adjustment and providing
a means of interrupting the light beam. I identified
other problems too. This solution would complicate
what was intended to be a simple mechanical
design. I considered and rejected various other
approaches.
Sometimes
when you’re too close to a problem, you can’t
see the obvious solution. Fortunately, a colleague
of mine suggested a software solution. Coming
up with an elegant software solution didn’t
take long after the idea was planted in my brain.
Mechanical changes weren’t required, and I didn’t
have to change any of the wiring. The only hitch
to this approach was that I couldn’t ensure
that the system would initialize in the correct
semicircle when a power outage occurred. But
the chances of initializing to the correct semicircle
were better than 50%.
Let’s
focus on how the 2X resolver is used as a weather
vane. A flag (Sflag) indicates the relevant
semicircle. Sflag = 0 when the east semicircle
is used. Sflag = 1 when the west semicircle
is used. If the east semicircle is relevant,
the R2D code returned is used as is. If the
west semicircle is relevant, the R2D code returned
gets 0x1000 added to it. In essence, this makes
the resolver/R2D combination a 13-bit system.
Dealing
with the semicircle boundary crossings at the
top and bottom of Figure 1 requires more coding.
The method requires an old R2D result to be
maintained so it can be compared to a new result
(see Figure 2). The top three elements deal
with crossing from the west semicircle into
the east when pointing northerly. The bottom
three elements deal with crossing into the east
semicircle when pointing southerly. If the two
most significant bits of the old R2D reading
are set, then the vane points northerly near
the top boundary. If the new R2D reading has
the most significant bit clear, then there has
been a boundary crossing. Signal that fact by
clearing the Sflag and exiting.
|
(Click
here to enlarge)
|
Figure
2—This flowchart shows half of the logic
necessary to test for semicircle boundary
crossings. Prior to executing this logic,
the Sflag was tested and found to be set. |
If
both of the top tests fail, then test for a
boundary crossing at the bottom. If the most
significant bit of the old R2D reading is clear
and the most significant bits of the new reading
are set, then there has been a boundary crossing.
Again, signal that fact by clearing the Sflag
and exiting.
If
both these tests fail, just exit. Similar logic
is applied when testing for transitions from
the east semicircle into the west, but it isn’t
shown in Figure 2.
Of
course, if the weather vane shaft rotates too
rapidly, this logic will fail. How fast is too
fast? Suppose that a sample is obtained every
10 ms, that the old R2D reading is 0xC00, and
that the new reading is 0x000. This is a worst-case
scenario, where the shaft has spun one-eighth
of a turn in one sample interval and corresponds
to an angular velocity of 12.5 revolutions per
second. I can’t imagine a weather vane shaft
waving at this velocity, so I concluded that
this algorithm would work with rapid sampling.
When
I tested the code, I was surprised to find that
I could spin the rotor by hand fast enough to
make the algorithm fail and switch semicircles
when it shouldn’t. That was strange. I puzzled
over it for a while before I found the culprit.
It turned out that I had a delay of several
hundred milliseconds in the code that I had
modified for this project to slow down the LCD
updates in another project. When I removed the
delay, the algorithm worked well. Rotating the
weather vane shaft by hand no longer results
an incorrect direction reading. I’m satisfied
that this will work reliably when installed.
How
do I deal with power-up and power outages? There
isn’t a sensor that determines which semicircle
is relevant at power-up, so I work off an assumption.
The wind here is predominantly from the west,
so the code will initialize Sflag = 1. Thus,
during the initial power-up or after a power
outage, there is a high probability that the
assumption will be correct.
What
if it’s wrong? Well, there are some options.
If you don’t mind the direction being wrong
for a long period of time, wait for the wind
to change until it’s from the west and then
reset the microcontroller. Or, if you can’t
wait, position the vane so it’s pointing west
with a pole (in my case the pole would need
to be about 10') and then reset the microcontroller.
The frequency of power outages will determine
if the assumption at power-up is an issue.
I
had to make some compromises when I was designing
my weather vane. But making compromises isn’t
too unusual in engineering. Nothing that I’ve
done is cast in stone either. However, changing
things made of metal is always more difficult
than changing things like circuitry and code.
I’m fairly sure I won’t be changing this weather
vane unless I’m forced to. The finished weather
vane is shown in Photo 4a.
|
a)
b)
(Click
here to enlarge)
|
Photo
4a—In the finished weather vane, the resolver
stator mounts to a plate in the middle of
the body. Above that are two bearings supporting
a shaft that protrudes down through the
resolver mounting plate. This allowed me
to attach the rotor. The tubing used for
the body of the weather vane is 4²
outside diameter. The black plastic rain
skirt is a plumbing fitting. b—The new anemometer
is even simpler inside than the weather
vane. Two bearings support the shaft. The
wind cups attach to the top of the shaft
and an interrupter cup is fastened to the
bottom. |
