And now for something completely different... besides the bitching & moaning that is normally my forte, as I'm sure I'll find plenty to gripe about here as well.
I came across & built this project from the long defunct magazine, Electronics Today International (ETI) way back in the early 90's - so yeah, I'm getting on a bit!
I loved the concept behind it from the get-go - superimpose control signals onto the mains supply, that could then be intercepted & acted upon by Remote Switches. I also loved the fact that I'd be building from scratch, my own 'real' computer - CPU, RAM, ROM, programmable input via the 6-button keypad, output in the form of the control signals that were being superimposed onto the mains and finally, a nice LCD display to program it with. Yes indeed, a real computer!
The building of it was laid out over 3 issues (1,2,3), and the firmware was available free of charge for the price of a SAE direct from ETI themselves. Construction itself was fairly straightforward, at least as far as getting it up and running. The firmware was tapped labouriously into a Sinclair Spectrum 48K, which was then used to burn a 27C128 eprom via a home-made eprom programmer board stuck precariously on its backside. In fact, this was my first experience with eproms and I actually bought new, specially for this project, the gear required for this, and which I still possess - 2 'black-light' tubes for developing light-sensitive PCB's, 1 UV tube for erasing the eproms, along with the necessary mains transformers to drive them. These I got from two nice old guys somewhere in London, both of whom are unlikely to be still with us, rest their souls.
Anyway, build it I did, and work it did, at least to a fashion. What immediately became apparent, was that the software was buggy - incredibly buggy as it happened! For instance, the unit was incapable of operating for more than a day or so before resetting itself, which resulted in all of the time settings, as well as the time-switch programs, being wiped. There was also the miriad of 'Power failure detect' messages that it randomly displayed, even when on battery power, that suggested that something was awry.
It had hardware problems as well, one of which I have only just discovered, much to my chagrin. The first involved the pulse-width of the 50Hz pulses that were being derived from the mains. This was solved by piggy-backing some additional circuitry onto the i.c. involved. The other concerned the crystal oscillator. For going on thirty years, I had always presumed this to be above suspicion. Recently however, the unit stopped working entirely, so after a brief scope-check, I concluded that the crystal had 'finally' died, so ordered a new one. I highlight, 'finally', 'cos at least 20 years previously, I had noticed on a crappy old Gould analogue oscilloscope that the frequency 'appeared off'. I put that down to the crystal also about to expire way back then as well! On swapping out the crystal with a new one, I was puzzled to find that it still would not power on. Checking the frequency, I discovered that it was well over 10 Mhz - the LCD/keypad-i/f was only capable of operating up to 3 Mhz. A quick google, soon revealed the problem - with the component values used, what you had was not a crystal oscillator, but a RC oscillator. In fact, the RC values used completely negated whatever effect the crystal might have had, oscillating at the RC frequency whether or not the crystal was even in the circuit. Using 'sane' values, I soon had an oscillator which produced a beautiful 1.8432 Mhz square-wave - probably for the first time ever!
But that was a present-day discovery. Jumping back 25 years, the real problems all seemed software-related. The firmware as it stood, simply didn't work, so I had the option of tossing everything into the bin, or debugging the software from scratch. The latter was obviously the chosen route, and much to my surprise, it took only about a week or so. I ended up with 8-10 pages of commented z80 code, removed all of the 'fatal' bugs, and discovered & removed 3-4 less obvious ones. A problem I discovered several years on from this, was that, as it stood, the original code did not correctly 'form' the control-codes that were being sent out over the mains. These codes determined which remote-switch was to be activated, the problem being that, say remote-switch number-4 was transmitted, remote-switch number-8 could end up being activated - so, not good! As the entire remote-switch number generation is done via software, this proved a real pain to fix, as it meant that about a dozen eprom erase-burn cycles were necessary before I got it working properly. What I wouldn't have given for an in-circuit eprom emulator way back then!
The one other real obstacle to fixing the firmware proved to be finding 'space'. The original code takes up 4092 of the maximium readable (by the CPU) 4096 bytes of memory - an extra address line would have made things so much easier! So, every time I needed to change something, I invariably had to first go and optimise the original code to gain a few more precious bytes. This proved relatively easy initially, but it has gotten to the point where a very large percentage of the subroutines have been altered. I was eventually reduced to merging individual subroutines in order to limit the number of 'push', 'pop' and 'ret' instructions that were needed.
Anyway, apart from the bug-fixes, and two little 'additions', the original firmware's functionality is still wholly intact. The additions are keypad-related. 1) With the backup-battery connected, it is necessary to physically open the unit (or wait 20+ hours for a Li-ion battery to die!) in order to issue a reset - real tedious! Now, by pressing both 'Sys' keys, the 'Down' key and the 'Entr' key simultaneously, while in 'Clock-mode', the system will be reset. 2) In Setup-mode, to facilitate calibration of the Remote Switches, the unit will normally send 13 'frames' to signal 'On', and 11 frames to signal 'Off'. However in 'normal-mode', the number of frames sent is 16 for 'On' and 8 for 'Off'. Now in Setup-mode, when the Xon/Off option is selected, by pressing the 'Down' key and the 'Entr' key simultaneously to initiate the sequence, the unit will instead use 16 & 8 frames when switching. Number 1) in particular requires a 'knack' to pull off - all keys must be pressed simultaneously - but once achieved, it's easy from then on.
There are a couple of other vexing hardware related problems with this design. One is that while the battery 'trickle-charge' circuitry does work, it will eventually result in the battery being destroyed, due to constant charging. I've been through several already. The other problem almost defeats the entire raison-d'etre of the device. Sometimes, after a power-cut, when power is restored, switching noise will cause the unit to reset itself, losing all stored programs. I'll try to find solutions to these problems and post updates here eventually, hopefully it won't take another 25 years! The original firmware, along with my final revision, is available here for download.
Finally, a word out to Mr Kevin Browne if he's still with us - Thank you for giving us this interesting project way back then - it's kept me interested anyway!
Edit:
A couple of months on, the unit is still on my work-bench, on test, its innards exposed. I was intent on fixing the battery-overcharging problem with the aid of a small DC-DC converter - over-kill, I know - and even ordered a few on eBay. All for naught as it turned out. Using a 9V Li-Ion battery with inbuilt protection is all that's needed, as its circuitry will electrically disconnect the battery when it is fully charged. At least the ones I have from manufacturer Soshine do (good batteries, but take their advertised capacities with a pinch of salt!).
The resetting on power-recovery issue seems to occur only when the backup battery voltage is very low, around 6V, so should only be a problem if the electricity remains off for an extended period (15+ hours with the Li-Ion battery I'm using).
Finally, I found & fixed, hopefully the last 2 remaining bugs in the firmware. Both were trivial display issues that didn't effect the unit's operation in any way. One I was already aware of, the other, would only show itself if the maximum number of user-programs entered exceeded 255 - ordinarily, an impossibility, but zapped anyway.
Addendum.
While perusing my old collection of electronics magazines, I came across a follow-up article in ETI, a few months on from the RCT project, 'critiquing' the original work. As I'd forgotten about it, I'll add it here for completeness, even though, imo, it was little more than a hatchet-job.
Several of the points raised by its author were frivolous, others without merit, while the rest are just plain wrong. For instance, the radical notion of replacing the original regulated power supply circuitry (which works perfectly!) with a 7805 is ridiculous, if only from an aesthetic point of view. He also mentions swapping pull-up resistors, just a few K-Ohms in difference, as being necessary, and tying another pull-up resistor to ground, rather than to the positive rail - both incorrect! In short, almost all of the component choices selected by Mr. Browne work fine, including those used in the various frequency-adjusting circuits.
The one thing he got right involved the 50Hz pulse-width that I've already mentioned above, although just using a different value resistor proved insufficient in my case, as the pulse amplitude gets attenuated below 'logic-level 1'. I chose to include an additional Schmitt trigger, feeding it's output to a pot/capacitor pair, which allows the required pulse-width to then be set with ease & precision.
Edit:
I've spent the last few days removing 2 more original bugs that I first thought couldn't possibly have existed and that I must have introduced - but having checked the original firmware in action, apparently not! Both concerned Program-entry. The big one required a 30+ byte workaround, which I initially thought an impossible fix, given the imposed 4096 byte limitation - but apparently not there too! Most of the space was found within a particular subroutine that was trying to do stuff that wasn't even necessary, the rest of the savings came from re-coding from scratch some other routines. The functionality still remains identical to the original firmware, with zero features having been removed. 2.5 years ago, I was certain I had eradicated all of the original bugs - now I'm even surer! The updated firmware is available from the original link above :)
I forgot to mention, my relying on the Soshine 9v battery's 'protection-circuitry' didn't go according to plan. The protection circuitry appeared to work fine - stick one on a crappy old 9v charger - the type with no proper voltage/current regulation, and it would disconnect itself electrically when charged. However, I've only just noticed that my once new & unused Li-ion battery has developed a 'bulge' from what appears to be from being over-charged! Worse, it's ability to hold charge has also been decimated, falling from around 450mAh to a miserly 180mAh - and all because of my laziness. It still manages to power the control unit for 9-10 hours (down from 21-22hrs when new), so things could have been worse. Maybe it's a result of all the power-cuts we experience around here - once the power reconnects, it will recommence charging. Anyway, here's hoping this alleviates the problem...
As a result, I've finally wired in a little circuit to limit the applied charging voltage to 8.4v, just 3 connections needed, with the 2 power-lines slotting in where R10, the current-limiting resistor used to be, and ground. Better late than never! Made up of a transistor, zener and a couple of resistors. Works ok, although the little bc108 transistor gets a bit toasty when charging the battery from flat - hits around 75DegC. - even so, the supplied current never goes above 60mA.
One other little discovery I've just made concerns the remote switches. Both of the two new builds have proven frustrating to get working properly, and though it should come as no surprise (to me), it's all been a result of those shitty bc108's from China. This realisation came the other day while working with one unit, whose performance was abysmal. Almost as a last resort, I swapped out the first 2 amplifiers, both of whose hFE's were in the 400 range, with 2 whose gains were just over 140 - yep, I was really grasping at straws! Unsurprisingly, I ended up with a door-stop! In one last final act of desperation, I swapped out the 1st input transistor again, but with a replacement that sported a gain of over 700. The result was profound. My once-barely-functioning switch is now by far the best of the three, reliably switching in remote parts of the house where none of the others will even operate. Alas, it was my one-and-only 700+ transistor - despite checking well over 100 'Chinese' transistors after the 'discovery' - so at present I don't have the means to see if this 'fix' would work in the other switch as well. I had & tried a bc108 that had a measured gain of 'just' 500+ ( the old one having been 400+) but it still won't operate from the 'remote' location.
I'm really going to have to source some genuine bc108/9's somewhere. While I realise that 'in-spec' bc108 (and BJT's in general) gains are all over the place, the alarming number of sub-100 gains that I've got through Aliexpress gives one pause for thought. Given my recent post regarding the 2n3819 FET's that I ordered & which turned out to be NPN transistors, right now I feel like ordering from China is no longer an option. It's one thing to be taking a chance and ordering out-of-spec components - like the bc108's I received seem to be - it's another thing entirely when they're labeling transistors as FETs.
