Okay, I daresay, I think we got the programming done.

Attached is the schematic, BOM, and code.

Tracecom and I used LEDs to simulate the lights and buzzer. Depending on the actual buzzer used, you'll probably want/need to use a transistor of some sort as the buzzer will likely require more voltage or current than the uC can provide.

The BOM only covers what is shown in the schematic. It does not cover additional items like a programming cable, breadboard or printed circuit boards, wires, connectors, etc. We'd suggest getting a breadboard and jumper kit if you don't already have one and building the circuit then testing it before putting it onto a PCB. You can use generic PCBs such as this.

As far as the AC lights, after some discussion, we both agreed we would not be comfortable attempting to design an AC interface. We'd barely trust ourselves to design and build such a circuit and only if it were for personal use where we controlled who would use it (no one but ourselves). Since this is to be built by someone other than ourselves and going into a classroom full of students, we're just not comfortable attempting an AC design. If a DC circuit fails, a part might blow or get cooked. If an AC circuit fails, someone could get hurt or worse.

We would strongly suggest replacing the AC lights with DC ones. Perhaps large, cheap multi-LED flashlights or low power automotive LED bulbs. If you opt to use these, we can help you select the right interface hardware to work with the uC circuit.

I haven't had time to redo the flowchart properly, but feel free to study the code and ask questions.

Unfortunately, the .bas file can't be posted because it is not recognized, so I had to use the PDF converter. You can copy and paste it - just note some of the lines were overrun (run longer than the width of the page), so they'll need to be corrected when you get them into the editor.

Good luck!

 

Quick Question, why do you define Symbol names for bytes and words, then use the bx/wx notation in the program itself, rather than the symbol names?

 

Okay, I daresay, I think we got the programming done.

Attached is the schematic, BOM, and code.

Tracecom and I used LEDs to simulate the lights and buzzer. Depending on the actual buzzer used, you'll probably want/need to use a transistor of some sort as the buzzer will likely require more voltage or current than the uC can provide.

The BOM only covers what is shown in the schematic. It does not cover additional items like a programming cable, breadboard or printed circuit boards, wires, connectors, etc. We'd suggest getting a breadboard and jumper kit if you don't already have one and building the circuit then testing it before putting it onto a PCB. You can use generic PCBs such as this.

As far as the AC lights, after some discussion, we both agreed we would not be comfortable attempting to design an AC interface. We'd barely trust ourselves to design and build such a circuit and only if it were for personal use where we controlled who would use it (no one but ourselves). Since this is to be built by someone other than ourselves and going into a classroom full of students, we're just not comfortable attempting an AC design. If a DC circuit fails, a part might blow or get cooked. If an AC circuit fails, someone could get hurt or worse.

We would strongly suggest replacing the AC lights with DC ones. Perhaps large, cheap multi-LED flashlights or low power automotive LED bulbs. If you opt to use these, we can help you select the right interface hardware to work with the uC circuit.

I haven't had time to redo the flowchart properly, but feel free to study the code and ask questions.

Unfortunately, the .bas file can't be posted because it is not recognized, so I had to use the PDF converter. You can copy and paste it - just note some of the lines were overrun (run longer than the width of the page), so they'll need to be corrected when you get them into the editor.

Good luck!

Wow! Woooooooooooooooooooooosh. A whole ton of info to process!

Regarding the light issue, does it have to be any specific type of LED? The light fixtures right now are traditional incandescent bulb fixtures, but there exist LED bulbs - so then we just need to re-do the wiring going into the LEDs, right? That seems simple enough.

 

The outputs should be low voltage high lumen LEDs.

This is for safety reasons, so you won't need to worry about wiring a connection wrong and getting shocked/killed/maimed.

The interface for the LEDs will be another issue, I'd suggest an opto-isolated Solid State Relay to simply switch the hot line to each of the outlets while it is unplugged.

Otherwise, you'll need another power supply to drive the LEDs at about an amp and around 5V. This would require an output MOSFET to sink the current of each LED. A few more parts involved.

It's a question of if you want line voltages in your project (discouraged), or go with a safe version.

 

Wow! Woooooooooooooooooooooosh. A whole ton of info to process!

Regarding the light issue, does it have to be any specific type of LED? The light fixtures right now are traditional incandescent bulb fixtures, but there exist LED bulbs - so then we just need to re-do the wiring going into the LEDs, right? That seems simple enough.

There are several low voltage options. One is to buy some 12 VDC bulbs that fit the sockets that are in the traffic light. They are available at RV dealers. Then, we could use MOSFETs to switch the DC without removing the sockets from the light. Of course, this would require a 12 VDC power supply large enough to power the bulbs. The way the software is designed, there is never more than one bulb lit at the same time, which, using a 60 watt bulb, calculates to a 5 amp supply. To provide some headroom, 8 amps would be better.

 

Quick Question, why do you define Symbol names for bytes and words, then use the bx/wx notation in the program itself, rather than the symbol names?

I use bit0, etc. to call out specific bits in word w0 defined as var_out. This is done because it seemed unnecessary to define each bit.

The only other instance I can immediately see is where I used b27 in the for loop in the Countdown routine. Again, didn't seem necessary to define it since it is only used in that loop.

This is my first foray into PICAXE programming, so I welcome any comments, suggestions, etc.

Tracecom, would these work? I'm just not sure if the base is the same or not.

Another option might be these. Not sure if they'll be bright enough or not though.

You could wire a few super-bright flashlights together - I've recently seen a 3-pack of Surefire-like knockoffs at Costco in the U.S. for ~$15 if memory serves. You could try one for each light or put three together per light.

Another thought is a cheap 6V lantern battery-powered spotlight like this. You'll need a decent-sized power supply, but it's DC and very bright.

 

Transitory,

One other note that I forgot to mention when posting the code - there is a section at the top called User-Defined Constants. This is all you need to change to meet your initial requirements.

You call out at what time the yellow light comes on and when it blinks. You can also select how long the buzzer comes on for when the counter reaches 00:00. On hindsight, I could have made that simplier, but if you want the buzzer on for X seconds then take the number of seconds and multiply by 8000. So if you want the buzzer on for 3 seconds, enter in 3 x 8000 = 24000, for 1.5 seconds, enter in 1.5 x 8000 = 12000, and so on.

If you need the display to be brighter or dimmer, you comment out the desired intensity setting. Be sure all other intensity settings are commented.

You should not have to change anything else, especially in the main code. I've tried to make this as easy to use as reasonably possible.

We could have some more fun and program it so that you can enter in the desired yellow light on and blink time using the buttons instead of changing code. As a bonus, we could allow you to change the intensity setting with the buttons as well. Not that I'm insisting on this, I'm quite pooped now, but it is a possibility.

 

In order to facilitate better consistency in button operation, there were some hardware changes made to the breadboard. Attached is a low resolution photo of the final breadboard assembly that works correctly with revision 4 of the code. Here's a link to the demo video. http://youtu.be/DsZ4LxnbmIY

 

Okay, I've finally had enough time to review all the items.

(1) The code looks great. The comments make it very easy to follow. I get lost on pages 2-6 (all the communications between the devices) but the definition of the variables and the IF clauses at the bottom to control the lights reads very easily to me.

(2) A thought on changing up the yellow light timing. Instead of adding a button, why not do it via a percentage of the original time? When you hit start, that time goes into a constant - say 5 minutes. The yellow time then is defined as a percentage of that value (say 20%). The flashing yellow time is defined as 10%. So in this case, yellow starts at 1 minute, flashing at 30 seconds. For a longer interval, say 15 minutes, the yellow and the flashing will be scaled up. That could all be done in the upper part of the code, correct? Just a few math calculations in the code and then there's no need to add buttons for changing the times. It would make more sense, too, since you want a larger advisory time (yellow light) if there is a longer interval.

(3) As far as lights, I looked back at the housing. There is not a ton of room in there and a lot of the brightness comes from the reflective mirror surrounding the light. For that reason, the light we get should not just be forward facing. To take advantage of the mirror, it should be a bulb type. I can't measure exactly, but it would seem that the bulb has to be no more than 5 inches tall and no more than 2.5 inches wide. It seems that this light ( http://www.superbrightleds.com/moreinfo/boat-rv-screw-base/e27-led-bulb-8w-12-volt-dc/1209/ ) might fit well. Any thoughts? I can certainly order one to test it. Unfortunately there are no RV stores near me, but I'll be near one next weekend.

(4) As far as constructing the board, is the example board you've put on the video all done with out soldering?

(5) Should I start to order the parts on the BOM list? It seems like there's more I'll need (breadboards and such).

Thanks guys for all your continued help - it's going to be a neat project when done.

 

I am glad to see you are still enthusiastic about the project; I agree it will be cool when it's finished and in the classroom.

The code is entirely elec_mech's product, so I won't attempt to answer questions about that. I will say however, that in the best possible scenario, you would be able to make any changes you want to the code. I have found that even with my limited coding ability, I can take some good code and working hardware, and make quite a lot of changes and even some improvments on it. The nice thing about sofware changes is that they are...well, software, and if you don't like the results, you can change it back and start over.

Regarding the LED bulb you linked to, it looks good to me. Three of those, even if they were lit simultaneously, would draw only 24 watts, which is 2 amps at 12 volts. A 12 volt, 3 amp supply would be plenty. If, only one at a time would ever be lit, then a 1 amp wall wart would be sufficient. It will work up to 18 V, so a regulated power supply isn't required. The link says that they are equivalent in brightness to a 40-50 watt incandescent bulb. That seems bright enough for indoor use, but the only way to be positive is try it. Overall, it looks like a great choice to me, if the price doesn't deter you.

The assembly in my photo and video is a combination of soldered and solderless connections. Here's a thought: there are solderless breadboards that have stripboard equivalents. The idea of such an arrangement is to build a circuit on the solderless breadboard, test it, and when you are satisfied with it, transfer it to a stripboard. Here's a link to what I describing; take a look and see if that approach appeals to you. http://www.busboard.us/#BreadBoards

In the interest of full disclosure, there are some very experienced members here who refuse to use solderless breadboards. They don't believe the connections are unreliable, and they can cause stray capacitance, however, I use them extensively without problems.

I am sure elec_mech will chime in with some suggestions.

 

(1) The code looks great. The comments make it very easy to follow. I get lost on pages 2-6 (all the communications between the devices) but the definition of the variables and the IF clauses at the bottom to control the lights reads very easily to me.

A flowchart will help. I'll see when I have some time to make an updated one.

(2) A thought on changing up the yellow light timing. Instead of adding a button, why not do it via a percentage of the original time? When you hit start, that time goes into a constant - say 5 minutes. The yellow time then is defined as a percentage of that value (say 20%). The flashing yellow time is defined as 10%. So in this case, yellow starts at 1 minute, flashing at 30 seconds. For a longer interval, say 15 minutes, the yellow and the flashing will be scaled up. That could all be done in the upper part of the code, correct? Just a few math calculations in the code and then there's no need to add buttons for changing the times. It would make more sense, too, since you want a larger advisory time (yellow light) if there is a longer interval.

Let's break this into two parts.


First, there is no need for extra buttons. I was thinking something like:

1. Power on unit. You may want to include a power switch to turn power off otherwise you'll need to unplug the power supply to turn off.
2. Turn on the yellow light (to signify when yellow light should come on) and flash the display. Flashing stops as soon as second or minute button is pressed. Once the desired value is entered, user presses start button.
3. Flash the yellow light (to signify when flashing starts) and display. User enters desired value and presses start.
4. Display shows zero with all lights off.
5. User enters time and presses start to begin counter.
6. Yellow on and flash times can either be set (unchangeable until power is cycled) or resettable (must be re-entered once counter has stopped or reset is pressed).

Again, no need for additional buttons, just more programming and determining how you want the user interface to work.

Second, if you instead wish to make the yellow on and flash times a percentage of the entered time, no problem. Yes, you'd have to write an equation to perform near the beginning of the code, right after the run time is entered. Setting it to a specific percentage all the time is simple. If you want the percentage to change depending on the value entered, this will be more complicated. Certainly doable though. You have to be a little careful because this might require more variable space and there isn't much left as the program is written, but I don't see an immediate problem.

(3) As far as lights, I looked back at the housing. There is not a ton of room in there and a lot of the brightness comes from the reflective mirror surrounding the light. For that reason, the light we get should not just be forward facing. To take advantage of the mirror, it should be a bulb type. I can't measure exactly, but it would seem that the bulb has to be no more than 5 inches tall and no more than 2.5 inches wide. It seems that this light ( http://www.superbrightleds.com/morei...-volt-dc/1209/ ) might fit well. Any thoughts? I can certainly order one to test it. Unfortunately there are no RV stores near me, but I'll be near one next weekend.

I'd suggest finding an incandescent bulb with about the same lumen rating and testing it to see if it will be bright enough first. While the bulb you found is omni-directional, only the top half emits light whereas an incandescent emits light everywhere but the base. Also test it in the classroom you're planning to use it in. Most classrooms use fluorescent lighting which is quite bright. You just want to make sure the light coming from the bulb is bright enough to be seen from the farest point in the room that you need it to be visible.

The reflectors are great, but they're designed to reflect light from a 360 degree bulb back out. If you find a partially-directional light like a flashlight, you could either point it at the reflector to better distribute the light to just point it out directly.

If you're planning to solderless breadboard (yes, tracecom and I both did this to test things out and we would strongly recommend doing this first), we can amend the BOM or create a separate testing BOM if you'd like.

How loud do you want the buzzer? Are you thinking about a recorded sound or do you want to go with a standard buzzer? If the latter, do you want a small noise or a wake the dead one?

 

Here is the flowchart. I didn't go into every single detail - for instance I skipped the update display and MSB first routines. The flowchart covers how the circuit operates as a whole.

I invite you to study it and ask questions. Hopefully this will make it easier to understand the code.

A note on interrupts: the program will immediately go into the interrupt routine IF an interrupt condition has been set and met. In all cases, it will return to wherever it stopped in the program, hence the need to recond which switch or signal tripped it. Also note that as soon as the program enters the interrupt routine, all interrupts are turned off. This means they have to be turned back on upon exit or whenever you need them on again later in the program. You'll notice the switch interrupts are kept off if the minute or second buttons are pressed and held to allow for the auto-repeat function.

Part of the frustration and joy in making a uC work is seeing and understanding how the program and chip functions from a global level. This is why flowcharts are extremely useful. A flowchart lays the groundwork for your program and if updated regularly often helps you troubleshoot it as well.

 

In your flowchart, how do you test display prior to initializing display?

Second question, it shows a blocking routine in the ISR for clock signal high, is that what was meant?

 

In your flowchart, how do you test display prior to initializing display?

The test display routine simply sends a command to the MAX7221 to light all segments. This doesn't require any initialization.

Second question, it shows a blocking routine in the ISR for clock signal high, is that what was meant?

Are you referring to the loop that waits for the clock signal to go low before proceeding? If so, yes. Otherwise it's possible the program may see and respond to multiple clock pulses when only one has occurred.

 

Attached is my schematic of the traffic light controller project. I have tried to make my component numbers agree with those on elec_mech's schematic, and believe there are no confusing discrepancies. If there are discrepancies between my schematic and elec-mech's, his should take precedence. The primary reason I included mine is that I have divided the circuitry into functional modules, and that is actually the way I built my breadboard. Note that in addition to the modules I have shown, there would be one additional module, i.e., the actual traffic lights themselves and the asssociated driver circuitry that is not shown.

 

Are you referring to the loop that waits for the clock signal to go low before proceeding? If so, yes. Otherwise it's possible the program may see and respond to multiple clock pulses when only one has occurred.

Won't that cause the keypad to not respond every half second?

I forgot how the interrupt handling works and how far the user is away from the hardware. Can you set "interrupt on change" rather than level (pulse on leading edge, pulse on trailing edge) or "leading edge" only? That would give a lot more time to the main loop rather than waiting for the pulse to end.

 

Won't that cause the keypad to not respond every half second?

True, but we overcame this by adding C9 and R10 which act as an edge-trigger. Thus, when a clock signal goes from low to high and stays high for half a second, the input pin only sees a brief pulse. I suppose on hindsight, we could now eliminate the loop until clear, but not a bad idea to keep in place just in case C9 and R10 are omitted.

I forgot how the interrupt handling works and how far the user is away from the hardware. Can you set "interrupt on change" rather than level (pulse on leading edge, pulse on trailing edge) or "leading edge" only? That would give a lot more time to the main loop rather than waiting for the pulse to end.

I'm not sure if it is possible to only detect a change. It would have to be specific - interrupt only on a change from low to high, but then again I suppose once tripped (low-to-high or vice versa), we could have the program look at the input and only response when the input is high. I just don't know enough about PIXACEs at the moment. As it is working well, I'm just going to leave it as is, but I'll keep this in mind for the future. Thank you for your observations and excellent suggestions thatoneguy.

Tracecom, excellent job on the revised schematic. I completely forgot about the 5VDC source. Transitory, let us know if you need an updated BOM and any help sourcing prototyping gear.

 

Okay. I promise I'm not dead! I've had a busy few weeks at work and now have some time. For the sake of spreading out cost, my plan is:

Phase 1: Build the circuit as you have shown it (LED lights first).

Phase 2: Once the small scale is working, return to the lightbulb question and bring it to full scale.

So, I'll start assembling, but it probably won't be for a week and a half since I'll be on vacation next week. Sorry for the delay, things just got real busy real fast.

 

You're alive! Good news.

Regarding the AC lights, I came across an Instructable that made me think of your project. The item that caught my attention was a 4-output AC relay board made to work with a uC for under $10 USD.

Let us know if you have any questions once you start prototyping the circuit.

 

Well then. I was waiting for funds to buy the right parts, then finals happened, then summer happened and I went around the continent. I'm finally back and I still have this traffic light in my room doing nothing! (all my fault, of course).

So here's where I am with the project:

I've placed my last order and should get some of the remaining parts on the BOM by Friday. I even got a little breadboard but as I look at all the shiny new parts my quandary is: What do I do with it all?

I assume I need wires to connect all the nice little parts and I think my little 2x3 inch breadboard is too small for everything. What size might I need and what kind of wires should I get?

I'm a also looking at the Wall wart and wondering where exactly does it get plugged into? Do I need clamps or something?

Lastly, do I need a soldering kit to just get it all connected via the breadboard?

Sorry for the delay but I guarantee construction on the prototype will begin in earnest next weekend. Once we get that running I'll refocus on the light itself.

Hope you guys are still out there, sorry for the delay. I didn't feel like I had the extra money to get all the parts and by the time I did summer came.