[aprssig] Echolink/IRLP objects for the mobile

[Stephen H. Smith]

Robert Bruninga wrote:
> EchoLink/IRLP for the APRS mobile:
>
> But I was surprised when I was rejected by a digi operator that
> would not support EchoLink at all, and only IRLP.  I thought
> this battle was over long ago, and that the two are getting
> along quite well.  I know there is a bias against all the
> non-radio Shack-potato's on EchoLink (same problem with
> shack-potato's on APRS), but, then this initiative to get these
> objects on APRS has nothing to do with the shack-potatos, only
> on-air ooperation.  We are only interested in OPEN Echolink
> Repeaters or links.  Can someone enlightmen me if this
> anti-echolink bias is still pervasive?
>   

There are significant differences between the two systems:

o     IRLP is Linux-based and requires a specialized purpose-built 
hardware interface between the computer and the radio. (Which physically 
makes the "shack potato" mic-and-speaker-in-front-of the-computer mode 
impossible.)

o     Echolink is is Windows-based and has no specific hardware 
requirements. Echolink's termination on the computer can be anything - a 
sound card interface to a user's radio, a mic & speaker, the  TX and RX 
audio lines of a repeater, etc.   Echolink incorporates SOFTWARE  DTMF 
decoding and SOFTWARE VOX-like audio  detection for RX activity which 
can eliminate the need for bringing a receiver COR or squelch line out 
of the radio.  (Though it will sense COR through a serial  port's DCD 
hand shaking line and works FAR better if you do so.)


The result is that IRLP setups tend to be by the serious hardcore 
techie  faction of amateur radio.    By contrast, because of it's 
minimal hardware requirements and seemingly simple setup, Echolink nodes 
are often just "thrown up" by casual appliance operators.   There tends 
to be some overtones of the Linux-vs-Windows religious war among the two 
factions.

Assuming they ARE actually connected to a radio instead of a computer 
mic & speakers, many Echolink installations are crude lashups with radio 
speaker and mic audio connections wired directly to a computer sound 
card with no attempt to properly match audio levels, 
de-emphasis/pre-emphasis equalization or ground-loop isolation, and with 
no positive COR-based TX/RX sensing.  

Many so-called Echolink "repeater" connections are not connected to the 
repeater at all, but are actually just users' radios listening to a 
repeater channel from miles away.  In this mode, the Echolink interface 
has no positive way to sense the repeater receiver's 
COR/squelch/"activity"  indicator. As a result, double squelch crashes 
get fed into the Internet connection -- first the repeater squelch, then 
the user's radio squelch. Worse, long repeater tails can  confuse the 
Echolink VOX -based "COR" by sensing "silence" during the tail, causing 
the Internet user to try to transmit before the repeater carrier has 
dropped and reset it's timer.  This is aggravated by the 2 second or 
more round-trip propagation delay over the Internet.  

By the time a mobile user's TX audio reaches the Internet in such 
lashups,  (and has been pre-de-re-de-emphasized FOUR times by his own 
radio's TX audio system, the repeater receiver audio system, the 
repeater transmit audio system and then the remote Echolink receiver's 
audio system, each with less-than-optimum response curves), the Internet 
user frequently experiences horribly distorted muffled muddy audio at 
wildly high or very low levels.   

This is not to say you can't have high-quality audio on Echolink.  You 
can.  I actually built a separate  op-amp-based precision de-emphasis 
network directly off the receiver discriminator for my Echolink node, 
and precisely set the TX level so that 95% level from the Internet 
corresponded to exactly 4.5 KHz deviation over the air.

In the "shack potato" mode, at least half the users try to close-talk 
junk computer electret multi-media mics resulting in  muddy muffled 
bass-heavy nearly un-intelligible audio.  [Echolink does provide a 
software-based TX-audio bass-cut function that reduces this problem but 
the appliance operators never read enough to discover this fact.]

[A little-known fact, due to the fact that most users don't RTFM, is 
that you can connect a normal mobile radio hand mic's audio to the sound 
card MIC IN and the mic's PTT line to one of the handshaking lines of a 
serial port. This then allows you to use a communications-grade mic with 
normal PTT EXACTLY the way you would on a radio!]

A large percentage of these clueless users:

a)     Don't know how to find and use the Windows record mixer to set 
their outgoing audio level, and

b)     Don't comprehend the huge difference between talking to another 
computer-only shack potato (with an essentially noiseless background 
that renders proper level setting non-critical) and talking to a radio 
user (where getting the link radio fully deviated with clean audio is 
essential to the mobile listener.

At least 4 or 5 times a day, I get random connects to my Echolink node 
from clueless shack pototatos that can't figure out how to set their TX 
(Windows record) audio level (often no audio at all) and can't figure 
out how to switch from RX to TX.   I get 15-30 seconds of dead audio 
before either I or they disconnect....

BOTTOM LINE:  The Echolink software is an incredibly sophisticated & 
capable program, but the deceptively-simple typical Windows 
"run-Setup-and-use"   interface encourages far, far too many half-assed 
setups by uninformed end-users that WON'T RTFM first!

------------------------------------------------------------------------


--

Stephen H. Smith    wa8lmf (at) aol.com
EchoLink Node:      WA8LMF  or 14400    [Think bottom of the 2M band]
Skype:        WA8LMF
Home Page:          http://wa8lmf.net

JavAPRS Filter Port 14580 Guide
  http://wa8lmf.net/aprs/JAVaprsFilters.htm

"APRS 101"  Explanation of APRS Path Selection & Digipeating
  http://wa8lmf.net/DigiPaths

Updated "Rev H" APRS            http://wa8lmf.net/aprs
Symbols Set for UI-View,
UIpoint and APRSplus:





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tapr.org/pipermail/aprssig/attachments/20090727/943b0bef/attachment.htm>