Searching \ for '[PIC] Capture on CCP1' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'Capture on CCP1'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Capture on CCP1'
2011\11\28@104917 by Yigit Turgut

picon face
Hi all,

Recently I am trying to capture pulse duration using Capture module on
CCP1 port and print the frequency to lcd. Configuration, timer
settings, interrupt monitoring etc, everything works as expected
except one thing ; LCD shows ridiculous values for example it gives
'11869' value for a 1kHz PWM input. It is responsive to changes in the
frequency of the applied pwm but not accurate/consistent. This is the
crippled code not to pollute around ; I am currently using MPLAB C18
with a target of 18f2550. I can post the entire code as well but the
mistake lies in this section I suppose ;

void main(void)
{
unsigned char config1=0x00,timer_value = 0x00;

TRISC = 0; //all c ports are output
TRISCbits.RC2 = 1; //ccp1 input

SetTmrCCPSrc(T1_SOURCE_CCP);   //Set Timer 1 as source for input capture module

         config1 = CAP_EVERY_RISE_EDGE | CAPTURE_INT_OFF ; //configure input
capture for capture on every rising edge and its interrupt off
         OpenCapture1(config1 );                                                                
         OpenTimer1(0); //start the timer        

while(!PIR1bits.CCP1IF);  // Wait for event

INCAPResult = (int)ReadCapture1(); // read result

 display((int)INCAPResult);   // print result on lcd

       while(1);                
CloseCapture1();                                
}

Connections and configurations are all triple checked and they work.
But as I mentioned LCD is not returning correct values. Went over the
code for lots of times without  no luck!

Any ideas ?

Have a nice day

2011\11\28@105507 by Yigit Turgut

picon face
I applied various frequencies (PWM) and LCD outputs are as following ;

1kHz >> 11857
2kHz >>  5857
4kHz >> 2857
16kHz >> 607

Timer was expected to counts less in a higher frequency than a lower
one. System responds logically somehow but lacks from precision. It
can be a data conversion typo or etc. My current mental situation is
not suitable to debug more.

On Mon, Nov 28, 2011 at 5:49 PM, Yigit Turgut <spam_OUTy.turgutTakeThisOuTspamgmail.com> wrote:
{Quote hidden}

>

2011\11\28@144248 by Brent Brown

picon face
On 28 Nov 2011 at 17:55, Yigit Turgut wrote:

> I applied various frequencies (PWM) and LCD outputs are as following ;
>
> 1kHz >> 11857
> 2kHz >>  5857
> 4kHz >> 2857
> 16kHz >> 607
>
> Timer was expected to counts less in a higher frequency than a lower
> one.

That is correct, and the results above confirm that. While not precise the results are definitely in the ball park.. as frequency is doubled the period count seems to approximately halve. Without knowing the units it would seem the only problem you need to address is to fine tune the accuracy/jitter in the results.

> System responds logically somehow but lacks from precision. It
> can be a data conversion typo or etc. My current mental situation is
> not suitable to debug more.

We have been all been there before, some very regularly :-)  
{Quote hidden}

Would be useful to see code for ReadCapture1(), as that would seem to be what captures the timer value. Incidentally you don't need to put (int) in front of it each time you call it if the prototype for this function implicitly states that it returns an int.

-- Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: +64 27 433 4069
eMail:  brent.brownspamKILLspamclear.net.nz


2011\11\29@114625 by Yigit Turgut

picon face
Hi Brent, thanks for the response.

I got mad last evening and wrote the entire code from scratch ;
replaced C18 library functions and coded every solid old school style.
It now works flawlessly. I also believe that you were probably right
about the content of ReadCapture().

However, I can measure very precisely between 200Hz - 60Khz, there is
no accuracy below 200Hz. I had read somewhere about this very case of
low frequency inaccuracy when using Capture module, but can't seem to
find it now.

On Mon, Nov 28, 2011 at 9:42 PM, Brent Brown <.....brent.brownKILLspamspam.....clear.net.nz> wrote:
{Quote hidden}

>

2011\11\29@122419 by Matt Pobursky

flavicon
face
Since the capture register is only 16 bits, at some lower frequency you'll
have to start counting CCP source TIMER rollovers too and include them in
the elapsed time between events calculation.

It's easy enough to calculate what frequency this will occur at -- 1/(65536
x CCP clock source period).

There's nothing inherently inaccurate about timing low frequencies with the
CCP module. I have several products where I time low Hz range signals
accurate to 1uS (using a 1 MHz TIMER to source clock for CCP).

Matt Pobursky
Maximum Performance Systems

On Tue, 29 Nov 2011 18:46:25 +0200, Yigit Turgut wrote:
{Quote hidden}

2011\11\29@123548 by Matt Pobursky

flavicon
face
I took another look at the numbers and unless you are using an extremely
high source clock frequency I doubt timer overflows are the problem.

What does your 200 Hz and below signal look like? As long as the edges are
within input level specifications, the capture function will work reliably
at any frequency below the maximum clock rate specification. It's essential
a free running counter with a latch that's clocked by your input signal.

If you are getting inaccuracies at lower frequencies I'd suspect signal
level or jitter issues.

Matt Pobursky
Maximum Performance Systems

On Tue, 29 Nov 2011 18:46:25 +0200, Yigit Turgut wrote:
{Quote hidden}

2011\11\29@131547 by Adam Field

flavicon
face
On Tue, Nov 29, 2011 at 11:46 AM, Yigit Turgut <TakeThisOuTy.turgutEraseMEspamspam_OUTgmail.com> wrote:
> However, I can measure very precisely between 200Hz - 60Khz, there is
> no accuracy below 200Hz. I had read somewhere about this very case of
> low frequency inaccuracy when using Capture module, but can't seem to
> find it now.

Are you checking to see if your timer overflowed? If your incoming
period is larger than timer_max*prescaler_period you will overflow.
Assuming you are using a 16 bit counter the maximum value is 65535 and
will overflow back to 0. When reading the captured timer value you
need to check if the timer has overflowed, either by interrupt or by
reading the flag.

You an avoid overflows by assigning a larger prescaler to the timer at
the cost of resolution.

You may be able to get away with storing an overflow count during a
timer interrupt service to add back in later when you calculate the
frequency. You will be off by some cycles (unless you keep careful
track of the instructions used during the ISR / or adjust the timer
accordingly) but you'll be helped by the fact the incoming signal is
lower frequency

2011\11\29@141822 by c h

picon face
Yigit Turgut wrote:
> However, I can measure very precisely between 200Hz - 60Khz, there is
> no accuracy below 200Hz. I had read somewhere about this very case of
> low frequency inaccuracy when using Capture module, but can't seem to
> find it now.

Someone on this list said that using free-running counters could be a
good idea.

- Capture the values of the counters on each pulse.
- Keep the values for a second or so.
- Calculate the difference between the latest value and the second ago value.
- Divide the difference by the number of pulses within the time interval.

Regards

2011\11\30@000730 by c h

picon face
Matt Pobursky wrote:
> Since the capture register is only 16 bits, at some lower frequency you'll
> have to start counting CCP source TIMER rollovers too and include them in
> the elapsed time between events calculation.
>
> It's easy enough to calculate what frequency this will occur at -- 1/(65536
> x CCP clock source period).
>

To stay platform independent, I think, we should take the counters as
24 or 32 bit arranged in software; Even for 18F line, the arrangment
seems not to be a problem at the frequencies (200Hz - 60Khz

2011\11\30@155952 by Yigit Turgut

picon face
On Tue, Nov 29, 2011 at 9:18 PM, c h <RemoveMEcognitive.harmonyspamTakeThisOuTgmail.com> wrote:
> Yigit Turgut wrote:
>> However, I can measure very precisely between 200Hz - 60Khz, there is
>> no accuracy below 200Hz. I had read somewhere about this very case of
>> low frequency inaccuracy when using Capture module, but can't seem to
>> find it now.
>
> Someone on this list said that using free-running counters could be a
> good idea.
>
> - Capture the values of the counters on each pulse.
> - Keep the values for a second or so.
> - Calculate the difference between the latest value and the second ago value.
> - Divide the difference by the number of pulses within the time interval.

TMR1 is already running as free running timer. Interesting thing is ;
when I implement the flow you listed without using CCP via standart
digital i/o it's not that accurate.


On Tue, Nov 29, 2011 at 7:35 PM, Matt Pobursky <piclistEraseMEspam.....mps-design.com> wrote:
{Quote hidden}

I had followed a crippled methodology while measuring the
characteristics. It actually can measure precisely between 40Hz-64kHz.
This limits are originating from using a 16bit timer, there are some
methods to enhance this range as Brent mentioned.

On Tue, Nov 29, 2011 at 7:24 PM, Matt Pobursky <EraseMEpiclistspammps-design.com> wrote:
{Quote hidden}

I hadn't read you this post before posting the previous reply, I
completely agree with you.

On Tue, Nov 29, 2011 at 8:15 PM, Adam Field <RemoveMEadamEraseMEspamEraseMEbadtech.org> wrote:
{Quote hidden}

I could use a larger prescaler but I need to perform something at
each rising edge. If a capture occurs but timer is not overflowed in
one duty cycle than I switch to low frequency measuring mode but I am
surely off some cycles. It might be originating from C18 as well, I
need to port it to asm and make a compare benchmark.

On Wed, Nov 30, 2011 at 7:07 AM, c h <RemoveMEcognitive.harmonyTakeThisOuTspamspamgmail.com> wrote:
{Quote hidden}

That's correct but one timer configuration lets a maximum of 16bit
timing, there are 4 timers in 18f which can be configured as one in
serial. Sounds pretty good to me

More... (looser matching)
- Last day of these posts
- In 2011 , 2012 only
- Today
- New search...