Benj wrote:
I find that when the datasheet is not being clear the best way is to experiment and find out for yourself what you can get away with.
see how fast you can run the ADC before your readings start going a bit screwy or inaccurate.
Very wise. I tried this and got the following results for every one of the speed options in the A/D properties screen.
Option, Sample time, Accuracy, Same result got from another option
FRC, 6us, No reading, 1MHz
OSC/2, 6us, Poor, 2MHz
OSC/4, 9us, Good, 3MHz
OSC/8, 28us, Excellent, 4 and 8MHz
OSC/16, 5us, Poor, 5MHz
OSC/32, 6.5us, Good, 6MHz
OSC/64, 14us, Excellent, 7MHz
OSC/128, 28us, Excellent, 8 and 4MHz
(Sorry that was a nicely tab aligned table till posted)
Those times include the time to turn an output on and off to drive a 'scope but I am assuming that that only takes <<1us.
Several things are weird about these results:
1) The sample time for RAW_sample_integer increases as expected from OSC/2 to OSC/8 but then drops dramatically again at OSC/16 and rises again to OSC/128 with 32-128 being a near repeat of 2-8. Why the non linear response? Has some Flowcode value rolled over at OSC/16 because my 64MHz clock speed is high?
2) Despite 1), slowing the OSC clock generally increases sample time as expected. But for MHz the opposite is true as faster clocks give slower sample times.
3) From OSC/32 to OSC/128 there is doubling of time for each division of clock by 2, as expected. But for the MHz settings changing slightly from 6 to 8 MHz causes a 4 times increase in time.
4) FRC is a default time but just produces a zero reading. One would assume that a default would be a safe value that would always work.
From 2) and 3) I’d interpret that the selected “MHz” is not really the MHz speed of the A/D clock, especially as this one isn’t supposed to operate at speeds higher than 1.3MHz, so how is it apparently giving accurate results at 7 and 8 MHz? Is it really: A/D clock = 2 x OSC/2^n where n is the “MHz”?
It is clear that accuracy drops off at times less than 10us and it’s consistent despite the anomalies above. "Good" above means within 3 and "poor" within 50 of the correct reading (out of 1023). For me OSC/64 gives a fast and accurate option, which matches the theoretical maximum of 11 A/D clock cycles at 0.7us per cycle = 7.7us = 1.3MHz. OSC/64 =1MHz if OSC=64MHz so OSC seems to be the PIC clock value after PLL.
I might push it to OSC/4 which only degrades 1 off the result for DC signals. Are AC ones likely to be less accurate due to the time taken to adjust the sampling capacitor between samples? But, as it's a 50Hz signal, there is not normally much change between sampes at my 100us sampling rate.
At higher A/D speeds is it reasonable to assume that what is happening is that the last few bits of the 10 bit sample are not being processed, so the answer for the first few bits is accurate but it’s miscalculating up to 1, 2, 4, 8, etc. as the speed increases? In results so far it is always reads low if overclocked, never high. If true my error of 50 is because it’s dropping the last 7bits which at most is an error of 64. I want to be sure it is never going to drop any of the first few bits instead, as the answer would then be up to 512 in error, but have not yet experienced that.
I can cope with up to 4 in error, so read as byte is an option, but in practice it makes little difference as I believe that the full 10 bit sample is still done but the last 2 bits then discarded. So it does not save sampling time.