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

Fri Apr 29 20:37:10 EDT 2022

Most yaesu's I've heard sound like they top out at about 5 KHz.

-----Original Message-----
From: ARM-allstar <arm-allstar-bounces at hamvoip.org> On Behalf Of "David
McGough via ARM-allstar"
Sent: April 29, 2022 8:27 PM
To: "M Lech via ARM-allstar" <arm-allstar at hamvoip.org>
Cc: David McGough <kb4fxc at inttek.net>
Subject: Re: [arm-allstar] Fwd: New Channel Driver Code in Debelopment

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
> 

_______________________________________________

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