I said before one of the devices I wanted to get was an independently switched extension - well this is the one I chose in the end. There wasn't a lot of choice when you look into it closely. The other options I found had a number of flaws:

• High Standby power consumption. As these are almost always sold for reducing standby power of appliances, this particular thing is often not spec'd until you receive the item and it's on the paperwork in the box. If you do some research there are grumpy people in forums / reviews complaining about having bought a device to reduce standby which actually uses more energy than the appliance on standby in the first place.
• Most extensions are have one common switch for all sockets - may be OK for some (eg. turn off all the components in a stereo at once) but I need to control things individually
• Some extensions have toggle controls (press once for on, again for off) which for home automation like this is high risk. There is a chance that the remote does the toggling, but if not there will be no way to reliably know when the Home automation sends the off command if the socket actually turns off or on.

As well as ticking all the technical requirements boxes, the bonus is that this lead is actually not badly priced. That's the good news sorted, now let's look closer.

It's black, but not really black - it's actually white with a really poor quality black paint job. Scuffs (yes, out the box), gouges round the screw holes from assembly, not properly covering the seam round the sides, etc. show the white plastic underneath and it's ugly. I'm sure it's also going to look much worse once there is wear around the sockets.

As if that wasn't enough there was something loose inside - I always fear something metallic that one day will short something internally. A friend won't use a new extension lead before he's opened it and made sure all is safe - probably very wise. I managed to rattle it around until I got the bit out - plastic fortunately, but it turns out it was part of a plastic plug for an additional hole in the side and the rest of the fragments of the plastic plug were in the packaging.

Again, nothing to inspire confidence. Inspecting it myself is going to be a hassle since it's assembled with security screws.

It does actually do as it says and the remote control turns each socket on and off - result!

There are some "nice to have" things missing: indication of what sockets are On (eg. LED for each), manual control.

This Mercury extension does look suspiciously similar to the (white) Philex Ecopower 76944R - no idea if they are related in more than appearance. There is also clearly some sort of "3 leaf" logo under the paint:

I can only guess this is some re-branding / white-label stuff going on as often the case, often even with some well known brands.

Intelligence gathering

Nothing significant to go on this time - we know it's 433MHz (despite some sites saying IR) and got individual switching with separate on and off buttons. I'm working blind otherwise.

Baseband Signal

Logging the signal from the remote with my Home Automation code I got something that looks like this:

What can I say... yet another horrible protocol. Like the STATUS plug we are using a pulse width scheme, just at a much higher rate: ~140us/580us pulses at a ~720us period. The gaps between packets are ~5ms... and little did I know how important this would turn out to be.

The fundamental problem here is this kind of encoding makes it very difficult to get a receiver operating reliably. Ideally we want to set a threshold down the middle for maximum noise immunity. We want to be tolerant to signal strength so that should not be a fixed threshold. This encoding means that with DC blocking in the receiver thresholds are going to be shifting all over the place and there is insufficient preamble to ensure everything is stable when we reach the data.

For example, on the initial bit the threshold is going to be following low, then hits the initial pulses... but those have a very low duty cycle so the threshold will remain quite low which is not the ideal for best noise immunity (who knows if these pluses on the initial packets can even be resolved, especially at long range), then we hit some more stable region where we probably do quite well, finishing up with the threshold being quite high at the end - not a nice clean stable "down the middle" run.

At this point we've got only 1 in 4 devices that I've looked at that have a well engineered protocol.

Data Structure

Based on the above encoding I leveraged my existing PulseWidth decoder class with a configuration for this faster rate and recorded the pattern for each of the buttons as well as 10x power on to check for any rolling codes.

As expected this is trivial and nasty, though in this case unexpectedly weird and pointless as well. Same as the STATUS socket it's 25 bits all together, but this time appears to be MSB first... not that that makes any real difference:

• 5-bits of 0's as a preamble
• 5-bits: 10101 as a sync.... presumably
• 10-bits of button and address data (see later) MSB (B=Button) first
• 4-bits of state (on/off) data: 1100 for off, 0011 for on
• 1-bit of 0 and the end (stop bit)

Now, that button and address data. The first bit (transmitted) is the 5 Buttons (either on or off), the second will either be the same as the state of the bit before, or a '1', and that I guess depend on the address that appears to be set with a solder blobs across pads on the remote control PCB.

So we're looking at 5 bits of address, but think about this.... the address bits interleaved with the button bits actually depend on the adjacent button bit.... so actually the address bits vary depending on what buttons are pressed. That then means that for the particular button being pressed the corresponding address bit becomes irrelevant (always a 1). Through the whole (tiny) address range there are plenty of combinations where some buttons on the remote will emit the same code as a remote with a different address. That's the weird and pointless bit.

As usual with these sorts of things we've got no validation means and with the encoding data integrity will always be a risk.

Unexpected twist

When I wrote the Plug-in for my universal encoder/decoder system I found I was struggling with getting it working with transmission reliably. After examining signals in detail and a lot of head scratching I realized this could be down the poor choices of encoding used. Because of this setup it is going to be a very fragile thing with shifting thresholds etc. and after updating firmware and the control software to verify, it turns out my suspicion was true.

It seems that this device can't reliably receive a single packet. It can't even receive 10 or 20 packets very reliably, unless the spacing is sufficiently close. I would guess it's actually relying on early packets as the preamble to stabilize the receiver enough to be able to actually decode the later packets. It's a very fragile thing and this is why I had to extend the firmware in my system to allow for multiple packets to be sent with precise spacing being done by the firmware (hardware assisted) rather than from the host.

If ever you needed a demonstration of why established good engineering practices for encoding data like this are important, here you have it.