Pacific Research Solutions RI-1 - Manual (Page 67)

Pacific Research Solutions RI-1 and PE-1 User Manual
Page 61
SETTING UP AUDIO CHANNELS
The auxiliary audio buss is set up to work with flat audio (audio without emphasis). If your application requires something
other that flat audio, you may change the emphasis to and from the receiver and transmitter port using JP4 an S-Command 00 3.
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. The RI-1 also requires that you jumper the
audio channel that you plan to use. This is addressed by JP-1. See Section 6 “Setting up the RI-1 Auxiliary Interface
Connector”.
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. 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 36 will 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 RI-1 is limited to receiving audio from the
auxiliary buss on only 1 predefined channel. This channel is controlled by JP-1. See Section 6 “Setting up the RI-1 Auxiliary
Interface Connector”.
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 audio path, use S-Command 01 mode 0. 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 within a macro. 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 68. 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.