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 |
|
PIC16F73 ADC "glitches"
Started by ●September 14, 2004
Reply by ●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 ●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 ●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 ●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 ●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 ●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 ●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 |