search

ul-gh / PiPyADC

Python classes for interfacing Texas Instruments analog-to-digital converters with the Raspberry Pi
GNU Lesser General Public License v2.1
69 stars 27 forks source link

Sampling speed problem #3

Closed imcort closed 2 years ago

imcort commented 7 years ago

It takes no effect when I tried to set the REG_DRATE over DRATE_3750, and the maxium sampling speed is about 300 points per second. How to make it faster? I just need one channel, thanks.

ul-gh commented 7 years ago

Hi, when you do not explicitly send a standby() command to the ADC, it will automatically stay in free running mode and sample data continuously with the last set input channel/multiplexer configuration.

I.e. you only have to read back the data fast enough using the read_async() method, whenever the DREADY flag is set, read_async will return with new valid data.

I can try this during the next days, probably, but it would help if you posted (a link to) your code.

Regards, Ulrich

ul-gh commented 7 years ago

Dear imcort,

what is your hardware? I tested yesterday and maximum time overhead for multi-channel acquisition was approx. 500 µs, with the DREADY_DELAY activated, on a Raspberry Pi 3. With some tuning, half of this is possible. I do not see the 300 samples per second limit.

However, if you want more than 1000 or 2000 SPS, you likely need a pure C implementation. Accurate timing below some ten or hundred microseconds is not possible in Python AFAIK.

mhk2010 commented 6 years ago

Hi, I want to read a channel with a sampling rate of 30,000 samples per second, I have been trying for a few days but I have not been able to do this, I could read 30,000 samples in the company's program in C, but the sampled values are wrong. . Can you write code to do this for me. Best Regards Mohsen Heidari

ul-gh commented 2 years ago

Added clearer note in the README.md about the limitation in version 2. This library does not support fast continuous streams from the ADC. This features configurable individual ADC reads with time overhead in the hundreds of microseconds or lower millisecond range which is caused by the operating system and otherwise unavoidable.