It's the season ... to automate

I don't celebrate Christmas but when there's an electronics design opportunity in it I don't complain. There are these Christmas lights which I have to switch on at night and then switch off before midnight. This is a nightly task which will go on till the end of the year. Well, as can be expected there are times when I'm not around to turn the lights on and there are days when I simply forget. And there has been at least one occasion when I forgot to unplug the lights from the outlet (that's what serves as the switch).

Got fed up so I decided to automate it. What I needed was for the circuit to know it's dusk, turn the lights on, keep them lit for several hours, and then have them off until dusk the next day. This is a temporary circuit--one month and it won't be used anymore--so I decided to just keep everything on a breadboard. I also decided that it would be best to keep the main electronics indoors with only the "dusk sensor" somewhere outdoors.

In a nutshell this is how the circuit works. The dusk sensor outputs an analog voltage proportional to the ambient light level. This is fed to a microntroller which switches the load when light level falls below a value determined by the user. After a preset time duration the MCU turns off the load.

The sensor is a simple voltage divider using an LDR and a 300K resistor. Its output is fed to an op amp configured as a voltage follower. The ultra high impedance of this buffer prevents any loading of the signal. The op amp output is then sent to one of the MCU's analog input channels. The analog signal gets digitized by its ADC. The MCU compares this value with the trip level selected by the user. The trip level is adjusted using a 10K potentiometer whose output is connected to another of the MCU's analog channel.

I've chosen an 8-pin Microchip PIC12F615 because the circuit needs only two inputs and one output and I need those inputs to be analog channels. I could've picked one from the PIC10F series but I don't have software to program those in C. I'm just not in the mood right now for assembly language. I have about half a dozen models of single-supply, rail-to-rail Microchip op amps around here. I just opted for the MCP6273.

Because there may be abrupt and transient changes in ambient light level (lightning flash, car headlamp glare, prankster shining a flashlight, etc.) it is necessary to make sure that the sensor/circuit ignores these changes, else intermittent switching of the load occurs. This can be done via hardware by adding a few components--a capacitor, diode, and maybe a resistor. It can also be effected in firmware. The latter is what I opted for--why put to waste all that MCU computing power and memory?

I developed an algorithm for this two years ago and is based on moving averages. Readings are taken at fixed intervals (one to several seconds apart--the longer the interval the more immune to transient changes in light level). Each reading is compared to the previous average. If it exceeds the average by a predetermined amount (meaning there has been an abrupt change in light level) this reading is replaced with the average plus or minus the maximum allowed change (added or subtracted depending on whether the light level has increased or decreased). Thereafter, the last eight readings are averaged and compared to the trip level. If this new average is below the trip level then the MCU turns the load on. A hysteresis value (deadband) is incorporated such that the average light reading must increase beyond the trip level + hysteresis before the firmware resets a flag bit which keeps track of the transition from light to dark and dark to light (analogous to the rising/falling edges of a square wave). If the light level is between the trip level and trip level + hysteresis, then no action is taken.

Power supply is an adapter from my collection of old chargers, adapters, and the like. The one I found suitable is an Ericsson phone charger. It's probably a linear supply--cubelike and heavy, implying a bulky transformer. Its output is around 5.3VDC which drops to around 4.5V when the gas guzzling DC relay (40-ohm coil) is connected. I didn't even bother using an oscilloscope to check ripple voltage. I just used the multimeter to see what the DC voltage was with and without the load. To help Ericsson along I added a 1000uF 10V filter cap. This pulled up the with-load DC to 4.8V. Fortunately the relay still functions at barely 5VDC this adapter outputs. A diode (D1 in the schematic) was placed in series to drop the supply to the chips to <5VDC just to make sure they'll be operating within their supply limits.

The MOSFET transistor I used to switch the relay is a 2N7000. Relay is an Idec 4PDT. Coil: 6VDC, 40-ohms. Contacts: 250VAC 6A. It's plugged into a socket so all the AC and DC wires can be conveniently screwed in and safely secured. I added LEDs to provide visual indicators for the status of the load. A high efficiency blue LED that requires only a couple of milliamps to be visible was used to indicate "on." This choice was made in order to reduce the total current load on the power supply when the relay is on.

The main breadboard and relay were plunked into a plastic box. The sensor was also put in its own small translucent box and situated outdoors some 10 meters from the main electronics. So far so good. I adjusted the potentiometer so the load turns on when the streetlights have already been on for some 15 to 30minutes. The circuit works as required and the MCU timer is right on the money, turning the load off in almost exactly 5 hours even if it's only using its internal clock oscillator.

I love these tiny microcontrollers.




Click on the schematic.

Telephone signals

Took the Rigol DS1102E scope and connected the probe to my home telephone line. I obtained the following readings. Click on the image to see a more legible version. Do keep in mind that dial tone, ringing, busy tone, and off-hook warning frequencies (and cadences) vary from country to country. So do voltages and other parameters. Seems like a free for all.

1. On-hook, telephone on standby. When the phone is not being used, the line is at 48 volts DC.




2. On-hook, phone ringing.



In the screen shot above the cursors are on and I've adjusted them to measure the DC voltage right before the ringing signal. You can see at the top right inset (delta Y) that the voltage has jumped to 54 Volts right before ringing.

The amplitude of the ringing signal itself is shown below measured. The value (delta Y) is 132 Volts peak to peak. That's around 47 Volts RMS (132/2/√2) riding on top of the 50 or so Volts DC.



I switched to split screen mode and both ringing signal and its frequency spectrum as obtained through the fast Fourier transform (FFT) function are shown below.



The same in full screen mode:



As you can see cursor A reads 20.8Hz. That's the ringing signal frequency


3. Off-hook, dial tone:



Like the ringing signal the dial tone is also a sine wave, but this one has high frequency noise riding on it. The cursors are on and you can read off the peak-to-peak amplitude which is around 350mV. The FFT function was turned on when I took the above reading and it is shown below.







I changed the resolution from 500Hz to 50Hz per division to get a better view of the peak frequency:



The dial tone is basically a single tone at 420Hz, although during other times I've measured it at 440 to 450Hz. The drift could be at the telephone company's end or somewhere along the transmission.


4. Off-hook, busy signal. I picked up the phone and just waited until the dial tone gave way to the busy signal. That took several seconds. Here's the waveform I got.



The low level high frequency noise to the left of the busy signal is the lull between the busy tone pulses. The purple curve at the bottom half is the frequency spectrum provided by the FFT. You can already see three or four significant blips there. Below are measurements of those frequencies using the cursors.







And a more detailed look at those:





So what I got were prominent signals at 480Hz and 620Hz with smaller signals at 1.9KHz and 2.0KHz. The latter two may or may not be actual components of the busy signal.


5. Off-hook alert. After several more seconds the busy signal gives way to the loud off-hook warning tone, which is screaming, "Hang up, you idiot!"



As you can see the maximum peak-to-peak voltage is approximately 460mV. The waveform along with the frequency spectrum:



Frequency spectrum measurements:









A closer look at those frequencies:







The most significant frequencies are 1.4KHz and 1.8KHz. The amplitudes of the 2.0, 3.2 and 3.6KHz are rather small. These may or may not be part of the off-hook alert signal.

Minuteman computer and the Tektronix 465B

Jim Williams, electronics engineer and author of The Art and Science of Analog Circuit Design.

Online lectures on electronics

Just stumbled on the following treasure. The National Programme on Technology Enhanced Learning (NPTEL) has hundreds of hours of recorded lectures on electronics and electrical engineering and other subjects as well. Watch them all on Youtube.

I just love lectures ... sans the exams of course.

You don't get what you don't pay for

Sigh. Repeat after me: You can't have your cake and eat it too. You can't have your cake and ....

I've been test driving the Hi-Tech C Pro compiler for the PIC MCUs and much as I am thrilled that it works under MPLAB and is being offered completely free (Lite version) without firmware size or time period restrictions, I must say that the lack of optimization in the freeware version is rather depressing. The code it produces is quite inefficient.

For instance, for the PIC 10F20x series, for the given a static global variable the C statement "POTATO++" or "++POTATO" is translated into assembly by Hi-Tech Lite as follows:

MOVLW 0x1
MOVWF 0x13
MOVF 0x13, W
ADDWF 0x1e, F

Am scratching my head. Why the two middle instructions? Why not cut to the chase and have:

MOVLW 0x1
ADDWF 0x1e, F

Or better yet, why not just

INCF 0x1e, F

Wasting two to three bytes and instruction cycles in an MCU that has only 256 / 512 words of program space is just crazy.

I know I'm making a hasty conclusion but this one example of utter wastefulness shows me why this is freeware. I'm wondering how the versions with "Omniscient Code Generation" will compile the above. Hopefully you do get what you pay for.

More on that timer

Modifications made to the timer:

• New "wall wart" power supply. Oscilloscope test of output shows it has no filter capacitor so a 470uF 25V electrolytic was added to the board. No-load voltage with filter cap was >20VDC.
  
• Added a LM78L12ACZ and LM78L05ACZ voltage regulator
• A 1N4002 was added as a safety feature in case power supply polarity is inadvertently reversed.
  

Here's the schematic:


MCU = Microchip PIC 16F785
Q1,Q2 = S9012 PNP transistor
Q3 = 2N7000 MOSFET transistor
XTAL = 32.768kHz crystal
7SEG LED = ELD-306IDB dual 7-segment LED common anode
all resistors 1/4Watt 5%

I've installed the timer in my aunt's kitchen. Much to my chagrin the volume of the buzzer was not close to earsplitting. Although as with any sonalert buzzer, it will surely be heard tens of meters away.

The timer's dead; long live the timer!

Two years ago I installed a countdown timer at my sister's apartment. The user can set the time anywhere from 1 to 99 minutes. After the countdown is over a Sonalert buzzer will blare. The alarm has three stages, each with successively higher duty cycle. It begins with gentle fractional-second beeps so as not cause a heart attack. Each stage runs for approximately 10 seconds.

The engine that drives the timer is a 20-pin Microchip PIC 16F785 microcontroller. For user interface the time has a two-digit 7-segment LED display and two momentary contact buttons. Pressing the UP/DOWN button for a fraction of a second will increment/decrement the readout by one; keeping it depresed will increment/decrement the reading by 10. If the readout is not zero and no button is pressed for around 4 seconds, countdown begins. Once countdown has started either button will abort the count and readout will be zeroed. If countdown is allowed to run its course and the buzzer starts sounding, either button will turn the alarm off. When readout is "0" for some 16 seconds, readout will be blanked and MCU will go to sleep. Pressing either button will wake it up.

Although my sis has almost never used the timer (all that effort soldering the dang thing for nothing!) I just found out it doesn't work! The only reason I discovered it's on the blink is that I took it down and was going to give it to my aunt. She found out I have a timer in my home (practically the same design but has some improvements) and she says she needs one too.

To cut to the chase, it turns out the power supply is dead. The PSU is an Ericsson cell phone charger model AA21990 which has an output of 5.1V 450mA. To add to the trouble, while testing the timer using a working PSU (not an Ericsson) I discovered that the MCU was running very warm. Now that's bad! The timer was working fine, meaning the MCU was still running the firmware, but somehow or other there was a short or a quasi short somewhere. I inspected the solder side of the board but it was fine. I cleaned the board just to make sure. Finally in desperation I took out a new 16F785, burned in the firmware, and dropped it in the DIP socket. Well, what do you know? The original MCU was fried as well!

My guess is that the PSU must've taken the MCU with it when it burned out.

I tried reprogramming the MCU. This PICkit2 says it has a Vpp problem. At some point it couldn't even detect the device. Guess that's it for that chip. Its time is up!

I'm modifying the circuit before installing it in my aunt's home. Instead of being powered by 5VDC the buzzer will now be operated at 12 volts. That increases the alarm volume considerably so it can be heard even in the next room with the door closed. It's going to be earsplitting in the kitchen.