Other Parts Discussed in Thread: ADS1118EVM, , ADS1118, TXB0104
Hello team,
Posting for a colleague:
I am developing a LabVIEW program to communicate with the ADS1018 using a NI USB-8451 SPI interface. I am using one of TI’s ADS1118EVM demo boards we purchased from TI.
I am scoping the –CS, SCLK, DIN & DOUT/-DRDY signals and from what I can tell I am sending the part legitimate commands. I have attached a photo of the scope showing the data stream. Top yellow trace is CS. Green is the SCLK. Blue trace is data being sent to the ADS1018. Purple is what the ADS1018 is sending back.
Referring to the ADS1018 Datasheet (SBAS526C Nov. 2012-Revised Nov.2015) page 18, Fig. 13, 32-Bit Data Transmission Cycle With Config Register Readback, as I understand it, when I send a 32 bit transmission it should respond with “Data MSB – Data LSB – CONFIG MSB- CONFIG LSB”. As you will see both on the scope and in my read back data it is not giving me this response. The response I get makes no sense. It is however, always the same regardless of whether I set it up for “Continuous-conversion mode” OR “Power-down and single-shot modes”.
- Am I sending the MSB and LSB in the correct order? I am currently sending it CONFIG MSB- CONFIG LSB – CONFIG MSB- CONFIG LSB. Per Fig. 13.
- I have adjusted the SCKL frequency to several values from 100kHz up to 1MHz and this has had no effect. (Note: the waveform example I have attached is 100KHz SCLK frequency.)
- I have tried both Continuous-conversion mode and Power-down and single-shot modes.
- I am operating under the assumption that in Continuous-conversion mode, I have to send at least 1 Config command to the device to start it. With subsequent commands, I am expecting to see data.
- I have the NI USB-8451 configured to ClockPolarity is set to Idle Low, clock on second edge, 8-Bits/sample. This is per Fig. 1 on page 8 of the Data Sheet.
I know that the NI USB-8451 is working properly because this same system communicates with a Linear Technologies Battery monitor device just fine. It sits on the same SPI buss using a different CS line.
Anything we can look into to help isolate what's going wrong?
Thanks!
Nate