ADS1118 default values?

James,

Welcome to the forum!  Can you send us some scope shots of the communication?  What are you trying to write to the ADS1118?  What you are reading back is the default value plus the pull-up enabled on the DOUT pin.

Best regards,

Bob B

I have tried writing both actual config and 0x00 0x00 (invalid, so it'll just be a read).

I have also tried it at both 4MHz and 100kHz.

The default also should have OS bit high (can issue a command) but does not -- scoping DOUT does suggest a pullup, so I think it's correct.

The OS bit never seems to change to 0x80.

I'll see if I can get some scope shots. Be "fun" to get separate probes on DIN and DOUT. :)

Actually it sends and receives the same thing over and over again, so I'll just take them separately. Just a sec...

DIN...

DOUT...

I am using CPOL 0, CPHA 1 as per the documentation. These scopes were taken separately, but the signal is more or less periodic.

It all looks OK to me, honestly, except that OS starts and stays at 0...

Hmm, after some investigation I noticed I'm sending 10 to the NOP. That'd explain why sending 0x00 0x00  gives the same result.

Unfortunately, 01 also gives the same result -- still receiving 0x00 0x00 0x05 0x8B...

James,

Is is possible for you to capture SCLK at the same time as the DIN and DOUT shots so I can see where the actual clock transitions relative to the data?

Thanks,

Bob B

DIN:

DOUT:

James,

It does indeed appear that the config is not getting written.  I will assume that the CS going low is meeting the required timing requirements.  I do notice that DIN is going tri-state.  The digital input pins should not float.  I'm not sure if this is the issue, but I would add a weak pull-up to the DIN line, and any other pin (CS for example) that might also be floating.

I would try increasing the time between the CS going low and the beginning/end of the transaction.  What are you using for communication, ie micro, fpga, etc.?

Best regards,

Bob B

I'm using a NXP LPC1343. I'll give a try about CS -- it's at about 3X the SPI clock time presently. That should be well above the minimum though, especially since I'm running it at 100kHz vs

James,

The CNV_RDY_FL should follow the operation in either mode as it is the same status used for DRDY.  I'm not sure how often you are running your loop, but if the OS is set high each time you execute the loop, the device will always be converting, which may be the reason why CNV_RDY_FL is always high.  I suggest you start the conversion, then when you poll make sure the OS bit is zero.

Best regards,

Bob B

Ah ok, I had thought the 'device will ignore conversion requests if already converting' would cover that case, making it a safe way to request both new conversions and verify when they were complete. I will try that... So then, to read the newest status, one has to send a valid config (as opposed to a NOP) in the first two bytes, just with OS bit 0?

James,

I believe that your original understanding is correct.  I would use the aforementioned method to verify that the conversion is actually starting and that at some point you know when the conversion is complete and the data is available.  Think of it as stepping into the water instead of diving in.  I think the question still remains as to whether the configuration register is actually being written.  Have you tried to just change the configuration settings (like gain or data rate) and seeing if it is changing?

Best regards,

Bob B

We've resorted to timing and ignoring the status register readback of OS, as it consistently reads OS=0 whether I wait until I know it's done or not.

Still don't know why. I'm going to see if I can set it up to not need SSEL first and come back to this later if I get the time.

The configuration register is definitely being written -- I am successfully reading all channels, and have done so at 250, 475 and 860 Hz,

as well as the pleasantly surprisingly accurate cold junction temperature...

It's working fairly well in this setup -- with the proper filters installed it's fairly stable using the full 16 bits at +/- 256mV, which is great.

I'll post back if I find out why the OS bit is giving me this trouble.

By the way, on the ADS1118 data sheet, slight bug report...

There is a section for Power-Down Mode (p. 19) which talks about a PWDN bit.

However Registers makes no mention of it at all. Guessing this feature got folded into MODE for this A/D.

Hi James,

I'm experiencing the same "OS always zero" read back. But not only that, also the cnv_rdy_fl stays always hi in my case.

Do you experience that also and what mechanism do you use to determine that the read converter data is then valid?

I would really like to hear your experience for this chip as the datasheet lacks a lot of info.

Regards,
Edwin

Yes, that is exactly what it does for me.

What I do now is record with a timer when I sent the last byte of the SPI request, and wait until it exceeds the time it's supposed to take before sending another packet (for example, at the chip's 475 Hz conversion rate, I send another query in 1/455 of a second... the safety margin just in case the clocks differ -- haven't tested if it's necessary but it doesn't hurt).

If the bits I *can* set differ from what I requested last time, I throw the data out. This takes care of startup, even if the converter power cycles while I am using it.

If you are pin-limited like I am, when the data is thrown out, also wait 50 ms before requesting again. This resets the SPI state on the chip, so you never become desynchronized (expected bits will differ if things become misaligned, which will be detectable), and yet you do not need to use a pin for SSEL.

The chip works fairly nicely for me -- I have to conclude that its documentation is just wrong.

James