This is not 'static testing' rather with a sinewave but seems quite relevant to testing DAC INL/DNL : https://pico-adc.markomo.me/INL-DNL/
The focus is testing the ADC in the Raspberry Pi Pico MCU, but since that chip's using an SAR technique, its using a DAC internally. He even works out a best fit of the bit weights using a Python program, based on the INL measurement. Pretty impressive to me.
The focus is testing the ADC in the Raspberry Pi Pico MCU, but since that chip's using an SAR technique, its using a DAC internally. He even works out a best fit of the bit weights using a Python program, based on the INL measurement. Pretty impressive to me.
Interesting reading. What my tool does is to visualize and adjust the DNL at cumulative code transition points. Cumulative code transition points are the binary value changes, where all lower bits change at the same time, e.g. the LSB change:
0000 0000 0000 0001 > 0000 0000 0000 0010
or in the middle of the range:
0000 0001 1111 1111 > 0000 0010 0000 0000
or the MSB change:
0111 1111 1111 1111 > 1000 0000 0000 0000
The same code transitions happen repeatedly and combined throughout the full binary range 0000 0000 0000 0000 to 1111 1111 1111 1111 (16-bit DAC, like on a CD).
I found that these cumulative code transitions are most critical for DNL error, as can be seen on the previously attached screenshots.
New low level distortion test
I wrote an other code for ESP8266, that sends a 440 Hz, -60 dB sine on I2S. The trick is that selectable fixed binary values (resulting in analog DC shift) can be added. This way the distortion can be measured (and with my variable error current injecting tool it can be minimized) at cumulative code transition points. I found that it is the 3rd harmonic that is dominant and it can be reduced into the noise floor, by monitoring the FFT spectrum.
What is also useful, you don't need a 100x low noise amplifier. You can also hear the clarity of the 400 Hz signal with headphones. You still need a simple hardware (ESP8266 and four toggle switches) to select the cumulative code transition point (bit where the test is to be done). Currently I can select bit 9, 10, 11, 12, 13, 14 and 15. Distortion can also be dialed in to minimum.
If there is enough interest, I will publish the -60 dB 400 Hz sine code, too. Please note that it is different from a 400 Hz sine that can be generated with Audacity. My code will shift the sine by selectable amount of DC, so various portions of the full range can be "magnified in", not only around the analog null level (which is the binary MSB code change, BTW). I can test at lower bits code transitions too, which are also causing DNL at those code changes.
0000 0000 0000 0001 > 0000 0000 0000 0010
or in the middle of the range:
0000 0001 1111 1111 > 0000 0010 0000 0000
or the MSB change:
0111 1111 1111 1111 > 1000 0000 0000 0000
The same code transitions happen repeatedly and combined throughout the full binary range 0000 0000 0000 0000 to 1111 1111 1111 1111 (16-bit DAC, like on a CD).
I found that these cumulative code transitions are most critical for DNL error, as can be seen on the previously attached screenshots.
New low level distortion test
I wrote an other code for ESP8266, that sends a 440 Hz, -60 dB sine on I2S. The trick is that selectable fixed binary values (resulting in analog DC shift) can be added. This way the distortion can be measured (and with my variable error current injecting tool it can be minimized) at cumulative code transition points. I found that it is the 3rd harmonic that is dominant and it can be reduced into the noise floor, by monitoring the FFT spectrum.
What is also useful, you don't need a 100x low noise amplifier. You can also hear the clarity of the 400 Hz signal with headphones. You still need a simple hardware (ESP8266 and four toggle switches) to select the cumulative code transition point (bit where the test is to be done). Currently I can select bit 9, 10, 11, 12, 13, 14 and 15. Distortion can also be dialed in to minimum.
If there is enough interest, I will publish the -60 dB 400 Hz sine code, too. Please note that it is different from a 400 Hz sine that can be generated with Audacity. My code will shift the sine by selectable amount of DC, so various portions of the full range can be "magnified in", not only around the analog null level (which is the binary MSB code change, BTW). I can test at lower bits code transitions too, which are also causing DNL at those code changes.
Last edited: