Echolink is een secundaire mogelijkheid voor radiozendamateurs om gebruik te kunnen maken van onze repeatersystemen. Alhoewel Echolink gretig op onze systemen wordt gebruikt kent het ook duidelijke beperkingen. In dit artikel gaan we nader in op de Echolink inmeldproblematiek die vaak wordt afgedaan als “te weinig ruimte laten”…

Echolink gebruikers ervaren met enige regelmaat problemen om tijdens een lopend QSO tussen de doorgangen in te melden. Dit is natuurlijk vervelend en leidt soms tot ergernis en onbegrip. In sommige gevallen wordt door radiozendamateurs opgemerkt dat door de gebruikers van onze repeaters aan de radiozijde te weinig ruimte zou worden gelaten voor Echolink gebruikers. Alhoewel enthausiast repeatergebruik soms wel eens kan leiden tot wat kleine ruimtes tussen de uitzendingen ligt hierin niét de voornaamste reden waardoor het inmelden via Echolink vaak moeizaam is.

Primair is Echolink bedoelt als simplex protocol. Dit wil zeggen dat het zodanig is ingericht dat slechts communicatie in één richting tegelijk mogelijk is; ofwel je zendt óf ontvangt, maar niet tegelijkertijd. Tijdens het transport van de echolink bron (bijvoorbeeld een repeater) naar de bestemming (de Echolink gebruiker) kan het pad tussen beide stations via de IP weg (internet) soms best excessief lang zijn. Het effect wat hierbij optreed is dat de tijd die nodig is om de audiopakketjes op haar bestemming te krijgen dan ook langer wordt. Doorgaans zal dit in de praktijk echter niet veel meer zijn dan 50 tot maximaal 100 milliseconden (0,1 seconde). In de praktijk zal dit dus niet de grootste bron van ellende zijn.

Veel echolink gebruikers maken tegenwoordig gebruik van een mobiele telefoon. Een bijkomend effect is in dit geval dat de latency (de vertraging) hand over hand toeneemt naarmate de klasse van verbinding van een lagere orde is. Bij 2G (GSM) verbindingen is de datasnelheid zelfs beperkt tot 9600bps wat er in combinatie met andere datagebruikers toe kan leiden dat de latency steeds verder toeneemt. Nu komt het gelukkig steeds minder voor dat mobiele telefoons afhankelijk zijn van 2G voor data overdracht, maar voornamelijk bij langdurig echolink gebruik kan dit toch wel een factor van invloed zijn.

Normaal gesproken als de latency klein is dan hoort de Echolink gebruiker de ruimte tussen de doorgangen prima en zal het doorgaans wel lukken om in te melden. Als echter een latency ontstaan van bijvoorbeeld 300ms of zelfs meer (en dit is helaas regelmatig het geval) dan betekent dit dat tussen de uitzendingen een kleinere tijd overblijft om via echolink in te melden. In veel gevallen neemt de latency toe naarmate het QSO vordert en zal deze latency kleiner worden doordat de ruimte tussen de uitzendingen wordt ingekort op Echolinkte. Hierdoor kan het soms lijken alsof de gebruikers héél kort achter elkaar uitzenden terwijl dit in werkelijkheid niet het geval is! Op Echolink klinkt dit dus vaak (veel) korter dan in werkelijkheid.

Een ander probleem dat optreed bij Echolink is dat het gebruikte protocol bij mobiele telefoons niet voorziet in zoiets als een “einde uitzending” markering. Omdat Echolink is bedoeld als simplex technologie hebben de ontwikkelaars een mechanisme ingebouwd dat ervoor zorgdraagt dat niet “gezonden” kan worden op het moment dat een signaal ontvangen wordt, dit noemt men interlock. Door het ontbreken van een “einde uitzending” markering is er praktisch gesproken maar één methode om vast te stellen of de uitzending voorbij is, namelijk door een wachttijd in te bouwen na de laatst ontvangen audiopacket. Deze wachttijd bedraagt ongeveer 2,4 seconden – dat is natuurlijk behoorlijk lang als je wil inmelden…

Opgeteld kan het dus gemakkelijk voorkomen dat je verschillende bronnen hebt die het inmelden gecompliceerd maken:

1. Latency die standaard voortkomt uit het manier waarop echolink functioneert (~1200 milliseconden)
2. Latency die wordt veroorzaakt in het netwerk (~20…100 milliseconden)
3. Latency door gebruik van langzame telefoonverbindingen (~0…500 milliseconden)
4. De interlock tijd die de Echolink client nodig heeft om vrijgeschakeld te worden na de laatste doorgang (~2400 milliseconden)

We doen een rekenvoorbeeldje:

• Tussen de uitzendingen van twee gebruikers zit, dankzij de courtesy toon (rogerbeep) gemiddeld een ruimte van 2 seconden.
• De protocol latency bedraagt standaard 1200ms.
• De echolink gebruiker beschikt over een internet verbinding via zijn GSM van lage kwaliteit. Hierdoor loopt de totale netwerk latency op tot 600ms.

case 1:
Daar waar de gewone gebruiker op zijn transceiver keurig een ruimte hoort van twee seconden zal Echolink proberen om de verloren tijd (latency) te minimaliseren. Stel dat de optimaal haalbare netwerklatency 100 milliseconden bedraagt, dan hoort de Echolink gebruiker slechts een ruimte van (2000 – (600 – 100) = 1500 milliseconden, ofwel 1,5 seconden. De praktijk leert dat deze ruimte in veel gevallen zelfs helemaal tot nul gereduceerd is waardoor de uitzendingen naadloos op elkaar aansluiten!

case 2:
Nu wil de gebruiker zich proberen in te melden. Praktisch gezien hoort hij een tussenruimte van ongeveer 1,5 seconde voordat de volgende persoon met zijn uitzending begint. De interlock van zijn Echolink software bedraagt echter 2,4 seconde! Dit betekent dat de echolink gebruiker 1,5 – 2,4 = 0,9 seconde tekort komt!

Om bovenstaande redenen moeten echolink gebruikers er rekening mee houden dat inmelden helaas gecompliceerd kan zijn. Sommige gebruikers stellen daarom voor dat de tijd tussen twee uitzendingen (de zogenoemde ‘kier’) langer moet zijn om echolink gebruikers tegemoet te komen. Praktisch betekent dit dat de ruimte tussen iedere doorgang tenminste de optelsom van alle mogelijke vertraging zou moeten zijn plus voldoende tijd voor de echolink gebruiker om zich in te melden, laten we zeggen één seconde. Dit leidt tot praktische bezwaren want het zou betekenen dat tenminste 5 seconden pauze nodig is tussen iedere doorgang. Dit staat een vlot gesprek natuurlijk flink in de weg en is daarom niet toepasbaar.

Er zijn enkele manieren waardoor je de nadelige effecten van Echolink enigszins kan beinvloeden:

• Gebruik zoveel mogelijk een optimale dataverbinding. Bij voorkeur Wifi boven 2G of 3G…
• Bij gebruik van de mobiele Apps (Android en iOS) kan je de route naar onze systemen korter maken door onze eigen proxy of relay server te kiezen. Onze eigen server is PI9NOZ.AMPR.ORG. Gewoon één van de beschikbare PI9NOZ proxyservers kiezen in de App is al voldoende, de rest gaat vanzelf.
• Indien je niet mobiel bent maar de PC gebruikt: Er is één toepassing voor Linux die géén interlock principe hanteert waardoor je zéér snel kan inmelden! Deze Linux toepassing heet Qtel en is hier te downloaden. Let er op, Linux only!

Het Echolink ontwikkelteam schrijft over de interlock op mobiele telefoons nog het volgende:

All three of the official EchoLink apps have an interlock that prevents TX until after the last RX packet is received. Unfortunately, there is no concept of an “end of transmission” packet or marker, so the only way to determine that RX has ended is to wait a certain short amount of time after each packet to determine whether any more are in the stream, possibly delayed due to network congestion. It might be possible to shorten this wait-time slightly, but it cannot be completely eliminated.

The reason for the interlock is that EchoLink is a half-duplex system by design, matching the half-duplex nature of Amateur Radio QSOs; one cannot talk and listen at the same time.

Wij blijven in contact met Echolink ontwikkelaars om te onderzoeken of hier verbetering mogelijk is.