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.

ADS131B04-Q1: Data Flow

Part Number: ADS131B04-Q1

Hello E2E Experts,

I've been reading through the datasheet for this part as well as looking at the example code  here and I'm a little confused about how it handles the transmission of the ADC conversion data after the host has sent a command.

For instance, Figure 8-21 shows that channel data is sent back and then the RREG response afterwards. 

image (6).png

However in the example code, the functions to execute commands don't seem to do anything to account for conversion data coming back before the command's response.

Will the sampled data come back before the command's response? 

  • Hi TI-CSC,

    can you ask Westin to watch this thread and comment on it? That might be the easiest.

    The ADS131B04-Q1 does actually output conversion data of all four channels in EVERY frame, no matter what command was sent previously. The only exception is the multi-register read command. In that case register data are output in the following frame instead of conversion data.

    That means if you always send a full SPI frame with 6 words, then you will receive the Response word, 4 Channel Data words, and the Output-CRC word on DOUT in every frame.
    The example code might not make full use of this functionality and might potentially also "short-cycle" the frame. I haven't studied the example code in all detail.

    Regards,
    Joachim Wuerker

  • Hi, Joachim. Thanks for the information. I think you're probably right that the example code is short cycling the frame since the message sizes are less than 6 words, but I'm not sure how that's possible as the datasheet seems to say that's not possible unless the ADCs are disabled and I don't think the example code disables them.

    Thanks,

    Westin

  • Hi Westin,

    I can assure you that you can short-cycle the command even when the ADCs are enabled. The datasheet is misleading in that respect. Our software team usually implements minimum SPI frames for writing register configurations to keep the communication overhead to a minimum, and because they are not interested in the conversion data while they are writing registers.

    What the comment in the datasheet tries to convey is, that you can't read all conversion data when you short-cycle the frame and that your DRDYn signal will not transition high if you don't read all channel data. We need to clean this statement up in a future datasheet revision. 

    Regards,
    Joachim Wuerker

  • Okay, I was wondering if that was the intent. Thanks for the help.