Issue
157 August 2003
Palm-Enabled
Telescope
PALMING
THE PROBLEM
As
I thought things over, I realized that my Palm personal
organizer could serve as the computer interface and
connect to a GPS receiver to automatically determine
the viewing location. The Palm also offered a wireless
infrared IrDA port for communicating with remote devices.
That would solve the cable problem, if the Autostar
also had an IrDA port. It didn’t, so I decided to build
one.
The
overall system design is shown in Figure 1 with the
completed module and
telescope shown in Photo 2. I created a bridge module
with an IrDA port that connects to the Autostar controller
and receives its commands from the Palm. The module
allows the Autostar to function normally as a handheld
controller, but it adds the ability to send commands
from the Palm, as well.
|
(Click
here to enlarge)
|
Figure
1—The bridge module attaches to the Autostar through
its serial port and receives infrared signals from
the Palm. It formats messages for the IrDA link
using a protocol designed to ensure message delivery. |
|
(Click
here to enlarge)
|
Photo
2—The complete system has three parts: the telescope
with Autostar, a Handspring handheld (running Palm
OS), and the bridge module. The module is housed
in the box at the bottom of the photograph. |
I
had a number of requirements to meet with this module
beyond its ability to offer an IrDA interface: it had
to be small, low power (it runs on the same battery
power as the telescope), and inexpensive to build and
develop software for. I also wanted some expansion capability
for adding more interface options in the future.
I
chose the Zilog eZ80 as the module’s core processor
because it provides the two main features I wanted,
an IrDA port and an Ethernet port (for future expansion).
In addition, it includes a number of other features
that would be useful for this and future projects. For
instance, the eZ80 offers an RS-232 port and an I2C
interface, which allow the bridge module to connect
to a number of different displays if I want to give
the module its own user interface. The eZ80’s real-time
clock allows the module to maintain time of day, eliminating
one manual step in the telescope’s setup. The processor
also has a large address range (up to 16 MB), which
will come in handy as I keep adding functions.
Another
important reason for choosing the eZ80 processor is
that it is available in fully formed modules with a
complete development tool package. In this case, I chose
the eZ80 Webserver module (eZ80L925048MOD), which comes
with on-board IrDA transceivers and an Ethernet port,
1 MB of flash memory, 24 general-purpose I/O lines,
and a system-expansion port for connecting other hardware.
The module’s software development support includes a
full tool suite with a flash memory loader, debugger,
compiler, assembler, and application examples. The software
package also includes Internet software that I will
use for future enhancements.
The
Webserver module needs a little bit more circuitry in
order to serve as the bridge between the Autostar and
Palm. The additional circuits, shown in Figure 2, are
on a PCB with pins that mate with the Webserver module’s
expansion sockets and provide back-up batteries, voltage
regulation for the Webserver module’s power, and RS-232
drivers for the serial port. I also needed to relocate
the IRDA transceiver from the eZ80 module to the front
of the enclosure and add a red IR window. The complete
assembly is shown in Photo 3.
|
(Click
here to enlarge)
|
Figure
2—The bridge module consists of a manufactured processor
board and additional circuitry. The additional board
provides RS-232 interface signals as well as voltage
regulation for the module. |
|
(Click
here to enlarge)
|
Photo
3—By looking inside the box, you can see the Webserver
module and the secondary board underneath it. The
module contains the core processor, memory, and
IrDA circuits. |
TWO
SOFTWARE MODULES
The
hardware was the simple part. In order to make the bridge
module work, I needed to develop two sets of software.
One set runs on the eZ80 and handles the exchange of
information between the Autostar and the IrDA link.
Commands and responses follow the Meade telescope serial
command protocol, which functions like the old AT command
set for modems (and bypasses the annoying nested menus).
The other software runs on the Palm and provides the
user interface as well as the interface to the GPS receiver.
The Palm is the master controller, which means that
the Palm initiates all communication between the telescope
and user. The telescope does not send messages without
a command from the Palm.
Of
the two software modules, the eZ80’s is the simplest.
The eZ80 takes a command coming over the IrDA link and
passes it to a routine that reformats it into an Autostar
message. It then completes the operation by passing
the message to the Autostar through the RS-232 link.
It takes responses from the Autostar and passes them
back to the IrDA link. One other note: when the eZ80
firmware powers up, it blinks the status LED hanging
on JP2 pin 1, reminding you that the date, time, latitude,
and longitude have not been set. After you send this
information from the Palm to the eZ80, the status LED
stops flashing and stays on.
The
datastream over the IrDA interface is different from
the Meade protocol. The first difference is that messages
passing over the IrDA link include a command code at
the beginning and add a checksum followed by end-of-message
code at the end, framing the telescope’s protocol string.
The eZ80 uses the command code to determine the start
of a message coming over the IrDA link and the checksum
to verify that the message arrived correctly. If there
is a message error, the eZ80 will not acknowledge the
message and will throw it away.
The
other difference is that the binary values 0xF0 through
0xFF are reserved as command codes in the IrDA link.
Any message that includes these values in the datastream
has to be modified. When sending data containing a reserved
value, the eZ80 or Palm (whichever is sending) inserts
a 0xF2 command to tell the receiver that something is
up, and then breaks the offending data into two bytes
with the first nibble set to zero. Thus, an attempt
to transmit 0x04 0xF3 0x06 would be sent as 0x04 0xF2
0x0F 0x03 0x06. This minor reformatting, along with
the framing elements, help ensure reliable communication
over the IrDA link.
The
Palm software includes an application program and the
IrDA communication program. I used the Metrowerks CodeWarrior
for Palm OS software development tool (V.7.0) to create
the Palm code. You may download the source code from
the Circuit Cellar ftp site. The software targets the
Palm OS V.3.5. The code will not work with later versions
of the Palm OS because of a change Palm made to the
IrDA Enable API call in version 4.0. The new call causes
a hardware conflict in this application, so if you want
to use the later version of Palm OS, you’ll need to
make an assembly routine for the Palm to bypass the
API call.
