1. main@DVSwitch.groups.io
   Date   
Re: Security password on Brandmeister

Ted Lawrence
 

Yes, that fixed it.  Thanks!
Re: Security password on Brandmeister

Steve N4IRS
 

Yes

On 11/29/20 6:14 PM, Ted Lawrence via groups.io wrote:
To be clear.  You replace "passw0rd" with the Self care password ?

Re: Security password on Brandmeister

Ted Lawrence
 

To be clear.  You replace "passw0rd" with the Self care password ?
BransMeister Self care password for a DVSwitch

Ted Lawrence
 

Hi folks!  I need help with DVSwitch edit. With the recent BrandMeister server security change, it broke our DVSwitch to DMR configuration.  What Stanza  do you insert the Self care BrandMeister  password for DVSwitch. Also, what is proper format needed in the line of code?

Thanks for you help!
Ted
KD4EG
Re: Coming to a browser near you

Jay
 

Amen,  I am Mac OS and IOS, with a WinDoze box around to program radios with.  It will be nice to have a web client I can run on everything.

--
jb   N4NQY
Re: level differences between YSF and DMR (again)

k7wby@...
 

You might try changing to AUDIO_USE_GAIN. My ASL side is set to .25 but yours may be different. This is one of those things that you just have to test and test until you get it right. There are also gain settings in rpt.conf that you can play with for ASL.

All my AB instances have DV3000 hardware as well as the XLX so it tends to make it a little easier to balance the audio.
level differences between YSF and DMR (again)

Patrick Perdue
 

Hi:

I'm sure this has been brought up before.

I have a system using DVSwitch, which involves an XLX reflector. Currently, the XLX module to which DVSwitch is connected is also configured as an autolinked YSF reflector. HBlink connects to that reflector, and MMDVM_Bridge connects to HBlink, with my XLX reflector as one peer and TGIF as another.

The YSF reflector on XLX is rarely used compared to DStar and especially DMR, which is the most popular digital mode on the system, but I am told that audio level is significantly higher for audio received by YSF connected clients than DMR, regardless of if the source is ASL or some other mode. I'm already running the gain from ASL to digital below unity (0.38, I think) to avoid distortion. This seems to work well for DMR even with hot analog audio. So, my question is, other than perhaps moving YSF traffic to another module on the reflector, then using an instance of Analog_Bridge to route everything destined for YSF through ASL and turning the gain down on that stage, then pointing YSF outbound traffic back to the original MMDVM_Bridge instead of a second ASL private node to avoid transcoding, since there seems to be no problem in that direction, is there anything I can do about this? I assume probably not, but I honestly haven't paid too much attention to YSF implementation of DVSwitch, since I'm not actually using it to provide YSF connectivity at the moment.
locked Notice to all DVSwitch users. #brandmeister

Steve N4IRS
 

This was posted a few days ago by N3FE
 
Due to issues that have been happening recently, we are going to need to start requiring users to set a hotspot security password to gain access to the US Masters.  If you already have a hotspot security password set on the BM portal, you can ignore this post. We are going to start requiring this on master 3101 November 30th,  3102 will follow on December 4th, and 3103 on December 11th.  This is already implemented on the RU masters, and other Master servers will follow. At this time this will just be for hotspots.  The API is being worked on to allow repeater owners to make this change as well, but it is not quite ready to go.
Here is a link to a post on how to set your hotspot security on the bm portal. Please configure a personalized security password for your hotspots !
 
What does this mean for DVSwitch users? If you have a bridge or server connecting to BrandMeister, you will need to have set your HS password. Up till now, a user could use the default password and connect to BM. With the above change, you will need to set your own password. This is one password per CallSign/DMRID. If you have 2 DMR IDs you will need to set 2 passwords.
 
We HIGHLY suggest you set your HS passwords now. That way when the changes are applied across BM, you will not loose connectivity.
Re: Adding P25 to existing YSF and DMR bridge

Steve N4IRS
 

Gary,
Think of it this way. What modes do you need? MB can do each of the modes, once.
You have a YSF <-> DMR
You want to do P25 <-> DMR

A P25 to DMR Bridge is one instance of MB and 2 instances of AB (the transcoder)

In you YSF <-> DMR bridge, you cross connected the TLV ports. In you P25 <-> DMR bridge that cross connect needs to go through a transcoder.
Think if it as 2 networks. P25 <-> AB and DMR <-> AB This is a single instance of MB and 2 instances of AB. Now, connect the 2 AB together at the USRP ports.
You have a transcoder.

On 11/28/20 6:43 AM, Gary, KE8O wrote:
OK, I think I have my head wrapped around the AB side but I'm not sure on the number of MB instances.  Below is how I currently have my /opt folder setup.

According to Steve's response and the port flow I need two AB instances for the DMR<--> P25 and one MB instance. Is that one MB instance my existing YSF/DMR instance or in addition ? 



Re: Adding P25 to existing YSF and DMR bridge

Gary, KE8O
 

OK, I think I have my head wrapped around the AB side but I'm not sure on the number of MB instances.  Below is how I currently have my /opt folder setup.

According to Steve's response and the port flow I need two AB instances for the DMR<--> P25 and one MB instance. Is that one MB instance my existing YSF/DMR instance or in addition ? 


Re: Nextion screen install #mmdvm_bridge

Steve N4IRS
 

<https://dvswitch.groups.io/g/Server/message/419?p=,,,20,0,0,0::relevance,,Nextion,20,2,0,78353798>

On 11/28/20 5:16 AM, Glenn VK4NGA via groups.io wrote:
Hi all,
I'm new to the group. I did search this but didn't find all the information.
I've installed a Nextion screen to my DVswitch server, an RPi 3B+ and have the hardware side of things correct.
I'm new to Linux and I just need guidance, more so a "how to" install the Nextion driver and any other detail.

Cheers
Glenn Vk4nga

Nextion screen install #mmdvm_bridge

Glenn VK4NGA
 

Hi all,
I'm new to the group. I did search this but didn't find all the information.
I've installed a Nextion screen to my DVswitch server, an RPi 3B+ and have the hardware side of things correct.
I'm new to Linux and I just need guidance, more so a "how to" install the Nextion driver and any other detail.

Cheers
Glenn Vk4nga
Re: Security password on Brandmeister

Steve - WB8GRS
 

Thanks Patrick, works great!

Steve_WB8GRS
Re: Adding P25 to existing YSF and DMR bridge

Gary, KE8O
 

Thanks Tony and Steve for the information. I will give this a try later tonight.
Re: Adding P25 to existing YSF and DMR bridge

Steve N4IRS
 

Close.
A DMR <-> P25 bridge would be one instance of MB and 2 instances of AB.

DMR Network <-> MB <-> AB_DMR <-> AB_P25 <-> MB <-> P25Gateway <-> P25 Reflector.

Here is the port map <https://dvswitch.groups.io/g/main/wiki/9379>

Steve N4IRS

On 11/27/20 12:54 AM, Tony Langdon wrote:
On 27/11/20 4:03 pm, Gary, KE8O wrote:
I currently have a test system where I have bridged YSF and DMR using
MMDVM_Bridge.  I have the P25Reflector  installed on the same system
running as a standalone reflector. I would like to add P25 to the
existing YSF / DMR bridge.  I searched the existing message and found
a discussion on bridging P25 to DMR that involved using Analog_Bridge.
I'm just not sure on how to add a third mode into the mix.  Any
guidance would be appreciated.
You would need a second instance of MMDVM-Bridge, which is sitting on
the same DMR TG as the original bridge.  The way I see it is:

DMR - MMDVM-Bridge - Analog_Bridge (1) - Analog_Bridge (2) -
MMDVM_Bridge - P25Gateway - P25 Reflector.

Analog_Bridge (1) would be configured to use the md380-emulator for DMR
AMBE encoding, while Analog_Bridge (2) needs to use the software IMBE
vocoder from op25.  Of course, hardware vocoders can be used instead of
the software options I've given, but the software vocoders are excellent
for DMR and P25.

So at the end of the day, you're running 3 instances of MMDVM_Bridge
(including the existing DMR - YSF instance), plus 2 instances of
Analog_Bridge.
Re: Adding P25 to existing YSF and DMR bridge

Tony Langdon
 

On 27/11/20 4:03 pm, Gary, KE8O wrote:
I currently have a test system where I have bridged YSF and DMR using
MMDVM_Bridge.  I have the P25Reflector  installed on the same system
running as a standalone reflector. I would like to add P25 to the
existing YSF / DMR bridge.  I searched the existing message and found
a discussion on bridging P25 to DMR that involved using Analog_Bridge.
I'm just not sure on how to add a third mode into the mix.  Any
guidance would be appreciated.
You would need a second instance of MMDVM-Bridge, which is sitting on
the same DMR TG as the original bridge.  The way I see it is:

DMR - MMDVM-Bridge - Analog_Bridge (1) - Analog_Bridge (2) -
MMDVM_Bridge - P25Gateway - P25 Reflector.

Analog_Bridge (1) would be configured to use the md380-emulator for DMR
AMBE encoding, while Analog_Bridge (2) needs to use the software IMBE
vocoder from op25.  Of course, hardware vocoders can be used instead of
the software options I've given, but the software vocoders are excellent
for DMR and P25.

So at the end of the day, you're running 3 instances of MMDVM_Bridge
(including the existing DMR - YSF instance), plus 2 instances of
Analog_Bridge.

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
Adding P25 to existing YSF and DMR bridge

Gary, KE8O
 

I currently have a test system where I have bridged YSF and DMR using MMDVM_Bridge.  I have the P25Reflector  installed on the same system running as a standalone reflector. I would like to add P25 to the existing YSF / DMR bridge.  I searched the existing message and found a discussion on bridging P25 to DMR that involved using Analog_Bridge. I'm just not sure on how to add a third mode into the mix.  Any guidance would be appreciated.
Re: Towards open-source infrastructure for DMR repost from OpenDV

Skyler Fennell
 

Nvm, guess I haven’t played with hamvoip for a while to test that stuff lol.  

I can’t think of a reason why it would be better for the community of experimenters to not release the source code, but certainly respect it’s the authors work and not a requirement to release it.



On Thu, Nov 26, 2020 at 8:09 PM Steve N4IRS <szingman@...> wrote:
It does not need to be compiled for Arch. The binary will run fine.


On 11/26/20 10:08 PM, Skyler Fennell wrote:
I'm guessing one reason is if you open source it HamVoip can then compile it for arch

On Thu, Nov 26, 2020 at 6:17 PM Steve N4IRS <szingman@...> wrote:
Because we do not feel it is in our or the communities best interest at this time.

On 11/26/20 7:58 PM, Skyler Fennell wrote:
Why is analog_bridge not open source? 

On Thu, Nov 26, 2020 at 3:19 PM Tony Langdon <vk3jed@...> wrote:
On 26/11/20 3:54 am, Steve N4IRS wrote:
> DMR, after D-Star, is the most political of the digtial voice modes.
> Unlike the other modes, most DMR systems connect to a centralised
> server, known as a "master" and that is responsible for all of the
> talk group routine, personal calls, and position data interpretation
> and forwarding. There are three main centralised systems:
> BrandMeister, DMR+ (known as Phoenix in the UK), and TGIF.
>  
> What these systems have in common is that they are closed source. This
> is not good for the amateur community. There were mutterings about
> them having signed NDAs with Hytera and Motorola to get details of
> their internet connection protocols, which may or may not be true.
> Even if true, why not make the non-NDA parts of the source code open?
>  
> In the commercial world, digital voice repeaters, be they for DMR,
> P25, NXDN, or dPMR have limited abilities within themselves for call
> routing. They do include CPUs of course, but for anything other than
> simple point-to-point links, they are useless. This limitation is fine
> for what they were originally designed for, small centrally controlled
> networks, with or without a dispatching console function. The YCS
> system for System Fusion is looking to do the same for YSF and that is
> why I oppose it.
>  
> This model of a centralised control structure carried through to the
> amateur DMR networks. In its simplest form, a repeater would simply
> have a point-to-point network connection to the master and things
> would be fine. Even with a semi-distributed system, with one or more
> master per country, there is still some central control of the system
> with the power to overrule the decisions made at the local level. Such
> central control is also not conducive to supporting each countries
> requirements, and leads to much used functionality being arbitrarily
> removed. In the extereme case the countries master may also be
> removed. When such things happen you have to ask from where did they
> derive their authority? Who voted for them? Who made the decision and
> how do they know that it is correct?
I'm in agreement with the general idea.  I was involved in EchoIRLP,
which came about simply because people like me simply wanted to be able
to connect to whatever network we wanted.  EchoIRLP also incorporated
features to protect the networks from accidental cross linking, which
was one of the reasons it was readily accepted, once people got their
head around the concept.

While it's great to play with different modes, we do have a real "Tower
of Babel" when it comes to DV modes.  Projects like DV Switch do go a
long way towards mitigating the effect of having multiple incompatible
modes among a relatively small user base. 
>  
> In the amateur world we have gone beyond having dumb repeaters. Most
> MMDVM systems for example have a Raspberry Pi or similar running the
> system, and have the potential to provide a lot of local processing
> power which can be used for more complex tasks than simply routing
> traffic over a point-to-point link. Many sysops expressed the wish to
> be able to have access to multiple masters, simultaneously, and hence
> the DMR Gateway was born in 2017. It does complex call routing, and
> almost everything else, bar the position data interpretation.

What would I like?  In an ideal world, I'd like to be able to
communicate with the hams I want to, regardless of network or mode,
using the radios I have,  In essence, think of it like EchoIRLP on
steroids.  I have something close to this with my AllStar node, which
not only can do AllStar, IRLP and Echolink (IRLP/EL via my existing
EchoIRLP node - with all proper lockouts in place), but it's configured
to do DMR (BM), YSF and P25 via a local DVSwitch installation.   I'd
like to be able to run multiple DMR networks eventually.  

The end game is something that performs the role that IP does for data -
providing routing over the top of multiple networks, so any endpoint can
find any other endpoint.

Another issue is audio processing.  I believe in processing the audio as
little as possible.  This philosophy goes back to EchoIRLP (2003-) and
the IRLP/Echolink integrated conference servers (2005-), and results in
the best audio quality with minimum latency.  DV modes, unlike the
analog systems often don't have a "common vocoder", so some amount of
transcoding is unavoidable, but again given the aggressive vocoders in
use, I'd like to keep it to a minimum, while preserving as much metadata
as possible.  Incidentally, this would be handy internally in cross mode
gateways like the one I have in the cloud.

Here's how I see it working.  At the source, the audio is decoded to
PCM, and two audio streams are sent - one in PCM and a second stream in
the original encoded format.  Information about the vocoder in use is
added to the metadata.  Stations receiving the stream examine the
vocoder metadata.  If they natively support the vocoder used, they
simply take the original encoded voice data and use that.  Otherwise the
receiving nodes that can't handle the source vocoder will take the PCM
stream and re-encode that.  In these days of unlimited (or near
unlimited) broadband Internet, the overheads of doing things this way
shouldn't be an issue.   If a viable software implementation of the
D-STAR vocoder comes along, it would still then be possible to have a
"dumb" node linked to a "smart router" running in the cloud, to save
local processing power or bandwidth, if needed.

>  
> In some quarters this development was opposed. I believe that the
> sysop should have the choice on how to route their traffic and so
> development went ahead and it has been enhanced since. It has been a
> huge success.
>  
> I think that the time has come to look at having an open source,
> non-centralised, DMR network. A network where no one person or group
> has control. We already have the beginnings of this with the HBLink
> and with XLX projects. If more people get involved with these projects
> then they will grow and offer more features as time goes on.  I
> haven't played with HBLink yet, but it does interest me.
The only issue I see is avoiding issues like routing loops or malicious
interference (sadly, it does happen).  For the former, it would be ideal
if the network was smart enough to detect loops and then take action to
block the source of problems or break the loop, until it's fixed. 
Otherwise some human oversight would be needed.

I do run an XLX reflector, but keep it standalone, as the very manual
interlinking process isn't compatible with my ADHD (I did play with it
in the early days of XLX).  I'm also somewhat cut off from that
community, because they moved all their internal communication to a web
forum years ago, which is relatively inaccessible to me - too slow and
cumbersome and yet another login to remember to check.
>  
> Some may say, what about integration of commercial repeaters like
> Hyteras and Motorolas? There is already a program available that
> converts the Hytera repeater protocol to the protocol used by the
> MMDVM, and integration of Motorola repeaters is possible all be it
> with a number of programs in series. Maybe someone will rationalise
> this into something simpler.
This could be a use case of the "dumb node" scenario above.
>  
> Things are already moving on this, and I hope that in the future we
> will see such systems appear and then DMR will be free of the tyranny
> of what we have now. Sysops and their users are sovereign and should
> not be dictated to by anybody (the same goes for software developers
> :-) ).


Let's hope for more openness. :)

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
Re: Towards open-source infrastructure for DMR repost from OpenDV

Steve N4IRS
 

It does not need to be compiled for Arch. The binary will run fine.

On 11/26/20 10:08 PM, Skyler Fennell wrote:
I'm guessing one reason is if you open source it HamVoip can then compile it for arch

On Thu, Nov 26, 2020 at 6:17 PM Steve N4IRS <szingman@...> wrote:
Because we do not feel it is in our or the communities best interest at this time.

On 11/26/20 7:58 PM, Skyler Fennell wrote:
Why is analog_bridge not open source? 

On Thu, Nov 26, 2020 at 3:19 PM Tony Langdon <vk3jed@...> wrote:
On 26/11/20 3:54 am, Steve N4IRS wrote:
> DMR, after D-Star, is the most political of the digtial voice modes.
> Unlike the other modes, most DMR systems connect to a centralised
> server, known as a "master" and that is responsible for all of the
> talk group routine, personal calls, and position data interpretation
> and forwarding. There are three main centralised systems:
> BrandMeister, DMR+ (known as Phoenix in the UK), and TGIF.
>  
> What these systems have in common is that they are closed source. This
> is not good for the amateur community. There were mutterings about
> them having signed NDAs with Hytera and Motorola to get details of
> their internet connection protocols, which may or may not be true.
> Even if true, why not make the non-NDA parts of the source code open?
>  
> In the commercial world, digital voice repeaters, be they for DMR,
> P25, NXDN, or dPMR have limited abilities within themselves for call
> routing. They do include CPUs of course, but for anything other than
> simple point-to-point links, they are useless. This limitation is fine
> for what they were originally designed for, small centrally controlled
> networks, with or without a dispatching console function. The YCS
> system for System Fusion is looking to do the same for YSF and that is
> why I oppose it.
>  
> This model of a centralised control structure carried through to the
> amateur DMR networks. In its simplest form, a repeater would simply
> have a point-to-point network connection to the master and things
> would be fine. Even with a semi-distributed system, with one or more
> master per country, there is still some central control of the system
> with the power to overrule the decisions made at the local level. Such
> central control is also not conducive to supporting each countries
> requirements, and leads to much used functionality being arbitrarily
> removed. In the extereme case the countries master may also be
> removed. When such things happen you have to ask from where did they
> derive their authority? Who voted for them? Who made the decision and
> how do they know that it is correct?
I'm in agreement with the general idea.  I was involved in EchoIRLP,
which came about simply because people like me simply wanted to be able
to connect to whatever network we wanted.  EchoIRLP also incorporated
features to protect the networks from accidental cross linking, which
was one of the reasons it was readily accepted, once people got their
head around the concept.

While it's great to play with different modes, we do have a real "Tower
of Babel" when it comes to DV modes.  Projects like DV Switch do go a
long way towards mitigating the effect of having multiple incompatible
modes among a relatively small user base. 
>  
> In the amateur world we have gone beyond having dumb repeaters. Most
> MMDVM systems for example have a Raspberry Pi or similar running the
> system, and have the potential to provide a lot of local processing
> power which can be used for more complex tasks than simply routing
> traffic over a point-to-point link. Many sysops expressed the wish to
> be able to have access to multiple masters, simultaneously, and hence
> the DMR Gateway was born in 2017. It does complex call routing, and
> almost everything else, bar the position data interpretation.

What would I like?  In an ideal world, I'd like to be able to
communicate with the hams I want to, regardless of network or mode,
using the radios I have,  In essence, think of it like EchoIRLP on
steroids.  I have something close to this with my AllStar node, which
not only can do AllStar, IRLP and Echolink (IRLP/EL via my existing
EchoIRLP node - with all proper lockouts in place), but it's configured
to do DMR (BM), YSF and P25 via a local DVSwitch installation.   I'd
like to be able to run multiple DMR networks eventually.  

The end game is something that performs the role that IP does for data -
providing routing over the top of multiple networks, so any endpoint can
find any other endpoint.

Another issue is audio processing.  I believe in processing the audio as
little as possible.  This philosophy goes back to EchoIRLP (2003-) and
the IRLP/Echolink integrated conference servers (2005-), and results in
the best audio quality with minimum latency.  DV modes, unlike the
analog systems often don't have a "common vocoder", so some amount of
transcoding is unavoidable, but again given the aggressive vocoders in
use, I'd like to keep it to a minimum, while preserving as much metadata
as possible.  Incidentally, this would be handy internally in cross mode
gateways like the one I have in the cloud.

Here's how I see it working.  At the source, the audio is decoded to
PCM, and two audio streams are sent - one in PCM and a second stream in
the original encoded format.  Information about the vocoder in use is
added to the metadata.  Stations receiving the stream examine the
vocoder metadata.  If they natively support the vocoder used, they
simply take the original encoded voice data and use that.  Otherwise the
receiving nodes that can't handle the source vocoder will take the PCM
stream and re-encode that.  In these days of unlimited (or near
unlimited) broadband Internet, the overheads of doing things this way
shouldn't be an issue.   If a viable software implementation of the
D-STAR vocoder comes along, it would still then be possible to have a
"dumb" node linked to a "smart router" running in the cloud, to save
local processing power or bandwidth, if needed.

>  
> In some quarters this development was opposed. I believe that the
> sysop should have the choice on how to route their traffic and so
> development went ahead and it has been enhanced since. It has been a
> huge success.
>  
> I think that the time has come to look at having an open source,
> non-centralised, DMR network. A network where no one person or group
> has control. We already have the beginnings of this with the HBLink
> and with XLX projects. If more people get involved with these projects
> then they will grow and offer more features as time goes on.  I
> haven't played with HBLink yet, but it does interest me.
The only issue I see is avoiding issues like routing loops or malicious
interference (sadly, it does happen).  For the former, it would be ideal
if the network was smart enough to detect loops and then take action to
block the source of problems or break the loop, until it's fixed. 
Otherwise some human oversight would be needed.

I do run an XLX reflector, but keep it standalone, as the very manual
interlinking process isn't compatible with my ADHD (I did play with it
in the early days of XLX).  I'm also somewhat cut off from that
community, because they moved all their internal communication to a web
forum years ago, which is relatively inaccessible to me - too slow and
cumbersome and yet another login to remember to check.
>  
> Some may say, what about integration of commercial repeaters like
> Hyteras and Motorolas? There is already a program available that
> converts the Hytera repeater protocol to the protocol used by the
> MMDVM, and integration of Motorola repeaters is possible all be it
> with a number of programs in series. Maybe someone will rationalise
> this into something simpler.
This could be a use case of the "dumb node" scenario above.
>  
> Things are already moving on this, and I hope that in the future we
> will see such systems appear and then DMR will be free of the tyranny
> of what we have now. Sysops and their users are sovereign and should
> not be dictated to by anybody (the same goes for software developers
> :-) ).


Let's hope for more openness. :)

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
Re: Towards open-source infrastructure for DMR repost from OpenDV

Skyler Fennell
 

I'm guessing one reason is if you open source it HamVoip can then compile it for arch


On Thu, Nov 26, 2020 at 6:17 PM Steve N4IRS <szingman@...> wrote:
Because we do not feel it is in our or the communities best interest at this time.

On 11/26/20 7:58 PM, Skyler Fennell wrote:
Why is analog_bridge not open source? 

On Thu, Nov 26, 2020 at 3:19 PM Tony Langdon <vk3jed@...> wrote:
On 26/11/20 3:54 am, Steve N4IRS wrote:
> DMR, after D-Star, is the most political of the digtial voice modes.
> Unlike the other modes, most DMR systems connect to a centralised
> server, known as a "master" and that is responsible for all of the
> talk group routine, personal calls, and position data interpretation
> and forwarding. There are three main centralised systems:
> BrandMeister, DMR+ (known as Phoenix in the UK), and TGIF.
>  
> What these systems have in common is that they are closed source. This
> is not good for the amateur community. There were mutterings about
> them having signed NDAs with Hytera and Motorola to get details of
> their internet connection protocols, which may or may not be true.
> Even if true, why not make the non-NDA parts of the source code open?
>  
> In the commercial world, digital voice repeaters, be they for DMR,
> P25, NXDN, or dPMR have limited abilities within themselves for call
> routing. They do include CPUs of course, but for anything other than
> simple point-to-point links, they are useless. This limitation is fine
> for what they were originally designed for, small centrally controlled
> networks, with or without a dispatching console function. The YCS
> system for System Fusion is looking to do the same for YSF and that is
> why I oppose it.
>  
> This model of a centralised control structure carried through to the
> amateur DMR networks. In its simplest form, a repeater would simply
> have a point-to-point network connection to the master and things
> would be fine. Even with a semi-distributed system, with one or more
> master per country, there is still some central control of the system
> with the power to overrule the decisions made at the local level. Such
> central control is also not conducive to supporting each countries
> requirements, and leads to much used functionality being arbitrarily
> removed. In the extereme case the countries master may also be
> removed. When such things happen you have to ask from where did they
> derive their authority? Who voted for them? Who made the decision and
> how do they know that it is correct?
I'm in agreement with the general idea.  I was involved in EchoIRLP,
which came about simply because people like me simply wanted to be able
to connect to whatever network we wanted.  EchoIRLP also incorporated
features to protect the networks from accidental cross linking, which
was one of the reasons it was readily accepted, once people got their
head around the concept.

While it's great to play with different modes, we do have a real "Tower
of Babel" when it comes to DV modes.  Projects like DV Switch do go a
long way towards mitigating the effect of having multiple incompatible
modes among a relatively small user base. 
>  
> In the amateur world we have gone beyond having dumb repeaters. Most
> MMDVM systems for example have a Raspberry Pi or similar running the
> system, and have the potential to provide a lot of local processing
> power which can be used for more complex tasks than simply routing
> traffic over a point-to-point link. Many sysops expressed the wish to
> be able to have access to multiple masters, simultaneously, and hence
> the DMR Gateway was born in 2017. It does complex call routing, and
> almost everything else, bar the position data interpretation.

What would I like?  In an ideal world, I'd like to be able to
communicate with the hams I want to, regardless of network or mode,
using the radios I have,  In essence, think of it like EchoIRLP on
steroids.  I have something close to this with my AllStar node, which
not only can do AllStar, IRLP and Echolink (IRLP/EL via my existing
EchoIRLP node - with all proper lockouts in place), but it's configured
to do DMR (BM), YSF and P25 via a local DVSwitch installation.   I'd
like to be able to run multiple DMR networks eventually.  

The end game is something that performs the role that IP does for data -
providing routing over the top of multiple networks, so any endpoint can
find any other endpoint.

Another issue is audio processing.  I believe in processing the audio as
little as possible.  This philosophy goes back to EchoIRLP (2003-) and
the IRLP/Echolink integrated conference servers (2005-), and results in
the best audio quality with minimum latency.  DV modes, unlike the
analog systems often don't have a "common vocoder", so some amount of
transcoding is unavoidable, but again given the aggressive vocoders in
use, I'd like to keep it to a minimum, while preserving as much metadata
as possible.  Incidentally, this would be handy internally in cross mode
gateways like the one I have in the cloud.

Here's how I see it working.  At the source, the audio is decoded to
PCM, and two audio streams are sent - one in PCM and a second stream in
the original encoded format.  Information about the vocoder in use is
added to the metadata.  Stations receiving the stream examine the
vocoder metadata.  If they natively support the vocoder used, they
simply take the original encoded voice data and use that.  Otherwise the
receiving nodes that can't handle the source vocoder will take the PCM
stream and re-encode that.  In these days of unlimited (or near
unlimited) broadband Internet, the overheads of doing things this way
shouldn't be an issue.   If a viable software implementation of the
D-STAR vocoder comes along, it would still then be possible to have a
"dumb" node linked to a "smart router" running in the cloud, to save
local processing power or bandwidth, if needed.

>  
> In some quarters this development was opposed. I believe that the
> sysop should have the choice on how to route their traffic and so
> development went ahead and it has been enhanced since. It has been a
> huge success.
>  
> I think that the time has come to look at having an open source,
> non-centralised, DMR network. A network where no one person or group
> has control. We already have the beginnings of this with the HBLink
> and with XLX projects. If more people get involved with these projects
> then they will grow and offer more features as time goes on.  I
> haven't played with HBLink yet, but it does interest me.
The only issue I see is avoiding issues like routing loops or malicious
interference (sadly, it does happen).  For the former, it would be ideal
if the network was smart enough to detect loops and then take action to
block the source of problems or break the loop, until it's fixed. 
Otherwise some human oversight would be needed.

I do run an XLX reflector, but keep it standalone, as the very manual
interlinking process isn't compatible with my ADHD (I did play with it
in the early days of XLX).  I'm also somewhat cut off from that
community, because they moved all their internal communication to a web
forum years ago, which is relatively inaccessible to me - too slow and
cumbersome and yet another login to remember to check.
>  
> Some may say, what about integration of commercial repeaters like
> Hyteras and Motorolas? There is already a program available that
> converts the Hytera repeater protocol to the protocol used by the
> MMDVM, and integration of Motorola repeaters is possible all be it
> with a number of programs in series. Maybe someone will rationalise
> this into something simpler.
This could be a use case of the "dumb node" scenario above.
>  
> Things are already moving on this, and I hope that in the future we
> will see such systems appear and then DMR will be free of the tyranny
> of what we have now. Sysops and their users are sovereign and should
> not be dictated to by anybody (the same goes for software developers
> :-) ).


Let's hope for more openness. :)

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
1521 - 1540 of 9072