Yale Smart Home Alarm – That review no-one seems to have written…

(Referenced product: Models SR-3xx)

I have owned one of these alarm systems for about 12 months now, and am finding myself increasingly frustrated with it.

To give a brief overview: The physical alarm sensors and control hub are an ODM product by Climax Technology in Taiwan (its original model number is MZ-1), this part of the package is quite well engineered. There are some tiny issues with the firmware on the control hub, but these could easily be fixed, provided that Yale ever asks them to. Here is the manual from another vendor who sells it, and we can see that it has an awful lot of handy features, but don’t get too excited, almost none of that is included in Yale’s cut of the product.

What really lets the package down is the App, which is the only way to interact with it. Despite two updates since I purchased, none of the issues I originally found/reported have been addressed, including the worst of them all: Excessive battery drain – which in the latest update, is now even worse. I strongly suspect it is developed by a different party, as in the case of other vendors, a smartphone app is not included.

I speak only from the point of view of having used the Android app, so cannot comment on the iOS edition, but can say that the two are functionally identical. There is little point in me detailing all the issues, as that has been done at length on the Google Play reviews.

Instead I would point any prospective buyers at what I think is the most significant pitfall of this product – that very attractive upfront promise: No monthly fees.

It’s true, you don’t pay anything per month, but quite frankly, I’d be happy to spare £5 a month for an alarm system that works and is issue free.

With every man and his dog wanting an app for something-or-other these days, app developers have become rather sought after, and therefore very expensive. Many work for app companies who also expect their own profits – Yale not being a company I would expect to have a large tech apparatus, It’s likely they are dependent on one or more such firms for their apps. This is bolstered by the observation of customer services using the term “Product Managers” instead of “Developers”, in reference to who issues are going to be passed on to.

That having been said, it’s not surprising, that Yale with only a bit of margin on successive retail sales to spend, has not got much to splash out on bug fixes, let alone adding all of the new features people are already asking for, ironically in many cases, features that the original package from Climax already supports.

My advice to Yale: A lot of people have expended significant effort physically installing one of these kits into their homes, and they’re clearly not happy. Get the issues fixed. You know what they are. If budgets are as tight as they appear to be, don’t even think about adding more features until what’s already there works properly.

Will we ever get a bug free system? In my case, likely not before my patience expires.

MC34063: A tough lesson

As a keen electronics hobbyist, I have designed some 50 or so PCBs to date. In each instance where a switching regulator is required, I’m typically reaching for one of two options: Where efficiency isn’t important – the trusty old LM2596, or when efficiency is required, I’ll be using a design from Linear Technology with synchronous regulation.

On my last two boards however, for reasons I am myself not entirely sure of (cost perhaps?) I used an MC34063. It’s been with us since the dinosaurs roamed the earth, and is unsurprisingly very primitive. It should have been designated to the dustbin of history, but thanks to the internet and the renascence of electronics in the hobbyist space, it has made an aggressive comeback, and for a simple reason: It’s dirt cheap.

My MC34063 was deployed on the PCB with the above circuit, lifted unchanged from the datasheet. It just so happened that I need 5V at 500mA max, from a 24-28V source. Perfect. What could possibly go wrong?

There is one very important thing we must consider when using this chip: It has absolutely no built-in thermal protection. The above circuit does have over-current protection, but this does not offer any protection from sustained short circuits. In many cases that isn’t a problem, but on this board it was.

From looking at the photo, we can see that there’s quite a bit of burned out stuff, making it a little difficult to piece together exactly what happened. Fortunately it all unfolded before my very eyes. The problem started with something that was nothing to do with the MC34063. See those two rectangular capacitors?  One of them is particularly toasty indeed.

That capacitor is an AVX “TAJ” series 330uF 10V tantalum. It had developed an internal short circuit which caused the MC34063 to gradually heat up, eventually reaching a point where its internals melted, then becoming a short circuit its self.

Once the MC34063 became a short circuit, the 25V input voltage surged straight through to the 5V secondary, bear in mind that, that voltage is coming from a bank of large lead acid batteries.

Both pairs of batteries were protected with battery fuses, but those were 15A a piece, as this is a very high power setup, also on the PCB was a 30A maxi blade fuse. Surely one of those would have blown? Nope. When silicon melts to the point of becoming a short circuit, there is typically still a few ohms of resistance, which in this case was not enough to blow any fuses.

What happens next? BOOM! The short circuiting of the MC34063 unleashed 25V @ ~40A of potential at that shorted capacitor, which promptly exploded, ejecting a significant amount of fire and hot gasses in the process. In the picture you can clearly see the internals of it have become a melted blob of metal, transforming it into a very effective short circuit.

The last phase of destruction was the MC34063 its self burning to a cinder, as it is now the weakest part of the circuit, doing significant damage to the PCB in the process.

It’s at this point that you start recounting exactly what is attached to the 5V rail, because it is likely now toast. The tantalum capacitor must have briefly been open circuit because all 10 ICs fed from the 5V rail were completely destroyed, as well as all of the chips on a second PCB also fed from this regulator, requiring hours of rework to replace them all. Just as well there was nothing expensive connected to it.

Lessons learned

  • When using an MC34063, or anything else without built-in protection – short out its output for a few minutes and see what happens. If you find yourself staring at a mess like the above, sort it out. Don’t ever assume it won’t happen.
  • In cases like this where the system is fed from batteries, protected by large fuses – add a second smaller fuse i.e. 500mA before small circuits like this.
  • In my case I have ditched the MC34063 and replaced with with a Wurth 173010542 7805 switching drop in replacement. It gets me a 5V output with 90% efficiency, over-current and over-temperature protection. Not cheap, but when you are talking about stuff that could start a fire…

An easy way to mount DS18B20 temperature sensors


One of the biggest advantage of these sensors over I2C sensors, is that you can mount them almost anywhere. That having been said, I’ve never quite managed to come up with an elegant solution, particularly when attaching to a heatsink (for cooling applications).

Typically I find myself drilling 5mm holes in pieces of aluminum, then stuffing the sensor in that hole, or using small metal clips, which aren’t always reliable.

One solution I looked at using the aluminum heatsink clips from vintage TO-92 transistors i.e. 2N3403 and 2N4425. These are absolutely perfect but unfortunately the clips aren’t purchasable without the transistor. Sadly these parts are no longer in production and becoming increasingly rare. Destroying them to scavenge thier heatsink clips is a little senseless.

Some old TO-92 transistors came with rather nice heatsink clips

Without wanting risk the wrath of the world’s remaining Ham Radio enthusiasts… What other options are there?

I recently had the idea of using ‘Yellow’ (6mm) ring terminals with 3.2mm holes:

Perfect! All I had to do was remove the plastic band, cut the crimp and open it a little, add a little heatsink compound (to be pedantic), then gently crimp the sensor in place with pliers.

This has turned out to be a robust and inexpensive solution, as those terminals are made of copper, they conduct heat very effectively. I wish I had thought of this a decade ago.

Putting a little heatshrink over the final assembly makes for a good finishing touch.

ROVAEdit Readme published

When I first started work on ROVA Tools around about 7 years ago, RTD2120+RTD2545 based platforms comprised the majority of the hobbyist LCD controller market. I personally spent a lot of time learning about them ultimately creating a firmware editor for that platform. These days RTD2660 based platforms now dominate, with ROVAEdit largely now forgotten.

I will never create a firmware editor for the plethora of RTD2660 boards now available, because there is no point in doing so. The source code for these boards is readily available.

ROVATool however, which was created at the same time, and now supporting RTD2660 still gets around 300 downloads per month, which is a small consolation.

I always meant to write a comprehensive guide of everything I’ve learned about LCD controllers, but ultimately realised that very few would be interested in reading it, so never bothered.

The ROVAEdit readme is the closest I ever got. So here it is.

A simple low battery detection circuit with hysteresis

I recently found myself needing a simple circuit which could detect a low battery condition of a sealed lead acid setup, but also with a hysteresis function i.e. don’t re-enable the output until the battery voltage rises to a certain threshold.

The internet is practically exploding with low voltage detection circuits but many are quite complicated with exotic ICs and other fussy details.

Geez man. All it takes is a single comparator and a two resistors (three for hysteresis).


Okay so my circuit has a little more, that is because making something that is actually useful requires a bit of extra stuff.

With the above component values it will cut out at 11.2V and re-activate at 12V, which is good for most sealed lead acid batteries. There is also second comparator – this is purely acting as a logic inverter, because I needed a negative logic output. If you don’t need it, leave it out. One of the cheapest and most available comparators – the LM393 has two units anyway, so this works out well.

The main guts of the circuit is R1, R2, R3 & U1A. R4 & R5 are a simple voltage divider to get the input voltage inside of the 5V operating range of the comparator. R6, R7 R8 & R9 should be left as is.

The math

Because I’m using fixed resistors, I’ve worked backwards, from a ‘components first’ approach, simply working out the formula for the circuit then plugging a variety of E24 resistor values in until I got what I wanted. I find this easier than working from a ‘results first’ approach i.e. starting with the desired voltages, to then being told by your workings you need a whole bunch of resistor values that don’t exist!

  • VCC (Constant – 5.0): The output of the 78L05
  • VL (Constant – 0.1): The voltage the LM393’s output transistor can pull down to. Yours may vary. The expression containing this term can be omitted if you are happy to call it zero.
  •  VIl: The low battery input threshold voltagevil
  • VIh: The high input threshold voltage i.e. re-enable output when voltage reaches this level


If you wanted to adjust my thresholds, assuming a 12V setup, focus on R1, R2 & R3. Leave R4/R5 as is. If changing to a different voltage / type of battery, then R4/R5 need to be adjusted to bring the voltage at pin 2 within a 2-3 volt range.

Making use of recycled Xilinx XC9500 CPLDs

If you happen to be producing boards which use Xilinx’s long discontinued classic 5V CPLDs which are purchased as scrap from the far east (which I hope you are not); You may have found that getting quality samples is not so straight forward.

The situation is not so bad for smaller devices, but for the larger ones, it’s tough. One of my projects (8OD) is stuck with the XC95216. Being a 100% 5V design with a swag of 5V bidirectional I/O pins, converting to a modern 3.3V device is completely out of the question.

Without the spare time or willingness to adapt the design to an inevitably ridiculously expensive alternative; I have been dependent on purchasing recycled chips from the far east (typically sold on eBay or AliExpress).

In terms of what arrives in the post, it’s a mixed bag. I’ve had perfect genuinely new batches, and other batches which are in poor physical condition (i.e. scratched, pins bent / missing).

To frustrate matters further, the best (absolutely perfect) batch I received then prompted me to make a second purchase from that same seller. But upon arrival of that parcel, I quickly see that it was sent from a different address, different packaging. Surprise surprise… Some were clearly scrap, and most of them were dead.

Here is a sample of the kinds of errors I find when I assemble boards when dead chips:

Completely sodding’ dead

When dealing with properly dead chips we sometimes see an error like this from iMPACT:

PROGRESS_START - Starting Operation.
INFO:iMPACT:583 - '1': The idcode read from the device does not match the idcode in the bsdl File.
INFO:iMPACT:1578 - '1': Device IDCODE : 00000000000000000000000000000000
INFO:iMPACT:1579 - '1': Expected IDCODE: 00101001010100010010000010010011

I have also seen iMPACT spit out messages like this when attempting to connect:

Less than healthy

I have seen quite a few that sort-of work, but fail on the identification stage, like this:

Identifying chain contents...INFO:iMPACT:1585 - '0':The part appears to be of type xc9500, but could not be identified correctly .
'0': : Manufacturer's ID = Xilinx unknown part, Version : 1
INFO:iMPACT:1111 - Can't locate bsdl file xc9500.bsd.

This is quite a curious error, as I have had chips, both from the same batch, identical markings etc where one identifies OK, but the other has a bit or two twiddled (i.e. version as shown here).

Avoiding wasting your time with dead chips

I have spent a lot of hours checking soldering, voltages, JTAG signals on my scope etc, all to no avail. I do not know what is involved in recycling these chips but whatever the process, a crapload of them don’t survive it.

Quite how so many end up dead leaves one to ponder, because from my own experiences, they are pretty robust. I have some XC95216’s that have been carelessly soldered/de-soldered 5 times or so by myself, zapped with large electrostatic discharges and even those survived! Perhaps these chips are typically removed from equipment with a propensity for suffering lightning strikes? Are they de-soldered with a flame thrower?

A quick google image search for “Guiyu” gives us a hint of what this business is like. My own guess it that they are killed with excessive temperatures during de-soldering.

Rule of thumb seems to be, if it can be successfully programmed with iMPACT, it’ll work. I have not yet found one that then went on to fail the burn-in test.

And on that note, I took the time to build a simple rig to weed out the duds:


It’s a blank PCB with power, decoupling and JTAG components fitted. I then use a small clamp to press the CPLD onto its footprint on the board, with a block of polypropylene and a layer of adhesive felt to ensure even pressure. To keep it extra high-tech – I’ve also got a pad of post-it notes underneath.

As much as this may not appear to be a reliable mechanism, it most certainly has proven to be. I happened to have preserved a tray of known-good / known-bad chips and when I tested them with this, the good chips – even those weren’t very well cleaned up (i.e. still some solder on them) verified perfectly in this rig.

Last but not least:

If you end up with a bunch of dead chips, use buyer protection to get your money back.

This is a lot easier on AliExpress than eBay

At the very least we may be able to entice recyclers to be a little more cautious.

Building an AT2XTKB (AT to XT) keyboard adapter on prototype board

If you like me you find yourself wanting an AT2XT adapter, you may have also discovered that they are not too easy to buy pre-made.

Project information here

Here is one I built on prototype board, using an AT to PS/2 Keyboard cable:


Without the IC Socket on it, it looks like this:


Once the IC Socket is fitted, the tails from the AT to PS/2 Keyboard can be attached like so:

topI forgot to preserve a trace to connect the shield on mine, so I’ve had to connect that through that black wire separately.

Here is the underside:

undersideIn my case I used a PIC12F675 (which needs different code)

The last thing to do is wrap it in heatshrink tube:


A modified and compiled version for PIC12F675 can be downloaded here. I just fired it in with my Universal programmer, plugged it in and it worked perfectly first go.

If yours is using a PIC12F629 like the original design, get the firmware from the original project information page.



Getting rid of that darn Device Information dialogue in Xeltek’s SuperPro programmer software

A little while back I purchased Xeltek’s SuperPro 610P Universal programmer.

It has the odd quirk, but overall it’s done the job. There is one thing however that has always irritated me about this product – This damn thing:

sp0Every time you start their application, or change device, you are prompted with this absolutely f–king useless dialogue, having to dismiss it every time, worse still, it has no OK or Close button. Even more annoying, there is no option to disable the displaying of it in the first place.

Hell, even if there was any useful information on it, that doesn’t mean I want to see it every single time I use the SuperPro!!!

I contacted Xeltek’s customer support about that, they had me go to the trouble of sending my invoice and serial number to them to prove that I in fact had actually paid them a sum of money, and then promptly did absolutely nothing about it, other than tell me that it could not be disabled.

Despite how simple it would be to even change the software to provide an option to disable it, repeated requests to do so were ignored.

Righty. Time to do something about this. 30 minutes behind IDA later we’re onto it. Quickly I can see it is written on the very same tech I cut my own teeth on: Microsoft Foundation Classes (MFC).

Given this, it’s pretty likely that we’ll see a call to _AfxPostInitDialog() at some point during the displaying of a dialog.

Let’s put a breakpoint in there, and bingo! Hop back up the stack a little, and there I find the offending instruction:



The highlighted instruction is in code written by Xeltek, and calls a function which displays that dialogue both when the application starts and when the device type is changed, but not when the “Dev. Info” button is pressed (in the unlikely event I actually want to see that bloody useless dialogue).


So all that needs to be done is remove it.

In the current version at the time of writing (the version dated 07/21/2016) that instruction (opcode 0xE8) and its 4 byte operand is physically located at 0x3373F in SP6100.exe. Replace it with 5 NOP (0x90) instructions, and we’re good.

Now that dialogue is only displayed when the “Dev. Info” button is clicked, which is all I ever wanted to begin with.

Feel free to contact me if you want the patched EXE!

6Gb/s SATA 3.0 over eSATApd (12V/5V) cables

A number of years ago I came across an eSATA cable system known as eSATApd (5V/12V) DeLock was the first vendor I am aware of which sold these products. The key feature with this system is that it carries +12V with no mandated current limit. This makes it possible to power 3.5″ external hard disks from a PC without needing that pesky power brick.

Not DeLock or any other vendor produce enclosures that make use of this system, but that’s fine. They do sell the eSATApd connector and I’ve been modifying (in some cases, their own) enclosures for years to accept eSATApd power input.

DeLock 3.5" HDD enclosure modified with eSATApd connector to allow power-brick-less operation
DeLock 3.5″ HDD enclosure modified with eSATApd connector to allow power-brick-less operation

Recently I upped the ante by modifying a 2 bay RAID enclosure (using RAID 0) to accept eSATApd so I could power the entire enclosure from the PC. As you can typically get 12V/3A across these cables this should not have been a problem.

StarTech.com RAID enclosure modified with eSATApd connector, allowing use without the power brick
StarTech.com RAID enclosure modified with eSATApd connector, allowing use without the power brick

Except now I needed 6Gb/s SATA in order to get the benefits from the increased performance of the RAID 0 array. Suddenly, I’ve got a bit of a problem: These cables do not work at 6Gb/s.

This wasn’t entirely surprising to me. The specification for SATA is pretty clear about cables: The correct cable is a distinctive 100Ω impedance, flat twinaxial cable, whereas the DeLock/LINDY cable is a fairly thin and flexible round cable.

An actual SATA cable showing the foam dielectric twinax data pairs

Another point that SATA-IO are clear about, is that there is no such thing as a 6Gb/s SATA cable. Cables that were properly designed for the original 1.5Gb/s interface should work just fine for 6Gb/s.

Notwithstanding this, I’m already suspicious about the construction of these cables. Let’s take a look at this one:

First revision DeLock/LINDY eSATApd cable

As the DeLock cables I purchased are now pretty much useless to me, Let’s cut one open and see what’s in there:

First revision DeLock/LINDY eSATApd cable

Well that clearly isn’t a very SATA looking cable. What appears to be in here is a couple of foil shielded PVC coated pairs of the same kind of construction that would be used in an HDMI cable.

Allow me to get out my Paint-fu to draw a little diagram of the two styles of cable:


That’s a pretty significant difference in design.

But despair not (?) DeLock seem now to be selling a newer version of this cable, which I’ve got a couple of. It’s a lot bulkier, with two fairly rigid cores bonded together. Perhaps this newer cable works at 6GB/s? Why else would they change the design. The old design, being thinner and several times more flexible, was a lot nicer to use.

Second revision DeLock eSATApd cable
Second revision DeLock eSATApd cable

Nope. This cable also doesn’t work at 6Gb/s. The system in most cases can’t detect the drive, and when it does detect it, file transfers frequently fail.

So now I’ve got another useless eSATA cable. Let’s cut this one open and see what’s going on:

Second revision DeLock eSATApd cable

From what I can see, the core on the right is a “Powered USB” cable, this is typically used in conjunction with a specially designed connector for Retail/POS terminals which have a higher power requirement. This cable carries the +12V, +5V and USB 2.0, and is the correct type of cable for the USB half of this application.

The cable on the left is the one of interest as it carries the SATA signals. It appears to be of exactly the same construction as the previous edition of the cable – two foil shielded PVC coated pairs.

Whatever the reason these cables don’t work at 6Gb/s, they both have the same problem.

Success at last


After hours of frustration – I found a very interesting looking cable on the U.S. Amazon site. Sold by “Micro SATA Cables“, it’s the first I’ve ever seen which uses proper SATA cable, bonded to a power cable. This is what I was looking for. Fortunately Amazon U.S. ships internationally, a week later I got a couple to try out.

Micro SATA Cabled eSATApd cable working at 6Gb/s
Micro SATA Cables eSATApd cable working at 6Gb/s

They work! Reliably sustaining the ~350MB/s my 2x6TB RAID 0 enclosure is capable of, and clearly surpassing the ~225MB/s limit of 3.0Gb/s SATA.

I don’t need to cut this cable open to know that it’s correctly designed. Aside from it actually working, the data wire is clearly labelled “Serial ATA”, and it also physically looks like SATA twinaxial cable.