Re: Adding P25 to existing YSF and DMR bridge
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 ?
|
|

Steve N4IRS
< https://dvswitch.groups.io/g/Server/message/419?p=,,,20,0,0,0::relevance,,Nextion,20,2,0,78353798>
toggle quoted messageShow quoted text
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
|
|

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
Thanks Patrick, works great!
Steve_WB8GRS
|
|
Re: Adding P25 to existing YSF and DMR bridge
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
toggle quoted messageShow quoted text
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
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
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
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.
toggle quoted messageShow quoted text
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.
toggle quoted messageShow quoted text
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
I'm guessing one reason is if you open source it HamVoip can then compile it for arch
toggle quoted messageShow quoted text
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.
toggle quoted messageShow quoted text
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
Why is analog_bridge not open source?
toggle quoted messageShow quoted text
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
|
|
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
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+GuidelinesDisclaimer: 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
|
|
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.
toggle quoted messageShow quoted text
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.
|
|
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
|
|
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.
toggle quoted messageShow quoted text
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.
|
|