kranenborg
Senior Member
Dear forum members
After some experimentation it seems to me that I cannot obtain the count accuracy as I should get according to the spec of the COUNT command. According to this spec, for a 64MHz 28X2 (with a very accurate crystal, see my recent Accurate Frequency Counter project) the following holds for the COUNT command:
* 400Khz max frequency for the incoming signal (2.5us)
* The unit of time for the sampling period used by the COUNT command: 62.5 us
So I fed a 400KHz signal to the count command with this sampling period. Since I had noticed a problem I also ran the count command with the frequency signal divided by 2 and by 4 (using a 74HC4040), and increased the sampling period to 125us and 250us respectively (to obtain the same number of counts). In all of these three cases the estimated frequency (= CountValue*divider/samplingperiod) should be really close to 400KHz. This is what I got as result as the calculated frequency based on the count value:
Divide: Sampl.period: CalcFreq (Khz):
1 (=400Khz) 62.5ms (=1x) 380.5
2 (=200KHz) 125ms (=2x) 398.7
4 (=100KHz) 250ms (=4x) 399.6
From this I think the following can be concluded:
I checked the effect of DISCONNECT, it has some very minimal effect but certainly does not explain the large deviations in the first two cases.
For a test at 4MHz I got a similar result: with a divider of 16, resulting in an effective frequency of 250KHz fed to the counter (which is way lower than 400 KHz) and measurement time of 250ms I obtained an estimated frequency of 3.93Mhz instead of 4MHz, which falls in line with the results in the table
So how can we explain these results in the light of these specs:
Thanks!
Jurjen Kranenborg
After some experimentation it seems to me that I cannot obtain the count accuracy as I should get according to the spec of the COUNT command. According to this spec, for a 64MHz 28X2 (with a very accurate crystal, see my recent Accurate Frequency Counter project) the following holds for the COUNT command:
* 400Khz max frequency for the incoming signal (2.5us)
* The unit of time for the sampling period used by the COUNT command: 62.5 us
So I fed a 400KHz signal to the count command with this sampling period. Since I had noticed a problem I also ran the count command with the frequency signal divided by 2 and by 4 (using a 74HC4040), and increased the sampling period to 125us and 250us respectively (to obtain the same number of counts). In all of these three cases the estimated frequency (= CountValue*divider/samplingperiod) should be really close to 400KHz. This is what I got as result as the calculated frequency based on the count value:
Divide: Sampl.period: CalcFreq (Khz):
1 (=400Khz) 62.5ms (=1x) 380.5
2 (=200KHz) 125ms (=2x) 398.7
4 (=100KHz) 250ms (=4x) 399.6
From this I think the following can be concluded:
- The upper limit frequency (for a single time unit) is likely much lower than 400KHz (as indicated by the first result but also by the second; even at 200KHz (divider 2) likely some signal transitions are missed.
- The effect of multiple time units (of 62.5us) used in a single sample period is probably very limited (maybe in the transition between time units a few counts are missed ...)
I checked the effect of DISCONNECT, it has some very minimal effect but certainly does not explain the large deviations in the first two cases.
For a test at 4MHz I got a similar result: with a divider of 16, resulting in an effective frequency of 250KHz fed to the counter (which is way lower than 400 KHz) and measurement time of 250ms I obtained an estimated frequency of 3.93Mhz instead of 4MHz, which falls in line with the results in the table
So how can we explain these results in the light of these specs:
- Maybe the upper limit of 400KHz is incorrect and much lower?
- Maybe some other processes interrupt the COUNT command, even within a single unit of time (62.5us at 64MHz), and if so, can they be disabled/controlled?
Thanks!
Jurjen Kranenborg