I read the posts on the ads1241 and while some of that made sense I'm still a little in the dark concerning the proper sequencing of commands to minimize settling time error.
Oscillator frequency is 4.9152 MHz
Configured for 15Hz operation
~DRDY is not wired to the processor. It’s value is read from the register.
Have an client with an existing design and they are having some intermittent problems with this device. I found a problem where they were not waiting the required 50 osc periods between the command and data phases on the register reads and ADC conversion read. So that is now working to specification.
After that, I wanted to look at the processes for programming the ADC to use all 8 channels. The current algorithm is
1. wait for ~DRDY to be true (0) by register read
2. read ADC conversion value
3. set next MUX channel
4. increment MUX channel (for next time through loop)
5. wait for 250 ms
6. go to step 1
What I noticed with this algorithm is that ~DRDY is always 0 when the register is read in step 1 because ~DRDY is only false(1) for 16ms or 32ms after the MUX channel is set. I looked at ~DRDY with an o-scope in conjunction with the SPI commands in the same trace to determine this relationship.
So here are my questions:
Why is ~DRDY false (1) for 16ms or 32 ms? It seems like this is the conversion time and I don’t understand why it’s variable. Usually the conversion time is fixed.
The data sheet specifies that you should change the MUX channel as quickly as possible once ~DRDY goes low or you will get settling errors. This is on page 10, figure 2 of the data sheet. This has me confused. Since setting the MUX channel causes ~DRDY to go false(1) then you would not be able to read the data from the previous conversion after the MUX change. So I need help here in determining if the above algorithm is correct or should be changed.
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.
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
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.
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.
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
read MUX channel 7
..... 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.
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.
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.
from the data sheet, page 14 DSYNC Operation
When the DSYNC command is sent, the digital filter is reseton the edge of the last SCLK of the DSYNC command. Themodulator is held in RESET until the next edge of SCLK isdetected. Synchronization occurs on the next rising edge ofthe system clock after the first SCLK following the DSYNCcommand.
My mistake...you are correct. I forgot this part uses the SCLK edge to start the conversion.
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.
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.
Once I have tested my fixes and have a working system I will post the solution. Thanks for all your help.
Here's the solution for measuring one channel at a time using only the registers. You must calculate the DRDY period from the equation on page 22 in the data sheet that defines fdata (data rate).
1. write the DSYNC command (0xFC) to restart the DRDY timing cycle
2. write the MUX register (0x51,0x00) to select the MUX and also releases DRDY on the first clock (see DSYNC command)
3. wait at least 1.0 DRDY period plus some guard band depending on factor like timer accuracy. I put a 15 ms guard band because my OS clock is 5 ms resolution.
4. read the DOR register (0x1)
Works great! Thanks again Bob for all your explanations that got me here.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.