Date   

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








Re: Towards open-source infrastructure for DMR repost from OpenDV

Steve N4IRS
 

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
 

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: metadata management

 

On 27/11/20 9:05 am, Patrick Perdue wrote:
Yes, that's what I was referring to. I don't know what the process is
for having your reflector listed, only that it can be done.
It's quite simple, you just have to put in a feature request on the
right (P25Gateway I think) Git repository, after setting up your
reflector.  I'll see if I can find it.

Yep, here's the Git repository.  You just need to make your request for
a new gateway number as an issue here.

https://github.com/g4klx/P25Clients/blob/master/P25Gateway/P25Hosts.txt

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com


Re: Towards open-source infrastructure for DMR repost from OpenDV

 

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

Andrew Palumbo
 

Hello,
Would there be any interest in joining an open source organization, e.g. Apache Software Foundation, as a project?

With this would come infrastructure:GitHub, JIRA. Jenkins, TravisCI and other GitHub CI/CD integrations, Slack, Infrastructure support, hosting of signed distributions of signed artifacts, along with possible collaboration and interest from other projects, legal support, marketing, conferences, and a very permissive ASF 2.0 License.  The ASF 2.0 License is about as permissive as they come, allowing for public branching and royalty free use of project artifacts.

I've spent a lot of time working with the ASF mainly on a single project, in many positions, and have found their project structure to very conclusive to OSS development; the ASF essentially provides a blank canvas with some very hands off guidelines [1], for OSS projects, freeing up time and resources to focus on project development, with support for much of the overhead that goes along with developing enterprise level products.

It seems a good fit IMO.

Andy
KN6HDF

[1] https://cwiki.apache.org/confluence/display/INCUBATOR/Default+Project+Guidelines

Disclaimer:
I am an ASF member, though not a salesman for the foundation;  This is the first time I've ever proposed something like this to a project or group,  The opinions are my own, and do not reflect the position of the foundation, my employer, or anyone else. 


Re: Coming to a browser near you

Andrew Palumbo
 

+1!


Re: metadata management

Patrick Perdue
 

Yes, that's what I was referring to. I don't know what the process is for having your reflector listed, only that it can be done.

On 11/26/2020 4:22 PM, Tony Langdon wrote:
On 27/11/20 8:20 am, Patrick Perdue wrote:
As I understand it, you can set up a private P25 reflector which is
available to anyone who uses the pi-star host files, thus, no need to
link to a public reflector. This is what I plan to do. I will probably
also get zero users, but at least I know that coming in.
You can do that, or you can setup your own public reflector.  You just
have to ask to get it listed in the public P25Hosts file.  I did this
for 50535.


Re: metadata management

 

On 27/11/20 8:20 am, Patrick Perdue wrote:

As I understand it, you can set up a private P25 reflector which is
available to anyone who uses the pi-star host files, thus, no need to
link to a public reflector. This is what I plan to do. I will probably
also get zero users, but at least I know that coming in.
You can do that, or you can setup your own public reflector.  You just
have to ask to get it listed in the public P25Hosts file.  I did this
for 50535.

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com


Re: metadata management

Patrick Perdue
 

As I understand it, you can set up a private P25 reflector which is available to anyone who uses the pi-star host files, thus, no need to link to a public reflector. This is what I plan to do. I will probably also get zero users, but at least I know that coming in.


On 11/26/2020 1:42 PM, k7wby@... wrote:
Here's a bit of advice, take it for what it's worth. 
If you're thinking of linking your other modes to a currently active P25 Reflector, don't. You will be chastised to no end and probably banned from that reflector for life.

The only solution you have is a P25Gateway and P25Reflector with a private TG. I did that for a while and had 0 users. I provided instructions on how to update the P25Hosts.txt files on their hotspots but I guess that was more work than they wanted to do. In the end I took down the reflector and gateway and just told them to use their hotspots in P252DMR mode and connect to my XLX reflector. I have a interlink to BM3103 on the XLX. Now I have P25 users and the meta data is not an issue.


Re: metadata management

 

On 27/11/20 5:42 am, k7wby@arrl.net wrote:
Here's a bit of advice, take it for what it's worth. 
If you're thinking of linking your other modes to a currently active
P25 Reflector, don't. You will be chastised to no end and probably
banned from that reflector for life.
I setup my own P25 reflector for my DVSwitch system to connect to, so I
wouldn't upset anyone else.  Got it registered and it can be reached by
any hotspot with up to date hosts files.

The only solution you have is a P25Gateway and P25Reflector with a
private TG. I did that for a while and had 0 users. I provided
instructions on how to update the P25Hosts.txt files on their hotspots
but I guess that was
Or do as I did and get G4KLX to put your reflector into the public hosts
file.  Just takes a "feature request" in the right Git repository.
more work than they wanted to do. In the end I took down the reflector
and gateway and just told them to use their hotspots in P252DMR mode
and connect to my XLX reflector. I have a interlink to BM3103 on the
XLX. Now I have P25 users and the meta data is not an issue.
Hmm P252DMR - that sounds like it would only work on an OpenSpot 3. 
This isn't possible on a Pi-Star based hotspot, because it requires
transcoding.

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com


Re: metadata management

 

On 26/11/20 11:51 am, Steve N4IRS wrote:
So,
you have D-Star, DMR and AllStar.
If you used AllStar to mix you could keep the number of vocoders to
two and only have one transcoder. For the audio, you would have 2
private nodes. The first node would be DMR and pointed at TGIF. The
second node would be D-Star and pointed at XLX.  As you said in your
first message, you issue would then be metadata.
This is where my system is at.  I have it arranged around an instance of
AllStar (except for DMR - YSF, which uses its own instance of
MMDVM_Bridge, and no transcoding).  Audio wise, my system works well and
maintains good quality (because I transcode as few times as possible,
regardless of path), but it would be nice to have a way of passing
metadata "around" AllStar when going between digital modes that are
using different vocoders, without handling audio, to account for cases
like mine.

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com


Re: metadata management

k7wby@...
 

Here's a bit of advice, take it for what it's worth. 
If you're thinking of linking your other modes to a currently active P25 Reflector, don't. You will be chastised to no end and probably banned from that reflector for life.

The only solution you have is a P25Gateway and P25Reflector with a private TG. I did that for a while and had 0 users. I provided instructions on how to update the P25Hosts.txt files on their hotspots but I guess that was more work than they wanted to do. In the end I took down the reflector and gateway and just told them to use their hotspots in P252DMR mode and connect to my XLX reflector. I have a interlink to BM3103 on the XLX. Now I have P25 users and the meta data is not an issue.


Re: Security password on Brandmeister

Patrick Perdue
 

You only need to change the

password=passw0rd

line in the [DMR Network] stanza of MMDVM_Bridge.ini for any DVSwitch instance, replacing it with the hotspot security password you've set up on the Brandmeister self-care dashboard.

AFAIK, this change doesn't affect repeater ID's yet, just personal CCS7.

So, you shouldn't need to make any changes to your MMDVM repeater at this time, assuming you are using a six digit repeater ID.


On 11/25/2020 11:14 PM, Steve - WB8GRS wrote:

I read elsewhere that Brandmeister Hotspot Users must configure hotspot security password to continue using Brandmeister.  This affect masters 3101, 3102 and 3103 and I assume many other masters. This starts to take affect on Nov 30, 2020.  I have both an Android to DMR and Allstar to DMR bridges running as well as a couple DMR hotspots and a MMDVM DMR repeater on Brandmeister..  Do I need to add a security password to my Android to DMR bridge that I use with DV Switch and to my Allstar to DMR bridge in order to stay logged into Brandmeister, and if yes, how do I do that?

If I need to ask this in a subgroup, please let me know which one.

Thanks,
73,
Steve_WB8GRS


Security password on Brandmeister

Steve - WB8GRS
 

I read elsewhere that Brandmeister Hotspot Users must configure hotspot security password to continue using Brandmeister.  This affect masters 3101, 3102 and 3103 and I assume many other masters. This starts to take affect on Nov 30, 2020.  I have both an Android to DMR and Allstar to DMR bridges running as well as a couple DMR hotspots and a MMDVM DMR repeater on Brandmeister..  Do I need to add a security password to my Android to DMR bridge that I use with DV Switch and to my Allstar to DMR bridge in order to stay logged into Brandmeister, and if yes, how do I do that?

If I need to ask this in a subgroup, please let me know which one.

Thanks,
73,
Steve_WB8GRS


Re: Towards open-source infrastructure for DMR repost from OpenDV

Randy AA6RH
 

G4KLX is saying what I've been thinking for at least a year now. The fact that BM and to a lesser extent DMR-MARC, DCI, TGIF and others have created a closed-source, walled-garden approach to interlinking leaves the individual repeater operators at the relative mercy of these networks. The recent UK master server crash is a clear indicator that the centralized technique needs some refactoring.

It's not original, sadly. Other analog-based interlinking tech has the same problems (I'm looking at IRLP and AllStarLink as two easy examples). Hams generally like the interconnection to be plug-and-play. A new approach would require people to actually do things like RTFM and test their changes in isolation before unleashing it on the network, possibly wreaking havoc.

I'm all for an open and decentralized approach to interlinking. The obvious downsides is that it moves more of the work to the repeater operators to be on the lookout for bad actors, or at least LIDS. Some of what I'm getting at is that there needs to be tools to help a sysop/control op check that their configuration changes are going to do what they think it will. That's a tall order.

I'd say that philosophically speaking, HBLink is aligned with this particular view of interlinking and interconnection. I think we have some real architectural challenges (not to mention devops, developer community, and all the rest) to become a robust contributor to this new approach. I also think that IPSC_Bridge and HB_Bridge (to a lesser extent) need to be brought up-to-date to Python 3 through a focus on creating a testable code base and then evolving it from there.

I love this manifesto. I hope we can build something from it.

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁


Re: metadata management

Patrick Perdue
 

OK, so things are pretty much as I thought they were. Just wanted to make sure I wasn't missing anything should I decide to redesign this system. I'll probably keep things as-is for now, then add another private node for P25.

Thanks.

On 11/25/2020 7:51 PM, Steve N4IRS wrote:
So,
you have D-Star, DMR and AllStar.
If you used AllStar to mix you could keep the number of vocoders to two and only have one transcoder. For the audio, you would have 2 private nodes. The first node would be DMR and pointed at TGIF. The second node would be D-Star and pointed at XLX.  As you said in your first message, you issue would then be metadata.

Steve


On 11/25/20 7:32 PM, Patrick Perdue wrote:
I'm not great at writing out flows.

My setup currently doesn't use ircDDBGateway, since that's all handled at the XLX reflector end. So, it goes like this.

Allstar <-> AB <-> HBLink <-> MB <-> XLXD (DMR, since XLX is also handling a BM interlink and YSF traffic) <-> ambed (connected to the XLX reflector) <-> TGIF.

I'm sure I screwed that up.

So basically, native AMBE traffic is transcoded to analog using the MD380-emu vocoder back to Allstar. DStar is transcoded through the pair of ThumnDV's on the reflector, which is then sent to MD380emu and then Allstar. Between DMR or YSF and DStar, this is fine, but from Allstar to DStar, it's going through another AMBE transcode before A_B sees it, so more latency and lower quality audio.

If I connect to the reflector directly as DStar, then use ASL to connect to the other modes, perhaps on another module of the reflector and HBLink, then DMR-YSF would only see the call specified in A_B, correct?


On 11/25/2020 7:18 PM, Steve N4IRS wrote:
I don't see how there are 2 vocoders to get from AllStar to D-Star. The flow would be:
AllStar <-> AB <-> MB <-> ircDDBGateway <-> XLX for D-Star.
You could drop the ircDDBGateway and go to XLX DMR.

Steve

On 11/25/20 7:14 PM, Patrick Perdue wrote:
Sure, but I'm currently going through two of them to get from Allstar to DStar.

I'm just wondering if there's a way to drop one of them out and still maintain metadata. I could directly connect A_B and MMDVM_Bridge to the XLX reflector and only direct DStar traffic to the module, and audio between DStar and the other digital modes should be about the same as it is now, but audio from Allstar to DStar has one less generation of vocoding, but then I lose metadata between the digital modes. At least, this is how I understand it.


On 11/25/2020 6:55 PM, Steve N4IRS wrote:
Patrick,
Either way, you have to go through a vocoder to go from analog to D-Star Same for P25, you still have to go through a vocoder.

Steve

On 11/25/20 6:28 PM, Patrick Perdue wrote:
Hi:

I have a system that incorporates ASL, XLX, HBLink and DVSwitch. I'm toying with the idea of adding P25.

Currently, DStar is handled by XLX and a pair of transcoders connected to the XLX reflector, not DVSwitch. I would like to connect ASL directly to the XLX reflector in DStar mode, so that the audio to and from DStar to ASL is not transcoded through AMBE, but still pass metadata to DStar from the other digital modes. Is this at all possible? Similar question in regards to P25.

Basically, I want to do the least amount of transcoding possible to and from analog, while maintaining the greatest compatibility across digital modes. What I have now works, but I'd love to get rid of that extra layer of transcoding between analog and DStar without sacrificing metadata.

Thanks.
























Re: pyUC P25 "not linked"

Steve N4IRS
 

You want to add it in 2 places.
Add the reflector TG, IP and port in private_P25Hosts.txt

Add the Name and TG in pyUC.ini in the P25 section.

Steve N4IRS

On 11/25/20 9:45 PM, Scotty 2543G KD2LWH wrote:
It seems to have fixed itself after a few times of opening and closing the application. Now I'm wondering how to add my private reflector to the list on USRP Client for P25. I have added it to the P25Hosts.txt file on the DV_Switch Server, but it doesn't show in the list on the client. Any ideas?


Re: pyUC P25 "not linked"

Mike Zingman - N4IRR
 

The app uses the configuration file pyUC.ini

1981 - 2000 of 9514