The fluctuation in the last two digits could be because of system noise. You can easily get rid of this by passing the ADC result through a a Low pass filter. Check out the below example project that shows how to stream 16 bit data through a DMA to a Filter. You will have to do some modifications to the project to pass the 20 bit result to the Filter.
Thank you very much for sending the link. I may be able to use a 16 bit if the Filter works.
Did you find that adding the filter helped to eliminate your system noise? my problem is , if I add the filter to the ADC it reduces the code value from its full scale range of 0-65535 to something like 0 -15 k. Currently im using a cutoff frequency of 100 Hz, as higher frequencies dont seem to reduce the code spread in the last two digits so well.
If you managed to get your setup working well, could you help me out?
Essentially, the data sheet is claiming to have a +/- 2 LSB INL for the 16 bit Delg Sig ADC. Im having alot of difficulty achieving this percision and need to find a configuration which can achieve this successfully
(Im using the CY8CKIT-001 with PSOC 5)
Unfortunately, the CY8CKIT-001 is not designed for high precision, low noise analog performance. The CY8CKIT-030 (PSoC3) and CY8CKIT-050 (PSoC5) are specifically designed for this goal.
The 001 kit is not designed to provide precision analog performance. The noise floor on this board is a bit higher compared to the CY8CKIT-030. The CY8CKIT-030 and CY8CKIT-050 are designed to provide good analog performance. Please read through this thread to know more about these boards, http://www.cypress.com/?app=forum&id=2232&rID=50255 .
I used averaging the results in software. Take three samples, add their values and divide the result by three. Made a huge difference for stability on psoc 4 BLE ADC
Welcome in the forum!
A bit old this thread from 2011. ;-)
Just a tip: You can do averaging in hardware by specifying to av 2, 4, 8... samples
Yes, I found the ADC setting in which it can be forced to average as much as 256 samples before issuing a result value. However, even these averaged values seem to have some 'flicker' in the last one or two digits. As the results are received fast enough on the client side, it is ok for me to do some more averaging on the client side as well in the software. This improves the stability of the reading. Even by averaging as little as 3 - 10 readings.
I tried to do this same trick on the server (peripheral) side, but seem to have some trouble (lack of basic knowledge...) in summarizing and dividing hex values. I'm not sure if an int16 can hold the sum of 256 int16 hex values.
I'm not sure if an int16 can hold the sum of 256 int16 hex values. No, it cannot even hold two added values for sure, but of course you may use as intermediate result an int32 Sum before you divide.