search

mcdermj / buster

Buster D-Star Reflector Client for MacOS X
Other
15 stars 7 forks source link

Feature Request: Ability to scan reflectors #8

Open richark opened 8 years ago

richark commented 8 years ago

Allow the user to identify x number of defined reflectors and 'scan' through them like a analog radio would scan through a list of repeaters.

Feature would establish links to the x reflectors, monitor the AMBE streams for activity and when a reflector has traffic, switch to the 'linked' state in Buster. When the activity stopped and if the user hadn't transmitted, resume scanning.

Alternatively you could have a timer for how long to listen to an active stream.

johnhays commented 8 years ago

A few things to think about:

  1. Bandwidth - if you are scanning 6 reflector servers with 5 "reflectors" all streaming, that's 30 streams that are coming down the pipe. Users may not recognize the bandwidth impact of that much data.
  2. Care must be taken to not cross the streams. Especially in the DPLUS network there is a lot of concern about linking reflectors together, there is a high potential for routing loops. An ability of cross-linking in an emergency may be desirable.
  3. If you are going to implement multiple AMBE processing streams, which I think is a great feature, make the code flexible to allow dynamic addition of AMBE processing nodes whether ThumbDVs on USB or over the network using AMBEserver.
  4. In the future you may have other protocols to support (e.g. Fusion/DMR) and having Buster able to drive more than one AMBE stream and mix audio products would be cool.
mcdermj commented 8 years ago

1) The bandwidth issue has come up to me. I'm not sure how to deal with this, really, although in a modern sense it's not that much bandwidth. I understand there are some people in out-back areas that only have 128k DSL lines and such, but a modern Comcast line is a few megabit, and we're talking about download bandwidth, which is nearly always fatter.

2) I think that it's impossible in the current architecture to do this. The only way to "transmit" is if the AMBE encoder produces AMBE packets. That only happens when the audio object queues audio data for it. I'm not writing something like ircDDBGateway where I'm trying to pass DSTAR streams. I'm only a destination for them. But I will keep it in mind as this comes to fruition.

3) The code is already sufficiently abstract that this shouldn't be an issue. The difference between a network AMBE device and a USB one is encapsulated in two classes. In fact, the plan is to support any number of vocoder drivers. If you look at the code, the main program doesn't care about what kind of vocoder it is, as long as it supports the BTRVocoderDriver protocol.

4) Supporting these other protocols has been in the back of my mind and trying to leave stuff open for future implementation. I think it will take some modification to the BTRVocoderProtocol interface to support switching the RATEP words and other parameters.