Pacific Research Solutions RI-300e User Manual
Page 122
SETTING UP AUDIO CHANNELS The auxiliary audio buss is set up at the factory by default to work with flat audio (audio without emphasis). If your application
requires something other that flat audio, you may change the emphasis with jumpers (JP2 and JP3) on the analog board. See
section 17 for more information.
To set up the auxiliary buss for multiple controllers, you must first define a unique address (Using S-Command 39) for each
controller on the buss. This address will also be the address of the audio channel that is used by the assigned controller. A
controller that has been assigned address 1 will use channel 1 of the audio buss.
For best operation of your system, use S-Command 34 to enable each controller to output audio on the auxiliary buss at all
times. The mode of S-Command 34 will determine when audio is output to the buss. If you use modes 2 or 3 to output audio,
you will need to set up the Auxiliary Tone Panel with the tones and/or codes that are required at the controller’s receiver for
audio output. When audio is output onto the buss, the sending controller will send the correct data packets so that other
controllers will know to process input audio from the buss.
Now that you have set up a controller address for the auxiliary buss and enabled audio from each controller to the buss, you are
ready to route audio. At this point, routing audio is as simple as enabling an input on a controller or defining to what channels a
controller will listen. This function is controlled by S-Command 35 and can be set as a default mode or integrated into a user
command with a macro. S-Command 35 will also allow you to define what audio from the buss is mixed with the controller’s
receiver audio or is muted when the controller’s receiver audio is active. The last item in S-Command 35 will allow one
controller port to monitor another controller port and respond to some of its functions, such as automatically regenerating
DTMF that is decoded by a source controller or regenerating CTCSS that was decoded by a source controller.
If you have two repeaters connected to the buss and you wanted to build a user command to connect them together, the user
command would call a macro that would only need two S-Commands. The first S-Command 35 would enable this controller’s
input channel from the other controller. The second S-Command would enable the other controller’s input channel from this
controller. Since the second command is coming from the first controller, it would have the “Ax” prefix to the S-Command 35.
If you chose to mix all audio, the users on each repeater could be full duplex and would be able to have a continuous
2-way conversation just like a telephone.
If you have attached a dedicated controller/port on the auxiliary buss with either a half duplex radio or simplex remote, you may
not want to repeat audio through that radio. To avoid a repeat aud io path, only use system modes 5, 6 or 7 (S-Command 01).
This will keep the radios receive audio from being routed to its transmitter. When using these modes, do not try to repeat the
buss audio by having the controller listen to its own auxiliary buss channel.
PASSING S-COMMANDS BETWEEN CONTROLLERS When creating a user command that is decoded by one controller, but is intended to adjust a value in another controller, you can
create macros that pass S-Commands from one controller to another via the auxiliary buss. Send these commands by adding the
destination controller’s address to the front of the S-Command. If you want controller/port #1 to send an
S-Command to controller/port #2, you simply insert an “A2” in front of the S-Command (and its data) into the macro. All data
from the “A2” through the “C” (S-Command separator) will be sent to the controller with an address of 2 (S-command 39) .
You can also call a macro in another controller using S-Command 67. It should be noted that a jump (S-Command 68) will
function the same as a call in this configuration. This procedure of calling macros in other controllers is best, because it
reduces the total amount of data that must be sent on the auxiliary buss. This is because each time a controller sends an
S-Command to another controller on the buss, the controller has to wait for a return acknowledgment before it can continue
with the macro. You should avoid conditions where controller #1 calls a macro in controller #2 and then the macro in
controller #2 calls a macro in controller #1 or any other controller. However, additional calls within controller #2 would be
OK.
If you want a message played in another controller, it is best to build the message in the other controller. Then call the macro
line from the first controller. This will start the message and allow macro control to return back to the calling controller.