AD7193 bad last bit when reading data register over SPI

Hello adamvs ,

Can you share a parallel scope shot of SCK and MISO? 50 ns is within specifications, but I'm not sure how the LSB is corrupted since bits are sampled during the SCLK rising edge.

Another thing I'm thinking is adjusting the drive strength, but this is not available on the AD7193. Are you somehow using a pull-up in your circuit? Can you also share your schematic?

Regards,

Yugel

Hi Yugel ,

I am not using a pullup. The relevant spec would be related to when the controller samples the edge. I can confirm I see this issue on an ESP32S3 but not on a UNO R3.

Scope shot is attached. This is with a 2 MHz SCK.

If i am reading the links below correctly other people have seen this issue for the ESP32S3. Espressif is saying that they sample at some interval *after* the rising edge, where after means a delay which may depend on the clock. They consider this a protocol violation by the device. (7193)

https://github.com/espressif/esp-idf/issues/7825

https://www.esp32.com/viewtopic.php?t=36723&start=10

I don't know how to fix at present (except in software). If you have any thoughts I'd be happy to hear them. The ESP32S3 is a popular device so I imagine this problem will pop up again.

I attach the schematic as well, but i don't think the problem is related to this.

Hello adamvs ,

Seems like the issue is due to hardware limitations. Does this happen on all ODR settings? Can you try setting it at, say, 960 Hz and see if it persists?

Also, can you check the feasibility of an 8 MHz clock? It may actually work reliably since this product doesn't have a FIFO function.

Regards,

Yugel

HI Yugel,

I haven't tried it on every ODR (as defined by the FilterWord) but it is present at both 50 sps (default) and the fastest 4800 sps.

8 MHz was found to work only inconsistently. (it worked on a protoboard prototype but not on my manufactured PCB). I am guessing the prototype has more capacitance in its lines so this slowed down SDO enough for it to work. I wouldn't be surprised if it works on some sufficiently high frequency but I was reluctant to rely on this inconsistent timing.

i tried a number of ways to read out the data (e.g. reading out only the status register, reading out data then status etc..) but I couldn't figure out any to get that last bit while unit is in continuous mode (where it is controlling SDO).

For now I, since I only enable a continuous bank of channels (no skipping), I can infer the last bit in software.

Scheme:

1) the sequencer goes in order, and I collect data (with status register attached)

2) If i get two samples in a row with the same channel, and the last bit is 1 I infer the previous data I received had a bad last bit and correct it from 1 to 0.

This isn't a general solution (it entails a 1 sample lag before the data can be available, it can't correct error if channels are skipped or data is missed) , but works for my use case, and for every SCK speed or sample rate I tried.

Hello adamvs ,

I have checked previous documentations about this but the AD719x isn't capable of adding a delay between the last SCLK rising edge and RDY high.

You can also check the FAQs about the digital interface here:

Digital Interface FAQ - Sigma Delta ADC - Q&A - Precision ADCs - EngineerZone (analog.com)

We could try making it work on a faster clock by adjusting the series resistors to, say, 50 ohms. Not sure how much of the trace resistance you have on your PCB SPI lines but it should match this.

Regards,

Yugel

Hi Yugel,

Thank you for the suggestions. If I revise the board I will consider them. As this is a finicky timing issue I think I am going to leave it for the moment and just use my workaround. 

I imagine this would be a persistent problem for any other devices which control SDO and use an ESP32S3 (and maybe similar models). Hopefully this info left here can help someone.

Hi Yugel,

Thank you for the suggestions. If I revise the board I will consider them. As this is a finicky timing issue I think I am going to leave it for the moment and just use my workaround. 

I imagine this would be a persistent problem for any other devices which control SDO and use an ESP32S3 (and maybe similar models). Hopefully this info left here can help someone.