Keith C. Perry on 17 May 2019 11:19:35 -0700

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] PLUG Fusion room or DMR Talkgroup


"Get on it and start doing"

I have mental image of you doing the "Just Do It" flex with an HT in each hand  LOL

I hear you but not everyone is built that way.  In fact, I wouldn't be surprised if newer hams were overwhelmed by this thread.  I'm looking at from the pov of the new ham that is a bit more nervous operating, regardless of the mode but in particular with phone modes since that is where the vast majority of us start.  I'm a life longer learner but I'm also a teacher, instructor, trainer so I like to figure out how to help people help themselves if I can when I notice I (or someone else like PLUG) has something to offer.


What I was planning on doing this weekend was setting installing the YSF reflector and XLXd software on one of my servers (or building a new one- I'm cleaning up IP assignments I might just dedicate one to this).  YSF registration is quick from what I read but the DMR registration sound like it might take longer.  In reviewing this again, it looks like ABME is not needed for YSF <--> DMR crosslinking.  I would just need to register another DMR id for the XLXd server.

Then again, I don't think I need to provide this because anyone running a hotspot would just select the YSF room (after turning on YSF of course) and turn on DMR2YSF.  Fusion is much simpler to deal with anyway.

That said... what should we call this?

My suggestion, per

name "US PLUG"

description "The Philly LUG"

Objections / Suggestions?

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 
Keith C. Perry, MS E.E. 
Managing Member, DAO Technologies LLC 
(O) +1.215.525.4165 x2033 
(M) +1.215.432.5167

----- Original Message -----
From: "Rich Freeman" <>
To: "Philadelphia Linux User's Group Discussion List" <>
Sent: Friday, May 17, 2019 8:12:44 AM
Subject: Re: [PLUG] PLUG Fusion room or DMR Talkgroup

On Thu, May 16, 2019 at 11:50 PM Keith C. Perry
<> wrote:
> Adam...  thanks for the info on D-Star's patent.  I wonder is that's what enabled the integration we're seeing via the radio hot spots.

Disclaimer: the info below is what I've heard from various sources,
but there could be a detail or two wrong and if so I'm all ears to
learn about it.  I wouldn't put this stuff into a talk without some
real research...

So, I don't know all the gory details on all the vocoders used by the
various modes and their patents.  However, I believe they all use AMBE
vocoders which were/are patent-encumbered to one degree or another.

The hotspots, dongles, radios, and everything else sold in stores all
have AMBE vocoder chips in them that are fully licensed and legal.
That is why you don't see software-only DMR/Fusion/D-Star clients all
over the place.  It isn't that your desktop CPU can't keep up (we can
transcode HD video in software realtime these days to a large degree,
audio is no big deal).  In fact, I've heard software-only
implementations are floating around, but since many are illegal they
don't make it onto mainstream sites/etc.  I wouldn't be surprised if a
lot of the bridged networks/etc out there use them, quietly.

I believe Fusion and DMR share the same vocoder in general, which is
why there are a lot of easier-to-use bridging solutions between them.
The container format is different, but the actual encoded audio
packets are the same, so it is pretty easy on even an ARM CPU to just
take the audio data packets, re-wrap them in a new container, and send
them on to a different server or out over the air.  This is also not
illegal since you aren't actually encoding any audio.  Going between
D-Star and the other two modes does require transcoding and thus a
licensed vocoder chip if you want to be legal for any still-patented

Now, I have heard that there is work to get a patent-free codec
working on several of these modes, but compatibility is a big concern
here, and some of the modes handle it better than others.  I've heard
that DMR/Fusion have more support for identifying protocol in them, so
if somebody sends out a transmission (OTA or online) and your radio
reads the codec ID and doesn't know what it is, it just keeps the
audio muted.  So, you get signal going over the repeater/etc, and you
can't hear it, just like having a tone-mute enabled with the wrong
setting.  I've heard that D-Star doesn't have any mechanism to ID the
codec, and so you end up getting noise coming out of the radio as it
doesn't decode properly, which really annoys other D-Star users.
Either way it is suboptimal so these codecs tend to be restricted to
talkgroups/etc designed specifically to experiment with them, because
95% of the radios out there won't work with them.  You can of course
operate these with pure software, legally, since there are no patents.
Eventually all the patents will expire and this issue will become

So, let me take this a different direction (hopefully the below
contains less ignorance):

1.  I suggest we just set up some talk groups and try them out.  The
whole point of ham is experimentation, and there are no limits on how
many things you're allowed to tinker with.  People can use whatever
interests them.

2.  I suggest looking for opportunities to build bridges anywhere we
can.  Set up a DMR talkgroup on brandmeister (I don't think this even
requires hosting anything - you just register a TG number with them).
Set up a YSF reflector.  Then set up a bridge between them.  Maybe set
up an echolink reflector and get that bridged too some day.  For an
example of this see:  They're running most of the
modes, bridged across them.

I don't mind looking into the logistics of setting up a BM TG.  It
sounds like there is some interest there.  If you set up a YSF
reflector I don't mind monitoring that as well with DMR2YSF.  Ideally
it would be best to bridge them but I can monitor both at once.

Philadelphia Linux Users Group         --
Announcements -
General Discussion  --
Philadelphia Linux Users Group         --
Announcements -
General Discussion  --