I bought this in the hope of it having a more robust protocol - it cost a bit more than the Imagintronix and has an LCD display on the front which is useful for this project as I know exactly what it should be transmitting. It also doesn't have an LED flashing to attract attention (may tempt those with sticky fingers) or prevent you sleeping if you put it in a bedroom, but does have a little icon in the corner of the LCD to indicate when it transmits.

The sensor comes in a plastic holding clip that can be attached via screws (supplied). It runs from 2x AAA batteries in the back at the bottom, and vents behind the louvres at the front and in the base, presumably to aide airflow for the sensors. I believe it is supposed to be an outdoor sensor and has a rubber seal around the battery compartment as well as some gauze behind the louvres which should help keep out water (presuming it's mounted upright) as well as insects. I would still go for sheltered placement simply because rain all over it is unlikely to produce accurate readings - it is after all the air we are trying to measure.

Intelligence gathering

As before, 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

Virtually nothing else is know... other than it transmits on 433MHz that is - it wouldn't have been much use otherwise.

Baseband Signal

Once again my USB 433MHz transceiver with the Generic Logging plug-in is useful for storing any unrecognized transmissions to a file. From there it's rather easy to get it into a spreadsheet for graphing and analysis.

What's this? Another encoding scheme! This is a bit different from what I've looked at so far in that it's a pulse-width encoding, with a fixed gap. Doing the maths it proves interesting - roughly 1ms gaps, with 0.5 or 1.5ms pulses - if there's an even spread of 0's and 1's then the DC blocking will put the average threshold will be right down the middle - ideal, though in reality you can't guarantee that in any signal (as can be seen at a glance). None the less, with the fixed gap and the ratios involved the threshold should always be within the middle 1/3 of the signal - that's workable.

We also have a moderate amount of preamble to stabilize things. This gives me more confidence than other devices I've looked at with this and this one seems to suggest some skilled engineers put some care into the design.

Breaking it down

I initially wrote the symbol decoder (turns data from the transceiver into bits) and given that this has a display it was rather easy to cause small changes (one tick) on the display and compare the data looking for isolated bits flipping.

That worked rather well and I quickly could guess what bits were temperature and humidity readings, but it took some head scratching to realise that unlike other devices, this one encodes the 0's as long pulses and 1's as short so I had inverted data. That also makes the preamble all 1's which again is unusual.

I also did a series of power-on tests to check for rolling codes which there is one, plus the last 8 bits seem to change a lot with even a single tick of temperature or humidity different - that's another comforting sign as it suggests they might actually be a decent data validation of some sort.

Data Structure

What I've established so far is that this is MSB first and contains:

• 8-bits of preamble 1's, followed by probably 3 bits of sync, but might be 1 bit and 2 flags or similar
• 8-bits Start up ID / Rolling Code. This effectively gives a device a unique(ish) ID every time it's powered up.
• 12-bits of 2's Compliment Temperature in 1/10'ths of a °C
• 8-bits of unsigned Humidity
• 8-bits of unknown data which does not change for the same readings, but changes significantly for even single tick changes - strongly suspect this is a checksum of some sort. UPDATE: It is indeed a CRC8 as found by Luc Small.

This is certainly a big improvement on recent protocols. This one actually features a useful preamble, some attention to DC balancing, plus all important validation.

Another nifty trick it does is sending multiple packets after power on and after a while it gets less frequent and drops to a single packet at a time at a regular rate. After all the first thing anyone is likely to do is want to see that it's transmitting and get it synced with the receiver so transmitting more frequently soon after power suggests some care beyond pure functionality has gone into this design.

Accuracy

I'm pleased to say that in my rather unscientific tests by putting bunch of sensors and other instruments in the same location, this one is right in the middle of the tight cluster of instruments I trust. In fact humidity is exactly as other more expensive instruments are reading and temperature within 0.3°C of the expensive one which is marginally closer to a heat source so they might actually be exactly the same if the test was tighter controlled.

Reassuring, even if it is only a sample of one. I might well buy some more of these for different rooms since they give me a good level of confidence for the price.

One thing to note though is that this is relatively slow to respond compared to the Imagintronix which will be settled again within one tick after a ~20°C step within about 90 minutes, whereas this sensor seems to take double that or more. Not surprising as the air path and bulk of material around the Imagintronix are much less than this one where the sensors are well inside the cavity of the body of the device with gauze protecting the air path which will also slow down the airflow significantly - effectively, it's well insulated.

Update: Accuracy of humidity appears to have deteriorated with time, and I'm having to apply large calibration factors to get this in line with other devices. It also appears to suffer from significant hysteresis with humidity now.

WH5 ... same protocol, different package

I've discovered that the WH5 uses almost exactly the same protocol as the WH2 even if it looks very different (like the WH15B, except the printing on the battery cover):

The only difference is that the temperature is represented as T + 40 in the WH5 where it's 2's Compliment in the WH2. Like the WH15B this device is fast responding, but initial accuracy compared to other sensors is not as good as the WH2 new, but more in line with the WH2 now that it's aged a bit.

The problem here is that there is nothing in the data to indicate if it's from a WH2 or WH5, so the only way I can handle both is for each transmission to generate data for both with the different temperatures. It's then up to when you use the data to pair the model and rolling code to select the appropriate one.