Jeremy Harris
Senior Member
In another thread discussing timing accuracy, hippy suggested starting a new thread on pulse width measurement accuracy:
The specification for the pulse train that I'm measuring is published and I've measured the pulse widths on my USB 'scope (a USB Instruments DS1M12 Stingray). My measured pulse widths match those of the spec very closely. For example, the inter-data packet low pulse should be 10mS and I make it exactly 10mS using the measurement cursors on the DS1M12. Similarly, the short data low pulse width (signifying a transmitted 0) should be 275µS and I've measured it at about 278µS and the long data low pulse width should be 1225µS and I make it 1260µS when measured with the 'scope.
A simple loop just measuring the 10mS pulse length with a 32MHz clock speed returns a value of around 7300, or about 9.125mS. I used this measurement to detect the start of a valid data packet and start measuring and storing the pulse widths for the next 32 low pulses, ignoring a 2.6mS low pulse that immediately follows the 10mS inter-packet gap. I get measured pulse lengths returned of around 193µS to 250µS for the pulses that are known to be about 275µS, yet the wider data pulses are measured as between 1218µS and 1258µS when they are known to be around 1260µS.
I suspect that the inaccuracy is more to do with other internal function behaviour rather than resonator accuracy, particularly given the non-linear error.
It's not causing me a problem, BTW, as I can easily work around it. This post is more a way of highlighting this behaviour.
which followed on from this observation I'd made:It's possibly you are reading 8% lower than expected but that could be an issue beyond internal oscillator accuracy. That is well outside manufacturer tolerances for the oscillator and far from what we have experienced when testing. Might be worth creating a separate thread to discuss that issue.
I'm currently pushing the limits a bit by trying to sequentially measure the width of 32 low pulses with just a 275µS high period between each low pulse. I therefore need to execute the code to measure the pulse width, store it, increment the storage address and be ready to measure the next low pulse in less than 275µS. Currently I'm running this on an 08M2, clocked at 32MHz, for two reasons. It seems that this variant might execute instructions very slightly faster than some of the others, plus I'm after a compact solution.Another vote for wide timing variability, even with seemingly similar code. I've been measuring this this morning, trying to get a bit of code to execute quickly, and even seemingly small changes have an appreciable effect on execution time. For example, running a simple FOR-NEXT loop to consecutively measure and store pulse widths indirectly into storage memory, with an ordinary variable as the loop counter, seems significantly slower than running the same loop with the byte pointer as the loop counter. The internal resonator and other internal function accuracy isn't great, either, my test programme reads around 8% low on a straightforward pulse width measurement, for example, and I suspect that would vary a bit from chip to chip.
The specification for the pulse train that I'm measuring is published and I've measured the pulse widths on my USB 'scope (a USB Instruments DS1M12 Stingray). My measured pulse widths match those of the spec very closely. For example, the inter-data packet low pulse should be 10mS and I make it exactly 10mS using the measurement cursors on the DS1M12. Similarly, the short data low pulse width (signifying a transmitted 0) should be 275µS and I've measured it at about 278µS and the long data low pulse width should be 1225µS and I make it 1260µS when measured with the 'scope.
A simple loop just measuring the 10mS pulse length with a 32MHz clock speed returns a value of around 7300, or about 9.125mS. I used this measurement to detect the start of a valid data packet and start measuring and storing the pulse widths for the next 32 low pulses, ignoring a 2.6mS low pulse that immediately follows the 10mS inter-packet gap. I get measured pulse lengths returned of around 193µS to 250µS for the pulses that are known to be about 275µS, yet the wider data pulses are measured as between 1218µS and 1258µS when they are known to be around 1260µS.
I suspect that the inaccuracy is more to do with other internal function behaviour rather than resonator accuracy, particularly given the non-linear error.
It's not causing me a problem, BTW, as I can easily work around it. This post is more a way of highlighting this behaviour.