Computers & Mobile
SPARK Project #3, Post #4

In my previous post, I finally started to make some progress with my Windows Embedded CE project. I was able to get a simple test application running which could send and receive messages via a serial port on my iCop eBox 2300 computer. I first sent messages to a host computer using an RS232 crossover cable. Once I confirmed that there were no problems sending and receiving messages or changing the baud rate, I cut the cable and plugged in a pair of XBee modules in place of the crossover cable. I wasn’t ready to install custom device drivers in my Windows Embedded CE operating system image, so I used an XBee serial explorer ordered from SparkFun to connect an XBee to the eBox computer. After confirming that everything was working as expected, I was ready to modify the serial port test application to run my wireless light controller.


The secret sauce is my home-brew Arduino clone running from a capacitive power supply.
More about that next week!

Before I continue, I want to briefly reflect on some of the steps required to get my program to finally work. I initially suspected that I had a serial port buffer overrun problem, since I couldn’t send messages longer than 16 characters. When I noticed that my serial port test program would hang at the end of a serial port transmission of any length, I started to think that the problem may be interrupt related instead of buffer related. If the serial port call was waiting for a “buffer empty” signal before it returned control to my program, hanging at the end of a transmission meant that it never got that signal. Since I had been editing a number of serial port settings in the BIOS and registry while trying to disable or reroute serial debugging messages, I might have inadvertently modified a critical registry key. Rather than retrace my steps and restore the factory settings, I started with a clean copy of the BSP to build the operating system image. I had also notice that many of the build directories for my Visual Studio 2005 installation were pointing to a more recent version of Visual Studio on my computer. After mapping all the directories to the correct location, I rebuilt the operating system using clean copies of all the drivers and BSP.

Finally, everything worked flawlessly when I tested the new operating system with the simple Visual Basic serial port terminal example from Samuel Phung’s Windows Embedded CE 6.0 online resources.

Follow along at the SPARK site!

4 thoughts on “SPARK Project #3, Post #4

  1. This design looks lethal!

    Looking at the photos it appears that the cold has been switched. Many older lamps had the metal connected to the cold lead. Now with this circuit you’d have the the hot running through the bulb to the cold but the cold is now disconnected meaning that the metal shell may well be at full line voltage.

    Hopefully I’m wrong here but it’s better to switch the hot line to make sure that the circuit is almost always referenced to ground (or in the case of return, something close to it). Personally I’m a fan of fully grounded but not everything works that way.

    In general if you’re using an Triac (or pair of SCRs – for improved performance with inductive loads). You’ll need to take the trigger above loads line voltage. This can easily be achieved by connecting one end of a pulse transformer to the gate of the SCR and the other end to the cathode (or in the case of a Triac, the load terminal). Now when you fire the pulse transformer you’ll raise the potential on the trigger enough to turn the device on for the rest of the cycle. You’ll have to re-trigger each cycle.

    Please stay alive!

  2. Any line powered device presents a number of risks, including possible electrocution or fire, and these risks must be taken very seriously. That said, this design has no greater risk than any unswitched “temporary power tap”, in that the outlets are always assumed to be live whenever the power tap is plugged in. This is true of any triac or SCR circuit since these devices do exhibit some leakage when turned off.

    I appreciate your wise observation that the neutral lines are switched, not the hot line. I generally prefer designs that switch the hot line instead of the neutral to minimize potential line-voltage energized pathways. This design is based on a rather novel logic-level “snubberless” triac that I found:
    Described below:
    “The ACST4 device has been designed to control medium power load, such as AC motors in home appliances. Thanks to its thermal and turn off commutation performances, the ACST4 switch is able to drive an inductive load up to 4 A with no turn off additional snubber. It also provides high thermal performances in static and transient modes such as the compressor inrush current or high torque operating conditions of an AC motor. Thanks to its low gate triggering current level, the ACST4 can be driven directly by an MCU through a simple gate resistor”

    By using this part, I was able to minimize the complexity of the triac circuitry. If you are familiar with triacs and SCRs, you’ll appreciate the benefits gained from using the ACST4 and parts like it. But it is very important to recognize that directly switching a triac from a processor port pin means that the digital circuitry is not isolated from the line voltage, and (as you observed) that the neutral leg is switched, thus the hot line is always energized.

    Thank you for paying attention!

Comments are closed.


Kipp Bradford is a technology consultant and entrepreneur with a passion for making things. He is the Senior Design Engineer and Lecturer in Engineering at Brown University, where he teaches several engineering design and entrepreneurship courses. Kipp is also on the Technical Advisory Board for Make Magazine.

View more articles by Kipp Bradford