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.


stack


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.

server

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.