Raspberry pi4 + ADC

Question

I have been working with Raspberry pi 4 to acquire analog signals. I get AD/DA High Precision Board by Waveshare (ADS1256 A/D) to convert analog input and I downloaded python source code from Waveshare to read samples from ADC. The board communicates with Raspberry through SPI. I tried to make a test: I acquired the equivalent in samples of 10s of signal and measured time elapsed reading those samples. I used time.time(). I repeated the test setting different sampling frequencies but I found out that increasing sampling rates resulted in increasing error and delay: at 100 Hz I got 10.34s instead of 10s, at 1000Hz I got 13.20s instead of 10s, at 15kHz I got 57.74s instead of 10s. SPI max speed has been set to 2MHz. Why there's such a delay? Here's the code:

import time
import timeit
import ADS1256
import RPi.GPIO as GPIO

try:
    ADC = ADS1256.ADS1256()
    ADC.ADS1256_init()
    fs = 5 #here I set the value of sampling frequency which has been previously changed in module ADS1256.py
    value = 0

    start = time.time()
    for i in range(10*fs): #cycle of 10s that only reads
        value=ADC.ADS1256_GetAll() * 5.0 / 0x7fffff
    end = time.time()
    print('time',end-start)

except:
    GPIO.cleanup()
    print("\r\nProgram end     ")
    exit()

Answer 1

This is not a definitive answer because you have not provided the exact code or referenced your hardware. But looking at the data, I see an obvious relation between the timing errors and the respective sample rate.

You need to take into account that the execution of code takes some time (especially in python as it is stupid slow). Let's have a look at the data you provided:

Measuring 1000 times (100Hz for 10s) gives you an error of 340ms, so the average error per measurement is 0.34ms. Assuming that this error is systematic, we can expand this to 10000 measurements (1kHz for 10s). This leads to an expected timing error of around 3.4 seconds, measuring those 10000 samples will take 13.4 seconds, respectively. Finally doing the same math for 15kHz: duration=150000×0.34ms+10s=61s.

Though this does not exactly match your observation, I think it's pretty close and you might ask yourself, how precise the value of time.time() actually is (it's not supposed to handle microseconds).

Things you could try:

• switch to a faster language, like C/C++ (though this can only reduce, but not solve the problem)
• ask waveshare for support, the software they provided might be poor or not supposed to work in kHz range
• account for the expectable delays by reducing the time-to-wait (this is a dirty solution)
• the hardware might (but I don't know, you didn't tell us the exact hardware) be able to buffer a reasonable amount of samples which you can read out in a burst. In this way, the hardware would also do all the timing and this would be the cleanest solution in my oppinion.

Just FYI: SPI is very fast and communication is handled by hardware. It's very unlikely that changing bus speed makes any difference when there are timing problems like yours. It's the software reading the internal registers that takes CPU time, not the actual data transmission.