ADS131A04EVM: Asynchronous sampling without DRDY signal

Hello Nicolas,

I'm personally not very familiar with RPi so please excuse some questions and assumptions if they are basic.

Assumptions

In summary, it sounds like your program on the RPi cannot reliably generate the signal needed for the XTAL1 / CLKIN pin on the ADS131A0x and trigger off the nDRDY signal to initiate ADC data readback. As a result, your system's SCLK and CLKIN are nonsynchronous, and the RPi must arbitrarily send a ADC data read command, without knowing the status of nDRDY, which doesn't give reliable data. Is that correct? Reliably, in this case means F_DRDY should not be triggered during a command that results in ADC data readback on DOUT.  

Before I comment on the situation above, let me talk about what the direct questions.

From the datasheet it seems that this chip... allow[s] to read and write new conversion data simultaneously. Is that correct?

I'm not sure what you mean by this. Conversions are not initiated by reading or writing to a register (using the WREG(S) and RREG(S) commands). The full duplex nature of the ADS131A0x and ADS131M0x allows the user to initiate a command, such as read, to the device on DIN, and read the conversion result or result of the last command on DOUT.

Ignoring reset, wake up, and similar commands that don't result in data in the SPI frame; the device will continue to make a conversion and update the status registers if it needs to. In the case of A0x, F_DRDY only occurs when all the data cannot be read before the next conversion starts and nDRDY has toggled.

More on the FIFO and the M0x on the next question.

Also, what happens when this FIFO is full? Are new conversions overwritten or discarded?

As you pointed out, the difference between the ADS131A0x and the ADS131M0x is the FIFO. I need to double check with the team with what exactly happens when the FIFO is full, as the only datasheet says that the FIFO "overflows". It will store two conversions and then on the third conversion the FIFO overflows.

So with this in mind, the ADS131M0x still has the same problem as before. If we don't know anything about nDRDY and don't attempt to collect the data within two pulses of nDRDY, then the ADC readback is worthless. I would argue that a difference between the M0x to the A0x would be that you have twice as long to go and read ADC data if we don't know what's going on with nDRDY.

In general it sounds like you attempt to read within 1 nDRDY cycle, so it may fix your issue. However, the recommendation will be to RESET or quickly read ADC twice before the next conversion if you suspect you go above 3 conversions without clearing the FIFO. Even an internal timeout type "interrupt" could solve your issue in this case.

sampling with good repeatability at high frequencies using an interrupt on the DRDY signal is almost impossible

For the A04, I think I calculated the max data-rate to be ~128kSPS or ~30uS of time between samples. Assuming SCLK is around 25MHz or 40ns, I assume the device can probably get through two full SPI data-frame reads before next data ready signal toggles, with worst case data-frame format. Are these conditions strenuous for the RPi to achieve? 

If CLKIN generation is part of the problem, is it possible to use a crystal oscillator that acts as input for both the RPi and ADS? Where the RPi input goes to some PLL that can be used as a reference for the RPi? This will have frequency drift be constant between both devices and free up some "program BW" to look for nDRDY.

Best,

-Cole

Thank you very much for your detailed answer. I will reply point by point using approximately the same structure.

Assumptions
You are right. The limitations come from the RPi Linux OS that is not a real-time OS. Therefore, it can interrupt the user process for up to several milliseconds, rendering reliable sampling at more than a few kHz almost impossible. The only way to avoid this is to use the DMA engine, that allows to be completely independent of the CPU. Unfortunately, there is no easy way to trigger the DMA conversion on a GPIO interrupt, therefore I need to launch an SPI transfer at regular intervals that are not in sync with the ADS131. This actually works quite well since the SPI transfer at 10MHz is much shorter than the sampling interval. But since the two clocks are not perfectly synchronised, there is some slow clock drift meaning that at some point during an SPI transfer a conversion / nDRDY toggle might happen, raising the F_DRDY flag. The data I read is worthless until the SPI transfer is again "out of range" of the data conversion.

ADS131A0x vs ADS131M0x
On the A0x, when I'm still reading the data when a new conversion starts / nDRDY toggles, the F_DRDY flag is raised and the new conversion is not updated. Therefore, the data I read is worthless until the SPI transfer is again "out of range" of the data conversion. My assumption was that there is some kind of "internal register" storing the new conversion, and it cannot be read and written to simultaneously. This could be solved by introducing a FIFO, where the "read" operation (through SPI) and "write" operation (new conversion) can happen simultaneously without raising a F_DRDY flag. New conversions could be added to the FIFO even though the SPI transfer is occurring at the same time. Does this make sense? Is this what is implemented in the M0x?

In my case, using the M0x, I could try to slightly increase the sampling frequency on the RPi in order to never let the FIFO overflow. But in that case I could sometimes read an empty FIFO, what would happen in that case? On the A0x, when reading faster than the conversion rate, the same conversion is read multiple times. But I'm not sure what would happen on the M0x with an empty FIFO.

sampling with good repeatability at high frequencies using an interrupt on the DRDY signal is almost impossible
I hope my answer in the assumptions paragraph cleared this out.

I don't think I can provide a CLKIN signal to the RPi. But you reminded me I should better investigate about generating a clock from the RPi to feed to the ADS131, as this could solve the issue as well.

Best regards,

Nicolas Verbeek

Hello Nicolas,

But in that case I could sometimes read an empty FIFO, what would happen in that case? 

I've confirmed the device will give back the same result. As a result, it sounds like the M0x family is a good fit.

Best,

-Cole

Dear Cole,

Thank you very much for your support. It's much clearer now. 

Best regards,

Nicolas Verbeek