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
