Raspberry Pi Zero as a high-speed datalogger
How well suited is the RPI zero as a high speed data logger? Depends on the definition "high speed", but I was able to sample a 16 bit number about 10 times per millisecond over the ic2 bus, and you could probably do better.
I'm using a relatively bog-standard distribution of Linux on a raspberry pi zero, not RT linux or anything like that. My sampling device is the TI ADS1015, which only provides 3300 unique samples per second at 12 bits. That's 3.3 samples per millisecond, so the pi is overkill for keeping up with it.
Now, that's not to say it's always hitting every 0.1ms mark. (1) is a representative graph of the time between samples taken over the IC2 bus in a tight loop(1*) without any other significant activity going on (networking is active, but not pushing anything in or out) for 300ms. Killing the network hardware and stack does improve things, maybe 25% more samples? I've not measured carefully).
(1) The Pi can keep up! |
Now, that's not to say it's always hitting every 0.1ms mark. (1) is a representative graph of the time between samples taken over the IC2 bus in a tight loop(1*) without any other significant activity going on (networking is active, but not pushing anything in or out) for 300ms. Killing the network hardware and stack does improve things, maybe 25% more samples? I've not measured carefully).
This is running as root, with nice(-18); during capture (and 0 otherwise to unstarve the kernel/whatever). As you can clearly see there are some regular glitches in the capture, apparently every 120ms, which is an odd frequency, I don't know what that is). But in my use case, 5 samples per MS still beats the ADS1015. Occasionally I do actually drop a single ADS1015 sample on the floor, but it's rare, and in my use case I can just repeat the measurements again automatically if the glitch occurs in an important part of the data.
To underscore that point see (2), the histogram of the same data showing the count of samples taken more than 0.1ms appart (everything near 0.1 ms and below is waaaaay off the top of the chart). Data only get lost on average when the delta is > 0.3ms, which only happened 5 times, out of ~3500 samples.
(2) very few dropped samples |
I'm satisfied, especially given that this $5 device has a HDMI port, which is critical for my use case.
notes:
(1*)
int readval() {
if (read(fd, readBuf, 2) != 2) // read conversion register
{ perror("Read conversion"); exit(-1); }
return readBuf[0] << 8 | readBuf[1]; // could also multiply by 256 then add readBuf[1]
}
for(...) {
on_buff[i]=readval();
on_times[i] = (microsec();- start);
}
Comments