Four-way traffic light

Scoured some 20 toy and collectibles stores in search of a model/toy traffic light that I can hack and modify. Not a single one had. Unbelievable! So over the week I painstakingly constructed my own 4-way light out of 12 LEDs, a pseudo-lego piece, the tube of a spent marking pen, an AA battery case, and wires of course. Used cyanoacrylate glue, hot melt glue, and epoxy to hold them all together. Spray painted it black all over.

Not pretty at all. It looks worse than any signal light in Japan after it'd been felled and drowned by this week's Sendai tsunami. Good thing my nephew didn't mind its looks. Just hope it's strong enough to withstand the temblors from a 6-year old.

A Microchip PIC 12F1822 is the brains controlling the lights. To minimize power consumption its internal clock is set to just 125kHz. (This baby is capable of running at 32MHz!). Three AA batteries provide the juice. No current-limiting resistors are used for the LEDs. Measurements show they're not needed for V_DD up to 4.5VDC. Only four MCU pins are used to switch the LEDs. Charlieplexing is employed to turn one LED in each of the four directions for 4milliseconds every 16 milliseconds (25% duty cycle). That's a frequency of around 62Hz--enough to fool the eye into not seeing the LEDs switching on and off that rapidly.

The original design was to power it off two AAs, but tests revealed that even without current limiting resistors the PIC could only deliver 5mA to the LEDs which have forward voltages of 1.6 to 1.8V. Considering the duty cycle is only 25% the average brightness would be quite low indeed. One option of course is to install very high brightness LEDs. I've searched RS Components and found various candidates. A possible drawback is that a number of these superbright LEDs have very high forward voltages, meaning their output will probably dramatically fall off as the batteries are depleted.

The circuit doesn't have an on/off (slide) switch. Instead the MCU goes to sleep 10 minutes after the last button press. When asleep pressing the button wakes it up and the light resumes operation in whatever it mode it was in when it dozed off.

When the lights are on the tactile switch/button allows the user to cycle between four modes:

1. Lights for opposite directions are on simultaneously. That is, when North-South is red, then South-North lights are red too and when NS is green SN is green too. Likewise with East-West and West East.

2. Light is green only in one direction at a time. This implies that for the direction that's green left-turning vehicles and those going straight can simultaneously go.

3. Four-way flashing yellow, 0.8 second on, 0.8 second off.

4. Four-way flashing red, 0.8 second on, 0.8 second off.

Just for fun I was tempted to add a four-way flashing green albeit at a much faster blink rate (say, 2 to 4 Hz). Would allow my nephews to have cars from all directions crashing into each other and getting a pile up. But I eventually scratched that idea--it's not a good way to train future drivers :)

Green stays on for 15 seconds, yellow for 2 seconds.

In modes 1 and 2, when after the light turns red, all directions will be red for a second. The rationale is that (in real life) any crazy driver beating the red light would be given enough time to cross the intersection without causing a tragedy.

When I gave the traffic light to John he critiqued the flashing mode saying one set should flashing yellow (eg. NS and SN) while the other (eg. EW and WE) should be flashing red. Actually I can't remember which lights are on in real four-way traffic lights during flashing mode. Googling shows that my nephew has a point. That's trivial enough to implement, given that the firmware uses a state machine implementation to charlieplex the lights. 

The table on the right shows which lines (PORT pins) control which traffic light direction. The table on the left gives the TRIS and PORT status in order to light up LED Lx.

Here's the light at work:



Hoping to make a much more decent model the next time around.