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

[M Lech]

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