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.

ADS1018: reading out temp and AD values

Part Number: ADS1018

We’re having an issue with the ADS1018 ADC with internal reference and temp sensor in a design.   We are polling the sensor every ~ 202 us, and on alternate cycles, switching between ADC mode and temp sensor mode by flipping the TS_MODE bit in the config register. The problem is, we don’t consistently get ADC and Temp data on the expected cycles. We are expecting that after the TS_MODE bit is set to 0 (ADC mode), then the data appearing on DOUT on the next cycle will be ADC data. Similarly, after TS_MODE is set to 1 (Temp mode), we expect Temp data on DOUT during the next cycle.

 

Can you please confirm this is how the ADS1018 should operate?

 

We have the device configured in continuous conversion mode.

 

I’ve checked the timing against the data sheet parameters, and there appears to be sufficient margin, although we are running SCLK fairly close to the Tsclk spec of 250 ns (we are running it at ~260 ns). Attached is a scope shot, with MISO/DOUT purple trace and MOSI/DIN green trace.

 

The complete config words we are using are:

 

temp: 0100010010011011

ADC:   0100010010001011

 

We are powering the ADS1018 at 3.3V.

 

The temperature and ADC data we are receiving, appears to be the correct values, just not in the expected sequence.

 

I will continue to troubleshoot our controller code, but please let me know if you have any insights.

 

Thanks and Best Regards.

  • tomuon24,


    When alternating between different channel configurations, we generally recommend using single-shot conversion mode to reduce the confusion on what channel the ADC is converting and what channel the data is comes from.

    For this device, Writing to the config register sets up the configuration for the next conversion. Even though the config register has set up the next conversion, this change does not occur until after the conversion that is in progress completes.

    Using continuous conversion and trying to alternate between channel setups can be difficult because it's hard to know when the conversion has completed and when the next new config setup and conversion has completed. In this case you need to wait 2x the data period to ensure that the conversion is the one you expect.

    Again, we recommend using single-shot conversion mode so that you can guarantee the data you get is for the correct channel, and then restart a new conversion for a new channel when the last one completes. This should eliminate any confusion on which channel conversion data is coming out.

    Hopefully that clears up your problem. If it doesn't, post back and we can look at it again.


    Joseph Wu
  • Thanks for the prompt response and clarification, Joseph. That makes sense. From the 'Data Retrieval' section, it seemed that we could put it in continuous conversion mode and just grab the latest reading without bothering about synchronization. I guess switching to temperature mode in the middle of the conversion throws a monkey wrench into the works.

    Follow up questions:
    How long does it take the temp conversion to complete? Is this also set by the config register DR setting? So, if we want to keep our current scheme, we should wait at least 2xDR period after the last config reg change, before reading data.
  • tomuon24,


    The temperature conversion is treated as any other conversion (similar to change mux settings), so it follows from the DR setting.

    As an example, if you are at a DR of 128SPS, then a conversion should take about 7.81ms nominally. You should add on 10% for the internal clock variation. If you continue to use your current scheme, then you'll need 2 x 1.1 x DR period after the last config change before reading data.

    If you decide to change to single shot conversion, then you would need DR period x 1.1 and then add on about 20us to allow for the ADC to power back up.

    Again, if you have any other questions or need a clarification, feel free to post back.


    Joseph Wu