On Apr 10, 2009, at 12:02 AM, john_ke5c wrote: > > -The One-Touch reply works only for those JA stations who are > populated > > in one of G2 gateways (this is his/her default gateway). Most likely > > those JA stations got registered to use DVDongles. > > Kay shares a key point - this only works for 20 or so of the J- > Landers: >
Yep, it is in interesting "side-effect" of two different things... non- US-Trust-Server stations being registered on the US-Trust-Server because they own a DV-Dongle... And the code added to the local Gateways to "cache" local port changes and make them faster, if a user switches modules/bands on the same system. What's interesting about this is the "caching" was reported not to be able to "know" which port a user came in from, thus it doesn't help a "roaming" user too much who jumps from Gateway to Gateway, even if they key up and talk back to the other person. If you recall, without any data to back it up, I was surmising a while back that if a Gateway could cache the information received from OTHER Gateway during a transmission (including which port the person was on) and compare that timestamp to the last known update from US Root, the whole "roaming" thing could be made to work MUCH faster, as long as you were continuing a conversation with someone who wasn't switching Gateways. So... I'm starting to think this leads to something that could be helpful for some... this JA thing helped me "see" something else here. Let's say I'm talking to John and he's mobile, and we're callsign routing. I'm "parked" for all intents and purposes on W0CDS Port B. John is on Gateway-A, we'll call it. John "roams" out of the coverage area of Gateway-A. We all know that this means today that me routing to UR: KE5C... is going to stop working at that point. John is now on Gateway-B, we'll call it... but the Trust Server and my local Gateway think he's still on Gateway-A. But, if John continues to callsign route to ME, continuing the QSO, we know that part will continue to work. I haven't moved Gateways. Now, if John says into his mic, "Hey Nate, I just switched systems... I'll stay keyed here for a moment while you hit your ONE TOUCH button..." That... should work. My rig -- not the local Gateway caching -- copies his new "routing" information into temporary memory, and now routes to the repeater he's on at each key-up, completely bypassing the lookup that normally has to take place when I'm routing to UR: KE5C. The rig is now going to route directly to whatever it "copied" from John's last transmission. This works as long as John stays on Gateway-B. If John travels out of coverage of that system and into a third, he just has to tell me again, so I can hit the one-touch button again. Effectively we're doing our own "routing", and you don't need the callsign roaming at all anymore. You can use it to "find" someone for the initial call-up, but if they move to another port, gateway, etc... and just TELL you to hit your one-touch... it's all going to work normally until they move again. So... "mobile roaming" with callsign routes DOES work, but it requires one more step at each "handoff" today. It's not really using the network to handle the roaming, it's just a knowledge of how the system works and an extra manual step to tell your rig "copy down where John is right now and route there". Do I have anything wrong there? Is that scenario correct? It sure sounds like with a little preparation/training on how it all works, users can easily hit their one-touch and "follow" any mobile user, moving from system to system... and it might not have been an "obvious" solution to those who are miffed that callsign "roaming" doesn't keep up with people changing repeaters "mid-flight". -- Nate Duehr, WY0X [email protected]
