John Walshe wrote: > > Roman, > Let me see if I have this right. I adjust the period until I get bit > change in the counter. However the pulse width will be constant (actually a > very very slowly changing - to the extent of being constant) so effectively > changing the period will only change duty cycle. Maybe I'm being obtuse but > I can't see how this will improve the resolution if I'm running with a > system clock of 1uS. Initially I thought you were suggesting a the use of > dither to get the resolution, but as far as I remember dither will help > resolve and additional 1/2LSB which will gain only 500uS. For the > application I would really need 250nS resolution on the width of the pulse. > > I'll give what I was proposing a shot and I'll let you know how it gets on. Hi John, this was your original idea am I correct?: > I'm considering a situation where I would clock timer1 in external mode, >driven by a copy of the Xtal output pin, in order to gain a bit of >resolution when capturing the width of a pulse using the capture register. >The Xtal frequency is 4Mhz, giving a pic clock of 1us which just a little >too slow. I am hoping to have a resolution of 250nS by using the above >method. I'm not sure it can work. If you are clocking the timer from the crystal itself (obviously with a buffer) you will get 4MHz ok and the timer will handle that speed. But at some point the PIC has to read the timer, and I believe PICs do that on a specific step every cycle. My datasheet says external clock inputs are read during Q3. That would always read the timer at count 3? Measuring the period of a very slowly changing pulse shouldn't be that hard to do at your required resolution. How long is the pulse? Could you use a faster PIC? Maybe if you generate a random element that adds a small random delay to the pulse start, you could read the dither and get very fine resolutions that way too. -Roman -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.