I did say "as designed", John. The roaming slowness is a fixable problem with enough eyeballs on it, and is directly related to the growth of the system, I would imagine. I don't see it as a way to "roam" between local repeaters as much as it is a way to find someone "anywhere" when they really "roam" around. Judging by the look I've had into the Gateway here, I can't imagine that Icom spent any real time optimizing the DB or doing other things I as a professional Linux/Solaris admin would have been REQUIRED to do to a production centralized server system. but that's just my guess.
By the way, putting my money where my mouth is, I'm open to logging into whatever box and carefully looking at data to figure out what's going on, if someone wants to take me up on that offer, but I don't think I'm "smarter" than any of the folks currently running the central system. I've administered MUCH bigger and far more critical boxes that do similar things in telco for over a decade now. one estimate put a single system at $40K/hour lost in direct billable cash revenue, if it is ever down. and there's MANY of those systems I'm responsible for in my support role. One database drop table by a customer was estimated at $2 million lost in billing data. (They really shouldn't have done that. but we wrote a perl script to recover the data from the plaintext logs and stuff it back into the DB.) Anyway. back to D-STAR. Roaming for local use probably doesn't work as well as we'd all LIKE it to, today. due to the suspected growth issues, mentioned above. But locally, all the users know the callsigns of the local repeaters (or should!) and repeater routes can be programmed into people's rigs, and probably should be, if they really understand D-STAR. so they'll have the appropriate routes already in memory locations, ready to use. Not hard. All the Japanese hams are doing it, obviously. Multicast. I can't comment any further on. I'd be interested in what "works poorly" means, though. That's not detailed enough for me. :-) The fact that people don't use it, isn't necessarily a sign that it doesn't work - It can also be a sign that they just didn't "get it" very well. (Which I don't doubt kills many a good technology. Human interface factors often trump the tech, no doubt!) Someone has to be an advocate for the built-in features of the system. I figured I'd play devil's advocate on the list. I've held a number of callsign-routed conversations all over the country, and of course, you and I have talked on REF001C, and others. I go both ways, so to speak! I just figured that a posting that says "Reflector linking is the only way" or gives that impression - isn't "fair" to the rest of the quite-good technology that Icom built. People don't try it. and don't see the ORIGINAL feature set as powerful. It is. Way more powerful than old-style "linking", for many applications. Could Icom's callsign routed world, and Reflectors BOTH be better? Sure. what couldn't? I know this. We all do. I just wanted to point out that callsign routing really does work fine, and it's not something to take for granted. it's a feature in the system that's pretty amazing really. I held a callsign QSO from Hawaii to a friend back home, in November when I was there, and it was utterly painless. Try doing THAT on *ANY* other linking system, Amateur or Commercial! (Cell phones don't count! LOL!) Fun stuff, either way. happy Friday! Nate WY0X From: [email protected] [mailto:[email protected]] On Behalf Of john_ke5c Sent: Friday, March 13, 2009 7:13 AM To: [email protected] Subject: [DSTAR_DIGITAL] Re: D-Star to "listen" to reflectors or distant repeaters > Callsign routing also has the excellent additional benefit in that it > will "follow" anyone anywhere in the network, as long as they've keyed > down ONCE on the local repeater... wherever they may roam. If you > put "WY0X" into your rig, and I go to California, Hawaii, or even just > switch modules on our local repeater stack... your call will find > me... as long as I've keyed once. DStar callsign routing does not provide the nearly instanteous roaming that you may be used to with your cell phone or a trunked two-way radio system. Folks have posted on this in the past, and when the gateway system software was working correctly, a four to ten minute delay was pretty common for the roaming database to catch up when a user keyed up on a different gateway. So if you are driving along the highway and switch from one repeater-gateway to another, folks trying to callsign route a DV stream to you will be unsuccessful for about that length of time. Lately the gateway database synchronization has been slower and sporadic, and some gateways were not updated for days at a time. When this happens, callsign routing will fail to work for folks who have "roamed" to a different gateway. Slash routing to a gateway band module (UR=/KE5RCSA)and dplus gateway linking still work so long as a gateway has not changed its IP address. > The "fix" Icom put in for large groups of repeaters is the Multicast route. > This requires some pre-setup by the Gateway operators, but also > works well, from what I've heard. Multicast must be statically set up in advance by each gateway sysop and works poorly when more than a just a few gateways are involved. Each involved gateway has to send a DV stream to each other involved gateway. That it is not used more is confirmation that it does not work well. Oh, and you cannot call sign route to join in a multicast QSO. 73 -- John [Non-text portions of this message have been removed]
