On Tue, Nov 29, 2011 at 9:18 PM, c h 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 va= lue. > - 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 wro= te: > 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 ar= e > within input level specifications, the capture function will work reliabl= y > at any frequency below the maximum clock rate specification. It's essenti= al > 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. 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 wro= te: > Since the capture register is only 16 bits, at some lower frequency you'l= l > 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/(655= 36 > x CCP clock source period). > > There's nothing inherently inaccurate about timing low frequencies with t= he > 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). 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 wrote: > On Tue, Nov 29, 2011 at 11:46 AM, 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. > > 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. 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 wrote: > 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 i= n >> the elapsed time between events calculation. >> >> It's easy enough to calculate what frequency this will occur at -- 1/(65= 536 >> 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) 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. --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .