Reply by Dennis Clark ●September 15, 20042004-09-15
All,

Responses in-line below...

--- In , Robert Rolf <robert.rolf@u...> wrote:
> Leon Heller wrote:
> >
> >>All good advice, guys. I've tried the low pass idea, that had
> >>little to no effect. I've not tried the dummy load. This latter
> >>could be most enlightening since I am indeed running on a
solderless
> >>breadboard for this initial circuit.
> >
> >
> > That's the cause of your problem. You won't get the ADC working
properly
> > without a properly
> > designed PCB.
>
> Really?? I started my project with a 16F73 ADC on a breadboard,
> and it worked fine. Moved up to a 16F876 and got 10 bits, rock
solid.

Me too here - care in layout is essential. This is a pretty low
frequency setup and noise, except for motor noise, is minimal. I've
been working with motors and PICs for a long time and understand
that dynamic pretty well. Although this is a new app for me.

> And there is lots of stuff going on (10khz interrupts,
> Mhz SPI and khz PWM. The key is making sure that your bypass caps
> are where they need to be and that you avoid ground loops.
> I do use the power and ground busses on the breadboards, but
> made sure to arrange the chips to put the 'quiet' stuff on
> one size, the noisy stuff on the other, and feed power into
> the center.

This is what I did - in any application I make sure that the CPU
has a single point power entry that is heavily "guarded" whether
on the final design or on a solderless breadboard.

> I'd suggest that he has a firmware timing problem and is reading
> the ADC before conversion is complete. If he were to feed it
> a fast triangle wave he would see if his convertor is uniformly
> sampling since the delta between samples should be the same
> for all points except the peak.

I think that you are correct here. I put a "monitor" on my readings
and just let the thing sit there, doing nothing - Every so ofter,
but pretty regularly, I got a "glitch" in the ADC readings when
there should be nothing there at all. This is a ghost reading,
there is no noise in the system since nothing but the processor was
running. I'm using CCS PCM C compiler for this project and haven't
looked to see how they implemented their setup. All I get is this
sequence of functions:

setup_adc(ADC_CLOCK_DIV_32); what this does is obvious
setup_adc+ports(RA0_RA1_RA3_ANALOG); again, this is obvious
...
set_adc_channel(0);
delay_us(90); Calculated Tacq is 87us
ma = read_adc(ADC_START_AND_READ);

I'm thinking that the following sequence might be better:
setup_yada_yada...
...
read_adc(START_ONLY) to get it into free run mode

set_adc(0);
delay_us(90);
ma = read_adc(READ_ONLY);

This latter might give me what I need to get a proper reading with
correct timing. I've not yet examined the ASM output to see what
code they are generating, that might shed more light too.

regards,
DLC

>
> Robert




Reply by Robert Rolf ●September 15, 20042004-09-15
Leon Heller wrote:
>
>>All good advice, guys. I've tried the low pass idea, that had
>>little to no effect. I've not tried the dummy load. This latter
>>could be most enlightening since I am indeed running on a solderless
>>breadboard for this initial circuit. > That's the cause of your problem. You won't get the ADC working properly
> without a properly
> designed PCB.

Really?? I started my project with a 16F73 ADC on a breadboard,
and it worked fine. Moved up to a 16F876 and got 10 bits, rock solid.
And there is lots of stuff going on (10khz interrupts,
Mhz SPI and khz PWM. The key is making sure that your bypass caps
are where they need to be and that you avoid ground loops.
I do use the power and ground busses on the breadboards, but
made sure to arrange the chips to put the 'quiet' stuff on
one size, the noisy stuff on the other, and feed power into
the center.

I'd suggest that he has a firmware timing problem and is reading
the ADC before conversion is complete. If he were to feed it
a fast triangle wave he would see if his convertor is uniformly
sampling since the delta between samples should be the same
for all points except the peak.

Robert


Reply by Phil ●September 14, 20042004-09-14
Well, at least you will have a lot more noise - I typically see 2-3
LSBs on a solderless bb. The problem with those things is they have
all these parallel metal plates so you get capacitance and some
pretty odd ball couplings.

Its not clear to me that the solderless bb is the root really wild
readings like you are seeing though its probably contributing. The
noise has to come from somewhere and something. I suspect its with
your motors.

One other thing to try is to use sleep while doing the conversion.
It screws up timers in the mid range but does make the digital
section quieter. You might have to move up the the PIC18 range to be
able to sleep with the timer running. But I doubt that is your
problem. --- In , "Leon Heller" <leon.heller@d...>
wrote:
> ----- Original Message -----
> From: "Dennis Clark" <dlc@f...>
> To: <>
> Sent: Tuesday, September 14, 2004 8:32 PM
> Subject: [piclist] Re: PIC16F73 ADC "glitches" > >
> > All good advice, guys. I've tried the low pass idea, that had
> > little to no effect. I've not tried the dummy load. This latter
> > could be most enlightening since I am indeed running on a
solderless
> > breadboard for this initial circuit.
>
> That's the cause of your problem. You won't get the ADC working
properly
> without a properly
> designed PCB.
>
> Leon
> --
> Leon Heller, G1HSM
> http://webspace.webring.com/people/jl/leon_heller/




Reply by Leon Heller ●September 14, 20042004-09-14
----- Original Message -----
From: "Dennis Clark" <>
To: <>
Sent: Tuesday, September 14, 2004 8:32 PM
Subject: [piclist] Re: PIC16F73 ADC "glitches" >
> All good advice, guys. I've tried the low pass idea, that had
> little to no effect. I've not tried the dummy load. This latter
> could be most enlightening since I am indeed running on a solderless
> breadboard for this initial circuit.

That's the cause of your problem. You won't get the ADC working properly
without a properly
designed PCB.

Leon
--
Leon Heller, G1HSM
http://webspace.webring.com/people/jl/leon_heller/


Reply by Dennis Clark ●September 14, 20042004-09-14
All good advice, guys. I've tried the low pass idea, that had
little to no effect. I've not tried the dummy load. This latter
could be most enlightening since I am indeed running on a solderless
breadboard for this initial circuit.

thanks,
DLC

--- In , Chad Russel <chadrussel@y...> wrote:
> Adding to this: What is response time you need. Tacq limits the
> minimum response time, but if that is much faster than needed you
can
> add a resistor/cap low pass to the input of the DAC to kill fast
noise.
> Add the cap and resistor to the Tacq equation. Also, without
> knowing the program flow, I have found it a good idea to make sure
the
> DAC is ready for you by checking the busy before messing with it.
>
> Good luck,
> Chad
>
> --- Phil <phil1960us@y...> wrote:
>
> > You don't say much about the board itself. Your application
probably
> >
> > is an acid test for noise with those nasty noise producing
motors. I
> >
> > hope you've practiced good layout design - isolating the analog
> > section, ground planes, bypass caps, shielding on external
> > wires, ... You could try replacing the motor with a resistive
load
> > to see if it is the source.
> >
> > I frequently see errant readings from PIC ADCs but usually its
when
> > I'm using a solderless proto board - lots of noise. In one case
I
> > found that fluorescent light noise was getting picked by a
> > temperature sensor. I always test with a dummy sensor to see
where
> > the noise is coming from. If you can't find the source, you
could
> > just do a sanity check on each sample and reject the oddball
> > readings. Not a particularly satisfying solution but at least it
> > cures the symptom (but not the disease).
> >
> > --- In , "Dennis Clark" <dlc@f...> wrote:
> > > Hi all,
> > >
> > > I have a program on a 16F83 that is reading motor CEFM, with
many
> > > safeguards of course, that usually works swimmingly. However,
> > every
> > > so often I'll get a totally bogus error out of it, for instance:
> > > reading 24,25,25,-84,25,24... Huh? what is this called?
> > >
> > > I've got my Tad set to DIV 32 for a 14.74MHz clock which gives
a
> > > total Tacq of about 87us. I wait 1ms for everything to settle
down,
> > > set to AN0, start the acquire, wait 90us, read the result and do
> > the
> > > same on the other winding side. Normally all works well, but
like
> > I
> > > said, occasionally I get this bogus reading and I don't know
where
> > > it is coming from. This bogus reading plays hell with a PID
> > > algorithm as I'm sure you'd see. I'd love to get rid of it but
> > > nothing I've tried seems to work.
> > >
> > > Has anyone else seen this with PIC ADC hardware and found a
way
> > > to correct it?
> > >
> > > thanks,
> > > DLC
> >
> > =====
> My software has no bugs, only undocumented features. >
> __________________________________
>



Reply by Chad Russel ●September 14, 20042004-09-14
Adding to this: What is response time you need. Tacq limits the
minimum response time, but if that is much faster than needed you can
add a resistor/cap low pass to the input of the DAC to kill fast noise.
Add the cap and resistor to the Tacq equation. Also, without
knowing the program flow, I have found it a good idea to make sure the
DAC is ready for you by checking the busy before messing with it.

Good luck,
Chad

--- Phil <> wrote:

> You don't say much about the board itself. Your application probably
>
> is an acid test for noise with those nasty noise producing motors. I
>
> hope you've practiced good layout design - isolating the analog
> section, ground planes, bypass caps, shielding on external
> wires, ... You could try replacing the motor with a resistive load
> to see if it is the source.
>
> I frequently see errant readings from PIC ADCs but usually its when
> I'm using a solderless proto board - lots of noise. In one case I
> found that fluorescent light noise was getting picked by a
> temperature sensor. I always test with a dummy sensor to see where
> the noise is coming from. If you can't find the source, you could
> just do a sanity check on each sample and reject the oddball
> readings. Not a particularly satisfying solution but at least it
> cures the symptom (but not the disease).
>
> --- In , "Dennis Clark" <dlc@f...> wrote:
> > Hi all,
> >
> > I have a program on a 16F83 that is reading motor CEFM, with many
> > safeguards of course, that usually works swimmingly. However,
> every
> > so often I'll get a totally bogus error out of it, for instance:
> > reading 24,25,25,-84,25,24... Huh? what is this called?
> >
> > I've got my Tad set to DIV 32 for a 14.74MHz clock which gives a
> > total Tacq of about 87us. I wait 1ms for everything to settle down,
> > set to AN0, start the acquire, wait 90us, read the result and do
> the
> > same on the other winding side. Normally all works well, but like
> I
> > said, occasionally I get this bogus reading and I don't know where
> > it is coming from. This bogus reading plays hell with a PID
> > algorithm as I'm sure you'd see. I'd love to get rid of it but
> > nothing I've tried seems to work.
> >
> > Has anyone else seen this with PIC ADC hardware and found a way
> > to correct it?
> >
> > thanks,
> > DLC

=====
My software has no bugs, only undocumented features.
__________________________________
Reply by Phil ●September 14, 20042004-09-14
You don't say much about the board itself. Your application probably
is an acid test for noise with those nasty noise producing motors. I
hope you've practiced good layout design - isolating the analog
section, ground planes, bypass caps, shielding on external
wires, ... You could try replacing the motor with a resistive load
to see if it is the source.

I frequently see errant readings from PIC ADCs but usually its when
I'm using a solderless proto board - lots of noise. In one case I
found that fluorescent light noise was getting picked by a
temperature sensor. I always test with a dummy sensor to see where
the noise is coming from. If you can't find the source, you could
just do a sanity check on each sample and reject the oddball
readings. Not a particularly satisfying solution but at least it
cures the symptom (but not the disease).

--- In , "Dennis Clark" <dlc@f...> wrote:
> Hi all,
>
> I have a program on a 16F83 that is reading motor CEFM, with many
> safeguards of course, that usually works swimmingly. However, every
> so often I'll get a totally bogus error out of it, for instance:
> reading 24,25,25,-84,25,24... Huh? what is this called?
>
> I've got my Tad set to DIV 32 for a 14.74MHz clock which gives a
> total Tacq of about 87us. I wait 1ms for everything to settle down,
> set to AN0, start the acquire, wait 90us, read the result and do the
> same on the other winding side. Normally all works well, but like I
> said, occasionally I get this bogus reading and I don't know where
> it is coming from. This bogus reading plays hell with a PID
> algorithm as I'm sure you'd see. I'd love to get rid of it but
> nothing I've tried seems to work.
>
> Has anyone else seen this with PIC ADC hardware and found a way
> to correct it?
>
> thanks,
> DLC
Reply by Dennis Clark ●September 14, 20042004-09-14
Hi all,

I have a program on a 16F83 that is reading motor CEFM, with many
safeguards of course, that usually works swimmingly. However, every
so often I'll get a totally bogus error out of it, for instance:
reading 24,25,25,-84,25,24... Huh? what is this called?

I've got my Tad set to DIV 32 for a 14.74MHz clock which gives a
total Tacq of about 87us. I wait 1ms for everything to settle down,
set to AN0, start the acquire, wait 90us, read the result and do the
same on the other winding side. Normally all works well, but like I
said, occasionally I get this bogus reading and I don't know where
it is coming from. This bogus reading plays hell with a PID
algorithm as I'm sure you'd see. I'd love to get rid of it but
nothing I've tried seems to work.

Has anyone else seen this with PIC ADC hardware and found a way
to correct it?

thanks,
DLC