Arcom's new RC810 supports site prefixing. I wonder if that has anything to do with the fact that Ken is originally from Southern California (grin)?
73's Skip WB6YMH --- In [email protected], Ed Yoho <[EMAIL PROTECTED]> wrote: > > Nate Duehr wrote: > > >DISCLAIMER: I haven't had a chance to try it on a real controller to > >see if it happens fast enough, so it'll react quickly enough, and my > >7K is currently up on a mountain filling in until a few 7330's > >arrive. (GRIN) > > > >Here's a way to do it. I don't know what number of macros you could > >get away with, but probably enough. I'm too tired to look up the > >limits and do the math. > > > >First off, on all sites... > > > >SITECODE12345* does something on a specific site and these macros are > >always active and programmed separately into specific controllers. > > > >Next, set up a hidden start-of-activity macro on all controllers on > >only the local user port's receiver (RX1) that renames macros stored > >in "parking" macros to the local macro commands that users would use > >locally. The parking macros are unpublished. Example, A12345 gets > >renamed 12345, and A23456 gets renamed 23456. > > > >A12345* (and it's cousin, the renamed 12345* whenever local user > >activity is present) is a macro that calls the local repeater's > >SITECODE12345 macro. > > > >During "local commanding", other repeaters in the network will be > >listening for the "parking" macros and won't respond to the command. > >Only the repeater(s) with active RX1's will respond to the "local" > >commands. > > > >Then an end-of-activity macro calls a 2nd hidden macro that names all > >"local" macros back from their new 12345 to A12345. > > > >Now, obviously that leaves a problem... if two repeaters in the > >network are both keyed on their user inputs when a so-called "local" > >command is executed, both will respond. > > > >To make this more robust... > > > >You tell end users that "All commands are available by typing the > >sitecode and the command on any repeater. However, if you don't want > >to type the sitecode, press 1* plus the command on your local repeater." > > > >In this case, you set up 1* to mute DTMF. Your end-of-activity macro > >now must both copy the local macros back to "parking" and unmute DTMF. > > > >(In fact, if you do this you don't need the start-of-activity macro > >at all, but I like that one better. You could have *1 do both setup > >of the macros and the DTMF mute.) > > > >To make this work, the default "*" as "enter" key option in the S- > >Com, must be on. This is so users don't even have to unkey to have > >the 1* execute. > > > >The users don't have to know the preceeding 1* is a separate > >command. They just know to prefix any local "simple" command with > >1*. If they hit 1* and drop key, the local controller will > >immediately revert back to only responding to the SITECODE commands, > >and unmute DTMF, resetting everything back to the state where any > >machine in the system can respond to either a local or remote > >SITECODE prefixed command. > > > >-- > >Nate Duehr - WY0X > >[EMAIL PROTECTED] > > > > > > > > > Nate, > > Renaming macros whenever the mobile input is active would cause all link > command ability to be blocked as the macro numbers the link is looking > for are currently non existent. For the majority of the time, this would > not be a big problem. If however there is a problem with the mobile > input receiver (RX1) on a site from either a failed receiver or a > problematic user sending unwanted transmissions, you would not be able > to resolve the issue from a distant repeater via the links. > > Processor load could become significant if you have lots of macros that > need to be renamed every time the mobile input COS goes active or > inactive. What happens to the poor processor when a signal is picket > fencing or a 'fly' decides to intentionally send short on and off > transmissions (rapid kerchunking). > > The whole idea of implementing pre-access or prefixing is to emulate the > functionality of the public telephone network command structure (not > exact, but similar to the simplicity of dialing a phone). Anywhere you > go within the system, dialing a local number (sending a local command) > gets connected to a local client (if the number is valid). Access to > that same local number from outside the local area code (a different > repeater) is accomplished by simply adding the area code (site prefix) > to the desired client number (command sequence). > > Simply adding command prefixing on a per port basis resolves all of > these issues. This method also allows all commands to always be > available to all ports. Each time the port specific pre access DTMF > sequence is received, the following DTMF digits are processed during > that specific transmission. > > Ed Yoho > WA6RQD >
