SHT15 Humidity Sensor with Luminary Cortex-M3

Development Boards MicroMod
1

I’m trying to get Sparkfun’s SHT15 humidity breakout board working reliably on a Luminary LM3S1968 system, but I’m having problems. I’ve gotten it to work, and it does return reasonable humidity and temperature values, but not reliably.

The SHT15 uses a pseudo-I2C interface that’s different enough from the I2C standard that I can’t use the I2C peripheral on the microcontroller but have to bit bang it instead. The protocol is straightforward enough, and well-documented in the SHT15 datasheet.

The breakout board has two signal lines: a clock line with a 10K pull-down resistor, and a data line with a 10K pull-up. Since both the microcontroller and SHT15 drive the data line, I’ve configured the GPIO port I’ve got connected to the data line as an open-drain output.

The SHT15 requires a special start sequence (this is the reason why it’s not strictly I2C compatible, BTW) that looks like this, with the microcontroller controlling both clock and data:

            ___     ___
SCK :   ___|   |___|   |______
        _____         ________
DATA:        |_______|

When everything works, the start sequence looks fine on the 'scope. When it doesn’t work, I see the microcontroller pull down the data line in the start sequence, but nothing when the microcontroller releases the data line that should cause the pull-up to take data high. The 'scope shows something that looks like this:

           ___     ___
SCK :  ___|   |___|   |______
       _____              
DATA:       |_______________

Anyone else get the SHT15 to work reliably? Do you always see clean startup sequences rather than sometimes abnormal ones where the microcontroller can’t pull the data line high a second time? (Actually, since it’s configured as an open-drain output, the microcontroller doesn’t “pull” data line high, it just tri-states the port and lets the pull-up resistor pull the line high). The only thing I can think of here is that the SHT15 itself is pulling the data line down, which makes no sense.

I’m following all of the timing specs for the sensor in my code, especially with respect to clock width, frequency, etc. One thing I did notice is that there’s a lot of slew in the data line. When the microcontroller tri-states the port controlling the data line, it takes around 2.5 microseconds for the line to be pulled up to a solid high.

I’ve got the sensor connected to my eval board with short jumpers (~2 inches), so I doubt this is an issue, especially since I’ve heard reports of people successfully using the SHT15 over 200 feet of Cat-5 cable.

Anyone have any ideas of what to check next?

2

I have done this, connecting to SHTxx, on Cortex-M3, ARM7 and Atmeg168. Once the protocol is understood and the timing is OK then it has always worked.

Since you seems to know what you are doing, at that all looks perfectly correct, it seems there is a “silly mistake” somewhere.

The rise time of 2.5mS i WAY to slow, with a 10k pull up this corresponds to 0.25uF capacitance on the data line. That is the type of values used for power supply decoupling, and not good for data communications.

So try the signals without the SHTxx connected and with an open data line and also with a weak 100k pull down.

Regards

Magnus

3

Without the sensor (with the GPIO port connected directly to a 10K pull-up to VDD), it takes 450 nsec for the line to be pulled high (10% - 90%) when the microcontroller releases it. It takes 120 nsec with a 2K2 pull-up.

It looks like the sensor itself is causing the slew.

4

Good description of your difficulty - suggest the following:

a) “just in case” always best to have a second sensor board to see if the problem persists across the 2nd board

b) same holds true with your ARM board - try a 2nd if available

I didn’t see mention of what voltage the p.u. R is tied? Are you sure that this voltage is acceptable “both” to the sensor and the ARM?

Last gasp - wonder if the mcu open drain pin/config is the cause. Perhaps you could use a “normal” open drain ic - see if that helps…

5

SeniorEE:
Good description of your difficulty - suggest the following:

a) “just in case” always best to have a second sensor board to see if the problem persists across the 2nd board

b) same holds true with your ARM board - try a 2nd if available

I didn’t see mention of what voltage the p.u. R is tied? Are you sure that this voltage is acceptable “both” to the sensor and the ARM?

Last gasp - wonder if the mcu open drain pin/config is the cause. Perhaps you could use a “normal” open drain ic - see if that helps…

Thanks for the reply!

a) I have a second sensor board–it behaves identically to the first.

b) Tried a second ARM board too – no change.

The pull-up is tied to the 3.3v rail, which is the power rail used by the ARM and the sensor. Both are 3.3v parts.

The ARM GPIO config is correctly set for open-drain operation. I hooked up just a 10k resistor to the pin directly to VCC (without the sensor) and measured the rise time when releasing the port. It was around 450 nsec. This contrasts to 2.5 usec when the sensor is connected, so it’s obvious the sensor is putting a capacitive load on the data line. I’ll probably try changing the pul-up on the data line to 2.2K next and see if that helps.

6

Thank you - the (A-B) test is so often worth-while.

My firm used that sensor (bought directly from maker) with both LMI and STM32 ARM mcus - no such issue! (dumb luck? superior cunning? phase of the moon?)

Bet that your sensors are from same build lot - close date codes. Before probing further - if that is the case - shoot an email off to maker - reporting lot/date code - “just in case.” Really aggravating to “confirm” a known problem (NOT known by you/me (general public). With the detail you’ve supplied the maker should “sample” (free) a “fresh” device for your evaluation.

Final swag - is it possible that the sensor is not “fully awake?” Maybe you are exercising it too soon after power up? And - once you obtain the failed condition - do repeated “challenges” to the sensor continue to fail?

Hope this is of some value - it is a good device. (IOHO)

7

Thanks for the suggestions. I’ll look into them.

One interesting thing about this sensor that I discovered is that it works just fine with no connection to its VCC pins. I guess it gets enough power parasitically through the data and clock lines to work without a direct connection to VCC.

8

Hi,

can any one tell me how to interface the SHT11(temprature and humidity sensors ) to the 8051 controller…I went through the datasheet and connected that properly to controller .Now i’m stuck at the coding part …can any one share the code ot docs to the above…?

thanks

chethan