AD421 spikes

Hi Cehacko , 

A similar issue has happened and was discussed in this thread: (+) [AD421] is there a dependency between Latch-falling and Clock-rising? - Q&A - Precision DACs - EngineerZone (analog.com)

TLDR: The spike seems to be coming from missing the MSB, and the part interpreting the data at normal mode. The solution that worked, is to try and a more time delay between the latch falling edge and the first clock. 

Another solution I could recommend is to try and send more than 17 CLKs. The extra MSB clocks are can be don't care and the device should only accept the last 17 CLKs, then if ever it fails to count the clock properly, there are some buffer clock pulses and it is sure to operate at alam current mode. 

Best regards,

Ian

Hi Ian,

I read mentioned thread and I am afraid it it not my case. There is a state machine with a periode of 5 ms therefore there is a time gap 5 ms between latch falling and clock rising edge. This can be seen in the following figure:

Another possible solution to send at least 17bits also does not work. The time frame consists of 3 bytes. The value is 0 10110101 11000010 this corresponds approximately to the value of 11 mA, not 22 mA that appears after the frame.

Best regards,

Martin

I've noticed the same behaviour on our boards when using the AD421.

We have 4 devices on the same bus: three AD421 DACs and one AD7792 ADC.  Only the data and clock signals are shared.  Each device has a separate GPIO as their Chip Select / Latch signal.

We also have each device connected to opto-isolators and our clock timings are 50us high, 125us low, for a period of approx. 175us.  We've always accessed each AD421 in constant alarm mode because there's more than one device on the bus.

Originally, each time we'd access one of the devices, we'd write/read using 32 clocks.  We'd see a spike on the 4-20mA outputs of an AD421 occasionally, but not very often.

After changing the number of clocks used (8, 16) and the CS behaviour when communicating with the AD7792 ADC to match the datasheet better, we noticed every second AD421 write of 17 bits would cause the 4-20mA outputs to spike. So this was completely unacceptable.

It seemed as though the first write of at least 17 bits to the AD421 after communicating with the AD7792 would cause the AD421 to miss the MSB for some reason.  The next write would catch the MSB properly and set the 4-20mA output to the correct value, as you show in your first scope capture.  Why the AD421 is missing this MSB is still a mystery.

By trial and error and a lot of testing, to get all AD421 devices outputting the correct value without spiking or dipping (depending on the required output value), we've had to add dummy clocks on the bus before each AD421 write and after each AD7792 read (after driving the AD7792's CS signal high).  Three or eight clocks before each AD421 write and 5 clocks after each AD7792 read seems to work the best.  Also, each time we write to an AD421, we have to write it twice in a row: 3 dummy clocks, 17 real data clocks, drop latch low, wait, then drive latch high again, then write 17 real data clocks, drop latch low, wait, drive latch high again.  This allows us to write the correct value right away if it does spike.  A small spike for about 100ms now occurs once every 20-40 seconds instead of every write (every 200ms or so).

This is not a complete fix but it's the best I've seen in a couple of months of on and off investigation.

I will be designing in the AD5421 in the next spin of the board because I believe it properly only allows written data when the chip select is active instead of writing everything and counting clocks.  Something in the AD421 is not working right.  Not sure if it's because of a lack of schmitt trigger inputs or what.

Hope this helps!

Ian, can you let us know if this helps ADI engineers in examining this issue?

Mike

I've noticed the same behaviour on our boards when using the AD421.

We have 4 devices on the same bus: three AD421 DACs and one AD7792 ADC.  Only the data and clock signals are shared.  Each device has a separate GPIO as their Chip Select / Latch signal.

We also have each device connected to opto-isolators and our clock timings are 50us high, 125us low, for a period of approx. 175us.  We've always accessed each AD421 in constant alarm mode because there's more than one device on the bus.

Originally, each time we'd access one of the devices, we'd write/read using 32 clocks.  We'd see a spike on the 4-20mA outputs of an AD421 occasionally, but not very often.

After changing the number of clocks used (8, 16) and the CS behaviour when communicating with the AD7792 ADC to match the datasheet better, we noticed every second AD421 write of 17 bits would cause the 4-20mA outputs to spike. So this was completely unacceptable.

It seemed as though the first write of at least 17 bits to the AD421 after communicating with the AD7792 would cause the AD421 to miss the MSB for some reason.  The next write would catch the MSB properly and set the 4-20mA output to the correct value, as you show in your first scope capture.  Why the AD421 is missing this MSB is still a mystery.

By trial and error and a lot of testing, to get all AD421 devices outputting the correct value without spiking or dipping (depending on the required output value), we've had to add dummy clocks on the bus before each AD421 write and after each AD7792 read (after driving the AD7792's CS signal high).  Three or eight clocks before each AD421 write and 5 clocks after each AD7792 read seems to work the best.  Also, each time we write to an AD421, we have to write it twice in a row: 3 dummy clocks, 17 real data clocks, drop latch low, wait, then drive latch high again, then write 17 real data clocks, drop latch low, wait, drive latch high again.  This allows us to write the correct value right away if it does spike.  A small spike for about 100ms now occurs once every 20-40 seconds instead of every write (every 200ms or so).

This is not a complete fix but it's the best I've seen in a couple of months of on and off investigation.

I will be designing in the AD5421 in the next spin of the board because I believe it properly only allows written data when the chip select is active instead of writing everything and counting clocks.  Something in the AD421 is not working right.  Not sure if it's because of a lack of schmitt trigger inputs or what.

Hope this helps!

Ian, can you let us know if this helps ADI engineers in examining this issue?

Mike