Gyrations with Temperature Sensors

Gyrations in this context means "going 'round and 'round.

or 

"Oh what a tangled web we weave, when we learn."

I tried using a thermistor for sensing the air temperature exiting the space heater. As mentioned before, it was salvaged from a color laserjet printer. 

Later I tried an RTD, which stands for Resistance Thermal Detector. This is the familiar 100 ohm
platinum RTD I have worked with for years in the plants. 

OK, what do these have in common? Yes they are active components that are used to measure temperature. What else?

They have a sensing element attached to some wires, so the measurement point (location) can
be at some distance from the display, and the electronics driving it.

They have a response curve that is more-or-less linear, in other words they respond to a given
change in temperature with the same amount of change in their electrical characteristics.

And they have a Temperature Coefficient. 

NTC (Negative Temperature Coefficient)

                                  In the case of the thermistor, this number has a negative sign.

                                  As the temperature increases, the resistance decreases.

PTC (Positive Temperature Coefficient)

                                 With the RTD, the number has a positive sign. 

                                 As the temperature decreases, the resistance increases..

Sensors are also designed to measure in certain ranges, and the extension wiring/insulation/protective covering ("da wirez")  is usually designed with that in  mind. For example if you want to measure 700 degrees C, you don't want your sensor or the wiring burning up. It must be protected somehow.

These sensors have ranges of other environmental factors too: Exposure to humidity, chemicals, radiation have to be considered. For lower temperature applications, such as a space heater, designed for use in a home or office environment, we don't usually think about chemicals or radiation.  

Finally the further your measurement has to travel, whether using wires or not, the harder it is to make it work right.

Thermistor

My basic challenge with using the thermistor for measuring temperature was to make the ADC output stable enough to use for measuring and control. 

The ADC  (Analog to Digital Converter) on the Arduino can theoretically read many thousands of times per second. You may know that ADCs  are used to convert analog audio to digital audio.  In order to get decent resolution (it still sounds good) an audio ADC would need a MINIMUM sampling rate twice the highest frequency you want to digitize. So (for the young pups anyway) 20,000 Hz x 2 or 40KHz sampling rate. 

I timed a loop() in some Arduino code and discovered that the loop execution time was about 50 milliseconds! With one analogRead() in the loop(), I was sampling the voltage from the thermistor at about 20 times per second, or 20 Hz--given as the lowest frequency audible to human ears. Also far faster than it could be read from the Serial Monitor, a 9600 baud.

The ADC converts whatever voltage that happens to be on the pin, mixed in with your theoretical voltage signal.  In a perfect world, that signal would be as stable as the excitation voltage applied, and only the change would be in response to changes in the temperature being measured.

I tried Vcc first, supplied through the USB cable from my desktop computer. I did some reading and learned that this Vcc is not well regulated. If you have some circuit connected to, and powered from your Arduino, and it needs more current, your Arduino's Vcc is going to drop under load. 

The USB controller as implemented in personal computers is supposed to supply up to 1500 mA 

There are almost always more than one controller in a desktop PC, and they may be different...USB 10., USB 2.0, or even USB 3.0.

While the higher numbers indicate faster data transmission speeds, it comes at a price...sensitivity to interference. The faster versions rely a lot on cabling and connectors being up to the job too. So many variables. I advise finding out what's under YOUR hood.

Another consideration is that the convenient front USB ports are connected internally to jacks on the back side of the motherboard, near where the rear USB ports are located on the back of the box. And the wires travel through a potentially extremely noisy electrical environment. If you have faster ports they are most likely going to be on the back.

I have a bench power supply made from an old ATX computer power supply. They are relatively inexpensive, easy to set up, and can supply some respectable current at several different voltage levels. 

My friend Gus reminded me that the regulation of these supply lines is not really comparable to a "lab grade" bench power supply. The power supply voltages are fed into a computer motherboard where they undergo extensive "additional regulation" before powering the electronics.  

So it seems that powering my breadboard with +5V or +3.3 Volts MIGHT be substituting relatively poorly regulated voltages to my circuits, even if it does take some load off the Arduino's power supply circuitry.

Someone suggested using a powered USB hub to supply the current needs of the Arduino's USB port, to avoid "brownouts" when uploading/reflashing the microcontroller, which I have done.

(provide attribution)

You could say that this exercise in design forces you to consider a lot of variables. I think we get spoiled consuming mass-produced stuff...which is designed to be as no-brainer as possible. How did they manage  that? By hammering out all sorts of questions like these. Hats off!

I tried using the analogReference() function in the sketch's setup() to compare the thermistor readings to the internal 2.5 Volt reference on the Arduino.   

(code) analogReference(INTERNAL2V5); (code)

That seemed to help, but the voltage still changed far faster than the thermistor itself could possibly be changing temperature!  This made a lot of "noise" being added to my temperature signal, feeding into the heater-controlling portions of the sketch. 

Shielding I thought, and jacketed the extension leads of the thermistor with braided copper sheathing, grounded to the 0 volt rail of the breadboard, which is supplied from the Vcc (+5V) on the Arduino

Maybe that helped a little, but I don't have any hard numbers to prove it. And in the course of pursuing temperature control, it MIGHT have been "cooked" a little. Being a salvaged part, I have very little environmental or other data on it. 

RTD

I gave the thermistor a break and tried connecting the Pt-100 RTD sensor to the Arduino. With the ADC being done over a range of volts (0-5 on the Arduino) you must have a device which either puts out its own DC voltage signal or you use something like a resistive voltage divider circuit. 

That has the virtue of being basic, easy to understand, easy to construct. The disadvantage is loss of resolution.  The voltage across whatever current limiting resistor (so you don't exceed current limitations on the pin you connect it to) will not change, and it takes a big bite out of the available voltage range applied to the input pin.

With the 100 ohm platinum RTD, you need at least 400 ohms or so in series to make the circuit draw less than about 9 mA (milliAmps).  Why am I worried about that? The reason is that my Arduino must supply that current, and the greater the current load, the more my Vcc will "droop".

I did actually get the RTD version of temperature control working. The analog voltage coming from the RTD was rather small, as the change of resistance of the RTD itself is relatively small...

For instance at 0C  (32 F) it has a resistance of 100 ohms. At 100 C (212 F) depending on what Standard was used to generate the table you look at, the resistance rises to somewhere close to 138.5 Ohms using  5 volts.

In my circuit that translates to a voltage input range of 1.00V to 2.909 V fed to  my ADC input pin

So I've lost 2 volts of my 0-5 volt ADC conversion range. In my setup I was seeing about a 4 degree C change for each integer change in the ACD's output ( a range of 0-1023). And then I cut that in half again using the internal 2.5V reference voltage

If you can't even see a change of 1 degree C, you find it difficult to control to within +/- 1 degree (which would be nice).

No, "further research" shows that some signal-conditioning circuitry for the RTD will increase its resolution dramatically. It took very little digging to find some useful Application Notes on this very subject, as many of the electronic component manufacturers want to make it easier for you to use the stuff they sell you.

Fortunately one of the first I found was a very good one, from Microchip

AN687 Precision Temperature Measurement With  RTD Circuits

This will be the model for the circuit I intend to assemble.

First step is to provide a PRECISION excitation current for the RTD (and the thermistor too, come to think of it!) that is low enough to avoid "heating" my resistance based sensor, or at least keep it to a stable (and quantified) minimum.

I have a wonderful collection of DIP chips, again many thanks to my friend Gus. There  I just happened to find some LM358N  (single-supply dual Op Amp) 8 pin DIP chips. Googling for datasheets, I learned this one is designed specifically for embedded applications with a single voltage supply (many op amps require two, a plus rail and a minus rail).

All right, a precision current source is easy enough using op amps (circuit). This will insure the voltage dropped across the RTD is not influenced by uncontrolled variation in the current going through it.

And as mentioned avoid resistance heating of the sensor.

The document linked above sets the excitation current at 1 mA, which has the added benefit of taking current load off the Arduino. Oh, okay the precision current source needs power...if we take it from the Arduino, it's certainly less than the 8 or 9 mA my current setup uses.

Then we need a voltage gain amplifier to change this 1 - 2.99 Volt range to 0 - 5 Volts, which is  the FULL RANGE of input to our ADC. Again, Op Amps to the rescue.  And wouldn't it be nice to put some kind of low-pass filter in there, so we don't see fast changes?  

Why Reinvent The Wheel?

I've worked with RTDs in an industrial setting, where all of these circuits were "built in" to both the systems and the calibration tools  used to maintain them. It made for a modular approach, which I highly recommend when you design and build anything. Building blocks that once mastered can be re used.

While I understood something about the level of complexity involved in these devices, I took them for granted. Now I want to really understand the nuts and bolts of this stuff! Wiser heads have advised me that it's easy to get sidetracked with theory, pleasantly lost in the details, (and learning a LOT) when for "a few pennies more" you could just "git 'er done".  

I took a break from my approach, mainly because of the unexpected time and effort it took me to get this far. 

I see that many retail sources, like  SparkFun  will sell you temperature sensors well suited for embedded applications..

TMP36 - Temperature Sensor
SEN-10988

Temperature Sensor - Waterproof (DS18B20)
SEN-11050

If you're asking why I send you off to SparkFun to look,  here's why: it's local for me and they
stock & sell some very tempting geek toys.

As an alternative, maybe Grainger would have items, that while more targeted to industrial
customers, would appeal to hobbyists.  I'm going to check on that and I invite you to do the same.

Disclaimer:      No ads here folks, that's the way I like it.
                      I get nothing from SparkFun that I didn't pay for.
                      (But if that changes I'll let you know)

I can't describe the feelings I had when I looked at these product descriptions...elated that they are so inexpensive, available and potentially useful. I have to admit, I needed a moment alone.  They are now "on order"...

And I became a bit frustrated at all the "gyrations" I've been through chasing down this data and trying to use it. I sat down initially thinking "I have all this in my head! Let's go!" but the exercise of translating that stuff "in my head" to a working model teaches me just how much I know and how well I understand it. I'm still catching up with myself!   

This is a very good example of the complexity that is to be found when you look "under the hood". It makes sense (to me) to be aware of it at the very least.

Able to use it? Wonderful. Able to  keep it "working good and lasting a long time"? Better still. Able to design your own solutions? That's where I want to go...

More ideas for Space Heater Thermostat

After studying up on quadrature encoders, I bought one from Sparkfun!

Rotary Encoder
COM-09117

While I was at it, I got the Mayhew Labs blue LED encoder ring board upon which to mount my encoder.

Rotary Encoder LED Ring Breakout Board - Blue
COM-10407

And a black plastic knob.

Originally, I wanted to use this quad encoder as a general purpose manual input adjuster. As it relates to my Space Heater project, I want a manual setpoint adjusting knob to control the level of heat being produced.

Later on I hope to have a better control system for my Space Heater to make it more useful as the "climate control" for my tabletop greenhouse.

I want a temperature sensor, a control knob, a thermostat,  and an LCD display of both setpoint (demand) and the output of the heater. Above and beyond that, the ability to monitor and control it from say, my Android tablet via WiFi. Yeah, pimp that puppy!!!

I control the heater with Pulse Width Modulation,  using a loaned TI MSP430G2 microcontroller board (thanks again Gus). I'm not sure if it will be up to doing all that, but if it can't, no problem.  I can use the Arduino.

I want to point out that I've gotten the LED display to respond to program inputs, but the quadrature encoder itself has never seemed to work.

After much digging and double checking I have convinced myself the encoder is functional, and that I've wired it up correctly to the proper pins on my Arduino Mega2560.  My friend Gus showed me how simple
it is to function check one of these encoders with an ohmmeter or two LEDs each with current limiting resistors in series, and a DC power source.

Oleg has written an elegant Tutorial & Example Sketch he makes available at the  Circuits@Home website's blog.  Oleg's function  uses a lookup table and some binary bit manipulation to implement a "state machine".

As I understand it this provides a sanity check by first reading the A and B pins simultaneously, and weeding out "illegal state changes". In other words, the function must return -1, 0, or +1 to indicate one incremental move either clockwise or counterclockwise, of the encoder shaft. the function is called many many times a second. This ensures a sampling rate that is sure to "catch" those twin-but-out-of-phase series of switch closures and openings.

This particular encoder has 12 "clicks" in one complete revolution of the encoder shaft, fortunately making it inexpensive for hobbyist and learning purposes.   These clicks are points where the encoders A and B terminals connect to momentarily to its ground or common pin using a mechanical switch.

Higher quality/price rotary quadrature encoders may have as many as 1024 points in on full revolution, and as a result provide far more resolution (and cost more!). Many of them are also employ optical switches...no "clicks"! They turn smoothly and avoid the problems associated with "bounce" prone mechanical switches.

The illegal (theoretically impossible or just plain meaningless) state changes, which could be due to electrical interference, bouncing switch contacts, broken wires, or bad timing,  are trapped and reported as 0, indicating no movement.

The heart of this function encoder_read() involves taking a snapshot of the logic levels of all the pins that belong to one "group" at the same time, which is important because you are monitoring two inputs, the encoder's A terminal and B terminal, in relation to time.

These A and B terminals make momentary contacts 90 degrees out of phase with each other, hence the term "quadrature". They are connected to digital input pins on the Arduino.

Setup involves enabling  the internal pullup resistors.  The digital input pins are set in the 1 state using digitalWrite().  When the encoder shaft turns, the switch contacts of the A and B terminals on the encoder pull their respective Digital Input pins on the Arduino low momentarily.

Oleg's example is written for an Arduino Pro, which has different pin numbers, names and PORT groupings than does my Mega2560. I've done a lot of digging to learn this much. Needless to say, when "it doesn't work" you end up learning far more about it than you expected to.

(Here's my sketch)

It is based on Mayhew Lab's example sketch, (which also uses Oleg's encoder_read() function) made freely available at their web site

I've been using debugging statements liberally sprinkled throughout this sketch to monitor what's going on, and it seems that when Oleg's encoder_read() function gets to the part about actually reading PINB, what it sees is that PB7, Pin 13 on my Arduino, is always high.

PINB = 10000000 prints out every time the loop calls the encoder_read function. I think that's pretty conclusive evidence...but of what I 'm not sure. This tells me PB7 is always HIGH and PB6 - PB0 are always LOW no matter how I twist that encoder knob.

Each of the 8 bits, 0-7 correspond to physical pins on the headers that form a PORTx group In this case, PORTB.

In my case I have my encoder hooked up to PINB, which includes PWM pins 6-13.

The Reference materials at Arduino.cc caution that pins 6 ( PB0 ) and 7 (PB1) , are not usable being connected to the crystal pins. So I guess we don't care about those two.

I believe we only care about the changes that occur on PWM Pins 8, 9, and 10 (PB2, PB3, and PB4).

But they never change. Still trying to understand why.

That's the latest.
.

IoT (Internet of Things)

IoT (Internet of Things)

The Meetup website, Meetup.com, has been under Denial of Service attack lately for some reason or other. 
Here's a link that may work or not:

http://www.meetup.com/Internet-of-Things-Denver-Meetup/

The Meetup

Last night at the Meetup we listened to Jim (Jingfeng Liu) of LinkSprite Inc., based in Longmont CO. 

www.linksprite.com  

Jim gave us a presentation on their company's powerful & versatile new micro-controller board (more like a PC actually)named pcDuino, seemingly designed to make techno-geeks like me salivate profusely. 

I WANT ONE!!! Maybe later after I've pushed my Arduino Mega 2560 to its limits, I'll move up. 

IoT deals with the idea of having all your clever personal electronics being able to communicate with each other and perform actions based on some plan. To somehow take care of those endless chores involved in managing our ever-growing list of "time saving/labor saving high-tech devices". 

IoT, I surmise, aims to give these devices the tools to manage themselves, to communicate with each other and you, to turn them into your own docile and well-trained electronic servants instead of a cloud of flies buzzing around your head demanding your constant attention. 

"Oh, there's an app for that."  

All well and good, but soon we have to have some "Uber-App" to rule them all (these one-trick ponies). Oh, and WHAT ELSE do these apps do(that you aren't supposed to know about)?

This is strangely similar to those wonderful plastic "discount cards" every retail chain would like you to carry around with you.

I don't want to carry a Rolodex around with me because all those "discount cards" won't fit in my wallet. And know that the card issuers are data-mining my every purchase.

This is another operational model designed to serve not you, but them.  

Home Automation seems to be near the bull's eye of this IoT target, with other subjects scattered around it.  

These words come to mind when I hear "IoT"

• Communication 
• Remote Monitoring & Control 
• Networking

Now of course, many businesses and developers want to "cash in" on this new area of interest. 

I for one dislike the idea that for anything "new" to survive it must FIRST and FOREMOST be Profitable. How useful or functional it is seems to be a secondary consideration. Sad.

I'll offer the example of Micro$oft, whose "business plan" seems to be based on  making constant changes to their proprietary operating system Windows, and their big cash cow Office, and selling it over and over. 

They rush it out the door on a schedule that makes their code monkeys work overtime, weeping as they watch their management-imposed "deadline" approach, and forces you the consumer to beta test it for them (for free) while they feverishly work on rolling out an "upgrade" or a "patch" to make it do what they told you it would do. 

And of course Microsoft is infamous for its "security through obscurity" philosophy. It's like trying to build a dam out of Swiss cheese if you ask me.

The better developers want to make their gadgets play nice with everyone else's gadgets. Some keywords here are: 

• Open Source Software
• Open Source Hardware
• Standardization
• Interconnectivity
• Interoperability.

The not-so-good developers (in my opinion) want to rush their proprietary walled-garden implementations to market, to gain "market share" and thereby try smother their competitor's "babies" in the crib.

I could start ranting about the evils of a capitalist economic model but I forgot to bring my soap box.

I am old enough to remember the market share race between VHS and BetaMax video recording and playback devices.  

BetaMax was far better but it "finished" in second place behind VHS and slid into disuse. 

About Technology In General 

The old saying about fire (and and later on, electricity) still holds true: 

It's a great servant but a terrible master. 

Get your hands on it, look "under the hood" -- learn about it, understand it, use it actively.

Don't be a passive consumer, trained to throw away "old stuff" and spend your money on the latest shiny new tech gadget.

I've worked for decades in the field of "automated remote control" as an Instrument & Controls Technician (we I&C Techs call it "Industrial Process Control") in large facilities: factories, chemical plants, electric power generation, pipeline.  
So this IoT business seems to me like the broader tech-aware public beginning to do many of the same things I've been working with most of my working life, with some new areas of application.

Now that I have more time on my hands, I'm beginning to seriously play with the popular new micro-controller  boards such as Arduino, TI LaunchPad, and SOC (System On Chip) boards such as GuruPlug, & Rasperry Pi.

Sustainability

In keeping with my personal values about reducing, reusing, recycling, I connect these shiny new tech toys to salvaged gear normally destined for the landfill, (or lately electronic recycling, which has become The Law not only for businesses but now for consumers as well, here in the Denver area).

Joe Public is slow to get the message (and comply).  "What? Now you want me to pay for recycling my hazardous waste? NOOOOoooooooo..."

I regularly scan curbs in my neighborhood for "free stuff" that the owners hope they won't have to pay to have hauled off, so I can salvage parts that are useful to me.

There are still TVs, Microwaves, Printers, Computers, Monitors, furniture, etc. being set out on the curb. it's an ecology of junk. I think that's great.

You have to get there fast, to beat the scrap metal salvagers... 
I set out the metal I don't use on MY curb...and that disappears! 

I disassemble broken or discarded devices and pull out the useful bits to reuse in my projects: LEDs, 7 segment displays, pushbuttons, potentiometers (and rarely, a quadrature encoder), stepper motors, sensors, wiring, discrete electronic components like voltage regulators, logic chips, op amps, LCD displays, etc.

I also dumpster dive for construction waste, scrap lumber/wire/sheet metal too. In lean times I have salvaged aluminum and other metals to sell at the scrap yard for money.

My Space Heater Thermostat project is described elsewhere in this blog.

I have incorporated that project into a little tabletop greenhouse I have put together (almost completely from salvaged/reused materials I might add). 

This year for my vegetable garden I want to try germinating my own seedlings instead of buying hothouse plants to transplant to my backyard. That involves controlling lighting and temperature.    

Space Heater Thermostat Project.

New project for a new year...

There are links in this blog. Words you might know, or not. Most of the links go to WikiPedia, "the free online encyclopedia". I'm a big fan of WikiPedia.

WikiPedia is edited by the general public, with some organizational oversight for consistency. To be sure, with hotly contested subjects, like religion or politics, there are actual "editing wars" going on continually but I feel pretty confident in the quality of entries on the sciences and technology.

   I do tinker with with my own Arduino ATMega2560  board, and a loaned Texas Instruments MSP-430G2553 board. Both of these are microcontroller boards.

   Both boards use an Integrated Development Envionment or IDE, which is in this case a free software download. The Texas Instruments I IDE, Energia, is a near clone of the preceeding Arduino IDE, both based on Wiring.

   Both let you create programs in an interpreted language (very similar in syntax to C++ or so I understand) that provides functions, data types, constants and conditional logic statements to get information, act on it in a defined way and provide outputs to the real world, to control electrical/electronic devices.

    These IDEs function to allow you to write code (referred to as "sketches") in an easy way and a compiler to turn your code into machine language, which is sent to the memory of the microcontroller on the board.
You can make your sketches public, share them as many are.

   What can these microcontroller boards do? Microcontrollers are at the heart of the controls of just about any modern gadjet that has a keypad and a display....the television, the remote controls you use, the microwave, dishwasher, clothes washer, dryer, house thermostat, your home security system, to name only a few. Want to build your own Home Automation system? You could do that now.

   Your car has at least one microcontroller, assuming it's 1980s or newer --- its Electronic Control Module or ECM. As you may be aware, these automotive microcontrollers are becoming the new hardware hacking frontier...for hot rodders old and new.

   Getting back on subject, these hobbyist-oriented microcontroller boards can be easily connected to additional circuits that are also inexpensive, well documented and easily constructed. And from there, you can connect to and control a wide range of devices, bring in information from sensors, connect to the internet...it's a techno-geek's dream come true.

   This is the power to create, put into the hands of the general public...google Maker culture sometime if you want a little tour of technology as seen from the hobbyist's and tinkerer's point of view.

What, no posts for over a year? Ooooops...

Well into 2014, no posts for over a year? Ooooops...

Catching up:  I got my built-from-junk quadrature encoder assembled.

It seems my sensors (paper presence detectors from printers) are not up to the task of seeing through my transparent encoder wheel, printed in black ink on overhead projector transparency sheets.

I was amazed how EXPENSIVE that stuff is ....wow! 3M still makes it but $50 for a pack of 10 8.5 x 12 sheets?  Overhead projectors yeah, another "not-obsolete-but-abandoned" technology. \

I've noticed that as consumer grade tech rushes into the future, older but serviceable tech suddenly gets a little cheaper...then a LOT cheaper...then the price goes back UP...as the available stock dwindles down.  

Punching holes in my encoder wheel for the benefit of these sensors is out of the question.
I wouldn't be able to cut small enough holes accurately enough.

I will be investigating other sensors...light sensitive perhaps, not IR sensitive like the paper sensors.

I have been working on other projects...I'll mention them in another post.

Encoders - How do they work?

 I will explain the term Quadrature a little later. This is a type of Incremental encoder, so I should first talk a little about how incremental encoders work.

Most encoders are based on a wheel of some sort. It might be made of some opaque material with a series of holes around the edge, or perhaps some transparent material with a series of opaque regions separated by transparent regions. Or it might be a printed circuit board with specially shaped traces to provide several different channels of electrical contact.

As the wheel turns, some sort of sensor, optical or electrical, marks the presence or absence of signal, and converts that information to some usable form. What is happening is that a mechanical device is generating digital data, which can be processed to give us the information we want.

                                   http://frontrangerobotics.org/Jan05/EncoderForRMS.jpg

In this picture, we see a code wheel and an optical sensor. It can detect the presence of the opaque sections of the encoder wheel, or the "see-through" areas. Sensors like this are used a lot in printers, to signal the presence/absence of a sheet of paper. I'll be showing you later how I used some to build my own encoder! This is an example of an Incremental encoder.

                                            http://en.wikipedia.org/wiki/Rotary_encoder

In this picture, we see a 13 track Absolute encoder. There are 13 concentric tracks of conductive areas on a non-conducive disk. 13 small metal spring contacts will ride on each of those 13 rings

and generate electrically a binary bit. All 13 of those bits will be used to generate a binary number,

that corresponds to one and only one position on the wheel.  And notice that the tracks don't go all the way around. We don't WANT an absolute encoder disk to turn more than one revolution.

We connect that wheel in some manner to something we want to monitor, like a rotating wheel, or the stem of a valve. Now, in the case of the tank level gauge, we are converting the linear motion of the float, riding on the surface of the liquid, into a measurement of distance.

Our little encoder wheel is revolving, being driven by a gearing system tied to the float by a flexible metal tape. Is it a rotary encoder? Or a linear encoder? Note there is a distinction made between how the encoder works and what sort of measurement is being made.

Also, consider that the encoder used in this tank level gauge is Absolute...it generates a unique digital pattern for each position on the wheel. That should tell you that we have to scale one revolution of this encoder wheel to the entire length that the float can travel, because if the wheel turns more than 360 degrees, we'd be generating these unique codes twice. This is done mechanically, with gearing.   

Investigating Rotary Incremental Quadrature Encoders

My interest in encoders started when I noticed that the volume control knob on my home stereo receiver/amplifier was acting strangely.

After some years of trouble free operation, I noticed that when I turned it on, and discovered that "the kids" had cranked the volume up to an intolerable level before turning it off, my frantic attempts to spin the volume knob in the CCW direction to lower the volume had the effect of increasing it even more!

Some experimentation revealed that by turning the knob very slowly CCW, the volume could be lowered. Turning the knob in the CW direction did not exhibit this behavior--that worked normally.

I mentioned this to my Electrical Engineer friend Gus. He asked me "Is the knob the kind that turns endlessly in either direction?" I told him it was, and he guessed it was probably a "rotary quadrature encoder".

Now, in my years as an Instrumentation & Controls technician, I had some exposure to shaft encoders on large machinery. Most of the ones I had seen simply output a switch contact to signal that a shaft or gear was either turning or not turning. Only a few of the ones I'd seen actually sent a signal range indicating the speed, direction or amount of rotation.

And I'd seen a float type level gauge for above-ground petroleum storage tanks. I'm referring to the trusty Varec 2900 Automatic Tank Gauge, with optional 2900 Float Tape Transmitter.  This device has a metal tape connected to a float inside the tank, going up and over two pulleys, and back down the outside of the tank (inside a metal tube) to a "head unit", where there is a spring to keep the tape under tension, without lifting the float out of the liquid, or preventing it from following the liquid level as it moves up or down.

Inside the head unit is a mechanical system which uses the motion of the metal tape to operate a large display, much like the old mechanical odometers found in automobiles. This provides a local display for reading the tank level visually.

The optional Float Tape Transmitter contained a circular wheel, much like a printed circuit board, with concentric rings of conductive traces linked together. Electrical spring contacts (we called them fingers) would ride on these rings and send either a "continuity" or "non-continuity" (as the encoder wheel was turned by the mechanical gauge) to an electronic circuit board that would convert that information into an analog signal range of 4 to 20 milliamps  of DC current--4 for "tank empty" and 20 for "tank full", and all the levels between those two points.

That signal could then be sent far away to a control room, to drive a remote display indicating the tank level, and perhaps optionally sound an alarm if the tank got "too full" or "too low", or turn pumps on and off, to maintain some desired level. 

OK, back from memory lane. Let me continue with a discussion of some terms I discovered.

This term "quadrature" sparked my curiosity, so I started searching the internets for more information. The first thing I learned is there are different words to describe encoders: Linear, Rotary, Absolute, Incremental, and Quadrature.

Linear and Rotary describe the type of motion the encoder detects. A linear encoder might report on the movement of some machine part that only moves in a straight line--forward and backwards, like the print head of a printer. A print head moves back and forth across the paper, depositing drops of ink, and its position and speed must be controlled precisely. Rotary, as the name suggests, means that the encoder is detecting motion in something that...(you guessed it) rotates.

Absolute and Incremental describe the manner in which the encoder detects and reports on the motion being observed. The example I gave, of a float type tank level gauge, would be an "absolute" encoder.

That means that for each position detected, there is a unique combination of bits (remember the multiple fingers reading "on" and "off"? That's a group of bits that can be read as numbers.)

Incremental, on the other hand, means the encoder can only detect changes--a change in distance (linear) or angle (rotary) from the previous to the current position, or the speed (and perhaps direction) of movement (linear) or rotation. You wouldn't be able to tell the exact position from that information.  You wouldn't know "where you are" unless you knew "where you were" and "how far you went".

So, I learned that my malfunctioning volume knob is an example of a Rotary Incremental Quadrature Encoder.

In my next post, I'll try to explain in more detail how encoders are made, and how they work.