These are an inexpensive (£7 delivered) Temperature & Humidity sensor operating on 433MHz which are sold as for the Imagintronix WH1400 Weather Station and have the model number WH15B on the back of them.

They are both a Temperature and Humidity sensor with 0.1°C Temperature resolution and 1% Humidity resolution. They run of 2x AAA batteries which are claimed to last a year. The bottom half of the device is the battery compartment with a red LED behind the round dot in the middle, and vents for sensors at the top sides. There are plenty of mounting options with a hanging screw at the back/top, and the clip at the base which can be screwed down or back onto something.

It is supposed to be an outdoor sensor and has a rubber seal around the battery compartment. I would still go for sheltered placement simply because rain getting into the sensors through the vents is unlikely to help getting accurate readings.

It does seem possible that this is originally manufactured by Fine Offset - it carries a similar numbering scheme and appears with a number of their products.

One note with the LED is that at night it does attract attention to it's self and this is something to consider if you are putting one outdoors where passers by may see it - some people may find it too much of a temptation.

Also beware that there is an almost identical looking device with WH5 printed on the back which actually has a protocol almost identical (apart from temperature encoding) to the WH2.

Intelligence gathering

There is little info on this other than basic specs.

• We know about the temperature range which would require 3 nybbles of BCD or 10 bits plus a sign bit to represent
• We know humidity range which would need 2-3 nybbles of BCD or 1 byte to represent
• We know this is a Channel 2 device which probably just means there is some hard-coded data

Baseband Signal

Now I've got my USB 433MHz transceiver operational and the code has a Generic Logging plug-in that stores any unrecognized transmissions to a file, it's rather easy to get it into a spreadsheet for graphing and analysis.

The signal is transmitted as a series of closely spaced identical packets (12x) with Pulse Gap keyed data. Data rate is very slow with ~4ms gaps between packets, ~2ms '1' gaps and ~1ms '0' gaps, the pluses being ~0.5ms.

This straight away presents a problem since DC blocking in the receiver is likely to introduce a varying offsets and increase the risk of corruption. There is also no preamble to settle the receiver making this even more susceptible to integrity problems, particularly at longer range where the SNR will be less favourable.

Breaking it down

I initially wrote the symbol decoder (turns data from the transceiver into bits) and placed the sensor in a number of different situations to get different data from it:

• Comfortable heated room (21°C/50%)
• Fridge (~4°C/high humidity)
• Freezer (<-10°C/very high humidity)
• Outdoors (winter - ~6°C/high humidity)
• Above a radiator (~40°C/low humidity)
• Above a shower (~30C/high humidity)
• 20x Startup cycles (identifies any rolling codes / startup IDs)
• 1hour from startup in a stable temperature/humidity (identifies any "recently powered up" flags)
• On a bench PSU from 3.2V-2.0V (identifies any low battery flag, if any)

From these I was able to identify what bits changed under what circumstances, and then derive the representations of the data.

Data Structure

As mentioned above, the encoding is crude - there is no preamble, unsettled DC levels, low data rate and a lot more to contend with, however the basic structure is as follows using MSB first:

• No preamble, sync or start sequence, but you do at least get a single pulse with the "end of packet" gap between it and the first packet
• 8-bits Start up ID / Rolling Code. This effectively gives a device a unique(ish) ID every time it's powered up.
• 2-bits of unkown data fixed at 0x2
• 2-bits of Channel data. This is the Channel - 1 so Channel 3 devices would be encoded as 0x2.
• 12-bits of 2's Compliment Temperature in 1/10'ths of a °C
• 4-bits of unknown data fixed at 0xf
• 8-bits of unsigned Humidity

It's worth noting:

• There does not appear to be a battery low flag nor a recently powered on flag - these could be used to re-detect devices that have had low batteries changed. Appears to stop working below about 2.2V
• There are no integrity checks (checksum, CRC, Parity etc.)

Data Integrity

This device is never going to be very robust when it comes to data integrity. It has a bit encoding that is prone to problems on this type of channel, no preamble, and most importantly, no integrity checks.

The method of ensuring (not really!) data integrity seems to be the brutal approach of just sending the data 12 times. While "random" (it doesn't really exists) errors would be handled by this method, due to distortions that occur in the signal in transmission (eg. DC blocking) parts of a sequence may be more susceptible to corruption and so the chances of repeating errors becomes significant. This is a very commonly overlooked area in ensuring integrity of transmitted signals as some error sources are deterministic leading to multiple bit errors and repeated errors.

The slow data rate along with this approach to integrity means that each transmission lasts around 0.6 seconds. That's a long time and blots a large amount of airtime which increases the risk of collisions with other devices. This is something I've already observed for the short time I've had the sensor.

All in all the design of the protocol leaves a lot of room for improvement: extreme inefficiency and very poor data integrity.

Suspect accuracy

I've put this with a bunch of other sensors and measuring devices and while the other devices are closely clustered (with 0.3°C and 1-2%) this one is reading around 2°C under and around 7% over the other devices (including expensive ones).

While this can't be conclusive without a carefully controlled environment to test in, calibrated reference instruments, and rigorous scientific method being applied, it does make me more than a little suspicious about the accuracy. Chances are a simple scale & offset calibration scheme will pull it into line well enough, but I expected better.

To add to this some of these devices are clearly way out on humidity. This is a graph where I had all my devices outside, then brought them indoors (spike) for some stable conditions. To get this particular device to fit the Average of Other Sensors I had to apply the formula 1.45 * Humidity - 36, and then it clearly still has a large error after being brought indoors:

The other WH15B I have required less aggressive calibration, but again didn't fit that closely to the average of other sensors.