Well it doesn’t. Take a look
at Table 3. The house code
bits are in reverse order.
If you look at Table 4,
you can see that there is a
pattern to the code/
function sequence but it’s
not simple, so I just took
the strong arm approach
and listed all the combinations. In the downloads,
there is a Zeus file called
FCm1.txt. This program has
support functions called:
and SendX17Adata. The SendX17A
data makes a call to the header and
footer functions so you need not worry
about them. You simply pass the house
code from Table 3 and the device/
function code from Table 4.
Here is an excerpt of the main loop
in the FCm1.txt program. It will turn on
Device K1, then wait five seconds and
then turn it off again. The FCm1.txt
program is very simple and will compile
and run in the free ZeusLite compiler
available on the KRMicros website.
BRIEF X10 HISTORY
■ Back in 1975, a company called Pico Electronics
developed technology for what is now the X10
interface. It gets its name from the fact that it
was the 10th project that Pico had created. The
technology did not reach the market until 1978
when RadioShack started to sell X10 products.
Sears then started selling X10 merchandise
Pico formed a partnership with BSR and
X10 Ltd. was born. X10 Ltd. bought out BSR’s
interest in 1987. The X10 Patent expired in 1997
and now X10 is an open standard.
■ FIGURE 5
transceiver. You must have one for the
FireCracker to operate. You can
purchase the CM18A from X10.com,
but I found the website very difficult
to navigate due to the overwhelming
amount of popups and crazy flashing
adds. I purchased a brand new
CM18A package from one of the
eBay online stores. The cost was only
$22 and I received it in just three days.
The FireCracker is a small and
Since it’s wireless
and gets its power
■ TABLE 3
■ FIGURE 6
from the RS-232 signal, you can use it
in portable interfaces such as a micro-controller or a Pocket PC. The only
downside is that it’s a one-way module.
It transmits only, so it cannot receive
data from sensors or other controllers.
The FireCracker uses a standard
DB9 connector with an RS-232 interface. When I first started researching
the FireCracker, I had assumed that the
TX and Ground lead on the DB- 9 connector were used at some predetermined baud rate. This is not the case.
The FireCracker uses a two-pin binary
interface. The RTS and DTR leads are
used to power and to clock-in the data.
To send a 1, RTS is high and DTR
is low, as shown in Figure 6. For a 0,
DTR is high and RTS is low. Once
signals are set, the system should wait
for 500-1,000 µs then set both RTS
and DTR high. The sequence is repeated eight times for a complete byte.
To send a complete control signal to
the FireCracker, you need
to send a sequence of 40
bits. This sequence consists of a header of 16 bits,
data consisting of 16 bits,
and a footer of eight bits.
The header is always
11010101 10101010 and
the footer is always
10101101. As you might
expect it’s the 16 bits of
data that tell the transceiver module what to send to
the remote X10 devices.
Now, you would
expect the data portion of
the FireCracker protocol
to match that of the X10.
The SendX17Adata function will
print the 1s and 0s as they are sent
to the FireCracker so you can see
Going Further with
I have given you the basics for
interfacing to the FireCracker. The
next logical step is to create a more
intuitive program to allow you to pass
actual strings like K1on or K1off. I
have included a ZeusPro source file
called FireCracker1Pro.txt as an
example of how to get started.
I have also included a couple of
programs called FireCracker2Pro and
FireCracker3Pro that will allow you to
use a small form to send codes to your