sample). Here's the setup of the Remote AT message used
by the prop:
The XBee remote worked really well, and both Matt
and Ed (at Midnight Syndicate) were thrilled. If you're in
northern Ohio, be sure to catch one of Midnight

Some final thoughts before we wrap it up. When you
deploy your own projects, do consider changing the
default channel, and at the very least change the PAN ID.
This will reduce cross-talk with nearby XBee networks that
are using default settings.

As you can see, it's a longer packet because the
payload contains the 64- and 16-bit addresses. To use the
64-bit address, the 16-bit address needs to be set to
$FFFE. Again, I find it simpler to use the 16-bit address.

Remember, too, that the common 802.15.4 models
are using frequencies in the 2. 4 GHz range that may be
competing with local Wi-Fi (802.11) devices. There are
The output of my Remote AT test program is shown in
Figure 8. If you want to try this kind of project, you can
use an XBee adapter to prototype on a solderless
breadboard as I did in Figure 9.

XBee channels that exist in the non-overlap areas of Wi-Fi
frequencies. These channels are $0F, $14, $19, and $1A,
though I've been told by a Digi rep that channel $1A
transmits at lower power on S2C series devices.

In operation, Matt's program can poll two possible
remotes. If neither responds, the local potentiometer
controls display and lighting behavior. If a remote
responds and its button is pressed, the remote pot value is
used. If the button is released, the local pot value is used.

For those that really want to explore XCTU, you'll
enjoy the Spectrum Analyzer tool. This will give insight
into the local radio spectrum. This is an XBee feature that
can be activated via AT commands. At some point, I'm
going to write a little Propeller app for it.

To prevent conflicts, the second remote is polled only
if the first does not respond. The idea is that the
secondary remote is available in case there’s a problem
with the primary; we don't expect both remotes to be on
at the same time.

Okay, we've been through a lot here, even though
we've really just skimmed the surface of using API
communications with the XBee. As I am looking toward
more build projects in 2018, you can rest assured that
we'll deploy XBees here and there. If you haven't used
XBees yet, do give them a try as they're quite a lot of fun.

For a stand-alone XBee remote node like this,
everything must be set up in XCTU. For this project, we
set the remote 16-bit addresses (MY) to $5200 and
$5201, respectively, and both were configured to use IO0
as a digital input and IO1 as an analog input, with all
other inputs disabled. The internal pull-ups for IO0 and
As I sign off for 2017, please allow me to extend my
sincere best wishes this holiday season to my friends at
Nuts & Volts (especially Robin who is immensely patient
with me), my friends at Parallax, and to all of you who
read my column. Blessings to you all.

IO1 are disabled. You can find the configuration file
(remote_control.xml) in the downloads.

Until next time — and next year! — keep Spinning and
winning with the Propeller! NV

The tricky part is understanding the
returned data, which starts at byte 21 in the
packet. If any digital inputs are enabled, the
first two bytes will hold the digital states
(the XBee can have nine digital bits; hence,
the need for two bytes). If any analog inputs
are enabled, there will be a two-byte value
for each that follows. In this case, we have
one digital input and one analog input, so
there are four bytes returned for the I/O.

By assigning the button to IO0 of the
XBee, byte 22 of the response packet will
be 1 when the button is pressed, and 0
when the button is released. The next two
bytes are the remote pot setting which Matt
scaled to match the requirements of the
prop control program.