8/4/2019 Gen 4 Spec

1/16

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 TorontoRepeater 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 previouspractice by using a micro-controller for each repeater/transmitter pair, instead of onemicroprocessor 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 insufficiencyof 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 gatingcircuitry to interface to a main transceiver and an auxiliary transceiver. The auxiliarytransceiver connection could be used for an local autopatch with external hybrid, a remoteautopatch over a radio link, an analog link transceiver, or an analog connection to an existingremoting system such as IRLP or private VoIP controller. The term xRIC means a radiointerface 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, theARIC 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 busconnector on each card in an equipment rack. There is an addressing limit of 255 controllerswithin one system. In a metropolitan area network, it is foreseen that the CAN buses in eachsite will be linked with megabit digital links In a complex system the second channel on theARIC will be disabled and all operations for linking shall be accomplished using digital linkingover the CAN bus.

A proposed digital interface card (DRIC) will allow users of future digital modulationtechniques to interface seamlessly with the system and communicate with those on analogchannels in a symmetrical manner.

A further proposal to add a controller from the CAN bus to the CIV protocol will make thecontroller able to be used as a remote base, as well as opening up remote control options forindividual amateur stations.

In this document, the term ARIC means the controller for one analog radio (and aux radio ifused). The term DRIC means the digital equivalent anticipated for the future. MADI is the

8/4/2019 Gen 4 Spec

2/16

Metropolitan Area Digital Interface proposed to link compatible systems, which will sit at theend 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 todevices connected to another ARIC in the same physically-connected system, and the term'external' refers to devices connected to controllers in another compatible system accessedvia the MADI.

The term 'control operator override' means an event occurs, such as the CTCSS tone beingdetected by a controller which is designated as the command channel for the system, or asimilar 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 receiversand 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 ofCTCSS on a receiver, one for user CTCSS and a separate one to indicate a commandtransmitter 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 discreteCTCSS ON or to interface using a bit-serial interface for transmitter CTCSS generators soequipped.

1.1 The controller will be capable of responding to a COS on any defined receiver within adefined system and connecting that receiver to its transmitters, subject to timer validation andchanges made to tables by users or control stations. Each receiver and each transmitter shallhave its characteristics stored in memory, and loadable from SD card, located on itself orfrom 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 inincoming 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 itspre-defined or control-modified table, the controller will disconnect all connections for thatreceiver and will not re-connect them until such time as the COS goes inactive, at which timethe timer will be reset.

8/4/2019 Gen 4 Spec

3/16

1.5 The controller will allow a control station, by dialling a command code, to enable ordisable each receiver and transmitter separately. If the receiver is disabled, it will notrespond to any COR assertions except as needed to detect further DTMF. Transmittersassociated with disabled receiver will still be able to be used as link outputs unless disabledseparately by command code.

1.6 The controller will allow a control station, by dialling a command code, to prevent anyreceiver form responding to DTMF. When such code has been dialled, and until re-enabledby another code, the receiver's DTMF operation will appear normal to the user, i.e. Thatmuting and transmission of fake tones will occur, but the codes will not cause any changes ofstatus in the repeater. When the receiver is in this mode, a report will be sent on thecommand channel which reports all codes attempt, whether valid or not.

1.7 Under MCU control, all receiver audio will be digitised and either:

a) Output from a DAC to its local transmitterb) 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 onboth the main and auxiliary interfaces

1.8 In case of MCU or program crash, the watchdog circuit will cause an output signal toreset the switching logic on the controller card, enabling each main receiver to be connectedto 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 ameans of disconnecting one receiver when the other is receiving DTMF signals to avoid audiomixing. The DTMF MAIN signal, when asserted, causes the audio from the main channel tobe connected into the DTMF decoder. The audio connection into the DTMF decoder will beconnected permanently to any sole channel whose COS is asserted. If both COS signals areasserted 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 forseven seconds, or such time as may be configured (DTMF initial connection time). No DTMFdetection shall take place on any receiver after this delay. If more than one receiver has COSassertion at the same time, the DTMF decoder will be alternately connected to each onewhile its COS is asserted and its local timer has not expired. If DTMF is received during theDTMF initial connection time, the initial connection time shall be extended by as much as theDTMF timeout time.

An exception to the above is that if one channel is designated as a command receiver, itsCOS assertion shall caused the DTMF decoder to be locked on to the command channel; Incomplex mode, scanning will be disabled and each receiver main will be connected to itscard's decoder.

8/4/2019 Gen 4 Spec

4/16

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 beflushed;

2.0.2.1 The COS on the receiver connected to the DTMF decoder de-asserts, at which pointparagraph 2.0.3 will be taken;

2.0.2.2 A control operator override occurs at which time any DTMF presently beingassembled will be ignored, and the buffer flushed

2.0.3 The assembled digits, terminated by receipt of COS de-assertion are looked up in acommand 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 samethings as others. Optionally, one controller in a system may be designated as the codestorage controller so that others will copy its codes into their own memory. This will allowchanges to a whole system to be made by changing the designated controller and resettingall the other cards. Such a system code table shall consist of all tables superimposed overeach other with a common end point. In this way, some receivers higher up in the chain willhave more codes assigned to them than others. This can be used, for example, to allowmore codes to be dialled on COMMAND than on repeater 2, and more codes on repeater 2than 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 bechecked.

2.1.1 If set, the audio connection between this receiver and all associated transmitters willbe cleared, and the same transmitter will be held on the air by an output line directly from themicro (TAIL signal) If linked to an off-board digital connection, the channel number and amute code will be sent to hold the remote transmitter on, so as to avoid users jumping in and

8/4/2019 Gen 4 Spec

5/16

causing interference. Optionally, a micro-generated sequence of audio tones can be sent ofa different DTMF digit to confuse would-be decoders of the system's codes. The fake tonepair does not need the stability of the DTMF chip, and the DTMF chip shall not be used tosend 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 willbe re-connected its receiver.

2.2.0 If DTMF reception is terminated due to a timeout, as in paragraph 2.0.2.0, thereceiver'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 COSasserts, the timer will be started, and when the COS de-asserts, (after a tail time preset in thereceiver'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 tothis receiver until:

3.1 The COS de-asserts, at which time the time-out flag will be cleared, and further serviceis possible.

3.2 A DTMF code is dialled to reset the receiver, at which time a COS de-assertion andassertion will be simulated.3.3.1 CW 'RTO' or the voice equivalent 'RECEIVER TIMEOUT', will be scheduled to be senton 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 toit 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 willbe 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 asa last resort hardware timer having a period of 15 minutes or thereabouts.) The timermentioned here determines time between COS de-assertion and beep tone.

8/4/2019 Gen 4 Spec

6/16

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 toin 6.0 has expired following de-assertion of the receiver's COS. The receiver's timer will bereset before the beep is scheduled.

6.2 Each receiver will be assigned a different beep tone to indicate to users which receiverhas just ceased receiving in a multi-repeater link.

6.3 If any transmitter keyed by the beep request is within n minutes of its hardwaretimeout, no beep will be sent. (n definable in transmitter TCB). This will force COS de-assertion, receiver and transmitter timer re-initialisation, and station identification.

IDENTIFIERS

7.0 Each transmitter will have provision for a separate callsign, however, more than onetransmitter 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 shallsimply give the callsign, and the informative shall include other data such as location, accessmethods, 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-configurableand stored in SD card by means of a separate utility provided for use in an offline PC typecomputer.

7.1 For the purposes of identification, each transmitter will, at all times, be considered tobe 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 iskeyed, plus a further time period presettable in the transmitter's TCB. At the expiration of thisperiod, the transmitter will be flagged as dormant.

7.1.2 A transmitter will be considered to be in beacon mode after a 'start beacon' commandhas 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 causesuch transmitter to go to active mode, but such transmitter will return to beacon mode insteadof 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 setagain two minutes after an ID has been sent. The ID will be scheduled under the followingconditions:

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.

8/4/2019 Gen 4 Spec

7/16

7.3 If the transmitter is in beacon mode, the dummy card will hold the transmitter on for anominal 30 seconds after I.D.

LINKING

8.0 There shall be provision for linking, on DTMF command, between any and all definedrepeaters 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 andshall 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 withno 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 beconnected 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 beconnected 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 linkrepeater, and the code is associated with another repeater defined within the same digitalsystem, then the requester is connected with the requested repeater and vice-versa, withouteither 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 eitherrequester or requestee, then such links will be replicated, both ways, to the requestee orrequester respectively, as appropriate.

8.1.5 When a link-on has been completed, then the requesting repeater's call will be sent onthe 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 placeafter the call sign.

8.1.8 When a link is in progress, the beep tail will be enabled on all receivers taking part inthe 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 linktimer disable code has not been dialled, then a link disconnect will be forced as if a link-off

8/4/2019 Gen 4 Spec

8/16

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 eitherdirectly or indirectly attach to a telephone line. In direct connection, the telephone line willterminate in a hybrid phone patch at the repeater site. Turning on the autopatch repeater'stransmitter will cause a relay to pick up and connect the phone line. On connection, theCOS will be asserted on the autopatch receiver. The autopatch routine may then proceed todial.

In the indirectly-connected mode, appearance to software will be the same. As far ashardware goes, keying the transmitter will cause an actual transmitter to go on-air, which willactuate a receiver at the remote phone site. At the phone, a relay will connect the phone lineon COS assertion, and turn on the UPLINK transmitter on completion. (The hardware foreither 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 theCOS is asserted on the UPLINK receiver. Note: The downlink audio will not go into thephone 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 oneof 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 'BADSIGNAL' bit is set for the requester when an autopatch request is received, then the controllerwill 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 notdefined, not available, or flagged as defective, then CW 'NAP', or the voice equivalent'SORRY, AUTOPATCH UNAVAILABLE' ,is sent on the requester's transmitter, and therequest 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 voiceequivalent 'GO AHEAD' is sent on the requester's transmitter. The DTMF decoder is lockedonto the requester.

8/4/2019 Gen 4 Spec

9/16

9.2.2.2 The requester's transmitter timer is set to 15 minutes and the requester's transmitteris 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, thefirst or second digits are not 0 or 1, and that the entire number is not in a prohibited numberfile in memory.

9.2.2.4 If the number dialled is '911' then the immediate autopatch request will be abortedand an emergency speed call autopatch will be forced on the requester's repeater withoutfurther 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 toemergency speed call), or a timeout, are encountered, the immediate request will be abortedand CW 'NBR', or the voice equivalent 'BAD NUMBER', will be sent to requester'stransmitter. 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. Afifteen-second timer will be set. CW 'AS' , or the voice equivalent 'WAIT', will be sent onrequester'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, theautopatch will be flagged as defective. CW 'NAP' , or the voice equivalent 'SORRY,AUTOPATCH UNAVAILABLE' , will be sent on the requester's transmitter, and the requestterminated.

9.2.2.8 A test will be scheduled every minute for five minutes to see if the autopatch still failsto 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 becleared and the tests stopped. Regardless of the outcome of the test, an alarm message willbe 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 associatedreceiver

9.2.3 CONNECTED PHASE

9.2.3.1 When the COS on the autopatch receiver is asserted the number to be dialled will betranslated, digit-by-digit, into a different number using a 16-element lookup table, whoseentries 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 theuser's transmitter. Note: The autopatch end will only pass audio from the user into thephone line after this point.

9.2.3.3 The requester's receiver is then connected to the autopatch transmitter and theautopatch is flagged as waiting for a disconnect code.

8/4/2019 Gen 4 Spec

10/16

9.2.3.4 If, at any point during this stage of the autopatch command CTCSS appears on therequester's receiver, then the autopatch will be aborted immediately as if the disconnect codehad been dialled.

9.2.3.5 If, at any point during this stage of the autopatch, the COS from the autopatchreceiver de-asserts, then a six-second delay will be started and continuous tone will be senton requester's transmitter. If the autopatch COS has not been re-asserted at the end of thesix-second delay, then CW 'NAP' or the voice equivalent 'SORRY, AUTOPATCHUNAVAILABLE' , will be sent to the requester when the requester's COS is de-asserted. Thepresent autopatch request will be aborted, the autopatch flagged as defective, and the testroutine 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 thevoice 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 re-initialised. 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 asin paragraph 9.2.3.8.

9.2.3.7 The disconnect code will be an octothorpe, or another single- or multiple-charactercode 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 voiceequivalent 'END AUTOPATCH', is sent on the requester's transmitter, and the autopatch willbe disconnected, flagged as free, and any emergency flag associated with the autopatch willbe cleared.

9.2.3.9 As soon as the autopatch is terminated, or aborted for any reason after the autopatchcode 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 dialledUUUU is the user code if this feature implementedMM:SS is the length of the call in minutes and secondsS is the success code:

B = bad number ( not 7 digits)C = COS timeoutD = dumped by command stationE = Pre-empted by emergency speed callF = negative file callH = hardware failureL = attempted LD or operatorN = call completed normally

8/4/2019 Gen 4 Spec

11/16

S = cancelled due to excessive emergency speed callingT = timed out

T is the type of call:

R = regular autopatchS = regular speed callE = emergency speed call

9.3 EMERGENCY SPEEDCALL OPERATION.

9.3.1 The numbers between 911 and 939 are reserved in all systems for emergency speedcall use.

9.3.2 The emergency speed call feature will only be available on those repeaters with anenabling bit set in their TCB.

9.3.3 The emergency speed call feature will be disabled if 4 attempts are made to dial a900-series number within 2 minutes. If this occurs (deliberate misuse suspected) thecontroller 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 featurewill 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 alookup table which will translate them each into a regular 3 to 11 - digit telephone numbercorresponding to a Police, Fire, or Emergency number.

9.3.6 On entry to the emergency speed call routine, the controller will attempt to find aworking, 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 senton 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 the900 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 thespeed calling routine is merely a front-end to the regular autopatch routine, all rules of use for

8/4/2019 Gen 4 Spec

12/16

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, setapart 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 thecode that was dialled as an argument. The speed call routine will then look this code up in atable, and, if no match is found, then will send CW 'NBR' or the voice equivalent WRONGNUMBER', to requester's transmitter.

9.4.4 If a match is found, the controller will turn on CTCSS on requester's transmitter, settransmitter 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 andcommand 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 thespeed 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 11digits, 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 numberscan be blocked, and the numbers translated to corresponding number to avoid ANI-ALIresponses 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 eitheran 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 containedon 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 latchesbeing left disconnected.

10.1.3 The direction of each bit will be set in the configuration tables for the repeater andmay be changed by DTMF code.

10.1.4 Each output bit shall be settable by command code, with an 'OK' response indicatingsuccess, and each input bit will respond to an interrogation code by CW or voice 'ON' or'OFF' respectively.

8/4/2019 Gen 4 Spec

13/16

COMMAND CHANNEL

11.0.1 A receiver-transmitter will be assigned as the command channel. This will be theprimary command channel for the system.

11.0.2 The serial communications adapter (SCI) of the micro controlling the receiver andtransmitter assigned to be a command channel shall be interfaced to a modem, which shallbe connected to the command receiver and transmitter as follows:

11.0.2.1 When no CTCSS is detected on the command receive channel, normal operationwill be for the receiver to be connected to the modem. When the monitor program sees thata remote modem is connected, then the local modem will be connected to, and key thetransmitter. 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 ASCIIcharacters 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-digitpassword has been entered.

11.0.3 A monitor program shall provide basic memory examine and change functions, aswell as duplicating all command codes used in DTMF, and provide reports on systemoperation 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 forrequirements.

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

8/4/2019 Gen 4 Spec

14/16

keyboard to all terminals on command net, for commentary and logging purposes. Thismode started by typing and ended with .

11.1.6 Send log entry every time emergency speed call disabled or enabled, including alarmbells 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 SDassociated 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 maybe exceptions to this rule for privileged codes only, and no such codes may be executablefrom 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 thiscase decoding of codes will be suspended when such a code is dialled until the required datahave 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 thevalidated data have been received for each code, or an inter-digit or total code timeoutoccurs. These timeouts will be assignable on a system basis.

8/4/2019 Gen 4 Spec

15/16

DATA STORAGE

13.0 Each controller card shall be provided with a socket for a standard consumer-type SDcard.

13.0.1 In simple mode, the SD card for each controller shall contain all configuration detailsand 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 cardon a designated controller may supply the information to all cards in the local site (Master SDCard)

13.0.3Master SD-card loading of parameters between sites linked by radio is notcontemplated

13.1 A disk-based supervisory system may replace the SD card usage by sendingrequested files from its hard disk as each card is reset, if the local card does not have an SDcard or does have an SD card but is set to override local settings when remote settings are

available over the CAN bus

13.0.1An optional disk-based supervisory system with remote TCP/IP access may be used tocontrol all features in a complex system, including overriding settings in the configurationtables 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 flashmemory 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 consumer-grade PC equipment and stored on an SD card in a format acceptable to the controller by aseparate configuration utility supplied with he controller.

14.1 All CW callsigns and prompts used in the system shall have an equivalent voiceversion, if configured by the owner.

14.2 There shall be a facility for recording up to 10 seconds of test audio from a userreceiver, at a user's unprivileged request signalled by DTMF, which will be played back on theuser's transmitter once only as soon as COS for that receiver is de-asserted, whether the tenseconds 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 (subjectonly to available SD card space) on privileged command by command stations, which shallbe playable back but not deleted or re-recorded by user command on any channel specifiedby user configuration.

8/4/2019 Gen 4 Spec

16/16

GLOSSARY

ARIC - Analog Radio Interface Card, interfaces standard analog radio to the CAN busCIVIC ICOM CIV-Equipped-Radio Interface Card (Proposed)Control operator override The occurrence of an event, such as the CTCSS tone beingdetected on a receiver which is designated as the command channel for the system, or asimilar 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, 100BTELIC Echolink Interface Card (proposed)IRLPIC IRLP Interface Card (proposed)MADI - Metropolitan Area Digital Interface, interface megabit link to other repeater stationsMCU Micro Controller UnitVoIPIC VoIP Interface Card (for private VoIP system) (Proposed)SHIOC shack I/O card, interface CAN bus to voltages and relays etc in the shackSIMPLE MODE The use of a single controller card as a standalone repeater, controlling amain transceiver and an auxiliary transceiver

xRIC Radio interface Card, either digital, analog, or other