[arm-allstar] Fwd: New Channel Driver Code in Debelopment

Sat Apr 30 19:15:55 EDT 2022

David,

The majority of our infrastructure is in fact customized GE MASTR II
stations in a form factor called the "uMASTR II" (micro). This is a 2RU
shelf using the original R/T 'door' of a MASTR II station. Entirely
replaced wiring harness, modded squelch circuit, modulator modification, a
few idiot lights, and native controller interface among other options. They
can mate with a rear-mounted PA up to 30W or separately mounted HPAs.

Other radios range from Motorola CDMs, Maxtrac/GM300s, GE Orions, GE Exec
II and MVP, Motorola MSF 5000, Kenwood TKR-850, TKR-820, Spectracom MX-800
and a Midland BaseTech II. Each type has been analyzed & an interface
method developed meeting our specifications. We aim for what some call
"simplex quality" system throughput. Care is taken for level, response &
minimal distortion.

Overall the radios implemented have little trouble meeting our
requirements. High-frequency compensation networks or comp mods inside the
control systems are sometimes needed for true flatness. The alignment of
these radios can have a real effect also. GEs benefit very much from a
fresh IF alignment. Transmit wise, we have a mixture of Phase Modulated and
(direct) Frequency Modulated exciters.

The 8KHz sampling is in my mind left over from the bygone era of low
bandwidth Internet. Remember dial-up? We're not constricted by that any
longer. Echolink has the same and worse problem of fidelity. It was
designed for the dial-up era. Likewise, we're not using 486s for horsepower.

Realizing the current audio bandwidth is "good enough" for most, I realize
it's maybe an uphill battle. As a wise man once said, "You can't be told
yes if you never ask." Were coding in that environment a better honed skill
for me, I'd jump in with both feet!

Short story, I'd love to see this highly successful medium be better yet.
Not only for us, for everyone.

All that said, as Will Roger's once said, "Never miss a good opportunity to
shut up!"

W6XC
GRONK Radio Wild Man

On Fri, Apr 29, 2022, 17:27 David McGough <kb4fxc at inttek.net> wrote:

>
> Matt,
>
> The RTCM is a very different beast from the HamVoIP chan_simpleusb.
> Comparatively, RTCM's have substantially compressed dynamic range.
>
> AllStar, running under Asterisk 1.4, is pretty much fixed at 8KHz sampling
> internally; the notion of 8KHz sampling being hard coded in many places. I
> did include the G.722 CODEC in HamVoIP, however it's present for
> compatibility more that true functionality.
>
> Recent versions of Asterisk have full support for wide-band CODECS, of
> course.
>
> What kinds of radios are you using to obtain 6KHz frequency response??
> I guess you're running full 25KHz deviation?? Kindof reminds me of my
> MastrII gear!
>
> 73, David KB4FXC
>
>
> On Fri, 29 Apr 2022, "M Lech via ARM-allstar" wrote:
>
> > Forgot to hit reply-all..
> >
> > ---------- Forwarded message ---------
> > From: M Lech <grandnationalradio at gmail.com>
> > Date: Fri, Apr 29, 2022, 15:12
> > Subject: Re: [arm-allstar] New Channel Driver Code in Debelopment
> > To: David McGough <kb4fxc at inttek.net>
> >
> >
> > Hi David,
> >
> > Indeed, well aware of the present config... this is for Amateur FM.
> >
> > We have typical flatness from about 20Hz to between 5KHz or 6KHz on our
> > system. Since there can be many hops with RF point to point,  keeping
> audio
> > high quality at each site ensures both pleasure to the ear and
> > functionality. These same systems normally rely on our DTMF to propagate
> > through the system to the far end's decoder. As such, keeping response
> > tight and distortion down is huge. We are normally on 220, 440 and 1200
> > where channel bandwidth isn't an issue like it is with 2-Meters and
> > narrower spacing.
> >
> > There is a noticeable lack of highs for any AllStar system traffic versus
> > the RF interlink. It's not that AllStar sounds horrible, but the
> difference
> > is very evident. It would be wonderful if they were at parity, where the
> > limiting factors became external.
> >
> > A settable lowpass knee up to the ~8KHz max of a 16KHz rate in the
> channel
> > parameters for a node would be nice. Then we could adjust as needed.
> >
> > I think most connections are using uLaw. It does have a limit as I
> recall.
> > RTCMs are ADPCM if I recall right. G722 or similar would address this
> > problem. If the choke point were eliminated, other choices of CODEC could
> > again accommodate users' needs/wants.
> >
> >
> > Is it impractical or just thought unnecessary in the past?
> >
> > On Fri, Apr 29, 2022, 15:00 David McGough <kb4fxc at inttek.net> wrote:
> >
> > >
> > > Matt,
> > >
> > > Are you talking about a ham FM application or broadcast/commercial
> FM???
> > > What kind of repeaters have you got?
> > >
> > > An 8KHz sampling rate allows 4KHz of audio bandwidth (the Nyquist
> limit).
> > > With HamVoIP running simpleusb, the FIR filters used already provide
> about
> > > 3.5KHz of audio bandwidth, which is fantastic!  Here is the FIR filter
> > > response curve:
> > >
> > > https://hamvoip.org/jdm2017/FIR-filter3300-3990.png
> > >
> > > The main factor impacting HamVoIP audio is the CODEC used.  What CODEC
> are
> > > you using?  uLAW or slin are best....slin will use a lot of network
> > > bandwidth, with little extra audio quality, of course.
> > >
> > > You should try a radio-less node with HamVoIP.  I think you'll be
> > > surprised by the audio fidelity. Also, note that the audio sampling
> rate
> > > isn't the FM deviation bandwidth.
> > >
> > >
> > > 73, David K4FXC
> > >
> > >
> > > On Fri, 29 Apr 2022, M Lech wrote:
> > >
> > > > While we're at it, can we implement 16KHz sampling instead of the
> crummy
> > > > 8KHz sampling ? I'd think I'd died & went to heaven to have the audio
> > > > bandwidth matching our RF links. For me this is huge. The hardware
> has no
> > > > problem doing it, so why don't we? Thanks in advance!
> > > >
> > > > 73,
> > > > Matt W6XC
> > > >
> > > > On Fri, Apr 29, 2022 at 9:27 AM "Dave Petrie via ARM-allstar" <
> > > > arm-allstar at hamvoip.org> wrote:
> > > >
> > > > > Hi David, just curious if you made any progress with the new
> channel
> > > driver
> > > > > code in development so that chan_simpleusb can send and receive
> CTCSS
> > > like
> > > > > usbradio does. Here is what I found that led me to ask the
> question.
> > > > >
> > > > > On 9/5/21 11:41 PM, David McGough wrote:
> > > > >
> > > > > Hi Jim,
> > > > >
> > > > > CTCSS generation isn't currently in the chan_simpleusb code.
> However,
> > > it
> > > > > is in new channel driver code in development.
> > > > >
> > > > > All the original usbradio related code and features are in
> HamVoIP. So,
> > > > > that should work, if you can tolerate the sporadically glitchy
> sounding
> > > > > audio.
> > > > >
> > > > > How quickly do you need this?  I can probably get you info on the
> new
> > > > > channel driver in a few days.
> > > > >
> > > > >
> > > > > 73, David KB4FXC
> > > > > _______________________________________________
> > > > >
> > > > > ARM-allstar mailing list
> > > > > ARM-allstar at hamvoip.org
> > > > > http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
> > > > >
> > > > > Visit the BBB and RPi2/3/4 web page - http://hamvoip.org
> > > > >
> > > >
> > >
> > >
> > _______________________________________________
> >
> > ARM-allstar mailing list
> > ARM-allstar at hamvoip.org
> > http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
> >
> > Visit the BBB and RPi2/3/4 web page - http://hamvoip.org
> >
>
>