> 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.
Nope read again. SITECODE12345 always works, everywhere. The macros that are changing are the local control macros. So yes, if the local RX1 is "stuck on" by something/someone, the local control op (who would have a clue, vs the end-users) would simply use SITECODE12345 when 12345 didn't work. > 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). Yep. Didn't say it was perfect. > 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). Around here, we had an overlay of two area codes, and "local" dialing has been gone for half a decade. Everything, including local is ten-digits. And the translation numbers to the full 10 digit numbers that had to happen for virtually every call in the switch (SS7 routing) all went away, and the translation numbe rtables got a whole heck of a lot smaller. Simple is good. :-) But I see what you're trying to do. Sounds like too much for a repeater controller. But if the controller could tell which port the DTMF command came in on, all of your problems go away... it could be easily implemented in any controller that could do that. (Same as the phone network, only the Class 5 switches handling the local loops had to deal with local vs. long-distance... the backbone always was the full ten digits, and nowadays, we can even tag inbound DNIS and ANI in the VoIP world (SIP) with any valid ASCII character... but there was always a translation from that "simple" dialing pattern to a specific routed number in the back-end.) Come to think of it... you could implement that... the controller always has DTMF muted and sends a whole new string out to the other site via the link radio... the users have a simple dialing pattern locally, the complexity is handled by the "backbone switches"... just like telco. Another option for ya... > 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. Doesn't this also mean you run into the same problems telco traditionally had? Example: If a local user in your desired setup dials : 2312345 - it's a site code and the 12345 command. 12345 - it's handled locally. But that means 23123 can never be a local command. You end up having to have a matrix of things that are "already used" if you don't have an "enter" key and probably also a "we're dialing long-distance" key "1" in the NANPA telco world... I still don't "get it"... what the heck would you want repeater USERS sending commands to far-away repeaters for, anyway? Could you be more specific about the commands? I just can't think of many I'd want to put in the hands of the end-users, really. Well anyway, I tried... I think there's a ton of other ways to manage it other than the site prefixing method... most of the time, end-users can't remember the local commands to do anything anyway unless you have a pretty savvy group of end-users. If you only have a small core that would use it anyway, they're going to be clueful enough to follow a cheat sheet and they'll probably happily copy it into their PDA or phone or carry it around in their wallets... All you'd need is a sitecode list on a business card to permanently fix the problem, right? :-) :-) :-) We already do this out here with the commands for eight sites worth of 121.5 ELT receivers... each site has it's own prefix code, and the rest of the command structure is the same at all sites... but there's no need for a "local" code... just a wallet card with the list of commands and site codes... takes about ten seconds to grab wallet, look at card... can even ID while reaching for it, and then command whatever I need to command. Been doing that for 10 years now... doesn't bother me. -- Nate Duehr, WY0X
