Forget Me Not : eLDERmon Hardware Hacking #2
This post continues with my Hardware modification to provide a 'status' indication back from RF switched Outlets
The first part of the task was tracing the circuit to find the important parts
The main processor IC doesn't include any markings.
Luckily there is an Atmel 24C02 eeprom fitted which presumably uses the same voltage and connects to the processor.
The relay is 24v, and is a good starting point to identify the voltage and ground rails.
The IC's are unlikely to be 24v, but checking against the eeprom datasheet. (8 leg PDIP), you can confirm the ground, and look for a regulator.
The operating voltage limits are also in the datasheet.
This confirms there is a regulator, and the voltage is within the ATtiny85 range, we can plan to connect to the same supply.
Tracing the circuit is a matter of identifying the part, and then tracing where each pin connects to.
It becomes easier once you know the parts, but even if you don't know what the device is, or what each pin does, you can still trace it.
Use a large piece of paper and don't worry too much about being too tidy.
Once you have enough completed (or its too messy), then start with a new piece of paper and tidy it up.
Included with the Challenge is Cadsoft Eagle, so its very useful for drawing a schematic ...providing you know the parts.
I have decided that the main control IC is a 18 pin PIC based on the voltage pins and the resonator.
There are two pins that change when the Outlet is ON, the relay drive and the LED.
You will note the circuit above I elected to use the LED pin.
This was because it already had a pullup (the LED), and had some extra pads available.
As I reviewed the design, it struck me that during the 'learning' mode (where you give the Outlet a code), the LED flashes at different rates.
Rather than code for this, I have decided to use the relay control pin (before the resistor).
In my last Challenge, I had a few problems with programming these very useful devices.
In the end I used a Digispark, rather than waste too much time.
I made the fatal mistake of assuming ....
I knew both the Digispark and the Orblink used the V-USB hack where a couple of 3.6v zeners and a pullup resistor provide the USB connection.
What I didn't realise is they used different pins on the ATtiny85.
So while I had programmed the raw IC correctly, when I tried placing it in the Orblink board, I couldn't talk to it.
To solve that I brought an Tiny AVR programmer
The advantage of this device is that you can use the prototyping pins to connect to the external parts without removing it.
One major advantage of the ATTtiny85 is that you can program it with the Arduino IDE, and apart from the smaller code space, the libraries work.
The ATtiny85 has no facility for an external resonator or crystal, and the clock speed is set during the programming.
But this causes issues since most things are based around the Arduino 16MHz clock.
Even delay(500) is only a 500mS timer when the clock is 16MHz.
The images below show the simple blink program running at different clock speeds.
At 1Mhz clock our 1 sec waveform is 16.5Hz
At 8Mhz clock our 1 sec waveform is 2Hz
At 16Mhz clock our 1 sec waveform is 1Hz (cursor is slightly off)
So the moral of this story is to ensure the clock speed matches, if you are using the internal libraries.
Luckily the Digispark board setting has the 16MHz clock option and is available here.
The libraries all work (or have been tweaked to suit the ATtiny85) BUT the Digispark bootloader allows for the P5 to be used (the reset pin).
So unless you reprogram your ATtiny85, you should avoid using that pin.
I was hoping to have a picture of the hardware installed, but other things transpired and prevented me from doing the installation.
I will do this over the next day or so, but in the meantime Christopher usually does his weekly summary, so it's better to publish now.