Toronto Repeater Controller

Generation 4 Specification
N.W. Johnson, VE3ID April 2006
nw.johnson@ieee.org

PREAMBLE: (For terminology, see glossary at end) This is the specification for the fourth generation controller to come out of the Toronto Repeater Controller design team. The original designs, starting in 1965, used discrete logic, and generation 3 used a 6809 micro-processor. The fourth generation departs from previous practice by using a micro-controller for each repeater/transmitter pair, instead of one microprocessor controlling 8 repeaters based on a simple switch card for each receiver and transmit card for each 8 transmitters. The 8 repeater limit was imposed by the insufficiency of 16-bit registers in the 6809, whereas the actual hardware is equipped for 16 channels. The Analog Radio Interface Card (ARIC) consists of a micro-controller and audio gating circuitry to interface to a main transceiver and an auxiliary transceiver. The auxiliary transceiver connection could be used for an local autopatch with external hybrid, a remote autopatch over a radio link, an analog link transceiver, or an analog connection to an existing remoting system such as IRLP or private VoIP controller. The term xRIC means a radio interface card without specifying whether it is analog or digital. For a simple repeater with one user channel, the ARIC can be used standalone to provide control of the main repeater and autopatch, command, or linking. In this (simple) mode, the ARIC will be capable of operating a second radio that may be used as a command channel, an autopatch, or an analog link radio, For a complex system, each xRIC will interface to others in the system over the CAN bus connector on each card in an equipment rack. There is an addressing limit of 255 controllers within one system. In a metropolitan area network, it is foreseen that the CAN buses in each site will be linked with megabit digital links In a complex system the second channel on the ARIC will be disabled and all operations for linking shall be accomplished using digital linking over the CAN bus. A proposed digital interface card (DRIC) will allow users of future digital modulation techniques to interface seamlessly with the system and communicate with those on analog channels in a symmetrical manner. A further proposal to add a controller from the CAN bus to the CIV protocol will make the controller able to be used as a remote base, as well as opening up remote control options for individual amateur stations. In this document, the term ARIC means the controller for one analog radio (and aux radio if used). The term DRIC means the digital equivalent anticipated for the future. MADI is the

Metropolitan Area Digital Interface proposed to link compatible systems, which will sit at the end of the CAN bus on each local group of controllers. The term 'local' refers to the devices connected to one ARIC, the term 'remote' refers to devices connected to another ARIC in the same physically-connected system, and the term 'external' refers to devices connected to controllers in another compatible system accessed via the MADI. The term 'control operator override' means an event occurs, such as the CTCSS tone being detected by a controller which is designated as the command channel for the system, or a similar indication of control operator abort using future digital control means. GENERAL 1.0 Each control card in a system shall be capable of controlling, in real time, two receivers and two transmitters in simple mode, and one receiver and transmitter in complex mode. 1.0.1 For the purposes of definition, an audio input, together with its request for service line (COS) considered as a receiver. 1.0.2 For the purposes of definition, an audio output, together with its keying output line (KEY), shall be called a transmitter. 1.0.3 There shall be two inputs to each control card's receiver input to show the presence of CTCSS on a receiver, one for user CTCSS and a separate one to indicate a command transmitter is being received. 1.0.3.1 A controller shall be able to operate on carrier detection or user-mode CTCSS 1.0.3.2 All references to COS assertion shall be deemed to apply to CTCSS if configured 1.0.4 There shall be an output to each controller's transmitter output, either to signal discrete CTCSS ON or to interface using a bit-serial interface for transmitter CTCSS generators so equipped. 1.1 The controller will be capable of responding to a COS on any defined receiver within a defined system and connecting that receiver to its transmitters, subject to timer validation and changes made to tables by users or control stations. Each receiver and each transmitter shall have its characteristics stored in memory, and loadable from SD card, located on itself or from a main SD card per system. 1.2 The controller will start a receiver timer for each local COS assertion.

1.3 The controller will start a transmitter timer when its local receivers or receivers on an in incoming link causes a transmitter to be turned on. 1.4 When a COS has been active for a period of time greater than that allowed for it in its pre-defined or control-modified table, the controller will disconnect all connections for that receiver and will not re-connect them until such time as the COS goes inactive, at which time the timer will be reset.

1.5 The controller will allow a control station, by dialling a command code, to enable or disable each receiver and transmitter separately. If the receiver is disabled, it will not respond to any COR assertions except as needed to detect further DTMF. Transmitters associated with disabled receiver will still be able to be used as link outputs unless disabled separately by command code. 1.6 The controller will allow a control station, by dialling a command code, to prevent any receiver form responding to DTMF. When such code has been dialled, and until re-enabled by another code, the receiver's DTMF operation will appear normal to the user, i.e. That muting and transmission of fake tones will occur, but the codes will not cause any changes of status in the repeater. When the receiver is in this mode, a report will be sent on the command channel which reports all codes attempt, whether valid or not. 1.7 Under MCU control, all receiver audio will be digitised and either: a) b) Output from a DAC to its local transmitter Sent over the CAN bus to a numbered destination transmitter if a link is up

1.7.1 In simple mode and under MCU program control, the same processing will occur on both the main and auxiliary interfaces 1.8 In case of MCU or program crash, the watchdog circuit will cause an output signal to reset the switching logic on the controller card, enabling each main receiver to be connected to its transmitter with no logic and pass-through audio. (FAILSAFE MODE) 1.8.1 Under failsafe mode, the auxiliary interface will not repeat. DTMF SIGNALLING 2.0 A DTMF detector will be available on each controller. In simple mode, there will be a means of disconnecting one receiver when the other is receiving DTMF signals to avoid audio mixing. The DTMF MAIN signal, when asserted, causes the audio from the main channel to be connected into the DTMF decoder. The audio connection into the DTMF decoder will be connected permanently to any sole channel whose COS is asserted. If both COS signals are asserted then the DTMF decoder will be switched between them in the following manner: As each COS assertion takes place, the DTMF detector will be connected to that receiver for seven seconds, or such time as may be configured (DTMF initial connection time). No DTMF detection shall take place on any receiver after this delay. If more than one receiver has COS assertion at the same time, the DTMF decoder will be alternately connected to each one while its COS is asserted and its local timer has not expired. If DTMF is received during the DTMF initial connection time, the initial connection time shall be extended by as much as the DTMF timeout time. An exception to the above is that if one channel is designated as a command receiver, its COS assertion shall caused the DTMF decoder to be locked on to the command channel; In complex mode, scanning will be disabled and each receiver main will be connected to its card's decoder.

2.0.1 The controller will receive valid DTMF, causing a DTMF IRQ. 2.0.2 If DTMF arrives, it and subsequent digits will be assembled in a buffer until: 2.0.2.0 A preset period of time expires after the receipt of the latest received valid digit (Nominally 7s, but changeable on a controller-specific basis) at which point the buffer will be flushed; 2.0.2.1 The COS on the receiver connected to the DTMF decoder de-asserts, at which point paragraph 2.0.3 will be taken; 2.0.2.2 A control operator override occurs at which time any DTMF presently being assembled will be ignored, and the buffer flushed 2.0.3 The assembled digits, terminated by receipt of COS de-assertion are looked up in a command table, as defined in paragraph 2.0.4. If a match is found with an entry in this table, the function found in the table is scheduled. If the end of the table is reached with no match, CW 'SRI' or the voice equivalent 'SORRY' is scheduled to be sent on the requester's transmitter. 2.0.4 Each controller can have a completely different set of codes. Some may do the same things as others. Optionally, one controller in a system may be designated as the code storage controller so that others will copy its codes into their own memory. This will allow changes to a whole system to be made by changing the designated controller and resetting all the other cards. Such a system code table shall consist of all tables superimposed over each other with a common end point. In this way, some receivers higher up in the chain will have more codes assigned to them than others. This can be used, for example, to allow more codes to be dialled on COMMAND than on repeater 2, and more codes on repeater 2 than on repeater 4. Specific order of entry points will be as follows: 2.0.4.0 Command receiver with CTCSS present 2.0.4.1 lowest-numbered receiver with command CTCSS 2.0.4.2 lowest-numbered receiver with user CTCSS 2.0.4.3 lowest-numbered receiver without user CTCSS 2.0.4.4 repeater designated as a main analog linking hub receiver 2.0.4.5 Other analog link receivers 2.1 When DTMF arrives on any receiver the mute bit in that receiver's TCB will be checked. 2.1.1 If set, the audio connection between this receiver and all associated transmitters will be cleared, and the same transmitter will be held on the air by an output line directly from the micro (TAIL signal) If linked to an off-board digital connection, the channel number and a mute code will be sent to hold the remote transmitter on, so as to avoid users jumping in and

causing interference. Optionally, a micro-generated sequence of audio tones can be sent of a different DTMF digit to confuse would-be decoders of the system's codes. The fake tone pair does not need the stability of the DTMF chip, and the DTMF chip shall not be used to send this tone pair. 2.1.2 If not set, no action will be taken with respect to the transmitters 2.2 When DTMF is no longer being received, a transmitter held on by the TAIL signal will be re-connected its receiver. 2.2.0 If DTMF reception is terminated due to a timeout, as in paragraph 2.0.2.0, the receiver's DTMF signals will be ignored until such time as its COS de-asserts and re-asserts. RECEIVER TIMERS 3.0 Each receiver TCB shall contain a separate, preset value for its timer. When the COS asserts, the timer will be started, and when the COS de-asserts, (after a tail time preset in the receiver's TCB) the timer will be reset. If the timer expires, the receiver will be marked as timed-out. All connections for the receiver will be cleared. No further service will be given to this receiver until: 3.1 The COS de-asserts, at which time the time-out flag will be cleared, and further service is possible. 3.2 A DTMF code is dialled to reset the receiver, at which time a COS de-assertion and assertion will be simulated. 3.3.1 CW 'RTO' or the voice equivalent 'RECEIVER TIMEOUT', will be scheduled to be sent on the transmitters associated with a timed-out receiver 3.3.2 Any transmitter connected to a receiver at the point of timeout will not be connected to it again until: 3.3.3 Its COS de-asserts and re-asserts, or; 3.3.4 A DTMF code is dialled to reset the receiver's timer. TAIL TIMERS 5.0 Each receiver will have in its TCB a time for the length of its tail.

5.1 If the receiver re-connects to the transmitter(s) during this tail period, the tail timer will be cancelled. BEEP TAIL 6.0 Each receiver will have in its TCB an associated beep tone frequency and timer value. The purpose of the beep tail is an alternative to having a transmitter timeout timer. (Except as a last resort hardware timer having a period of 15 minutes or thereabouts.) The timer mentioned here determines time between COS de-assertion and beep tone.

6.0.1 The tone for the beep will be sent from stored sound files. 6.1 The beep tail will be sent on all connected transmitters after the timer period referred to in 6.0 has expired following de-assertion of the receiver's COS. The receiver's timer will be reset before the beep is scheduled. 6.2 Each receiver will be assigned a different beep tone to indicate to users which receiver has just ceased receiving in a multi-repeater link. 6.3 If any transmitter keyed by the beep request is within n minutes of its hardware timeout, no beep will be sent. (n definable in transmitter TCB). This will force COS deassertion, receiver and transmitter timer re-initialisation, and station identification. IDENTIFIERS 7.0 Each transmitter will have provision for a separate callsign, however, more than one transmitter may send the same callsign. Parameters associated with the callsign will be a) Speed, b) tone used , c) voice or CW 7.0.1 There shall be two types of identification, normal and informative. The normal shall simply give the callsign, and the informative shall include other data such as location, access methods, frequencies, etc. The informative announcement shall be given only in voice mode, and is entirely at the discretion of the configuring user. 7.0.2 All voice announcements, such as callsigns, prompts, etc, shall be user-configurable and stored in SD card by means of a separate utility provided for use in an offline PC type computer. 7.1 For the purposes of identification, each transmitter will, at all times, be considered to be in either active, dormant, or beacon mode. 7.1.1 A transmitter will be considered to be in active mode at all times the transmitter is keyed, plus a further time period presettable in the transmitter's TCB. At the expiration of this period, the transmitter will be flagged as dormant. 7.1.2 A transmitter will be considered to be in beacon mode after a 'start beacon' command has been dialled, and before an 'end beacon' command has been dialled. 7.1.3 Any keying of any receiver associated with the transmitter in beacon mode will cause such transmitter to go to active mode, but such transmitter will return to beacon mode instead of dormant mode when the conditions for dormant mode have been met. 7.2 An 'ID' flag will be set during the first 'transmission' of an active phase and will be set again two minutes after an ID has been sent. The ID will be scheduled under the following conditions: 7.2.0 When the last connection holding a transmitter on clears, if the ID flag is set. 7.2.1 After a repeating time period defined in the transmitter's TCB while in beacon mode.

7.3 If the transmitter is in beacon mode, the dummy card will hold the transmitter on for a nominal 30 seconds after I.D. LINKING 8.0 There shall be provision for linking, on DTMF command, between any and all defined repeaters in the system. 8.0.1 Each repeater shall have an associated 'LINK ON' and 'LINK OFF' code. 8.0.2 One individual repeater shall be designated as the prime analog link repeater and shall be a gateway to other systems. Such repeater will have no tail. 8.0.3 Any additional analog link repeaters will be defined solely as additional repeaters with no special characteristics 8.1 On receipt of a link-on code, the controller will check to see who dialled it.

8.1.1 If a user is dialling the code associated with his own repeater, the requester will be connected to the main analog link repeater and vice versa. 8.1.2 If a link-on code is dialled from the link repeater, then the link repeater will be connected to the repeater associated with the link-on code and vice-versa. 8.1.3 If a link-on code is dialled from a repeater within the system other than the analog link repeater, and the code is associated with another repeater defined within the same digital system, then the requester is connected with the requested repeater and vice-versa, without either being connected to the analog link repeater. 8.1.4 In cases 8.1.1, 8.1.2 and 8.1.3 above, if any links are already in progress on either requester or requestee, then such links will be replicated, both ways, to the requestee or requester respectively, as appropriate. 8.1.5 When a link-on has been completed, then the requesting repeater's call will be sent on the requestee's transmitter(s) and vice versa. 8.1.6 When a link-off command has been dialled, the logic of paragraphs 8.1.1, 8.1.2, 8.1.3, and 8.1.4 will apply but links will be disconnected instead of connected. 8.1.7 When a link-off code has been completed, paragraph 8.1.5 will apply, but in addition, a steady tone 400 ms long will be sent before the call sign, and disconnection will take place after the call sign. 8.1.8 When a link is in progress, the beep tail will be enabled on all receivers taking part in the link, so that anybody listening to the link will be able to tell which receiver was just used, since each receiver will have a different beep tail. 8.1.9 If no COS is active on any receiver in a link for 5 consecutive minutes, and the link timer disable code has not been dialled, then a link disconnect will be forced as if a link-off

code had been dialled in accordance with paragraph 8.1.7. AUTOPATCHING 9.0 BACKGROUND - HARDWARE OPERATION

There will be one or more repeaters defined as an autopatch. Each repeater will either directly or indirectly attach to a telephone line. In direct connection, the telephone line will terminate in a hybrid phone patch at the repeater site. Turning on the autopatch repeater's transmitter will cause a relay to pick up and connect the phone line. On connection, the COS will be asserted on the autopatch receiver. The autopatch routine may then proceed to dial. In the indirectly-connected mode, appearance to software will be the same. As far as hardware goes, keying the transmitter will cause an actual transmitter to go on-air, which will actuate a receiver at the remote phone site. At the phone, a relay will connect the phone line on COS assertion, and turn on the UPLINK transmitter on completion. (The hardware for either local or remote operation will have a dial tone detector which will control the reverse channel only when DT is detected.) The controller will proceed with the call only when the COS is asserted on the UPLINK receiver. Note: The downlink audio will not go into the phone line until the 'end code' digit is sent. 9.1 The autopatch will be available on all repeaters in the system unless it is denied by one of the following specific conditions: 9.1.1 An 'autopatch deny' bit is set in the requesting receiver's TCB 9.1.2 CTCSS tone is present on the command receiver. 9.1.3 The autopatch has been disabled by command DTMF. 9.2 NORMAL OPERATION

9.2.1 REQUEST PHASE 9.2.1.1 On DTMF command, the autopatch will be requested by a receiver. If the 'BAD SIGNAL' bit is set for the requester when an autopatch request is received, then the controller will send CW 'SIG' or the voice equivalent 'BAD SIGNAL', and abort the request. 9.2.1.2 The controller will check to see if an autopatch is available. If an autopatch is not defined, not available, or flagged as defective, then CW 'NAP', or the voice equivalent 'SORRY, AUTOPATCH UNAVAILABLE' ,is sent on the requester's transmitter, and the request terminated. 9.2.2 DIALLING PHASE 9.2.2.1 If an existing, working autopatch is found, it is reserved, and CW 'GA' or the voice equivalent 'GO AHEAD' is sent on the requester's transmitter. The DTMF decoder is locked onto the requester.

9.2.2.2 The requester's transmitter timer is set to 15 minutes and the requester's transmitter is keyed continuously until the end of the autopatch, using the TAIL signal. 9.2.2.3 The controller will then accept a 7- or 10- digit telephone number from the requester, configurable on a system-specific basis. It will then check to see that it is exactly 7 digits, the first or second digits are not 0 or 1, and that the entire number is not in a prohibited number file in memory. 9.2.2.4 If the number dialled is '911' then the immediate autopatch request will be aborted and an emergency speed call autopatch will be forced on the requester's repeater without further action on the part of the requester. 9.2.2.5 If any of the error conditions of paragraph 9.2.2.3 (except lack of digits due to emergency speed call), or a timeout, are encountered, the immediate request will be aborted and CW 'NBR', or the voice equivalent 'BAD NUMBER', will be sent to requester's transmitter. A timeout will occur if 7 seconds elapse between digits. 9.2.2.6 When a valid, un-prohibited telephone number has been dialled, the controller will turn on the autopatch transmitter and wait for a COS assertion on the associated receiver. A fifteen-second timer will be set. CW 'AS' , or the voice equivalent 'WAIT', will be sent on requester's transmitter every five seconds until COS assertion is seen. 9.2.2.7 If the fifteen-second timer expires without the COS assertion being seen, the autopatch will be flagged as defective. CW 'NAP' , or the voice equivalent 'SORRY, AUTOPATCH UNAVAILABLE' , will be sent on the requester's transmitter, and the request terminated. 9.2.2.8 A test will be scheduled every minute for five minutes to see if the autopatch still fails to respond. If no response is found within 5 minutes, then the autopatch concerned will be left flagged as defective for maintenance. If autopatch responds to this test, the flag will be cleared and the tests stopped. Regardless of the outcome of the test, an alarm message will be sent on the command channel indicating that the patch has been disabled, or re-enabled. 9.2.2.9 Any exit from the dialling phase will unlock the DTMF decoder from its associated receiver 9.2.3 CONNECTED PHASE 9.2.3.1 When the COS on the autopatch receiver is asserted the number to be dialled will be translated, digit-by-digit, into a different number using a 16-element lookup table, whose entries correspond to a matching descrambling table in the autopatch itself. 9.2.3.2 The scrambled phone number is then sent to the autopatch transmitter. An 'end code' consisting of one of the fourth column digits, is sent, and the uplink receiver is crossed to the user's transmitter. Note: The autopatch end will only pass audio from the user into the phone line after this point. 9.2.3.3 The requester's receiver is then connected to the autopatch transmitter and the autopatch is flagged as waiting for a disconnect code.

9.2.3.4 If, at any point during this stage of the autopatch command CTCSS appears on the requester's receiver, then the autopatch will be aborted immediately as if the disconnect code had been dialled. 9.2.3.5 If, at any point during this stage of the autopatch, the COS from the autopatch receiver de-asserts, then a six-second delay will be started and continuous tone will be sent on requester's transmitter. If the autopatch COS has not been re-asserted at the end of the six-second delay, then CW 'NAP' or the voice equivalent 'SORRY, AUTOPATCH UNAVAILABLE' , will be sent to the requester when the requester's COS is de-asserted. The present autopatch request will be aborted, the autopatch flagged as defective, and the test routine will be entered as described in paragraph 9.2.2.8. 9.2.3.6 If no COS is asserted on the requester's receiver for at least 30 seconds, 'K' or the voice equivalent 'PLEASE REFRESH TIMER', will be sent, and a 5 - second timer will be set. If the COS is re-asserted, the 5-second timer will be cancelled and the 30-second timer reinitialised. If the 5-second timer is allowed to expire, CW 'TIM' or the voice equivalent 'SORRY, TIMED OUT' is sent on requester's transmitter and the autopatch is terminated as in paragraph 9.2.3.8. 9.2.3.7 The disconnect code will be an octothorpe, or another single- or multiple-character code as may be defined in the DTMF command table. 9.2.3.8 When the disconnect code is dialled on the requester's receiver, CW 'AR' or the voice equivalent 'END AUTOPATCH', is sent on the requester's transmitter, and the autopatch will be disconnected, flagged as free, and any emergency flag associated with the autopatch will be cleared. 9.2.3.9 As soon as the autopatch is terminated, or aborted for any reason after the autopatch code has been recognised, the controller will send, on the ASCII command channel, a status line in the following format: HH:MM RRRRRR (AAA)NNN-XXXX UUUU MM:SS S T Where: HH:MM is the time, 24 hour clock at the start of the call. RRRRRR is the requesting repeater's callsign (AAA)NNN-XXXX is the number dialled UUUU is the user code if this feature implemented MM:SS is the length of the call in minutes and seconds S is the success code: B = bad number ( not 7 digits) C = COS timeout D = dumped by command station E = Pre-empted by emergency speed call F = negative file call H = hardware failure L = attempted LD or operator N = call completed normally

S = cancelled due to excessive emergency speed calling T = timed out T is the type of call: R = regular autopatch S = regular speed call E = emergency speed call 9.3 EMERGENCY SPEEDCALL OPERATION.

9.3.1 The numbers between 911 and 939 are reserved in all systems for emergency speed call use. 9.3.2 The emergency speed call feature will only be available on those repeaters with an enabling bit set in their TCB. 9.3.3 The emergency speed call feature will be disabled if 4 attempts are made to dial a 900-series number within 2 minutes. If this occurs (deliberate misuse suspected) the controller will report the following on the command channel: ****** ALARM ****** HH:MM RRRRRR EMERGENCY SPEEDCALLING DISABLED DUE TO ABUSE. 9.3.4 Within the limitations of paragraphs 9.3.2, and 9.3.3, the emergency speed call feature will be available to all repeaters in the system. 9.3.5 The numbers defined in 9.3.1 are to be found in the main DTMF table, as well as in a lookup table which will translate them each into a regular 3 to 11 - digit telephone number corresponding to a Police, Fire, or Emergency number. 9.3.6 On entry to the emergency speed call routine, the controller will attempt to find a working, free, autopatch. If no autopatch is defined, or all defined autopatches are defective, then CW 'NAP' or the voice equivalent SORRY, AUTOPATCH UNAVAILABLE', will be sent on requester's transmitter and the request will be aborted. 9.3.7 If a defined, working autopatch is found, then it is checked for active status. If active, and not already in emergency mode, CW 'SRI EM' or the voice equivalent 'SORRY, EMERGENCY CALL IN PROGRESS', will be sent on the transmitter of the repeater currently in autopatch mode, which will then be disconnected. 9.3.8 The emergency flag is then set. The regular speed call mode is then entered with the 900 series code as an argument. 9.4 REGULAR SPEEDCALLING

9.4.1 Any repeater in the system can use speed calling on DTMF command. Since the speed calling routine is merely a front-end to the regular autopatch routine, all rules of use for

the regular autopatch apply equally to speed calling. 9.4.2 Speed call codes will consist of three-digit codes, preferably in a special series, set apart from other codes in the DTMF table. 9.4.3 When a speed call code is dialled, entry will be made to the speed call routine with the code that was dialled as an argument. The speed call routine will then look this code up in a table, and, if no match is found, then will send CW 'NBR' or the voice equivalent WRONG NUMBER', to requester's transmitter. 9.4.4 If a match is found, the controller will turn on CTCSS on requester's transmitter, set transmitter timer to 15 mins and check for emergency flag. 9.4.5 If emergency flag is present, alternating alarm tones will be sent on requester's and command transmitters for 5 seconds. 9.4.6 The autopatch routine will then be entered at paragraph 9.2.2.6 without sending CW 'GA' or the voice equivalent 'GO AHEAD'. 9.4.6.1 The autopatch routine will be passed a regular telephone number generated by the speed call routine from the 800 or 900 series translate tables. 9.4.6.2 The phone number generated by the speed call routine will be between 3 AND 11 digits, and will not be subject to validity checking by the autopatch routine. 9.4.6.3 As an option configurable on a system basis, the use of 3-digit emergency numbers can be blocked, and the numbers translated to corresponding number to avoid ANI-ALI responses to the repeater site if abuse occurs. SHACK INPUT/OUTPUT SIGNALS. 10.1 The shack I/O consists of 32 bits of read/write latches, each bit being defined as either an input or an output. These bits are organised as four 8-bit bytes at four device addresses. The actual hardware to handle latching, signal conditioning, and A/D conversion is contained on the SHIOC, which is connected to the system by the CAN bus. 10.1.1 All output latches will be read/write. 10.1.2 Bits specified as inputs will not be latched, the outputs of the corresponding latches being left disconnected. 10.1.3 The direction of each bit will be set in the configuration tables for the repeater and may be changed by DTMF code. 10.1.4 Each output bit shall be settable by command code, with an 'OK' response indicating success, and each input bit will respond to an interrogation code by CW or voice 'ON' or 'OFF' respectively.

COMMAND CHANNEL 11.0.1 A receiver-transmitter will be assigned as the command channel. This will be the primary command channel for the system. 11.0.2 The serial communications adapter (SCI) of the micro controlling the receiver and transmitter assigned to be a command channel shall be interfaced to a modem, which shall be connected to the command receiver and transmitter as follows: 11.0.2.1 When no CTCSS is detected on the command receive channel, normal operation will be for the receiver to be connected to the modem. When the monitor program sees that a remote modem is connected, then the local modem will be connected to, and key the transmitter. For handling with CTCSS, see paragraph 2.0.2.3 11.0.2.2 The command transmitter will be turned on for 500 ms before any ASCII characters are sent, and will be left on for 30 seconds after loss of uplink carrier. 11.0.2.3 As ASCII characters are received, they are checked by the monitor for valid commands. 11.0.2.4 No ASCII characters will be output on each connection until a valid, six-digit password has been entered. 11.0.3 A monitor program shall provide basic memory examine and change functions, as well as duplicating all command codes used in DTMF, and provide reports on system operation as defined in this document 11.1 DATA TO BE SENT

11.1.1 Every hour, complete status of the entire system, including: a) Status of all receivers and transmitters; b) Telemetry readings of all A/D channels; c) Any power failures or lightning detection within the last hour; d) Complete I/O scan, reporting state of all bits; e) Whether any alarms are present, if so, which ones; 11.1.2 Every DTMF command received, a) The time-of-day; b) The code, scrambled by the same method as used for scrambling into the telephone line when using autopatch (see 9.2.2.1); c) The repeater on which it was dialled (callsign, or a maximum six-digit ASCII mnemonic representing the repeater e.g. RPT/U) d) The number of the command station logged on if privileged code 11.1.3 On autopatch, send status report at termination. See paragraph 9.2.3.9 for requirements. 11.1.4 On ASCII request, any data required by a monitor function. 11.1.5 On command from local shack ASCII terminal, echo every data from local

keyboard to all terminals on command net, for commentary and logging purposes. This mode started by typing <^P> and ended with <^Z>. 11.1.6 Send log entry every time emergency speed call disabled or enabled, including alarm bells if disabled. 11.1.7 On any alarm, send report with data and time. Include alarm bell. 11.1.8 At the beginning of each line of data shall be sent a prompt, consisting of: 11.1.8.1 - HS> to indicate hourly status per 11.1.1 11.1.8.2 - CR> to indicate command received per 11.1.2 11.1.8.3 - AP> to indicate autopatch termination per 11.1.3 11.1.8.4 - > to indicate monitor function per 11.1.4 11.1.8.5 - LG> to indicate log entry per 11.1.5 11.1.8.6 - ED> to indicate emergency features disconnected per 11.1.6 11.1.8.7 - AL> to indicate alarm per 11.1.7 11.1.8.8 - FC> to indicate false code received while a receiver's DTMF is disabled DTMF CODES 12.0 Standard Bellcore-defined DTMF signalling shall be used to indicate changes of status, by a duly identified command station, or user service requests 12.1 Numeric codes will be assigned on a system-specific basis, and stored in the SD associated with each controller or in one master file for the while system. 12.1.1 Each controller shall have a particular digit as the first digit of all its codes. There may be exceptions to this rule for privileged codes only, and no such codes may be executable from links to other systems. 12.1.2 All codes will be five digits or less. All 16 DTMF digits are valid. 12.1.3 No code will have two consecutive digits the same. 12.1.4 Codes may have data required to be sent after the code is acknowledged. In this case decoding of codes will be suspended when such a code is dialled until the required data have been sent, terminated by the system termination code, as defined, or a timeout occurs. 12.1.4.1 If a code requires data to follow, normal DTMF detection will resume only after the validated data have been received for each code, or an inter-digit or total code timeout occurs. These timeouts will be assignable on a system basis.

DATA STORAGE 13.0 Each controller card shall be provided with a socket for a standard consumer-type SD card. 13.0.1 In simple mode, the SD card for each controller shall contain all configuration details and callsigns, voice prompts, and messages for the system 13.0.2 In complex mode, the SD card may be used on a per-card basis, or a single SD card on a designated controller may supply the information to all cards in the local site (Master SD Card) 13.0.3 Master SD-card loading of parameters between sites linked by radio is not contemplated 13.1 A disk-based supervisory system may replace the SD card usage by sending requested files from its hard disk as each card is reset, if the local card does not have an SD card or does have an SD card but is set to override local settings when remote settings are available over the CAN bus 13.0.1 An optional disk-based supervisory system with remote TCP/IP access may be used to control all features in a complex system, including overriding settings in the configuration tables stored locally. Such remote access will use SSH for security. 13.0.2 The system will be designed to allow future updates of the core program in flash memory from such a supervisory system VOICE OUTPUT 14.0 The system shall permit voice recordings to be sent over transmitters 14.0.1 The voice recordings for the system shall be recordable using normal consumergrade PC equipment and stored on an SD card in a format acceptable to the controller by a separate configuration utility supplied with he controller. 14.1 All CW callsigns and prompts used in the system shall have an equivalent voice version, if configured by the owner. 14.2 There shall be a facility for recording up to 10 seconds of test audio from a user receiver, at a user's unprivileged request signalled by DTMF, which will be played back on the user's transmitter once only as soon as COS for that receiver is de-asserted, whether the ten seconds is expired or not, and only for the length actually recorded 14.3 There shall be a facility for recording system announcements of any length (subject only to available SD card space) on privileged command by command stations, which shall be playable back but not deleted or re-recorded by user command on any channel specified by user configuration.

GLOSSARY ARIC - Analog Radio Interface Card, interfaces standard analog radio to the CAN bus CIVIC ICOM CIV-Equipped-Radio Interface Card (Proposed) Control operator override The occurrence of an event, such as the CTCSS tone being detected on a receiver which is designated as the command channel for the system, or a similar indication of control operator abort using future digital control means. DDSIC ICOM DDS Interface Card (Proposed) DRIC - Digital Radio Interface Card , interfaces proposed digital radio to the CAN bus, 100BT ELIC Echolink Interface Card (proposed) IRLPIC IRLP Interface Card (proposed) MADI - Metropolitan Area Digital Interface, interface megabit link to other repeater stations MCU Micro Controller Unit VoIPIC VoIP Interface Card (for private VoIP system) (Proposed) SHIOC shack I/O card, interface CAN bus to voltages and relays etc in the shack SIMPLE MODE The use of a single controller card as a standalone repeater, controlling a main transceiver and an auxiliary transceiver xRIC Radio interface Card, either digital, analog, or other