Brusque wrote:

>
>    When I put a square-wave of 1,000 Hz, it counts 2480 instructions for a
>complete cycle when the correct would be 2500. Also, it tells readings like:
>        2480, 2480, 2425, 2480, 2425
>
.......
> // Counting the time (in instructions) that it takes to detect 32 cycles
> T1CON.TMR1ON = 1;
> for (x=0; x < 32; x++) {
>  while(!PORTC.B7);
>  while(PORTC.B7);
> }
> T1CON.TMR1ON = 0;
>

Hi Edson,

It doesn't look like anyone else has solved the problem. I looked
over the algorithm again, and couldn't see anything obviously wrong.

The only thing that really stands out to me is that the difference
between 2500 and 2480 is 20 instruction cycles, or 4 usec, and this
could possibly the overhead involved in your for() loop above,
related to terminating the loop and turning off the timer. This is
why I code timing routines in assembler - so I know exactly what
the overhead will be.

Another issue relates to how accurate your input signal is. May not
be 1000 hz, but actually 992 hz.

Also, variability between readings - sometimes 2480 and sometimes
2425 - usually indicates something flaky in the initialization or
startup procedures, but I don't see anything obvious.

????????
============

Other comments:

All in all, this algorithm looks nice in terms of being able to
measure very very slow signals - however, clearly the loop overhead
is going to affect accuracy for faster signals.

It alos occurred to me that you have no way to bail out of the
for() loop in the case that signal freq = 0hz [no signal] or signal
disappears during measurement. Adding in bailout code, however, is
going to make the loop overhead that much longer.

- dan michaels
www.oricomtech.com
==================

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body