--- In [email protected], "Nate Duehr" <n...@...> wrote:
> What MIGHT work well on a multi-repeater D-STAR "stack" is setting local > policy that a particular MODULE is where that type of thing goes on, and > keep the other modules "quieter"... for example, one could gateway stuff > from APRS to D-STAR only on module C, while local users would be > encouraged to chit-chat and use the system regularly on Module B. Nate I think you have hit the nail on the head here. It seems that many SYSOPS are concerned (and rightfully so) about the data traffic from apps such as DRATS, DSTARComms, DChat and others, that they discourage their use. Auto beaconing of DPRS falls into this same category. For DSTAR/DPRS to ever become a viable replacement,or even an augmentation to the existing APRS network this issue needs to be addressed. A larger issue is the use of data apps on Dstar in general. The solutions seems simple but will require a consensus of the sysops to enable such a thing. Your suggestion of designating certain modules (on full stacks or multiple module systems) makes a lot of sense. Most of this effort has been towards the Digital Voice (DV) side up to this point with a few sysops suggesting local chat only traffic on certain modules. i.e. Local ragchewing on port b and linking on port c One of the key selling points of DSTAR was the ability to do data and voice simultaneously. While this can be done, we have all learned it is best for just position reporting as anything more just ties up the repeaters. Auto beaconing (akin to APRS) just adds to the mess by placing more traffic on the systems. With APRS we have a dedicated frequency for such traffic and is not intended for voice. Trying to use the "close call" feature of APRS in a metropolitan area during drive time is like trying to break a pileup on field day weekend. Data and voice need to be on separate frequencies. It's the way we do it on every other ham band. Maybe that's what we need for Dstar. Encourage the use of port b for voice and port c for data and beaconing. ( Although the other way around would probably work better due to the 2m side being more susceptible to multipath) A more ideal situation might be to have 2 "B" modules in a stack. One for voice and one for data. I realize this goes against Icom's marketing philosophy, as they would rather we buy the 1.2 GHZ module and radio but the benefits don't seem to outweigh the cost for most of us. Has anyone ever done this? Can it be done? As I understand it, a controller can accommodate up to 4 modules. Just a thought... With the decreased activity on most local area DSTAR systems it seems evident that for DStar to survive we must encourage the use of its full capabilities i.e. voice, data, and position reporting. There are many hurdles to overcome but simple discussion and cooperation will go along way to ensure the future of Dstar. Just ask yourself, Would you want to shell out about a grand for a radio that the sysops discourage the use of its unique features such as linking, callsign routing and data? What are we left with? Some simple operational guidlines might go along way to help. System owners have a sizeable investment in their equipment and have the right to set usage guidelines but the bottom line is that they all want their systems to be used. This seems to be an issue that the SYSOPS need to discuss and address. Make your decisions and recommendations and then encourage it's use. DSTAR has the capability to provide enhanced data communications especially for EmComm applications. Hopefully it will survive these growing pains. Dave N2LZ
