Over the course of my investigations into the systematic errors in the frequency readout using digital frequency counting, I noticed that my counter variable that keeps track of the number of clock cycles between successive zero crossings was NOT oscillating between 2 values as I would have expected (because of there being a +/- 1 clock cycle difference between successive zero crossings due to the fixed sampling time of 1/16384 seconds), but that there were occassional excursions to values that were +/- 3 clock cycles away. I then checked the output of the SCHMITTTRIGGER CDS library part (which I was using to provide some noise immunity), and noticed that it wasn't triggering on every zero crossing at higher frequencies. I tested this by hooking up a digital oscillator to the SCHMITTTRIGGER part, and looked at its output for different frequencies. The parameters used were as follows:
SCHMITTTRIGGER lower threshold: -1.0
SCHMITTTRIGGER upper threshold: +1.0
I am attaching plots for two frequencies, 3000Hz and 4628Hz (Attachments #1 and #2) . I would have expected a flip in the state of the output of the schmitt trigger between every pair of horizontal red lines in this plot, but at 4628 Hz, it looks like the schmitt trigger isn't catching some of the zero crossings? Come to think of it, I am not even sure why the output of the schmitt trigger takes on any values other than 0 or 1 (could this be an artefact of some sort of interpolation in the visualization of these plots? But this would not affect the conclusion about the schmitt trigger missing some of the zero crossings?)
As an interim measure, I implemented a Schmitt trigger in my C code block - it was just a couple of extra lines anyways - I have designated the schmitt trigger output as a static variable that should hold its value in successive execution cycles, unless it is updated by comparing the input value to the thresholds (code attached for reference). Attachments #3 and #4 show the output of this implementation of a Schmitt trigger at the same two frequencies, and I am seeing the expected flip in the state between successive zero crossings as expected (though I'm still not sure why it takes on values other than 0 and 1?). Anyways this warrants further investigation. An elog regarding the implications of this on the systematic error in the frequency counter readout to follow.