Implementation
This section and the section on Keyer protocol describe some of the internals of the µH Router. This documentation is meant for those who are curious about the internal workings of the router, or if you have a need to modify the router itself.
The µH Router is implemented in Cocoa and uses Unix named pipes (also called FIFOs) to communicate with client applications. Named pipes are implemented on MacOS X for both Carbon and Cocoa frameworks and it is of course also available to Unix command line utilities.
The µH Router can also be controlled through AppleScript -- a simple AppleScript Studio application can for example be written to use a microHAM keyer as a configurable CW contest/memory keyer.
The µH Router application contains three independent Router objects that are associated with each of the three microHAM keyers that uses the Keyer Protocol. These objects are identical except for functions that are missing on a specific model - specifically, the DIGI KEYER does not come with a WinKey chip and the CW KEYER does not come with a serial Baudot port for FSK.
Each Router object has its own Server component and its own Keyer component. The Server component is the one responsible for communicating with client applications and the Keyer component is responsible for communicating with a particular keyer. This is shown schematically below.
The Router object is the one
that is responsible for multiplexing commands from client
Applications into the shared Keyer Protocol data stream
(see section on Keyer Protocol), and it is
responsible for demultiplexing the data streams that are
received from the physical keyers and sending the
demultiplexed streams to a client Application.
The next diagram shows the signal flow in greater detail.
The Keyer component is
responsible for opening and closing the serial port to the
keyer and maintaining frame synchronization for the serial
stream that arrives from the keyer. The synchronized frames
are sent to the router component to be demultiplex into the
data for the separate functions of the microHAM keyer. The
Keyer component also closes the serial port to the keyer
device before the computer is put to sleep and reconnects
to the device when the computer wakes up.
The Keyer component is responsible for sending frames of
commands from the Router to the microHAM device. When the
data stream is idle, the Keyer periodically sends a
"heartbeat" frame to keep the watchdog timer on the keyer
from timing out. (The watchdog timer on a microHAM keyer
ensures that if the connection to the computer is lost, the
PTT connection to the transmitter will not remain keyed for
longer than 15 seconds.)
The Router component takes the frames of data from the
Keyer component and parses the data to separate the stream
into individual Control, Radio (CAT), FSK, WinKey, PTT, etc
streams (see the section on "Keyer Protocol" for more
details). These individual streams are handed over to the
Server object through individual software ports.
A client application accesses each specific function of a
keyer by requesting a unique port (a Unix named pipe that
can be accessed using the standard I/O open, close, read
and write calls from both Carbon and Cocoa applications)
from the µH Router's master port.
Within the µH Router, these ports are maintained by the
Server object. When the Server object receives data from
the Router, for example, the Radio's CAT data, it checks if
there is any client application that is attached to that
port. If so, the Server sends the data to each of the
clients that has a Radio port open.
When the client application sends command bytes to one of
these ports, they are received by the Server object. The
bytes are merged in the Router object into appropriate
locations in the data frames and then sent by the Keyer
object to the physical device.