Folks, There are basically three options
A) Use the Icom Gateway Software and Robin's DPLUS Software B) Use the Icom Gateway Software only C) Don't use any gateway software There are probably a million other ways that different people want things to work, but, they aren't available right now. I personally wish that the Icom software never implemented call sign routing and did linking instead, but I get what they want to deliver. Same with Robin, I can make suggestions, but since he wrote it, he gets to control it, that's just the way that life works, and I'm fine with it. For all of those who don't want the DPLUS software to route call sign routed packets into the network, there's just as many of us who think that it is working they way it should. So no matter what Robin does, a number of people are going to think that it is wrong, he can't win. We got what we got, instead of complaining about how bad it works, why don't we think of ways, using the existing system, that we can do things to make it better? This thread/discussion has popped up probably a dozen times now, it's getting quite boring and wasting people's time. Ed WA4YIH From: [email protected] [mailto:[email protected]] On Behalf Of Bob McCormick W1QA Sent: Monday, August 10, 2009 8:07 PM To: [email protected] Subject: RE: [DSTAR_DIGITAL] Wouldn't It Be Nice ? Adrian VK4TUX shaped the electrons to say: > Very good point Fran, really the onus is on the operator > to unlink before undertaking a routed session. Thats probably > the reason Robin did not adopt the idea and implement it. OK - but what if the admins / trustees don't want people to unlink? Or if they do unlink - are they going to put the link back after they are done? Running a cron job to do this (restore linking) is a hack IMO ... > Another idea may be perhaps an automatic unlink by dplus > when it detects a non cqcqcq call within the gateway. > Unlinking will be the only solution to stop incoming > dplus streams during a routed qso as you described. OK - I would accept that if the linking could be automatically re-established, for example, after a certain amount of inactivity after being unlinked (because of the non UR=CQCQCQ) ... Still: Let's say you have two, three or four repeaters that are connected to a regional reflector - to make in effect a regional repeater covering a larger area. And then assume you have users that communicate across the reflector - some users use system A and some users use system B - and rely on the dplus reflector support to seamlessly link the systems together. If one of the repeaters becomes unlinked from the reflector (either through command or software detection) ... one would likely find users on the remaining (still connected) repeaters not knowing that the other system is unconnected. To me (as a user) that would be very frustrating ... especially if I made use of the fact that I could talk (use) my local D-STAR system to regularly speak with other D-STAR users that can't necessarily reach/access my local system. Does this make sense? My personal opinion: Although on the onset I was sold on the standard ICOM gateway callsign routing capabilities ... as we have built out our sites I am much more interested in the dplus and reflector capabilities. And this is being mentioned by someone who does do a fair amount of travel. Hopefully the ideas and comments in this thread are being captured by those working in the background on new, improved D-STAR capabilities! Bob W1QA
