Sensor SEN 0334

I recently bought an SEN0334 Temp And Humidity Sensor through Core Electronics. I could find little basic info on it so I followed the instructions on the DFROBOT website. I used the suggested library and loaded up the singleMeasurement Example ,The basic hook up diagram shows the SDA and SCL connected to pins 16 and 17. Being a bit of a novice I couldn’t understand why??. Tried it out and nothing worked. So I connect SDA and SCL pins to A4 and A5. everything worked perfectly until I checked the readings.

Chip serial number181047656
------------------Read adta in single measurement mode-----------------------
Ambient Temperature(°C/F):29.89 C/61.92 F Relative Humidity(%RH):65.05 %RH
Ambient Temperature(°C/F):29.91 C/61.92 F Relative Humidity(%RH):65.06 %RH

My Room temperature 28.9 C ,84.0 F
My Room Humidity 66%
The problem is the Fahrenheit reading, is way out . It should be reading 84 F not 61.92F
I checked the conversion in DFRobot_SHT3x.cpp and it appeared ok.

  tempRH.TemperatureC = convertTemperature(rawTemperature);
  tempRH.TemperatureF = (9/5)*tempRH.TemperatureC+32;
  tempRH.Humidity = convertHumidity(rawHumidity);
  return tempRH;

Could you help me sort this out because I need to use it in Farhenheit for a dehydrator.
Thank you

1 Like

I checked the screen shots of the readings on the DFROBOT site and they don’t make sense either, I know I can convert the Celsius reading to Fahrenheit in coding , but I don’t understand the readings that the sensor are showing, please help

1 Like

Hi Allan
Try “tempRH. TemperatureF = ((tempRH.TemperatureC*9)/5)+32” Take note of the brackets.
Cheers Bob
Add on
Put another left bracket “(” in front of “(9” like this “((9” and put right bracket “)” between “TemperatureC” and “+32” like this “TemperatureC)+32”.
Does the same thing.
Cheers Bob


Bob’s solution should fix it, but it’s an interesting issue! I don’t think it’s strictly an order of operations issue - I suspect that changing the line to:

tempRH.TemperatureF = (9.0/5.0)*tempRH.TemperatureC+32;

will also fix it.

I’m betting this issue is due to integer truncation:
9.0/5.0 = 1.8, but because these are integers, the decimal gets thrown away, so int 9 / int 5 = int 1, remainder 4 (you would use the modulo operator like 9%5 to get the remainder 4).

Having a float in the multiplication automatically casts an int to a float; so after 9/5 is solved int 1 is cast to a float 1.0, after the fact. Then the addition of the float and the int 32 is performed, and the 32 is also cast to a float 32.0.

Thus the calculation process goes like this:

(9/5) * tempRH.TemperatureC+32
(1) * tempRH.TemperatureC+32
1.0 * tempRH.TemperatureC+32
1.0 * 29.89 + 32
29.89 + 32.0
= 61.89

The calls for reading °C and reading °F cause separate reads from the sensor, so it may just be potluck that the example you’ve shown has 61.92 both times for the °F measurement, but a .89 and .91 for the °C measurement.

Hi Oliver
I think you are pretty spot on with what is happening. I was not aware that in a calculation like this that the term “9/5” would also be an integer. If this is the case using the first method in by above post will minimise the error as the “tempRH.TemperatureC” gets multiplied by 9 before anything else happens so you will only discard 0.9 degree at most and you are not multiplying the error caused by dividing 9 by 5 first.
What sort of a thermometer is measuring temp to 2 decimal places anyway.
Cheers Bob

1 Like

Ah well putting the *9 first will cast the 9 to a float, and so at every stage the result will be float, so it’ll be floats all the way down to the answer.

The problem with the way its written at the moment is the compiler does an operation on two integers first, so there’s no reason for them to be cast to floats at that first step. You can’t do maths on an integer and a float, they have to be the same type, so the compiler automatically converts the integer to a float when it sees an operation between incompatible types (rather than convert a float to an integer and throw away everything after the decimal).

A very optimistic one!

Classic DFRobot, that’s even how it is in their Wiki example:

I’ve made a pull request on their Github repo, so they might merge it and fix it up!

Edit: Actually there’s already a pull request for this exact problem from the 2nd of March (though it’s not quite as neat a patch as mine if I do say so myself :wink: ). Hopefully they’ll get around to it soon.

Thank you very much for your reply’s, I’m working on it and will let you know how I go.

1 Like

P.S. I saw a great video about temperature measurement the other day - worth a watch:

Note that there’s 2 places in the code where they’ve used 9/5 instead of 9.0/5.0.

The easy thing to do is download the file I modified :slight_smile:

Here’s a direct link to that file:

You should be able to just replace the one you’ve downloaded with this and it’ll work (fingers crossed).

Also, here’s a link to the pull requests on the repo:

Edit: Just got an email saying my change has been merged :slight_smile:

It should now work for everyone in future by just downloading from the Repo!

Phew!!! Every hobbyist should have one of those.
As a matter of interest with thermocouples cold junction compensation is done electronically these days but laboratory instruments had the cold junction held at the point where water goes from liquid to solid without changing temperature or 0ºC. in practice in a container of ice water. I think this is what the guy in the video called the triple point of water.
Another snippet of trivia. A refrigeration specialist once told me that it takes 1 BTU (British Thermal Unit) to lower 1lb of pure water 1ºF but it takes 11 BTU to turn 1lb of water from liquid to solid without any temperature change.
All pretty interesting when one wants to measure to a few decimal places but it is like calibrating a piece of test equipment. All it shows is the last few measurements you took were probably correct. But you have got to draw a line somewhere otherwise we could not believe anything.
Good interesting viewing anyway.
Cheers Bob

1 Like

Ah yep, the triple point is very very close to 0°C, but it’s at very low pressure - about 600 Pascals (not kPA!). Water coexists simultaneously as a gas, a liquid, and a solid, spontaneously jumping between phases. Ice water is almost exactly zero precisely because of the large latent heat needed to shift it from solid to liquid state - it keeps the temperature very stably near 0°C - at least until most of the ice has melted (or the water frozen if the ice is cold enough).

Ice water at atmospheric pressure is a good enough temperature reference for pretty much everything except those ridiculously accurate temperature measurements.

Mind you, that guy’s talking about their super special equipment having the precision and accuracy of 10^-5 which is 0.003°C at 27°C! Makes you realise how overly optimistic reading off to 2 decimal places is on a cheap sensor! Also makes you realise how poor we are at measuring temperature compared to something like voltage or distance which every man and his dog can readily do down to 10^-6.

Thanks for all your help, I watched the video, very interesting. Downloaded the script and it works just fine. Was on the right path, saved the ccp file but forgot to upload the UNO. One quick question, how do you upload screen shots , thinking some additional script is involved.
Thanks again

Hi Allan,

Glad to hear you got it working, and thanks again @Robert93820 and @Oliver33 for helping out!

Re the screen shots, you can just take a screen capture either using the print screen key on your keyboard, or a screen capture tool, then with the cursor in the reply box hit Ctrl+V to upload! You can also upload images using the the upload button:

Just got an email saying my change has been merged :slight_smile:

It should now work for everyone in future by just downloading from the Repo!

That’s great , tinkerers with old brains like myself can easily get waylaid for many hours looking for problems. We all make mistakes and that’s how we learn

1 Like