Rich Freeman on 17 May 2019 05:13:01 -0700


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

Re: [PLUG] PLUG Fusion room or DMR Talkgroup


On Thu, May 16, 2019 at 11:50 PM Keith C. Perry
<kperry@daotechnologies.com> 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
codecs.

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
moot.

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: https://padmr.net/  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.

-- 
Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug