This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Read By Command ADS1282

Other Parts Discussed in Thread: ADS1282

I am currently working on a design where we need to sync the ADC to our data matrix, to ensure symmetric sampling.  So we need to implement the read by command mode, unfortunately we have not got this operating correctly yet.

We are able to initialize the device and set the configuration registers to run at different data rates, so we know that it we are talking with the device properly. We can also get data from the converter while running in read data continuous mode.

Our current commanding sequence is this:  Stop Data Continuous -> Write Cmnd 1st Byte ->Write Cmnd 2nd Byte ->Config Reg 1 -> Config Reg 2->Read Cmnd

At this point our controlling FPGA goes into a wait state to wait for the DRDY line to go low, but it never goes low.

I have probed the device to make sure that all of the proper waits are in between each command.  The manual makes it unclear about whether the command actually starts a new conversion or if command simply reads from the conversion registers.

Any advice I could get to help me get through this would be sweet.

  • Dan,

    I'm not sure what the problem is. Is it possible that you have accidentally gotten the ADS1282 into standby mode or into a pin activated reset?

    Could you please post the specific commands you are using, starting with Stop Data Continuous (along with the hex word for the commands)

    Just to let you know, the RDATA command does not initiate a conversion, it simply reads the data that is currently in the output register. Normally, you would wait for the DRDY to go low to read the data.

    Joseph Wu

  • Joseph,

    It could be possible that it is in a stand by mode.  I have looked into it, but haven't found any evidence to support this.  When I configure the registers and then do a Read Data Continuous mode the device works fine.  I only have a problem when I do the Read Command and then wait for DRDY to go low.

    Also I have found that if I loop the Read Command then the DRDY will go low on uneven intervals, and there is DATA that appears on the DOUT line.  It seems like odd behavior.  I have also tried to send the command and then about 250 us later try to shift out the data, which doesn't seem to work either.

    This problem is killin me.

    So here are the commands that I am sending the,

    • Stop Data Continuous:h11
    • Write Cmnd 1st Byte: h41
    • Write Cmnd 2nd Byte: h01
    • Config Reg 1: h62
    • Config Reg 2: h04
    • Read Cmnd: h12

    As per the data sheet it seems that I should give a read command and then after time Tdr DRDY should go low.  When It goes low I shift out the data and then send a command to Read again and wait for DRDY.

    Hopefully this will help identify the problem.

    Dan

     

  • Dan,

    From your commands, it looks like this is what you are doing:

    1. Stop read data continuous.
    2. Write to register 01
    3. Write 2 bytes
    4. Set data rate to 4000SPS
    5. Set no chopper, PGA=16
    6. Read data by command.

    In your first email you state that the DRDY does not go low, but in the second email you say that you loop the RDATA command the DRDY goes low at uneven intervals. Does the DRDY go low on the first RDATA and not on subsequent ones?

    What should happen is that the DRDY will fall after you have issued the RDATA command and then you can access the data. Remember that you are in SDATAC mode and that DRDY is suspended even though the converter is still converting. Once the read out after RDATA, the DRDY will not fall again until you issue another RDATA command.

    If you loop the RDATA and are getting different data periods (and you are only looping the RDATA command), could you get a scope shot of a few subsequent DRDY drops? I'd like to know how far off the DRDY low going pulse is from the expected data rate. Do you loop at a periodic interval, or do you loop by looking for the low-going DRDY pulse?

    Joseph Wu

  • Joseph,

    I think that I was a little misleading.  Normally I send the read command, shift the data in when DRDY goes low, then send another DRDY command.  This wasn't working, DRDY stays high.  So I just wanted to see how it would respond if I sent it multiple Read commands on a looped time interval.  So I would send a Read command wait 270 us and then send another one.  As I did this I watched the DRDY line to see the response.  DRDY would go low sometimes as quick as 80 us or as long as closer to 280us.  Which I thought it should be 250us since I set the data rate to 4KHz. 

    The real problem I am having is that DRDY does not go low after the first command, and therefore does not signal the FPGA to shift in the data.  So Ideally we want to loop off of the DRDY pulse as I explained but this isn't working.  After we shift the current conversion in, we wait till the input registers on the FPGA are clear then we send the next command to read. We are syncing up to a frame rate of 3.6 KHz.  Again, I have triggered the DRDY and after the initial read command DRDY does not go low.

    What reasons would DRDY not go low?  I am going to double check on my end to see if this wait, to give the read command is not causing any grief.  So, if I understand correctly, DRDY should fall 250us after a Read command is given?

    Dan

  • Another quick question, all of the commands are MSB first, right?

  • Yes MSB is first.

    Joseph Wu

  • I just went through each ADC and using a scope set to trigger off of the first falling edge of DRDY, and none of them triggered.  So DRDY is not falling low after the first read command.  This is in the configuration where we send all the commands I specified earlier and wait for DRDY before sending the next read command. Help?

    Dan

  • I received this from Dan:

    ****

    Joe,

    Thanks for your help with this issue.  I was able to resolve the read by command issues that I was having.  What ended up working for me was doing the SYNC command as you had suggested then waiting for the SYNC to complete and following it with a RDATA command.  This part now works beautifully. 

    Now that this is working I have more clarity on how the device works.  Am I correct in thinking that the conversions in the Delta Sig run freely at the data rate set by the DR register and the RDATA just simply reads the current data that is in the output registers? 

    This seems to be the case.  We need to be able to sync the conversions up to a 3.5 KHz data rate so that the ADC acts as a slave to our system and not our system as a slave to the ADC.  The timing of the conversions is very critical to the mission so that we can recover frequency information.  Apparently we miss some of the sample cylces in the converter, while sending a sine wave through the converter we recover the signal on the other end but with distortion due to the uneven sampling.

    Is it possible to delay the conversion with out performing a sync or doing the one-shot conversion?  We have thought of possibly holding the system clock to delay the clock edges and hold the converter after we have shifted data in.

    Hopefully this makes sense.  Let me know what you think.

    Thanks again,

    Dan

     

  • Dan,

    I'm glad you were able to get something out of the part.

    When it comes to the RDATA command it works like this: SDATAC will stop the updates of the output data onto DOUT. To get the data, RDATA will load the output data at the next DRDY. Then the data can be read out. However, the ADC does not stop converting, it simply suspends the update of the DOUT until the next RDATA command.

    For syncing up the data rate, it may be best to change the clock frequency to get the desired data rate. If you want to get 3.5kHz for a data rate, then run the master clock at 3.584MHz instead of 4.096MHz and set the configuration register 0 so that the DR bits are 100. In this case, you could run it in RDATAC mode and just get the data.

    If you want to try suspending the CLK to get the same result, it may be possible, but I don't know of anyone who has tried. There may be other obstacles in trying this method. For example, the input impedance of the reference is about 85kOhms. If you shut off the master clock, the reference (and input stop sampling) and even this change in load may disrupt the value of the reference.

    Joseph Wu

  • Can you post the formula you used to figure out the master clock rate based on a desired data rate?

  • The data rate set in the configuration register on page 37 of the datasheet assumes the CLK rate of 4.096MHz.

    If you set the data rate to 4kSPS with a 4.096MHz CLK, you will get a data rate of 3.5kHz with a 3.584MHz clock. (scaling the clock by 3.5/4)

    Joseph Wu

  • Same problem, DRDY never went down when I tried to read by command mode. My commands sequence was:

    after power on the data conveter enter in continuous read mode...

    send command 0x11  ( stop data continuous mode)

    send command 0x42 (write register 0x02)

    send command 0x00 (write 1 register)

    send command 0x18 (data input select 2)

    send command 0x12 (read by command)

    and DRDY never goes down....

    the solution is:  after configure or read any register data send another stop data continuous mode 0x11

     

    Cristian

  • Thanks for the tip Cristian!

  • Anyone reading through this post.....

    See the answer to the DRDY not going low after the RDATA command.  The answer is found at:

    http://e2e.ti.com/support/data_converters/precision_data_converters/f/73/p/119999/434549.aspx#434549

    The problem relates to the digital filter getting reset after a register write.  Youmust wait long enough for the digital filter to settle before giving the RDATA command.

    Best regards,

    Bob B