I am trying to accurately measure audio rate square waves using the TC module of the SAM3S. I am finding that the actual counts coming back between ra and rb are about 1.1% off, varying depending on the freq if the square wave. I need 0.27% accuracy.
I have a SAM3S4A with an external 12Mhz crystal 403C35E12M00000 and 22pf caps. This device has a 30ppm tolerance. Am I expecting too much?
Meanwhile, I have swtiched the slow clock to XTAL32 and measured main clock. I get 12001280Hz, so if that measurement process is reliable, then it appears the 1.1% error is elsewhere. Could it be introduced in PLLA? Is there a way to use the slow clock to measure the actual MCK value? Or is the error within the TC module itself? Is the loading of ra and rb subject to error on the order of 1%?
Note the signal is not perfect, and ra and rb do jump around, but the variation there is around 0.25%, which is great. It really seems like the whole process is shifted either by a MCK inaccuracy, or something systemically wrong in the ra and rb acquisition.
Discussion around product based on ARM Cortex M3 core.
2 posts • Page 1 of 1
The problem was that I was using rb-ra to get a half wave count. Of course the wave is not perfectly symmetric, in fact there is about a 1.1% symmetry error in the signal. So the answer was to configure the clock to start on a falling edge. Load ra on rising, rb on falling, and trigger an interrupt on rb load. Disable the interrupt and the clock in the interrupt, and then take rb as the full cycle count (falling edge to falling edge).
Who is online
Users browsing this forum: No registered users and 4 guests