AD4134 data is delayed by one, two or three ODR ticks

A bit of a breakthrough revealed that it's related to the setting of register 0x1E - there appears to be some corruption of this register resulting in each channel having a randomly different filter type which, of course, would give the random phase offset.

Are there any 'rules' for setting the filter register 0x1E?

Thanks, Steve

Hi squirest ,

Can you try to set the DIF_IF_RESET bit before data capture?
We are checking the setting of the filter register 0x1E.

Thanks,
Janine

Hi Janine,

I assume you mean DIG_IF_RESET?

I have added a crude implementation of this (architecturally, the code is not properly set up for multiple chip-selects to send the SPI command to multiple devices). This has brought all 16 ADC channels into alignment but there is a one ODR jitter in the data from reset to reset.

I don't know why this might be as the analog inputs to the ADC are precisely synchronised to ODR. Still investigating...

Steve 

Hi Janine, the more I look, the more I think I have the same problem as this:

AD4134 Multi-Device Synchronisation - Q&A - Precision ADCs - EngineerZone (analog.com)

Please kindly confirm the precise sequence for performing a DIG_IF_RESET.

Thanks, Steve

FYI,

Summary of application:

• Board-wide reset (incl AD4134s)
• Start ODR (80kHz, 200ns positive pulse-width)
• Software reset AD4134s
• Program AD4134s (daisy-chain, slave, SINC3 etc.)
• Check for AD4134 PLLs
• Send DIG_IF_RESET (Note SPI is asynchronous to ODR - on different sub-systems)
• Start DCLK (~50ns after ODR falling edge, ~16MHz)

Typical timing diagrams:

State of AD4134 registers after DIG_IF_RESET:

However, sampling phase jitter of exactly one ODR tick is still observed from system reset to reset.

What am I missing?

Steve 

As per the other post:

AD4134 Multi-Device Synchronisation - Q&A - Precision ADCs - EngineerZone (analog.com)

I too can only achieve syncronisation by muting the ODR input for a period (currently 1 second) after programming it. After this, the data is aligned as expected - so long as I send no further SPI commands (even the registry dump causes problems)!

I do not need to send DIG_IF_RESET - this now has ne effect.

Why? Is this a known issue? Is muting ODR an approved approach? Silicon errata? 

Please document the correct programming sequence.

Thanks

Hi Steve,

Your initial spreadsheet plots bring back nightmares. It's somewhat comforting to see that someone else is having very similar issues, right down to SPI commands causing problems in the apparently unrelated ODR subsystem.

Interesting that you have found that DIG_IF_RESET is superfluous. Are you now getting 100% reproducible results by programming everything then muting ODR?

We are still having to rely on the "No Chip Error" and "Filter settled and PLL locked" bits in the "Data Interface Status and CRC Header" to ensure sync.

Diagnosing and testing this has been incredibly time consuming. I'm still open to the idea that we are breaking some rules in the spec but without a formal document that specifies the reset procedure it's very difficult to tell.

Cheers,

Scott

Hello Scott - thanks for getting in touch.

It seems we are indeed suffering from the same problem - thanks for the hint on muting ODR and suppressing SPI - this helped a great deal.

At the moment, we are keeping the DIG_IF_RESET for no other reason than it's in the data sheet. Frankly, we have tried so many time-consuming combinations and, as you know, trying to prove a negative is so hard.

Our ADCs share the same 48MHz clock which made us believe DIG_IF_RESET was unnecessary - we are probably wrong so it's staying in.

Regarding why SPI reading causes a problem, my only guess is that error bits are cleared on a register read and this could be interfering with other subsystems.

Ironically, our prototyping used the AD4134 EVM which used pin configuration mode (no SPI) - the ODR delay was absolutely consistent - no jitter at all. Switching to SPI control in our next prototype may have been a mistake (but what about DIG_IF_RESET?).

Having a consistent ODR to output delay is critical for our application.

What I need from ADI is some formal guidance on correct use of the AD4134 to ensure a consistent ODR to output delay.

ADI, please help.

Thanks,

Steve

Hello Scott - thanks for getting in touch.

It seems we are indeed suffering from the same problem - thanks for the hint on muting ODR and suppressing SPI - this helped a great deal.

At the moment, we are keeping the DIG_IF_RESET for no other reason than it's in the data sheet. Frankly, we have tried so many time-consuming combinations and, as you know, trying to prove a negative is so hard.

Our ADCs share the same 48MHz clock which made us believe DIG_IF_RESET was unnecessary - we are probably wrong so it's staying in.

Regarding why SPI reading causes a problem, my only guess is that error bits are cleared on a register read and this could be interfering with other subsystems.

Ironically, our prototyping used the AD4134 EVM which used pin configuration mode (no SPI) - the ODR delay was absolutely consistent - no jitter at all. Switching to SPI control in our next prototype may have been a mistake (but what about DIG_IF_RESET?).

Having a consistent ODR to output delay is critical for our application.

What I need from ADI is some formal guidance on correct use of the AD4134 to ensure a consistent ODR to output delay.

ADI, please help.

Thanks,

Steve

Hi Wa$iM,

My ODR is 80kHz with a pulse width of 200ns (~1.6% duty cycle).

Analysing 10ms of data (800 points): ODR rising edge to rising edge:

Which is what I would expect from an AD9542.

Is there any other data that you need in order to confirm how to correctly use the AD4134 in my application?

Thanks, Steve 

Hi Steve

80 kHz ODR will correspond to 12.5usec, i think the ns is a typo in the table.

Do you see the PLL unlocking? 

squirest said:

too can only achieve syncronisation by muting the ODR input for a period (currently 1 second) after programming it. After this, the data is aligned as expected - so long as I send no further SPI commands (even the registry dump causes problems)!

also i am trying to understand - in your message above do you say that all 3 ADC data samples are aligned as long as there is no SPI command sent?

squirest said:

Ironically, our prototyping used the AD4134 EVM which used pin configuration mode (no SPI) - the ODR delay was absolutely consistent - no jitter at all. Switching to SPI control in our next prototype may have been a mistake (but what about DIG_IF_RESET?)

Also in above message do you mean in PIN control mode there was no phase difference in the samples from 3 ADC's?

thanks

Hi Wa$iM, my mistake - usec - we are in kilohertz here.

By following the sequence:

ODR -> SPI program registers -> check PLL -> DIG_IF_RESET -> mute ODR -> resume ODR -> no further SPI

I am now seeing coherent and consistently delayed data from all 16 ADC channels. (each ADC input is a 5kHz carrier sine wave generated from the same clock source as ODR - I am highly confident that the phase of the carrier to ODR is accurate and unchanging).

The measured phase of the carrier being consistent from reboot to reboot is absolutely crucial (as is low latency). Don't really care about the absolute phase - we measure it during calibration.

If I read SPI ADC registers after the muting ODR technique (thanks Scott Robson) with a register dump, for example, the consistent delay is lost. Confirmed.

I have re-experimented with skipping the DIG_IF_RESET - it's unclear whether I need this - it's left in simply because it's not breaking anything and I'm out of time for further experiments.  

I am not checking if the PLL is unlocking (no SPI after muting) and I don't want the burden of extended data transfers. Once locked, the system runs for days and days consistently.

For the PIN controlled ADC (I only had one) I always had consistently delayed data from all 4 ADC channels - it was rock-solid. However, and it seems not coincidentally, no SPI was involved.

I hope that clarifies.

Thanks, Steve

thanks Steve for your reply

SPI and data interface are independent interfaces so its surprising.

Can you let me know the HW connections between the uC and ADC

Also PLL lock bit can also be seen with the CRC plus header option described in table 36 of datasheet.

Lastly please confirm me if these sequences did not work

1.  SPI program registers -> Start ODR->check PLL Lock -> DIG_IF_RESET ->

2. start ODR -> SPI program registers -> check PLL Lock -> DIG_IF_RESET ->

thanks

Hi Steve !

I'd like to design a system with 5 AD4134s and input IN-AMP AD4254s, all controlled by an MCU. After a lot of time reading datasheets, I'm still struggling to work out all the mandatory interconnections between the various components. Would you have some schematics to share so that I can check my understanding and clear up my doubts?

Thanks in advance for your feedback.

Best regards

Hi Wa$iM,

I have again tried several sequences of, for example, not starting ODR until after programming, omitting/including the DIG_IF_RESET (after PLL locked), checking and not checking the PLL state via SPI (it always matches the ODR muted/not muted state as I would expect, BTW).

To be clear, the ONLY way I have found where I can get coherent data with a consistent delay is to wait until I know the PLLs have locked, mute ODR (arbitrarily for 1 second), enable ODR again - as the VERY LAST non-data interface interaction with the ADC.

What I need from you (ADI) is for you to confirm that this recipe is appropriate and that it will work reliably for all current and future versions of AD1434 silicon.

Thanks, Steve

Sorry - the circuits are company confidential.

Have a look at the circuit for the AD7134 EVM - it has two AD7134s on it.

Steve

Hello Wa$iM - any feedback on this?

Thanks, Steve

Nudge

Dear ADI,

We are at a critical juncture with our project and I need to know if the recipe outlined above is supported by you.

Please respond.

Thank you.