[arm-allstar] Yet another USB FOB Modification

[Kevin Custer]

On 11/16/2014 12:58 PM, Doug Crompton wrote:
> My definition of users is individual simplex nodes which I would 
> suspect is the overwhelming majority especially in the BBB world.


We'll have to agree to disagree there.....


>
> I lost track of what we are even talking about here.


I'll get you back on track.


> If it is pre/deemphasis then that can be done in the radio or in SW.


I never said anything about pre or deemphasis.

>   In my opinion characteristically distorted usbradio audio is much 
> more of an annoying problem than improper equalization.


By definition, systems that have double pre-emphasis or any other 
equalization problem are distorted.   Generalizing that ALL usbradio 
installations have distorted audio is not factual.  If a usbradio system 
has distortion which is offensive, something is wrong with the deployment.

>
> Most radios can be made to work with simpleusb and with pre/deempahsis 
> done in the radio.


Suitable audio usually isn't the problem.  Getting quality logic to the 
radio interface is.  But, there is a new solution to that problem.

> That is using fixed level speaker audio and mic input. It works fine. 
> Mototorla's can do it and so can most all commercial ham equipment.

Many commercial radios have high pass filtering on the MIC input. This 
is for good reason, to eliminate voice energy that can mix with the PL 
tone and cause 'talk off'.  As such, these filters keep you from 
effectively using the MIC input for CTCSS.  In some instances, you can 
crank the CTCSS audio up to overcome the losses of the filtering, only 
to create problems with the dynamic range of the clipper/limiter, 
creating distortion.  PL distortion of even the slightest amount will 
cause harmonics which 'sound' louder than they are comparing deviation.  
"PL" buzz is a big problem when using MIC audio on radios that have 
HPF'ing.  Jamming the CTCSS into the MIC jack creates another problem.  
When you modulate voice peaks which are clipped by the limiter, the 
CTCSS tone gets chopped off, causing the decoder to drop on the users end.

  The right way is to get to the modulator, so the CTCSS tone injection 
is after the clipper/filter.


> It makes no difference what type of FM modulation is being used if you 
> let the radio do the pre/deemphasis.


It's evident you don't have a lot of experience with modulators in FM 
radio.  Some modulators are PM (phase modulated).  These modulators are 
present in many Motorola and GE radios don't have the ability to 
modulate with the same index across the entire PL and voice range.  As 
such, it takes a greater amount of voltage to get industry standard PL 
deviation.

> Why make things more difficult at the expense of a dB or two more 
> flatness that most people can't even hear.


Because not doing it correctly is bad news.  Creating spurious emissions 
can get you a pink slip.  Besides, people know the difference - believe me.

>
> Our local network typically has 15 to 20 nodes connected and a mixture 
> of radios, many Alinco, a few Motorola, and a others. They are all 
> running simpleusb and all typically have good audio. I find that most 
> audio problems arise with the users handhelds. Listen to any repeater 
> and you will find audio all over the place in quality and level. You 
> can't correct something that is bad to begin with.

While I agree that you can do anything with poorly designed and aligned 
user radios, by maximizing the dynamic range and minimizing the 
distortion introduced, the better you can tolerate it.  Why make it 
worse than it already is?  I'll agree that it is more difficult to 
deploy a system where the audio is taken from the discriminator and 
feeds the modulator directly, but there is no substitute for the amount 
of dynamic range and lower distortion that results.  Like anything, 
taking the easy way out usually works okay, but I'm not one that is 
generally satisfied with it just being okay.

Kevin



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hamvoip.org/pipermail/arm-allstar/attachments/20141116/171d4fe6/attachment-0001.html>