Sensirion Temp/Humidity sensor library help

Hi, I have been trying to fool around with a Sensirion temp/humidity module using the library provided in the playground: http://www.target23.de/data/Sensirion_20081128.zip

I have been trying get the included example running but I dont get very far very quickly. I get this error when I try to compile the sample code without any mods:

C:\...\arduino-0012\hardware\cores\arduino/wiring.h:124: error: expected ',' or '...' before numeric constant

This is a bit over my head and would greatly appreciate any help.

Thanks!

1

1

The problem is caused by the two #defines in the Sensirion example code. They clash with variable names in the wiring.h library code.

It can be fixed e.g. by changing the #defines to

#define sensirionDataPin  2
#define sensirionClockPin 3

and a few lines later

Sensirion tempSensor = Sensirion(sensirionDataPin, sensirionClockPin);

This did the trick for me. Maybe the wiring library has changed since the Sensirion library was written.

Worked a treat - thankyou very much..!!

Hoops

I'm testing SimpleSensirion sketch with SHT71(almost the same as SHT11)
and having a problem concerned to resolution of temperature data.
I get sparse temperature data like the following:

Temperature: 24.0 C, Humidity: 34.44 %, Dewpoint: 7.37 C
Temperature: 26.55 C, Humidity: 43.42 %, Dewpoint: 13.11 C
Temperature: 29.11 C, Humidity: 52.14 %, Dewpoint: 18.30 C
Temperature: 29.11 C, Humidity: 52.14 %, Dewpoint: 18.30 C
Temperature: 26.55 C, Humidity: 34.67 %, Dewpoint: 9.71 C
Temperature: 26.55 C, Humidity: 34.67 %, Dewpoint: 9.71 C
Temperature: 26.55 C, Humidity: 25.56 %, Dewpoint: 5.25 C
Temperature: 26.55 C, Humidity: 25.56 %, Dewpoint: 5.25 C
Temperature: 26.55 C, Humidity: 25.56 %, Dewpoint: 5.25 C
Temperature: 24.0 C, Humidity: 25.38 %, Dewpoint: 2.99 C

It seems to me that the data has only 4 bit resolution...

But when I'm using another sketch (http://www.nuelectronics.com/download/projects/sht10_float.pde)
I can get full resolution temperature data:

Temperature = 26.36C Rel Humidity = 36.95% Dew point = 10.48C
Temperature = 26.26C Rel Humidity = 36.66% Dew point = 10.28C
Temperature = 26.19C Rel Humidity = 37.21% Dew point = 10.45C
Temperature = 26.11C Rel Humidity = 37.40% Dew point = 10.46C
Temperature = 26.5C Rel Humidity = 37.2% Dew point = 10.25C
Temperature = 25.97C Rel Humidity = 37.1% Dew point = 10.17C
Temperature = 25.90C Rel Humidity = 37.11% Dew point = 10.15C
Temperature = 25.80C Rel Humidity = 37.24% Dew point = 10.11C

Can everyone get correct data with using the library?

I found how to fix it.
Adding a line of code is needed at Sensirion::readByte function in Sensirion.cpp file.

pinMode(_pinData, INPUT);
// PULLUP1;
return (val);

to

pinMode(_pinData, INPUT);
digitalWrite(_pinData, HIGH); // PULLUP1;
return (val);

I think the auther of the library forgot to translate "PULLUP1" command into digitalWrite.
With this fix, I can get full resolution temperature data.

Temperature: 25.76 C, Humidity: 34.1 %, Dewpoint: 8.73 C
Temperature: 25.65 C, Humidity: 34.10 %, Dewpoint: 8.68 C
Temperature: 26.61 C, Humidity: 40.19 %, Dewpoint: 11.98 C
Temperature: 27.69 C, Humidity: 52.47 %, Dewpoint: 17.9 C
Temperature: 27.90 C, Humidity: 58.14 %, Dewpoint: 18.90 C
Temperature: 27.50 C, Humidity: 45.23 %, Dewpoint: 14.58 C
Temperature: 27.19 C, Humidity: 38.16 %, Dewpoint: 11.72 C
Temperature: 26.88 C, Humidity: 35.65 %, Dewpoint: 10.41 C
Temperature: 26.63 C, Humidity: 34.33 %, Dewpoint: 9.63 C
Temperature: 26.37 C, Humidity: 33.71 %, Dewpoint: 9.14 C

I found another problem of the library and the answer.

When you connect the SHT-xx to arduino via a short cable(about 10cm), the library works fine.
But if you hook up the sensor with very long cable, you will get corrupted data.
The reason is that, the default clock pulse width is too short for the long cable.

You can easily fix the problem by only modifying two lines in the library file.

at hardware/libraries/Sensirion/Sensirion.cpp file,

before:

#define PULSE_LONG delayMicroseconds(3) 
#define PULSE_SHORT delayMicroseconds(1)

after:

#define PULSE_LONG delayMicroseconds(300) 
#define PULSE_SHORT delayMicroseconds(100)

With this fix, I can get correct data with using a 40 meter cable! Probably I can use more long cables.
Though I have not found the best width of the pulse, 300 and 100 usec delay doesn't cause any problems.

note: You have to remove the old Sensirion.o file after the modification.

Hi,

I've been using a program from Sparkfun(a Wiring program based on Maurice Ribbel's) without any problem with cable lenght of 2ft during the last couple of months.
Since I am a noobie, the program you have cited seems to me different from the above program.
In this case, I wish to know how should I change the code as you suggested in your code.
http://wiring.org.co/learning/examples/SHT15sparkfun.html

I have inserted a portion of the program, which seems to me sort of relevant to the portion you have mentioned(which might or might not at all relevant)

--portion of code ---
[//commands for reading/sending data to a SHTx sensor

int shiftIn(int dataPin, int clockPin, int numBits) {
int ret = 0;

for (int i=0; i<numBits; ++i) {
digitalWrite(clockPin, HIGH);
//delay(10); not needed
ret = ret*2 + digitalRead(dataPin);
digitalWrite(clockPin, LOW);
}
return(ret);
}

--- end of code -

thank you.
Bryan

You should insert delay commands after almost all the digitalWrite commands so that you can control the width of the pulses.
That is a bit troublesome job, I recommend that you try to use the library instead of modifying your code.
First of all, why not read the library file?
You can download the library from http://www.target23.de/data/Sensirion_20081128.zip.

I'm also playing with this sensor and have communication working fairly well. However, I occasionally get a problem where the temperature sensor returns 255 for one byte. I haven't implemented the CRC, but it is sending back FF for the CRC, so it seems like a data communication error.

I can't figure out the conditions that cause this behavior. Has anyone else had this happen?

thanks,
mike

Hello my hamijos mios

I had the same problem with our sensor Sensirion, we couldn't read the second data word. We solved it like you by putting some delays in the original code. I don't know if you arrived to a definitive code, but if you want here is my code:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1246400334/10#10

NOTE: it's such a long code that I had to put it in 2 posts. Just copy&paste both parts in the same file.

It works 100% sure. It's in Spanish, but I don't think it's a problem to work with. Besides, I included some functions for dew point (rocio), real humidity and more..

REALLY IMPORTANT: don't forget the pull up resistance (view data sheet) connecting DATA and Vdd, because w/out it you won't be able to read the second word, getting worse accuracy.

Also important: I believe the sensor works better with Vdd = 5volt than 3.3, what do u think?

A question: I have checked that the first value is not true in the sense the Sensirion hasn't stabilized yet. Anyone has made some test to know the minimum milliseconds to wait (in the start up) to have real stable results from the beginning?????

If someone wants to make a good library, I'll be pleased, let me know.

PS: I hate ****ing Sensirion sensor. It took us several days to write a good code. I don't think it's logic to sell a sensor with such a estrange communication protocol without a good code made by the people inside Sensirion: "We won't do the code, all the geeks will make it in the 2.0 web.." it's really kind, really kind :-? :-? But I can say it works really really well (with a good code). However it's expensive. Before buying it, think about Sencera's humidity sensor + LM35 temperature sensor.

I hope you like it

Also important: I believe the sensor works better with Vdd = 5volt than 3.3, what do u think?

In SHT-71's datasheet page 5, you can find the following footnote;

10 Recommended voltage supply for highest accuracy is 3.3V, due to sensor
calibration.

When the sensor is driven at 5.5V, the temperature values tends to be between 0.2 to 0.5 degree C higher than that of 3.3V drive.

Many thanks, tasasaki.

Now, my sensor is working great.

Bryan.

@tasasaki
I have the same issue with the resolution. But I cant get your code working to get the full resolution. I (G)edit the cpp file in hardware/libraries/ and saved the change.

        }else{
                digitalWrite(_pinData, HIGH);
        }
        digitalWrite(_pinClock, HIGH); //clk #9 for ack
        PULSE_LONG;
        digitalWrite(_pinClock, LOW);
        PULSE_SHORT;
        pinMode(_pinData, INPUT);
        digitalWrite(_pinData, HIGH);         // PULLUP1;
        return (val);}

Then I re-verified it and loaded it to the arduino. No change to the data. Can you help me in getting thatup and running?

I think you are using arduino IDE 0016 or older.
And it's very likely that you didn't remove the Sensirion.o file after the modification.
Please remove it and re-verify.

The latest IDE 0017 fixed this kind of problem.

• Libraries are now compiled with the sketch, eliminating the delay when
  switching boards and the need to delete .o files when changing library
  source code.

Everything works fine now and "Yes" I used the Version 16.

Thanks fr your help: [smiley=dankk2.gif]

When you connect the SHT-xx to arduino via a short cable(about 10cm), the library works fine.
But if you hook up the sensor with very long cable, you will get corrupted data.
The reason is that, the default clock pulse width is too short for the long cable.

If you connect the Sensirion recommended resistors and capacitors this problem should be elminated.

Can someone post their working code..??

Hello, amigos míos

I suggest you going to a post in Spanish where you can find my code: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1246400334

It's tested and works good. There are TWO parts of code, both are needed, just copy&paste together. There are several lines that are for another sensors, but there's no need to delete anything if you don't want to. It's not a library, it's just a set of functions, .. but who cares?

Regards