ads1241 command sequencing

John,

Welcome to the forum!  The most important DRDY timing issue is in the update period when new results are being posted.  This is shown as t18.  If you place an oscilloscope on the DRDY pin, and never read any data you will notice that DRDY dwells low most of the time.  In the time period where new results are being posted DRDY will go high, then assert low again when new valid data is available.  The time between the DRDY asserting low is the tDATA, which will directly correspond to the data rate.

If you read data from the DOR, the DRDY line will return high and then assert low when new data is available.  You should not attempt to read from the device during the t18 period.  Results will not be valid in this period.  DRDY being low doesn't directly translate to the data rate.  Rather it is the time between the region where DRDY asserts low.

The other part of your concern is settling and mux change.  This is the t17 period in the diagram.  This is the small time window where you should change the mux inputs for proper settling of the digital filter.

As you can see this can be a difficult process to adhere to if you are polling.  It is usually much easier to use an interrupt driven system where you change the mux and read the data results on the negative going edge of DRDY.  Polling of the DRDY pin state will be faster than polling the register bit.

Best regards,

Bob B

Bob,

Thanks for the quick response. I'm a very pragmatic person and although I appreciate the explanation I need to know the proper command sequence for a situation when I'm polling ~DRDY from the SPI bus and don't have the ~DRDY signal connected to the processor. Yes, I can tell now it would be better to have the signal tied to the processor and interrupt driven but this is a production product with many products in the field. I need to find a solution that will work on the existing design. I'm sure you can appreciate that.

Here are the facts I have at hand,

t17 = 5000 osc periods = 1017ms @ 4.9152 MHz. Therefore must poll for DRDY every 0.5ms to make sure I can hit the 1ms window.

I want to space my ADC reading at 230 mS to reduce processor overhead. I don't need this data very often.

I'm reading from all 8 channels.

Would this algorithm be correct

1. poll for ~DRDY at 0.5ms interval until signal is true (0)

2. write the MUX register for the next conversion

3. wait 230 mS (I only want to sample every 230 mS)

4. read the data from the DOR register for the previous (this triggers the next conversion??)

5. go to step 1

I guess what I'm most confused about is how the next conversion is triggered.

So I boot the system and ran it through the init sequence and then stopped the processor with the debugger to watch the DRDY signal. What I see with the scope is a positive pulse 32us wide every 33ms. So to synchronize with the 32us pulse via polling I'm going to have to poll in the 20us range which is impossible.

So I need another solution

One of the previous posts mentioned using the DSYNC command. Reading the data sheet this seem to put the modulator in reset. So maybe the command flow would be??

1. check for ~DRDY true (0)

2. read the DOR (but how do you know that DRDY won't randomly go high during the read?)

3. DSYNC (resets digital filter and puts the modulator in reset until the first clock of the next command)

4. change the MUX channel

5. wait 230 ms

6. go to step 1

John,

Delta-Sigma converters are bit different than SAR type converters in that they are actually converting continuously at a high sampling rate.  So the input is continuously sampled and processed through a digital filter and decimated to the actual data rate.  So there is a sampling rate that is based on the modulator clock, and the actual data rate which is based on the digitally filtered result.

The most basic form of a digital filter is an averager.  If you think of averaging a lot of samples together, and you have a step change in the middle of the sample set you end up with an inaccurate representation of both before and after the step change.  This is basically what happens when you change the mux in the middle of a conversion cycle.  To allow the digital filter to fully settle, the mux change should happen within the t17 period.

In your case, I wouldn't worry about the digital filter settling if you are going to wait 230ms between readings.  Depending on your actual data rate, you will have already passed a full conversion cycle by the time you take your next reading.

If you are going to do a burst of readings through all of the mux channels so that they are done in succession  as quickly as possible you will want to hit the t17 window.  The tricky part of doing this is not reading a result during the t18 period.  The ADS1241 will continuously update the DOR with new results at the prescribed data rate.  You can poll the ACR register for the correct timing as you have stated.  If you are able to poll to capture the high to low transition of DRDY then you are good to go.  But there is one other option, and that is using the DSYNC command.  Using DSYNC, you can change your mux at anytime as the DSYNC command clears the digital filter, resets the modulator and starts a new conversion cycle.  In this way you can use DSYNC as a start of conversion, or trigger.

Let me know if I'm misinterpreting what you want to accomplish, or if you need further details about any particular aspect I've mentioned.

Best regards,

Bob B

John,

It looks like our posts crossed the forum about the same time.  Once you've read through my last post let me know how you want to proceed and I can step you through it.

Best regards,

Bob B

Bob,

Thanks again for being responsive.

So I definitely get the settling time is not an issue because many conversion cycles will take place between changing the MUX and actually reading the data. Thanks for that piece of information. I looked at the signals again with the scope and current algorithm is totally asynchronous with respect to the DRDY signal. Even though DRDY is not connected to the processor I can still see the voltage at the pin. So I think I have a good handle on the electrical part now. Thanks again.

So here's some more details. I don't want to burst the readings. Here's the flow.

read MUX channel 0

wait 230 ms

read MUX channel 1

wait 230 ms

....

read MUX channel 7

wait 230 ms

read MUX channel 0

..... and it starts all over again.

By biggest worry is that this algorithm is operating asynchronously with respect to the ADC conversion cycle. I may poll for DRDY and find it true(0) just before DRDY goes high and then read the DOR while the data is changing. The 230 mS wait has a range of 5 ms (225 to 230) based on when you ask for the wait withing the 5 ms operating system clock tick window.

So I guess the BIG question is. How do I sync up this software algorithm with the ADC hardware?

I guess I could use the DSYNC command in conjunction with the fact that the DRDY period for this configuration is a constant 33ms controlled by the crystal. Then I can put my processor wait centered into the DRDY low period so that I know it will be OK to read the DOR.Then I don't even poll for DRDY because I know I'm sync'ed.

What do you think about this algorithm....

1. read the DOR (this would yield garbage on the very first reading but I'll throw it away)

2. issue the DSYNC

3. change the MUX channel

4. wait 6.5 DRDY periods (6.5 * 33ms = 215ms - range of 210 to 215 ms) - 6 conversion cycles has no settling time issues.

5. go to step 1

John,

I would follow your last plan, and ditch the polling.  The only difference is swap 2 and 3.  You want to change the mux first, then sync.

Best regards,

Bob B

Bob,

Thanks for the feedback. I put the commands in that order based on this statement regarding DSYNC in the data sheet. How do you interpret this?

My interpretation is the chip is held in reset until it gets another command. The first SCLK of the next command pulls it out of reset. So I used the MUX command get it out of reset. My software driver can't provide a single clock after DSYNC is issues because it's a byte oriented driver.

John

from the data sheet, page 14 DSYNC Operation

When the DSYNC command is sent, the digital filter is reset
on the edge of the last SCLK of the DSYNC command. The
modulator is held in RESET until the next edge of SCLK is
detected. Synchronization occurs on the next rising edge of
the system clock after the first SCLK following the DSYNC
command.

John,

My mistake...you are correct.  I forgot this part uses the SCLK edge to start the conversion.

My apologies,

Bob B

Bob,

One last question. On my scope trace I see DRDY go high for either 16 ms or 32 ms on the last clock of the read DOR command. Is there an explanation of why this happens? And do I need to worry about the state of DRDY before I issue the DSYNC command or can issue DSYNC while DRDY is high?

Thanks again for all your help. I wish some of this was in the data sheet.

Regards,

John

John,

I can't really say why you see those two values. It may just be due to the timing of where you do the reads in relation to the conversion cycle.  In one case you may be reading at the beginning of the conversion, and another mid cycle.

Best regards,

Bob B

Once I have tested my fixes and have a working system I will post the solution. Thanks for all your help.