Reply by Chris Bore January 31, 20132013-01-31
Thanks to all who contributed to this discussion - it has been valuable to me and I am grateful.

Further to this, I checked with the NPL (National Physical Laboratory, the UK's standards body for measurement). They use the term 'ADC code' to refer to the output from the ADC. That is regarded as a code rather than a 'number' - a code being the result of a rule that has been applied to the input, and subject to interpretation only once decoded. The code may be decoded to an intermediate code: for example an ADC may return unsigned integer codes where code '0' refers to the most negative analog input, and this might be transcoded to signed integer so that '0' represents zero input. There is no standard defined term for such an intermediate code, only for the raw output. Conversion of code to a value with physical units is by reference to calibration, as has been discussed in this thread.

NPL, being a measurement institute, are uncomfortable with the result of any measurement being divorced from its origins, so the concept of an ADC code or any value derived from it being 'just a number' is alien to them and unacceptable (all measurements must be labelled with their origin, units, calibration, and so on) - however this is in the context of measurement and obviously there are fields where the things being dealt with are not thought of as the results of measurement. In the context of my original question I was thinking of the ADC output being the result of some measurement of some physical quantity, so I will take NPL's advice on that. The term 'LSB' is used not as a unit for the ADC code, but as a measure of error - thus to label a graph of ADC code against time with the units 'LSBs' is incorrect (though commonly done).

NPL referred me to IEEE Standard 1241-2010 [1] �Terminology and Test Methods for Analog-to-Digital Converters� which defines terminology and uses the term 'ADC code' as do the NPL and others.

On Wednesday, 30 January 2013 23:50:00 UTC, rickman  wrote:
> On 1/30/2013 10:00 AM, Chris Bore wrote: > > > On Tuesday, 29 January 2013 14:37:36 UTC, Chris Bore wrote: > > >> When creating metadata for a signal I give names to the values - for instance 'volts' or 'Pascals'. Before calibration, a signal read from an ADC has a value that I tend to refer to as measured in 'ADC counts'. That sounds a bit clumsy - does anyone know of a routinely accepted name for that type of unit? > > >> > > >> > > >> > > >> Thanks, > > >> > > >> > > >> > > >> Chris Bore > > >> > > >> BORES Signal processing > > >> > > >> chris@bores.com > > >> > > >> www.bores.com > > > > > > Having sought guidance from some ADC manufacturers (Freescale, Analog Devices and Texas Instruments) all agree that the term 'LSB' is the most commonly used. > > > > > > Wikipedia (should have looked before..) also defines the LSB but uses ADCcode on the axis of their graph. > > > > > > Freescale's definition is as follows: > > > > > > "Least Significant Bits (LSB) � A least significant bit (LSB) is a unit of > > > voltage equal to the smallest resolution of the ADC. This unit of measure > > > approximately relates the error voltage to the observed error in > > > conversion (code error), and is useful for systemic errors such as > > > differential non-linearity. A 2.56-V input on an ADC with � 3 LSB of error > > > could read between $1FD and $203. This unit is by far the most common > > > terminology and will be the preferred unit used for error representation" > > > > Don't mean to be offensive, but Wikipedia is not a primary source of > > info. It is put together by amateurs with no formal supervision. It is > > supposed to be based on valid references, but is often wrong. I > > remember once when I checked a reference and found the wiki page had an > > important statement exactly *backwards*. > > > > Freescale I will consider to be a primary source. > > > > Rick
Reply by Tim Wescott January 30, 20132013-01-30
On Wed, 30 Jan 2013 18:45:50 -0500, rickman wrote:

> On 1/30/2013 12:07 PM, Tim Wescott wrote: >> On Tue, 29 Jan 2013 18:02:06 -0500, rickman wrote: >> >>> On 1/29/2013 12:34 PM, Tim Wescott wrote: >>>> So I should stop using "radians", "radians/second", etc., in any >>>> calculations involving angles or frequencies? >>>> >>>> >>> Actually, it's not a "pure" number. >> >> Yes and no. In digital-land, it's a pure number, regardless of how it >> arrived. > > I can't say I get that. Are *all* digital numbers unitless? If not, > then why this one?
How can a digital number be anything other than unitless? Digital numbers are, by definition, numbers. Numbers are, by definition, unitless. Unless you know way more about mathematics than anyone else on earth.
>>> Each count of the ADC represents some voltage and that is always >>> considered when doing signal processing, >> >> Now how can you say that? How many signal processing projects have you >> been involved in? How many products that include signal processing of >> your authorship have successfully shipped? >> >> I've been at this game for well over 20 years. Yes, the ADC input >> (which isn't always a voltage, especially if you consider things like >> encoders and resolver-to-digital converters to be "ADC"s). But there >> are significant stages in the design of a signal-processing chain where >> you want to take each signal in its native units, and the native units >> of a number isn't volts. > > You keep saying this, but you really aren't explaining. BTW, I think > your playing the "experience" card is a bit pompous. Can no one with > less experience than you have a valid opinion? BTW, you really don't > know how much experience I have. It's not like I woke up this morning > and decided to consider ADCs.
I know that you've asked some pretty damned naive questions regarding your WWVB receiver, and that you stated that you were a hobbyist, and that you have a history on this group and others of refusing to accept good advice. And, of course, getting bent out of shape when this is pointed out. I am explaining. My transmitter is working. You aren't listening. Fix your receiver.
> If the user is measuring a signal from an antenna or an amplifier, would > volts not be the unit the input is scaled to? In the part quoted below, > I said, "unless that voltage represents some other quantity like... > power." So there may be other units for the input. But to say it is > always unitless by definition is so far unsupported.
OK. You're clearly smarter than me. So, oh experienced, smart one, educate me: What are the units of 10? What are the units of 100? What are the units of 42? Whatever your answer is -- that's the units of the number that comes out of an ADC.
>>> for example calculating dB between two values of ADC readings, the >>> multiplier will be 20, not 10 because it the ADC is measuring >>> voltage... >>> unless that voltage represents some other quantity like... power. >>> >>> The measurement has some units. The question is about what to label >>> the ADC reading before it has been scaled, that's all. I say label it >>> by the quantity the input to the ADC represents. >> >> If you have a block diagram of a large system, and you are analyzing >> the signal flow, it is an extremely good idea to get very picky about >> dimensions, both of your signals and of your gains. >> >> So, for instance, an ADC will have an input that is a voltage, an >> output that is a dimensionless number, and a gain whose dimensions are >> volts^-1. Similarly, a DAC might have an output that is a voltage, an >> input that is a dimensionless number, and a gain whose dimensions are >> volts. > > I can't say I follow that. What is wrong with having units of volts on > the digital signal and the converters having unitless gain? If you want > to make a point, please give some justification for it other than, "this > is the way I found it to be best".
Because the digital signal is a _number_. Which is inherently _unitless_. What's wrong with having units of volts on a tape measure? Because it's totally WRONG, that's what's wrong with it!
>> But expressing gains in volts^-1 or volts can be confusing: hence, I >> prefer to speak of an ADC gain as counts/volt (or fullscale/volt -- I >> use one or the other depending on what I'm trying to convey and how >> many short cuts I feel I can take), and a DAC gain as volts/count. >> That clarifies things immensely, much as one may see an amplifier's >> gain labeled as "volts/volt", even though technically the amplifier's >> gain is dimensionless. > > I think the issue the OP is discussing is how to make the code more > clear. In that case I see no reason not to give a label to the digital > values that represent the quantity being measured.
"Before calibration I tend to refer to it as..." "Before calibration" Let's try that again: "Before calibration" What is the reading, in volts, of an uncalibrated meter that reads "10"? Remember: you're way smarter than me, so you _do_ have an answer. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
Reply by rickman January 30, 20132013-01-30
On 1/30/2013 10:00 AM, Chris Bore wrote:
> On Tuesday, 29 January 2013 14:37:36 UTC, Chris Bore wrote: >> When creating metadata for a signal I give names to the values - for instance 'volts' or 'Pascals'. Before calibration, a signal read from an ADC has a value that I tend to refer to as measured in 'ADC counts'. That sounds a bit clumsy - does anyone know of a routinely accepted name for that type of unit? >> >> >> >> Thanks, >> >> >> >> Chris Bore >> >> BORES Signal processing >> >> chris@bores.com >> >> www.bores.com > > Having sought guidance from some ADC manufacturers (Freescale, Analog Devices and Texas Instruments) all agree that the term 'LSB' is the most commonly used. > > Wikipedia (should have looked before..) also defines the LSB but uses ADCcode on the axis of their graph. > > Freescale's definition is as follows: > > "Least Significant Bits (LSB) � A least significant bit (LSB) is a unit of > voltage equal to the smallest resolution of the ADC. This unit of measure > approximately relates the error voltage to the observed error in > conversion (code error), and is useful for systemic errors such as > differential non-linearity. A 2.56-V input on an ADC with � 3 LSB of error > could read between $1FD and $203. This unit is by far the most common > terminology and will be the preferred unit used for error representation"
Don't mean to be offensive, but Wikipedia is not a primary source of info. It is put together by amateurs with no formal supervision. It is supposed to be based on valid references, but is often wrong. I remember once when I checked a reference and found the wiki page had an important statement exactly *backwards*. Freescale I will consider to be a primary source. Rick
Reply by rickman January 30, 20132013-01-30
On 1/30/2013 12:07 PM, Tim Wescott wrote:
> On Tue, 29 Jan 2013 18:02:06 -0500, rickman wrote: > >> On 1/29/2013 12:34 PM, Tim Wescott wrote: >>> So I should stop using "radians", "radians/second", etc., in any >>> calculations involving angles or frequencies? >>> >>> >> Actually, it's not a "pure" number. > > Yes and no. In digital-land, it's a pure number, regardless of how it > arrived.
I can't say I get that. Are *all* digital numbers unitless? If not, then why this one?
>> Each count of the ADC represents >> some voltage and that is always considered when doing signal processing, > > Now how can you say that? How many signal processing projects have you > been involved in? How many products that include signal processing of > your authorship have successfully shipped? > > I've been at this game for well over 20 years. Yes, the ADC input (which > isn't always a voltage, especially if you consider things like encoders > and resolver-to-digital converters to be "ADC"s). But there are > significant stages in the design of a signal-processing chain where you > want to take each signal in its native units, and the native units of a > number isn't volts.
You keep saying this, but you really aren't explaining. BTW, I think your playing the "experience" card is a bit pompous. Can no one with less experience than you have a valid opinion? BTW, you really don't know how much experience I have. It's not like I woke up this morning and decided to consider ADCs. If the user is measuring a signal from an antenna or an amplifier, would volts not be the unit the input is scaled to? In the part quoted below, I said, "unless that voltage represents some other quantity like... power." So there may be other units for the input. But to say it is always unitless by definition is so far unsupported.
>> for example calculating dB between two values of ADC readings, the >> multiplier will be 20, not 10 because it the ADC is measuring voltage... >> unless that voltage represents some other quantity like... power. >> >> The measurement has some units. The question is about what to label the >> ADC reading before it has been scaled, that's all. I say label it by >> the quantity the input to the ADC represents. > > If you have a block diagram of a large system, and you are analyzing the > signal flow, it is an extremely good idea to get very picky about > dimensions, both of your signals and of your gains. > > So, for instance, an ADC will have an input that is a voltage, an output > that is a dimensionless number, and a gain whose dimensions are > volts^-1. Similarly, a DAC might have an output that is a voltage, an > input that is a dimensionless number, and a gain whose dimensions are > volts.
I can't say I follow that. What is wrong with having units of volts on the digital signal and the converters having unitless gain? If you want to make a point, please give some justification for it other than, "this is the way I found it to be best".
> But expressing gains in volts^-1 or volts can be confusing: hence, I > prefer to speak of an ADC gain as counts/volt (or fullscale/volt -- I use > one or the other depending on what I'm trying to convey and how many > short cuts I feel I can take), and a DAC gain as volts/count. That > clarifies things immensely, much as one may see an amplifier's gain > labeled as "volts/volt", even though technically the amplifier's gain is > dimensionless.
I think the issue the OP is discussing is how to make the code more clear. In that case I see no reason not to give a label to the digital values that represent the quantity being measured. Rick
Reply by Tim Wescott January 30, 20132013-01-30
On Wed, 30 Jan 2013 08:54:07 -0800, Rick Lyons wrote:

> On Tue, 29 Jan 2013 09:30:28 -0600, Tim Wescott > <tim@seemywebsite.please> wrote: > >>On Tue, 29 Jan 2013 06:37:36 -0800, Chris Bore wrote: >> >>> When creating metadata for a signal I give names to the values - for >>> instance 'volts' or 'Pascals'. Before calibration, a signal read from >>> an ADC has a value that I tend to refer to as measured in 'ADC >>> counts'. That sounds a bit clumsy - does anyone know of a routinely >>> accepted name for that type of unit? >>> >>> Thanks, >>> >>> Chris Bore BORES Signal processing chris@bores.com www.bores.com >> >>Hey! Maybe we have enough gravitas to think of one ourselves and claim >>that it's industry standard! >> >>I also use "ADC counts", or just "counts". "Counts" is less confusing >>when you've got a system with both ADC counts and encoder counts running >>around. "LSB" works, too, and matches what you see on ADC and DAC data >>sheets, although I'll bet that _someone_ would get confused and think >>you're storing data logarithmically. >> >>Or, if we all started now (particularly Rick Lyons, who could misuse his >>well-earned notoriety) we could call them "bunnies" or something. > > Hi Tim, > Instead of "ADC count" we could use the terms: > > doohickey, or > thingamabob, or maybe > thingamajig. > > [-Rick-]
I like "bunnies" because they're little, and there always seems to be more around than you think. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
Reply by Tim Wescott January 30, 20132013-01-30
On Tue, 29 Jan 2013 18:02:06 -0500, rickman wrote:

> On 1/29/2013 12:34 PM, Tim Wescott wrote: >> On Tue, 29 Jan 2013 11:22:44 -0500, robert bristow-johnson wrote: >> >>> On 1/29/13 10:30 AM, Tim Wescott wrote: >>>> On Tue, 29 Jan 2013 06:37:36 -0800, Chris Bore wrote: >>>> >>>>> When creating metadata for a signal I give names to the values - for >>>>> instance 'volts' or 'Pascals'. Before calibration, a signal read >>>>> from an ADC has a value that I tend to refer to as measured in 'ADC >>>>> counts'. That sounds a bit clumsy - does anyone know of a routinely >>>>> accepted name for that type of unit? >>>>> >>> ... >>>> >>>> Hey! Maybe we have enough gravitas to think of one ourselves and >>>> claim that it's industry standard! >>>> >>>> I also use "ADC counts", or just "counts". "Counts" is less >>>> confusing when you've got a system with both ADC counts and encoder >>>> counts running around. "LSB" works, too, and matches what you see on >>>> ADC and DAC data sheets, although I'll bet that _someone_ would get >>>> confused and think you're storing data logarithmically. >>> >>> when we model the whole system with analog and digital components, the >>> value that comes out of the A/D is dimensionless. a number. a *pure* >>> number. i don't think it should have any units. anymore than any >>> other pure number. like 2.718281828 . >>> >>> both the A/D and the D/A have their own "Vref" value that is known. >>> the A/D essentially divides the input voltage by Vref and scales that >>> result with a known value (usually 2^(N-1) where N is the number of >>> bits in the output word). the D/A divides by that scaler and >>> multiplies by its Vref and the output has units "volts". (also that >>> Zero-Order Hold transfer function is applied at the D/A model.) >>> >>> you might also scale it differently so that the rails on that value is >>> -1 and +1 rather than +/- 2^(N-1). that would make sense if you have >>> a fixed-point DSP where a left-justified implies that. >>> >>> i might *label* that value coming out of the A/D port as "raw data", >>> but i would never attach any unit to it. it's just a number. a pure >>> number. >> >> So I should stop using "radians", "radians/second", etc., in any >> calculations involving angles or frequencies? >> >> > Actually, it's not a "pure" number.
Yes and no. In digital-land, it's a pure number, regardless of how it arrived.
> Each count of the ADC represents > some voltage and that is always considered when doing signal processing,
Now how can you say that? How many signal processing projects have you been involved in? How many products that include signal processing of your authorship have successfully shipped? I've been at this game for well over 20 years. Yes, the ADC input (which isn't always a voltage, especially if you consider things like encoders and resolver-to-digital converters to be "ADC"s). But there are significant stages in the design of a signal-processing chain where you want to take each signal in its native units, and the native units of a number isn't volts.
> for example calculating dB between two values of ADC readings, the > multiplier will be 20, not 10 because it the ADC is measuring voltage... > unless that voltage represents some other quantity like... power. > > The measurement has some units. The question is about what to label the > ADC reading before it has been scaled, that's all. I say label it by > the quantity the input to the ADC represents.
If you have a block diagram of a large system, and you are analyzing the signal flow, it is an extremely good idea to get very picky about dimensions, both of your signals and of your gains. So, for instance, an ADC will have an input that is a voltage, an output that is a dimensionless number, and a gain whose dimensions are volts^-1. Similarly, a DAC might have an output that is a voltage, an input that is a dimensionless number, and a gain whose dimensions are volts. But expressing gains in volts^-1 or volts can be confusing: hence, I prefer to speak of an ADC gain as counts/volt (or fullscale/volt -- I use one or the other depending on what I'm trying to convey and how many short cuts I feel I can take), and a DAC gain as volts/count. That clarifies things immensely, much as one may see an amplifier's gain labeled as "volts/volt", even though technically the amplifier's gain is dimensionless. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
Reply by Rick Lyons January 30, 20132013-01-30
On Tue, 29 Jan 2013 09:30:28 -0600, Tim Wescott
<tim@seemywebsite.please> wrote:

>On Tue, 29 Jan 2013 06:37:36 -0800, Chris Bore wrote: > >> When creating metadata for a signal I give names to the values - for >> instance 'volts' or 'Pascals'. Before calibration, a signal read from an >> ADC has a value that I tend to refer to as measured in 'ADC counts'. >> That sounds a bit clumsy - does anyone know of a routinely accepted name >> for that type of unit? >> >> Thanks, >> >> Chris Bore BORES Signal processing chris@bores.com www.bores.com > >Hey! Maybe we have enough gravitas to think of one ourselves and claim >that it's industry standard! > >I also use "ADC counts", or just "counts". "Counts" is less confusing >when you've got a system with both ADC counts and encoder counts running >around. "LSB" works, too, and matches what you see on ADC and DAC data >sheets, although I'll bet that _someone_ would get confused and think >you're storing data logarithmically. > >Or, if we all started now (particularly Rick Lyons, who could misuse his >well-earned notoriety) we could call them "bunnies" or something.
Hi Tim, Instead of "ADC count" we could use the terms: doohickey, or thingamabob, or maybe thingamajig. [-Rick-]
Reply by Chris Bore January 30, 20132013-01-30
On Tuesday, 29 January 2013 14:37:36 UTC, Chris Bore  wrote:
> When creating metadata for a signal I give names to the values - for instance 'volts' or 'Pascals'. Before calibration, a signal read from an ADC has a value that I tend to refer to as measured in 'ADC counts'. That sounds a bit clumsy - does anyone know of a routinely accepted name for that type of unit? > > > > Thanks, > > > > Chris Bore > > BORES Signal processing > > chris@bores.com > > www.bores.com
Having sought guidance from some ADC manufacturers (Freescale, Analog Devices and Texas Instruments) all agree that the term 'LSB' is the most commonly used. Wikipedia (should have looked before..) also defines the LSB but uses ADCcode on the axis of their graph. Freescale's definition is as follows: "Least Significant Bits (LSB) &#4294967295; A least significant bit (LSB) is a unit of voltage equal to the smallest resolution of the ADC. This unit of measure approximately relates the error voltage to the observed error in conversion (code error), and is useful for systemic errors such as differential non-linearity. A 2.56-V input on an ADC with &#4294967295; 3 LSB of error could read between $1FD and $203. This unit is by far the most common terminology and will be the preferred unit used for error representation"
Reply by rickman January 29, 20132013-01-29
On 1/29/2013 12:34 PM, Tim Wescott wrote:
> On Tue, 29 Jan 2013 11:22:44 -0500, robert bristow-johnson wrote: > >> On 1/29/13 10:30 AM, Tim Wescott wrote: >>> On Tue, 29 Jan 2013 06:37:36 -0800, Chris Bore wrote: >>> >>>> When creating metadata for a signal I give names to the values - for >>>> instance 'volts' or 'Pascals'. Before calibration, a signal read from >>>> an ADC has a value that I tend to refer to as measured in 'ADC >>>> counts'. That sounds a bit clumsy - does anyone know of a routinely >>>> accepted name for that type of unit? >>>> >> ... >>> >>> Hey! Maybe we have enough gravitas to think of one ourselves and claim >>> that it's industry standard! >>> >>> I also use "ADC counts", or just "counts". "Counts" is less confusing >>> when you've got a system with both ADC counts and encoder counts >>> running around. "LSB" works, too, and matches what you see on ADC and >>> DAC data sheets, although I'll bet that _someone_ would get confused >>> and think you're storing data logarithmically. >> >> when we model the whole system with analog and digital components, the >> value that comes out of the A/D is dimensionless. a number. a *pure* >> number. i don't think it should have any units. anymore than any other >> pure number. like 2.718281828 . >> >> both the A/D and the D/A have their own "Vref" value that is known. the >> A/D essentially divides the input voltage by Vref and scales that result >> with a known value (usually 2^(N-1) where N is the number of bits in the >> output word). the D/A divides by that scaler and multiplies by its Vref >> and the output has units "volts". (also that Zero-Order Hold transfer >> function is applied at the D/A model.) >> >> you might also scale it differently so that the rails on that value is >> -1 and +1 rather than +/- 2^(N-1). that would make sense if you have a >> fixed-point DSP where a left-justified implies that. >> >> i might *label* that value coming out of the A/D port as "raw data", but >> i would never attach any unit to it. it's just a number. a pure >> number. > > So I should stop using "radians", "radians/second", etc., in any > calculations involving angles or frequencies? >
Actually, it's not a "pure" number. Each count of the ADC represents some voltage and that is always considered when doing signal processing, for example calculating dB between two values of ADC readings, the multiplier will be 20, not 10 because it the ADC is measuring voltage... unless that voltage represents some other quantity like... power. The measurement has some units. The question is about what to label the ADC reading before it has been scaled, that's all. I say label it by the quantity the input to the ADC represents. Rick
Reply by Tim Wescott January 29, 20132013-01-29
On Tue, 29 Jan 2013 17:29:33 +0000, Eric Jacobsen wrote:

> On Tue, 29 Jan 2013 09:17:10 -0800, Rob Gaddi > <rgaddi@technologyhighland.invalid> wrote: > >>On Tue, 29 Jan 2013 08:51:55 -0800 (PST) Chris Bore >><chris.bore@gmail.com> wrote: >>> >>> I agree the value is dimensionless, although a dimensionless quantity >>> may still have units (for example that show its origin, as in 'm/m' >>> for a ratio of lengths. I am thinking though of how the value should >>> be labelled, for instance on the axis of a graph. ADC manufacturers, >>> as Tim points out, tend to label as 'LSBs'. It would also be >>> reasonable to label simply as 'ADC value'. My question was more to see >>> if there is an accepted and commonly used term, but to establish a >>> correct but new one (or the lack of one) is an option. >>> >>> >>I tend to use "codes" rather than counts, but same thing. And I agree, >>ascribing it a unit even though it's dimensionless is handy, for many of >>the same reason that keeping track of radians (equally dimensionless) is >>handy. >> >>The other unit I use is "fullscale". I go back and forth depending on >>the project and my mood as to whether my ADC outputs 12 integer bits >>worth of "codes", or 12 fractional bits of "fullscale". >> >> > When dealing in the raw numbers I've always found LSBs to be the most > useful and easily understood. For a lot of signal processing stuff if > it's in DB it's DBFS (from fullscale, as Rob suggested). > > Sometimes, like for some phase detectors, I use MSBs. > > I think if there was a unit that would stick easily with broad > application it probably would have done so already. > > On rare occassion when the signal is proportional to a physical > measurement it is useful to assign units, but usually something like > psi/LSB. Usually there's an oddball scaling factor involved which > makes it unhandy, but having the proportional units come along with the > signal can help a lot in system analysis or interpreting results.
On those even rarer occasions where I have the luxury of using floating point numbers, the signal gets labeled with the appropriate units. I suppose that if you were using fractional values and had enough headroom you could arrange your scaling so that (for instance) a 0-10V reading would get converted to fractional then multiplied out so the result was in kV. That doesn't scan for me, though. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com