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.

ADS131E08: ADS131E08 output data rate is two time lower

Part Number: ADS131E08

Good day Colleagues,

Could you help to undestand output data rate question from my customer? he is using the ADS131E08.

Internal clock is 2.048MHz. Customer tried to set different DR CONFIG1 settings, but always got data rate and /DRDY signal two times lower than it should be.

For example, he used value of 101 and instead of 2kHz he got 1kHz.

he also checked register's values and they were setup correctly. he also tried to use differenct SPI clock (6, 10, 20MHz) but DRDY signal every time is two limes lower value.

Could you tell me what he should check? Or what can be wrong in here?

Thank you, Mikhail

  • Mikhail,


    I'm not sure what is wrong here, but there are some things the customer can check. First, I would have them try toggling the START pin (or the command) to see the length of the settling time. You can see the settling time on /DRDY in Figure 31 of the datasheet as shown below.

    As the START pin rises, the /DRDY goes high and stays high as the digital filter is reset and is filled again. For a setting of DR[2:0]=101, the settling time should be about 2.25ms. This can be found in Table 5, with the fCLK set to 2.048MHz.

    Just in case, I would also measure the width of the /DRDY pulses, just to check the master clock. It should be about 1.95us wide. For these measurements, they should verify that the clock frequency is correct, and that the the DR[2:0] setting is correct (besides through reading the register).

    One possible problem is the way that the customer is measuring the /DRDY pulses to see the data rate. As mentioned before, the /DRDY pulse width is 1.95us, but the data period should be 500us. This means that the scope is showing a pulse that is very narrow compared to the pulse period. If the oscilloscope shot is zoomed in too much, the resolution of the scope shot might be too coarse to see each /DRDY pulse (and it may be missing every other pulse). I mention this because I've been asked this as a similar question before.

    Regardless, have you customer check the START to /DRDY settling time.


    Joseph Wu

  • Good day Joseph,

    Thank you for answer. The customer made scopes. Please, see them attached. Will be glad if you can tell what can be wrong in here.

    The customer checked the Settling Time by a software and got 280msec. Also scope shows the same time.

    C1 - YELLOW - START signal (50msec per div)

    C2 - GREEN - /DRDY (came after 280msec)

    Zooming:

    1div = 1msec. ADC programmed for 2 kHz. The signal comes every 1msec but for 2 kHz is should be every 500usec.

    Customer checked all registers by reading their values. All were seput correctly.

    Also customer tried 32 kHz and got 16 bit data, but /DRDY signal comes like it's 16 kHz.

    Thank you, Mikhail

  • Mikhail,


    I'm still not sure what's wrong, but I still want to keep checking a few things. First, I mentioned in my last post that I wanted the customer to show the width of the /DRDY pulse, and that it should be about 1.95us wide. I'd like to see that on a scope shot. I also want to verify the fCLK frequency. Originally you mentioned that they were using an internal clock, but I want you verify that they aren't using an external clock and have them measure the fCLK frequency if they are using an external clock.

    The reason I'm checking the clock is because the scope shots seem to still imply that the fCLK is half of the expected. It's not just the /DRDY period, but also the amount of time that /DRDY is high after the /START goes high. Normally this would just be the 2.25ms from the table that I showed in the last post. However, the customer reported back that this time period was 280ms. This is much larger than expected from the settling time of a reset of the digital filter (by >100x). Were they using the START pin for this test? Is this different if they use a START command?

    There are only two times in the device that are of that scale of 100s of ms. First the time to /DRDY low after a power up is about 150 us. Second the time to complete an offset calibration is also about 153us. However, if the fCLK is half of expected, then the data period would be 1ms instead of the expected 500us, and both the startup time and offset calibration time would be off by 2x also, both at about 300ms.

    Again, have the customer verify the fCLK period, then verify the SCLK pulse width. After that, they could check both the start up time and the offset calibration time, just to verify any other device time.

    If none of this seems to be the problem, I would like to get them to read back all the registers and report back with the entire register map settings with all register values. At this point getting the schematic may also be helpful.

    Joseph Wu

  • Good day Joseph,

    Please, looks at questomer's answers on your questions:

    1) The lenght of /DRDY is about 1.95 usec as scope shows below

    2) Customer removed (didn't use) calibration command and got a time between START and /DRDY signal became about 4.5 msec (two times higher than it should be accorting to the table).

    Customer doesn't use an external crystal (uses the internal generator). There is a possibility of using an exernal one (by the jamper setup) as it shown on a shematic.

    3) customer also measure the frequency of the external crystal and it's 2MHz

    4) SPI frequency is 20 MHz (C1 = 19.98 MHz)

    Registers settings after write / read:

    Config1 = C5h

    Config2 = 12h

    Config3 = E9h (LSB should be "0", but customer reads "1")

    Thank you, Mikhail

  • Mikhail,

    I still have no good answers for the data rate. For the /DRDY pulse width 1.95us is perfect for 2.048MHz. However, from the previous post, the START pulse rise to /DRDY fall is still way off (expecting 2.25ms, but getting 280ms). I'd still like the customer to try that one because it should be the equivalent of 3 three ADC reads with some overhead. This would ensure the timing of the ADC in conversion mode besides the /DRDY pulses. It might be good to look at the timing of the offset calibration also, because this is done with a set number of ADC reads, and we could look at that as well.

    Looking at the configuration, this is how the device is set up according to the customer. This all looks good to me too.

    Config1:C5h
    Multiple data readback mode
    Oscillator clock output disabled
    CLKSEL pin=1
    Internal oscillator used
    Data rate 2kSPS

    Config2: 12h
    Test signal not used

    Config3: E9h
    Enable internal reference buffer
    Int VREF=4V

    SCLK 20MHz

    One thing that I wanted to be sure of was if these registers were read back to determine the register contents. In particular, I wanted to verify the readback of Config1, bit 7, just to make sure if it isn't 0 somehow. I think this might have an effect on the data rate of the device and make it half as slow.

    Other than these comments, I would also like the customer to short the inputs to get a read of the ADC, and also plot the SPI communcation for several ADC reads. This might be a better view of the /DRDY in case the oscilloscope is dropping /DRDY pulses. The read would force /DRDY high after the first SCLK in. One last question, is this effect seen on multiple boards, or have they looked at only one board?


    Joseph Wu

  • Good day Joseph,

    Please, see customer's answers below:

    1) the time 280 msec customer observed was related to ofsetcal calibration. He switched off this calibration and the time from the START to /DRDY became 4.5 msec. It's two times longer than it should be according to the table.

    2) Customer checked registers above (in my previous post) after reading them from ADC. A software is checking reading and writing of the registers.If they are not the same, the system reports an error.

    3) /DRDY signal the customer checked without SCLK time by the oscilloscope and got two times longer result.

    4) the same behavouor in two different devices (different hardware) with two different software engineers.

    Thank you, Mikhail

    also attached top marking of the device.

  • Mikhail,


    I'm almost out of ideas on what could be the problem on this one, but here's another thing to try. Can you have the customer read the ID control register (address 00h), and report back the result? I just wanted to check this register status.

    I reached out to another apps engineer that has supported this device in the past. I've supported this device for the last two years, and he supported it from the introduction until then. He is just as unsure what the problem is. He had suggested that they bring the internal oscillator to probe that as well. He realizes that they've already done that with an external clock, but it's another data point just to check the internal clocking in the device.

    He did ask about on how many units this has occurred on, but I don't know if he had seen that the customer has tried two units already from the last post.

    This may take some time, but I'll check with the design group and see if they have any thoughts on this. I'm not aware of any other similar issues, but I'll also check if there's been anything has ever been reported.


    Joseph Wu

  • Good day Joseph,

    Thank you! I'll be waiting any news.

    Could you tell me how to check the frequency of the internal generator?

    Also answering your question about the ID control register. Customer gave value of D2h

     

    Thank you, Mikhail

  • Mikhail,


    The internal oscillator can be brought out to CLK pin when the CLKSEL pin=1 and the CLK_EN bit is set to 1. CLK_EN is in the CONFIG1 register. Also, D2h is the correct reading for the ID register.

    However, I did talk to another apps engineer who reviewed this and he noticed a couple of things for the register settings that I missed. First, the customer reported that the CONFIG1 register was set to C5h. This is an invalid setting. If you look at the CONFIG1 register, bit 4 is Reserved should be set to 1. This setting should be D5h.

    Also, the customer reported that the CONFIG2 register was set to 12h. This is also an invalid setting. Bits 7:5 are also Reserved and should be set to 1. All things being equal, this setting should be F2.

    These Reserved bit settings may be important to the operation of the device. Sometimes these are used for alternate unused modes, so it's important to check on them. I would make sure that they follow those carefully. Have the customer make those changes and see if it sets the data rate correctly. I'd probably look at these settings before checking on the internal oscillator frequency.


    Joseph Wu

  • Mikhail,

    One other comment that I'd failed to mention is that we generally don't use inductors in the supplies or ground for data converters. In these devices, there will be some amount of digital current and using inductors will spike the voltage supply with the large L(di/dt) seen from digital current. I would short the inductor for any tests (L1E1) in the schematic.

    Joseph Wu

  • Good day Joseph,

    Customer resolved this ussie.

    A problem was in BIT 4 of the CONFIG1 register.

    He changed it to D5H (instead of C5H) and the speed now is according to the table.

    Thank you for helping!

    Mikhail