Macro commands have been implemented in every S-COM controller since 1976. Why?
The term dates from mid-1950s computing. It was common for a programmer to enter a short macro instruction to generate a series of other instructions. It saved time, reduced errors, and helped standardize the code.
We figured the concept would be beneficial in repeater controllers for the same reasons. Command line programming sometimes required long strings of characters, and substituting a short code made sense. And, macros kept the programming password secure while executing any command in the book.
The popularity of the autopatch (radio/telephone interface) also helped promote macros. Back then, the standard procedure for most autopatches was: (1) enter a code to take the phone off-hook; (2) listen for dial tone; and (3) enter the desired phone number. The user’s DTMF went to the controller and the phone company simultaneously. Unfortunately, noisy and/or distorted digits often led to misdials and non-detection of long-distance calls that ran up the club’s phone bill.
We added a simple autopatch to our first controller, a SWTPC microcomputer, by interfacing it to a Heathkit HD-15. Because we preferred self-contained commands, the access command was:
(AUTOPATCH PASSWORD) (PHONE NO.) (*)
The controller checked the password and phone number before engaging the phone line. Following a time delay for dial tone, it dialed the number with pulses or locally-generated DTMF, which also meant the number was not disclosed over the air. The system worked very well, and autodials became the biggest use for macros. Being stored in volatile RAM, they had to be reloaded after every power interruption.
A wire-wrapped MC6802-based autopatch/controller replaced the microcomputer. It had 4K bytes of EPROM and 128 bytes of on-chip RAM, and included a command line user interface and 100 macros. Two macros could be stored in volatile RAM for experimental purposes, and the rest were stored in EPROM.
The drawback was maintenance: EPROMs had to be reprogrammed whenever phone numbers changed (or we came up with a bright idea for a new macro), and that meant a trip to the site.
The fix was obvious: Store the macros in nonvolatile RAM instead of EPROM, and come up with the commands needed to manipulate them.
The next two controllers were wire-wrapped MC6809 designs that included battery-backed RAM. The macro system became more sophisticated. Macro names were increased from two to four digits; user functions were given easy-to-remember codes (73, 807, 999, 1234, etc.), while control op codes were made obscure (A1B2, CC67, etc.). Commands were invented to create, delete, rename, and read macros. Later, the development of the append command let owners stack multiple commands in a single macro. A repeater’s entire ‘personality’ (ID, timeout, tail characteristics, etc.) could be changed from ragchew to net to emergency with just a few keystrokes.
The next step was to support macros within macros, making sure that each embedded command or macro was parsed and placed in the correct sequence in the queue. This ensured left-to-right command execution as the customer would expect. It also permitted self-modifying macros.
But that wasn’t the end. A further development was event-triggered macros, or macros that could be executed not only by DTMF commands but also by internal and external events.
The idea was built on alarm inputs. They performed a fixed action when tripped, such as appending “BATT” to the CW ID. By instead assigning macros to the low-to-high and high-to-low transitions, our alarm inputs became logic inputs and executed any commands the owner desired. COR and CTCSS inputs were later added to the logic inputs as trigger sources.
Macros were later assigned to internal events such as repeater activity. For example, an ID-triggered macro manipulated a logic output that enabled a cartridge machine that played a voice ID. A scheduler was developed to trigger macros based on time and date to automate repeater functions. And IF/THEN/ELSE functions added further flexibility to these controllers, truly differentiating them from others on the market.