TEMPerHUM measurement calibration

[ourmoonfalls]

First at all: the driver is running fine on a Raspberry Pi with raspian and two TEMPerHUM attached (0C45:7402 Microdia). However, the measurements appear a bit strange. E.g. in normal conditions (around 25° room temperature) the output is:
./tempered
0001:0004:01 0: temperature -15.85 °C, relative humidity 34.4%, dew point -26.8 °C
0001:0005:01 0: temperature -15.99 °C, relative humidity 34.8%, dew point -26.9 °C

./tempered -e gives:
0001:0004:01 : TEMPer2HumiV1.x (USB IDs 0C45:7402)
0001:0005:01 : TEMPer2HumiV1.x (USB IDs 0C45:7402)

So, here the thermometers are both off by about 40 degrees. I do not know much about current relative humidity, but the values are reasonable. Looking into the code I see that temperature is calculates as

temp = -39.7 + 0.01*rawmeasure

following the sensirion SHTx1 data sheet. Well, now I am not sure if the SHTx1 is actually used on this TEMPerHUM chip. Or maybe there is an onboard calibration so that is suffices to do:

temp = 0.01*rawmeasure

When running the pcsensor software for windows, I get correct values of +25°C and humidity about 33%. So there must be some issue with the calculation in the TEMPered driver. To my surprise the windows driver also gave -16°C yesterday directly after starting the software, but the measurements afterwards were again correct.

Maybe someone can help with this? My first guess was that the TEMPerHUM has a different sensor, needing different calculation, but on second thought I would rather tend to say this might be more a problem of reading the raw data. I read somewhere that a sleep command between sending the measurement signal and reading the data would be required in order to give the sensor enough time for measuring. I am wondering if this is considerd in TEMPered and if not, where to put a hard coded sleep.

Thanks in advance!

[stefaan84]

Hi,

same issue here.

System: ESXi 5 Host, Ubuntu 12.04 i386 Client, using Zabbix for monitoring.
Sensor:
/dev/hidraw2 : TEMPer2HumiV1.x (USB IDs 0C45:7402)

Room temperature is about 21°C, if the value from the Dell server is correct. Humidity could be correct, the room is in the basement.

tempered
/dev/hidraw2 0: temperature -17.11 °C, relative humidity 46.7%, dew point -25.0 °C

tempered -c 39.7
/dev/hidraw2 0: temperature 22.59 °C, relative humidity 46.7%, dew point 10.6 °C
could be correct.

The next time I'm on site I can try the windows software and compare the values to an external thermometer.

Thanks!

Stefan

[dhobi]

Hi there,

another "lost guy" with...
/dev/hidraw0 : 0c45:7402 interface 0 : RDing TEMPERHUM1V1.0
/dev/hidraw1 : 0c45:7402 interface 1 : RDing TEMPERHUM1V1.0
...is getting cold in here ;-)
/dev/hidraw1 0: temperature -13.03 °C, relative humidity 27.7%, dew point -26.4 °C

+1 for +39.7 even if there is a nice workaround (tempered -c 39.7) :-)

Daniel

[ourmoonfalls]

Actually, using a constant offset of 39.7 will not work very well. I have compared the TEMPerHUM data with an older TEMPer sensor, both located at the same position for more than a week. It turns out that there is no constant offset. When the TEMPer reports a temperature change of lets say 4°C, the TEMPerHUM only registers a change of not more than 1°C. Maye a linear relation is more appropriate (my data gives something around: tempered -c 56:2). However, I would rather like to get a correct calculation that should usually be not off by more than +-2°.

Moreover I find that relative humidity far to low (currently the sensor reports 25%, whereas a separate hygrometer says 38%.

Still waiting for a proper solution...

[stefaan84]

Additional info to my last post:
Temperature seems to be correct (tempered -c 39.7: 23,38°C, Dell: 24°C - shows only integer values).

Relative humidity is interesting (compared to an analog hygrometer):
11.06.13 10:15 22,86°C tempered: 46,3% analog: 63%
20.06.13 15:30 23,26°C tempered: 49,3% analog: 61%
21.06.13 08:40 23,38°C tempered: 48,3% analog: 71%
21.06.13 15:30 23,38°C tempered: 47,9% analog: 70%

any ideas?

Stefan

[ourmoonfalls]

I do not believe that tempered -c 39.7 does the trick. See my comment above. The temperature might look correct, but only for values around 25°C. Check the measurements in colder and warmer ambient air and you will notice, that it will still give you somethign around 25°C. Standard output for humidity is too low by about 20% - that's what I observe, but a validation here is difficult. I'm afraid there won't be an empirical solution and someone needs to check the sensors and processing...

[stefaan84]

Hi,
I placed an arduino with a DHT21-sensor next to Temperhum (for about 2 weeks now) and got following data:
Humidity = Feuchte

DHT21: Values from DHT21
Temperhum: Original Temperhum-Value (Temperature +39,7)
Temperhum + Offset: tried to find an offset-value (see difference-graph), but the avg value jumped around during the last two weeks

The processing of the raw values from Temperhum seems to be correct (formulas given on datasheet). Maybe there's an error while reading the data.

Stefan

[fenderb]

My sensor reports -13.34C with tempered, while my analog thermometer shows 27C. In the Windows software I only have to adjust by a tiny amount, -5.5F (sorry, I am in USA), unless the included TEMPerHUMv22.1 code makes a large adjustment on its own.

[edorfaus]

Hi everyone, sorry for taking so long to answer here.

RDing has apparently come out with a new variant, that is different enough from the old one that the same code doesn't work properly - but similar enough that it actually gets some data (even if it's misinterpreted). I hope it won't be too difficult to find some way to separate them from the older devices, since I want to support both at the same time.

I would guess that this new device uses a different sensor, which requires a different formula to get the correct values. I don't suppose any of you have cracked yours open to check which sensor type is actually in it?

There are also other possibilities of course, such as it now requiring some initialization time (since the Windows software got odd temperatures once too), or having changed the offsets of the temperature bytes in the response data.

One thing worth noting is that the relative humidity formula uses the temperature, so if the temperature is wrong, the resulting relative humidity value will probably also be wrong.

The easiest thing to check is probably the initialization time thing. If you run the read-repeat example program on the device, it will open (and initialize) it just once, but read it repeatedly, with some seconds of delay in between. If the device just needs some time to initialize, at most the first reading should be wrong. (Honestly though, I think the time between plugging it in and starting the program is probably enough time to initialize it properly.)

Checking if the data makes more sense with a different sensor's formula is not quite as easy - tempered does not currently allow overriding the sensor type or other detected information (I should probably add that), but it could be changed with a fairly simple code change. That is, assuming the sensor is an FM75 compatible one, since that's the only other sensor type it currently supports (NTC isn't implemented yet). If it's not that type, but some other new sensor type, then some research and implementation is probably required.

Another way of checking for that would be to run a raw query to the device, and then doing the math on the returned bytes manually, to see if they make sense. That's probably also the easiest way to figure out the offsets if they have changed, along with some experimentation (like heating it up to see which bytes change).

As for waiting between measuring and reading the measurement, I've so far assumed that the device handles that in its firmware (we're not talking directly to the SHT1x after all), and I've never had any problem with that until now. Since the device is capable of reading the sensor on its own and outputting the values as keypresses, I would think that's OK.

If you want to try it though, you could insert a sleep between the HID write and the HID read calls, e.g. right before line 277 in libtempered/type_hid/common.c. If that turns out to be required, I'd probably do something a bit more complicated so I can avoid it for the devices where it's not needed, but just for a quick test that should work. (Unless HIDAPI is doing something odd in the background there.)

[ourmoonfalls]

Unfortunately, I do not own the sensors (they belong to the university I am working at). Hence I cannot crack it open, even though it's quite tempting.

By the way: RDing says they won't give any information about the sensor (I am wondering why...), but they are willing to provide the dll (source code I presume - their mail was not very specific) used in the windows software for 20$ - without guarantee that it helps.

I'm going to test a simple sleep and report. Maybe someone would like to check the sensor on the chip in the meantime? ;-)

[ourmoonfalls]

I managed to open the device (see attached images). I'm not sure is the visible chip is the sensor or the controller, but there is some print "1238" "7000" and "700S" (or "7005"). Google did not give any results, but I guess it's the controller with an integrated LED in the middle. On the bottom side you only see this big black dot made of plastics. I assume it covers the sensor. But then I am wondering how it is able to measure anything...

Any ideas?

[edorfaus]

I think it's probably the other way around - the black dot is probably the controller, since the USB goes directly into it, and, as you say, it would make it hard to sense the humidity. Also, my own TEMPers are very similarly built, with a plastic dot that the USB goes into, with what is very obviously the sensor at the end of the stick. I would guess that the opening in the middle is probably there to allow the humidity to get in, so that it can be sensed.

Unfortunately, I haven't had any luck searching for the chip - haven't found all that many 24-pin quad-sided surface-mount chips (in what looks like QFN packaging, maybe?), and none of those I found were sensors.

I guess we could just look at the raw data and try to figure out how exactly it changes with changes in the environment, maybe sniff the USB bus while recording what the official program says it's measuring (to see if we can get the same results), but it's annoying to have to do that kind of thing...

I just recently had an idea that might make this unnecessary for your use case though, I'm going to announce that soon. I would still like to figure this out and get it to work with tempered, but it's possible that you won't need it, so I'll understand if you don't want to do any more on this at that point.

[ourmoonfalls]

Thanks!

I just googled a bit and found this: http://www.silabs.com/Support%20Documents/TechnicalDocs/Si7005.pdf
Looks similar - and the number "7005" might fit. I just haven't had the time to read the datasheet yet.

[edorfaus]

THANK YOU!

Your google-fu is strong, unlike mine... That looks like it's exactly what we needed - the chip certainly looks very similar, IMO too much so to be a coincidence, and it's exactly the right kind of chip.

I took a quick look through that datasheet, and it seems to contain everything I'll need to turn the raw data into understandable measurement values. I'll study it a bit closer and turn it into code.

I still need to find a way to separate this type from the other 7402 type, but I've been lucky enough to be given one of these devices, so I should be able to figure that part out by comparing them (I already have one of the earlier type).

[edorfaus]

Just a quick update: I've figured out how the Windows program separates these variants (thanks to sniffing the USB bus for both and comparing) - it sends a request to the device, and the device responds with a string that describes which variant it is.

This is a little different than the other types, which use a response with a binary number that separates the types, but not really all that different. The strings require two responses instead of just one, though, and are basically identical for the first of them, so I'll have to read both. The code needs to change a bit for that.

IIRC, the strings are "TEMPerHumV1.0" and "TEMPerHumM12V1.0", or at least something similar - I've got the dumps saved, so I can check when I get around to implementing it.

[edorfaus]

I believe I've added support for this device type to tempered now - it works with the device I was given, at least - can you check if it works for you now?

[ourmoonfalls]

Thanks for your quick implementation. However, we've been some troubles during compilation and during runtime. Cmake reports the following error:

Please wait while cmake processes CMakeLists.txt files....

RegularExpression::compile(): Unmatched parentheses.
RegularExpression::compile(): Error in compile.
CMake Error at CMakeLists.txt:57 (if):
if given arguments:

"HIDAPI_OBJECT" "MATCHES" "(-libusb|/libusb/" "(" ".libs/" ")" "?hid).o$"

Regular expression "(-libusb|/libusb/" cannot compile

We modfied the code as follows:

--- vi CMakeLists.txt: ------------------

< if (HIDAPI_OBJECT MATCHES (-libusb|/libusb/hid).o$)

---

  if (HIDAPI_OBJECT MATCHES \(-libusb|/libusb/(.libs/)?hid\)\\.o\$)

Make and make install then ran successfully. Nevertheless, the driver reports:

--- Test TEMPered: ----------------------

root@F227pi:/opt/InstallSource/TEMPered# export LD_LIBRARY_PATH=/opt/TEMPered/lib/arm-linux-gnueabihf

root@F227pi:/opt/InstallSource/TEMPered# /opt/TEMPered/bin/tempered
0001:0008:01: Could not open device: Unknown device subtype string: m1V1.0HuTEMPerHu

Looks like that the string is messed up a bit ;-).

[ourmoonfalls]

Whoo, I have had so much things to do that I kind of forgot about this one. However, I would like to bump this issues, as we still have a TEMPerHUM and still not working driver. Any chance you can solve this issue?

[ourmoonfalls]

Update! I "solved" the issue. A few explanations for all those who have the same problem:

1. ./hidtest-hidraw gives
   Device Found
   type: 0c45 7402
   path: /dev/hidraw1
   serial_number:
   Manufacturer: RDing
   Product: TEMPERHUM1V1.0
   Release: 1

2. The name string for my temper to be read by the driver (in temper_type.c) is
   "TEMPerHum1V1.0Hu", not "TEMPerHumM12V1.0". However, exchanging the string in temper_type.c was not successful. I'm not familiar with the code and haven't had the time to look into it in detail (especially what is been done not similar to sht1.x) so I could not figure out why. Basically, my model requires the same actions as for the sht1.x, except the calculation of temperature and humidity.

3. The chip is a SI7005 and si7005.c works correctly.

4. Workaround: I used the previous version of temper_type.c where the subtypes are not considered. The driver then runs into the "standard" branch where I previously got those values around -14° (just as everyone else). Then I just replaced the lines containing "sht1x" to link to the new calculation:
   .get_temperature = tempered_type_hid_get_temperature_si7005,
   .get_humidity = tempered_type_hid_get_humidity_si7005,

Fortunately that did the trick. I guess it will be only a few lines for edorfaus to make this happen in the current version of temper_type.c as well. Anyhow, I got mine finally working now. I also checked temperature and humidity against the windows driver.

[JuanKman94]

@ourmoonfalls Excuse me, could you please tell me which version you took the temper_type.c file? From which commit, I mean

[CyBer-T]

Hi. I am running in circles here, tried to setup my new temperhum usb sensor, but I always get an error when I run ./tempered: /dev/hidraw4: Could not open device: Unknown device subtype string: TEMPerHumM12V1.2. Would you be so kind and explain a little bit more about what u have done here to make it work?

[JuanKman94]

@CyBer-T I have a branch that works with TEMPerHum1V1.2. I would suggest that you clone it, use grep to substitute EVERY instance of "TEMPerHum1V1.2" for "TEMPerHumM12V1.2" then compile it and see if works.

Note that I added si7006.{c,h} to libtempered/type_hid/ - I don't remember how but I got the ID of the sensor I had. Although I don't get why it isn't working for you, since "TEMPerHumM12V1.2" is listed in libtempered/temper_type.c

[eskhool]

My device gives the following error:

utils/tempered:
/dev/hidraw4: Could not open device: Unknown device subtype string: TEMPerHum1V1.0Hu

examples/enumerate:
Found device: 0c45:7402 1 | /dev/hidraw4 | TEMPer2HumiV1.x

From [https://github.com/edorfaus/TEMPered/wiki/TEMPer2HumiV1.x] regarding this category of devices, I ran the following command:

utils/hid-query /dev/hidraw4 1 0x80 0x33 1
Device /dev/hidraw4 : 0c45:7402 interface 1 : RDing TEMPERHUM1V1.0

Writing data (9 bytes):
     00 01 80 33   01 00 00 00   00

Response from device (8 bytes):
     80 04 0a a2   05 cc 48 75

Without having to go through the code base and figure C out (urrrgh), how do I go about adding support for this?

[cjwxxx]

I managed to get this working for device ID 0c45:7402 "Microdia TEMPerHUM Temperature & Humidity Sensor", reporting itself as "TEMPerHumM12V1.2". My device is definitely using a Si7006 chip, as per the spec sheet it uses RelHum% = RH_CODE*125/65536-6, TempC = TEMP_CODE, no linearization or temperature compensation.

I followed the same process described above, basically clone an entry in temper_type.c to make a new "TEMPerHumM12V1.2" entry, changed it to reference *_si7006() calls, and then added the "si7006.c" and "si7006.h" files from [https://github.com/JuanKman94/TEMPered].

Many thanks to @edorfaus and especially @JuanKman94 , this would have been impossible without
the info they have provided here.

[normanr]

fyi: #40 has a PR for V1.2 and V1.3