JTTY: WSJT-X 3.2 brengt RTTY-achtige snelheid naar zwakke signalen
WSJT-X 3.2.0-rc1 introduceert JTTY, een nieuwe digitale toetsenbordmodus die de directheid van RTTY combineert met gecodeerde signalering voor betrouwbaardere ontvangst bij zwakke signalen. De release bevat ook nieuwe mogelijkheden voor Q65, MAP65 en QMAP en nodigt radioamateurs uit de software vóór de algemene release te testen.
Een ander ritme voor digitale radio
Digitale radioamateurcommunicatie is de afgelopen twintig jaar steeds meer gericht geraakt op een bepaald soort efficiëntie: verdeel de tijd in vaste perioden, zend in het ene tijdslot en luister in het andere, waarna de computer de uitwisseling decodeert. Die aanpak heeft communicatie met zwakke signalen bijzonder effectief gemaakt. Tegelijkertijd heeft hij veranderd hoe het voelt om de radio te bedienen. Bij FT8 of FT4 zet de operator vaak een reeks berichten klaar en kijkt toe terwijl de software die afwerkt, in plaats van zelf een bericht te typen en het antwoord van het tegenstation in realtime te zien binnenkomen.
JTTY, de nieuwe modus in WSJT-X 3.2.0-rc1, volgt een ander ritme. Het is een toetsenbord-naar-toetsenbordmodus voor live, asynchrone communicatie. Een uitzending kan beginnen zodra de operator een bericht verstuurt, zonder te wachten op een UTC-grens of een vast zend-ontvangstschema. Binnenkomende tekst verschijnt zodra die wordt gedecodeerd, op een manier die vertrouwder is voor operators die RTTY of andere digitale gespreksmodi hebben gebruikt.
Die manier van werken is geen poging om RTTY exact na te bootsen. JTTY combineert live tekst en vertrouwde contestbediening met een gecodeerde golfvorm die berichten robuuster moet maken bij zwakke signalen of ongunstige omstandigheden. De centrale belofte is specifiek: de directheid en bedieningsgewoonten van RTTY-contests behouden, terwijl digitale signaalverwerking de fouten helpt beperken die conventionele RTTY moeilijk te decoderen kunnen maken.
WSJT-X 3.2.0-rc1 is een release candidate, geen definitieve versie voor algemene beschikbaarheid. Het WSJT Development Team vraagt radioamateurs de software te proberen, de nieuwe functies uitgebreid te testen en bugs of vragen te melden via de openbare issue tracker, de discussieomgeving of gebruikersforums van het project. Dat onderscheid is belangrijk. Een release candidate biedt de kans om software te testen die al bruikbaar genoeg is, maar nog kan veranderen op basis van ervaringen uit de praktijk.
JTTY is de meest zichtbare vernieuwing, maar vormt niet de hele release. WSJT-X 3.2.0 introduceert ook nieuwe mogelijkheden voor Q65, MAP65 en QMAP, naast een groot aantal verbeteringen en foutoplossingen. Die programma’s ondersteunen verschillende vormen van zwak-signaalcommunicatie, van digitale communicatie met een gewone transceiver tot breedbandige VHF- en EME-activiteiten. De release is dus zowel een experiment met een nieuwe modus als een omvangrijke update van de bredere WSJT-softwarefamilie.
De timing valt op omdat WSJT-X al sterk wordt geassocieerd met een manier van digitaal radioverkeer die bijna het tegenovergestelde is van JTTY. FT8 en FT4 maakten gestructureerde, door computers ondersteunde verbindingen toegankelijk voor een enorm wereldwijd publiek. JTTY stelt de vraag of hetzelfde software-ecosysteem ook een modus kan ondersteunen waarin de operator directer bij het gesprek betrokken blijft: zelf bepalen wanneer er wordt gezonden, met functietoetsen een contestuitwisseling aansturen en tekst lezen terwijl die binnenkomt.
Het antwoord hangt van meer af dan de kwaliteit van de demodulator. Operators moeten uitvinden of de uitwisselingsformaten van JTTY bij hun gewoonten passen, of de macro’s bruikbaar zijn tijdens een snelle contest, of stations elkaar op de voorgestelde frequenties kunnen vinden en of de prestaties bij zwakke signalen ook buiten een voorbeeldopname standhouden. Daarom presenteert het ontwikkelteam de release als een testversie en vraagt het om feedback, in plaats van de aankondiging als het eindpunt te beschouwen.
Van getimede reeksen naar live tekst
De vertrouwde WSJT-X-modi zijn gebaseerd op nauwkeurig afgestemde timing. FT8 gebruikt zend- en ontvangstcycli van 15 seconden, terwijl FT4 cycli van 7,5 seconden gebruikt. De computer en radio van de operator werken binnen die herhalende structuur. Zo kan de software een signaal in een voorspelbaar tijdvenster plaatsen en er in de bijbehorende ontvangstperiode naar zoeken. Die organisatie is een belangrijke reden waarom de modi betrouwbare uitwisselingen kunnen automatiseren bij moeilijke propagatieomstandigheden.
Werken met vaste tijdsloten heeft een onvermijdelijk compromis. De computer moet wachten op de juiste zendperiode en het andere station moet tijdens de bijbehorende ontvangstperiode luisteren. Een bericht wordt normaal gesproken niet weergegeven als een doorlopende stroom tekens. In plaats daarvan ontvangt de software een volledige gecodeerde uitzending en toont zij de gedecodeerde inhoud nadat de periode is afgelopen. De operator ziet een reeks voltooide berichten, geen tekstregel die teken voor teken binnenkomt.
RTTY heeft traditioneel een directere ervaring geboden. Dankzij de asynchrone tekenstroom kan het ene station beginnen met zenden en kan het andere de tekst ontvangen zonder dat elk bericht op een gemeenschappelijke klok hoeft te worden afgestemd. Operators kunnen een toetsenbord, functietoetsen of contestlogsoftware gebruiken om vertrouwde uitwisselingen te versturen. De indeling is praktisch voor contesten omdat een QSO kan worden teruggebracht tot een callsign, een signaalrapport en een serienummer, terwijl de operator het tempo bepaalt.
Die directheid brengt andere technische uitdagingen met zich mee. De gebruikelijke RTTY-contestsignalering met 45,45 baud gebruikt twee frequentieverschuivingsmodulatie-tonen. Wanneer ruis, fading, interferentie of een slechte signaal-ruisverhouding de ontvangen tonen vervormt, kan de decoder verkeerde tekens produceren. Eén fout teken in een callsign of serienummer kan al een herhaling noodzakelijk maken. De vertraging die daardoor ontstaat, kan een deel van het snelheidsvoordeel tenietdoen dat de modus aantrekkelijk maakt.
JTTY probeert tussen deze twee modellen in te zitten. De modus behoudt asynchroon, toetsenbordgericht werken, maar verstuurt informatie in korte, geframede bursts met vier-toons-Gaussian frequency-shift keying. De framing en codering geven de ontvanger structuur om mee te werken, terwijl het asynchrone ontwerp voorkomt dat operators op vaste UTC-zendtijdsloten moeten wachten. De uitzending is niet continu zoals een niet-geframeerde stroom; in plaats daarvan worden compacte frames verstuurd zodra berichten zijn samengesteld en verzonden.
Elk JTTY-frame duurt 1,888 seconden en neemt ongeveer 127 Hz bandbreedte in beslag. Daarmee past het in een smal stukje spectrum, al is het breder dan de ongeveer 80 Hz die vaak met FT4 wordt geassocieerd en smaller dan de nominale shift van 170 Hz bij gangbare RTTY-configuraties met 45,45 baud. Deze getallen beschrijven verschillende eigenschappen en vormen samen geen volledige maatstaf voor de prestaties in de ether. Bezet bandbreedte, toonafstand, symboolsnelheid, codering en het gedrag van de ontvanger bepalen allemaal hoe een modus presteert op een drukke band.
Een frame van 1,888 seconden is kort genoeg voor snelle uitwisselingen, maar de frame-indeling beperkt hoeveel willekeurige tekst er in één keer kan worden verzonden. Eén frame bevat vijf vrije tekens. Op het eerste gezicht lijkt dat een ernstige beperking voor een toetsenbordmodus. Het ontwerp wordt begrijpelijker wanneer berichten niet als gewone lopende tekst worden behandeld. Contestuitwisselingen zijn sterk repetitief: callsigns, rapporten, serienummers en korte bevestigingen komen voor in een beperkt aantal combinaties. Een protocol kan zulke gestructureerde berichten efficiënter weergeven dan wanneer het willekeurige tekens één voor één codeert.
Hier zit het belangrijkste verschil tussen JTTY’s gestructureerde contestberichten en vrije tekst. De standaardindelingen benutten de beschikbare framecapaciteit efficiënt, waardoor een contestuitwisseling veel sneller kan verlopen dan de limiet van vijf tekens doet vermoeden. Het voorbeeld van de ontwikkelaars, “CQ CQ K1ABC CQ”, past in één frame, terwijl een volledige uitwisseling als “W9XYZ 599 107” twee frames nodig heeft. Vrije tekst haalt daarentegen ongeveer 30 woorden per minuut, ruwweg de helft van de snelheid van de gestructureerde indelingen.
Dat verschil heeft een praktische consequentie: aangepaste berichten kunnen de operator vertragen. In veel digitale modi zijn macro’s een handige laag boven op het onderliggende protocol. Bij JTTY bepaalt de keuze van de berichtindeling rechtstreeks hoe efficiënt informatie in de beschikbare frames wordt verpakt. Een operator die compacte contestberichten vervangt door een uitgebreidere eigen uitwisseling, kan meer frames nodig hebben en langer uitzenden.
Het ontwerp van de modus beloont daarom discipline. Een korte, consistente contestuitwisseling is niet alleen gemakkelijker te typen, maar sluit ook beter aan op de structuur van de uitzending. Dat maakt vrije tekst niet nutteloos. Die biedt ruimte voor korte opmerkingen, bevestigingen of gesprekken wanneer snelheid geen prioriteit heeft. De claim dat de modus snel is, geldt echter vooral voor de vooraf gedefinieerde contestformaten, niet voor onbeperkte tekst.
Waarom vier tonen ertoe doen
De vier-toons-GFSK-golfvorm van JTTY biedt de ontvanger meer dan een eenvoudige keuze tussen twee tonen. GFSK, of Gaussian frequency-shift keying, vormt de overgangen tussen frequentietoestanden zo dat abrupte verbreding van het spectrum wordt beperkt. Gaussische filtering maakt de frequentieveranderingen geleidelijker en helpt zo de bezette bandbreedte van het signaal begrenzen. Het resultaat is een golfvorm die symboolinformatie met een reeks discrete tonen kan overbrengen zonder de scherpe overgangen van een ongefilterd geschakeld signaal.
De toevoeging van meerdere tonen garandeert op zichzelf geen betere prestaties bij zwakke signalen. De ontvanger moet nog steeds de timing en frequentie van het signaal bepalen, de verzonden symbolen van de ruis onderscheiden en de informatie in de frames reconstrueren. Codering, synchronisatie, interleaving, signaalverwerking en de berichtstructuur beïnvloeden allemaal het resultaat. De prestaties van een golfvorm zijn een eigenschap van het volledige modulatie- en decodeersysteem, niet van een label als “vier tonen”.
Het WSJT-project richt zich al lange tijd op het terugwinnen van bruikbare informatie uit signalen die met het menselijk gehoor moeilijk te onderscheiden zijn. De modi zijn gebaseerd op het idee dat een computer structuur kan benutten die een menselijke luisteraar niet betrouwbaar uit een ruisachtig audiosignaal kan halen. FT8 is een bekend voorbeeld: compacte berichten, strikte timingafspraken en digitale decodering maken samen korte uitwisselingen mogelijk wanneer spraakcommunicatie lastig zou zijn. JTTY brengt die nadruk op signaalverwerking naar een modus die veel meer moet aanvoelen als een live toetsenbordgesprek.
De ontwikkelaars beschrijven JTTY als een modus met aanzienlijk betere prestaties bij zwakke signalen en een veel lagere foutmarge dan standaard-RTTY. De releasematerialen verwijzen ook naar een voorbeeldopname in de nieuwe User Guide. Volgens het team is het JTTY-signaal in die opname zo zwak dat ontvangst met conventionele RTTY op 45,45 baud marginaal en foutgevoelig zou zijn. Dat is nuttig materiaal voor operators die de modus willen beoordelen, maar het is niet hetzelfde als een gepubliceerde, gestandaardiseerde gevoeligheidsdrempel.
In het materiaal bij de release candidate is nog geen formele JTTY-drempel voor de signaal-ruisverhouding gepubliceerd. Dat is belangrijk voor iedereen die modi met één getal in decibel wil vergelijken. De gevoeligheid bij zwakke signalen hangt af van de meetmethode, de referentiebandbreedte, de berichtlengte, de toegestane foutmarge, de implementatie van de ontvanger en de omstandigheden waaronder de test is uitgevoerd. Een drempelwaarde zonder die details kan een misleidende vergelijking opleveren.
RTTY en FT4 dienen bovendien verschillende gebruiksdoelen, waardoor een rechtstreekse rangschikking onvolledig is. De korte, gesynchroniseerde perioden en gestructureerde berichten van FT4 zijn geoptimaliseerd voor snelle geautomatiseerde uitwisselingen. De asynchrone tekststroom van RTTY blijft aantrekkelijk omdat die een herkenbare contestworkflow ondersteunt en operators in hun eigen tempo laat zenden en ontvangen. JTTY wil een deel van die workflow combineren met een gecodeerd signaal, niet alle functies van beide modi vervangen.
Ook de bezette bandbreedte van 127 Hz wijst op een praktische afweging. JTTY is smal genoeg om binnen een bescheiden audiofilterband te passen, maar een smal signaal is alleen nuttig als stations het betrouwbaar kunnen afstemmen en decoderen. Operators moeten drukte vermijden, audioniveaus beheersen, hun transceivers goed afstemmen en rekening houden met de voorgestelde dialfrequenties. De ervaring in de ether wordt gevormd door het gedrag van echte stations, niet alleen door een golfvorm die onder één schone testopstelling is gegenereerd.
Frequentieafwijking is een van de basisproblemen van digitale radio. Zowel zender als ontvanger hebben oscillatoren en de gezamenlijke afwijking kan de ontvangen tonen verschuiven ten opzichte van de verwachte frequenties van de decoder. Moderne software kan binnen een bepaalde onzekerheidsmarge zoeken, maar de hoeveelheid drift en de breedte van dat zoekgebied bepalen hoe gemakkelijk het signaal wordt gevonden. Ook een contestmodus die niet-gesynchroniseerde starts ondersteunt, vereist een goede frequentiediscipline als stations elkaar binnen een beperkt spectrumgebied willen vinden.
Propagatie voegt daar nog een laag aan toe. Op HF kan fading de signaalsterkte binnen enkele seconden of fracties daarvan veranderen. Selectieve fading kan verschillende delen van een signaal verschillend beïnvloeden, terwijl atmosferische ruis, lokale elektrische interferentie en naburige stations delen van een uitzending kunnen maskeren. Codering kan helpen informatie uit beschadigde symbolen te reconstrueren, maar geen enkele digitale modus laat het radiokanaal verdwijnen. De prestaties van JTTY zullen variëren met de band, het tijdstip, het antennesysteem, het propagatiepad en de hoeveelheid activiteit.
Daarom zijn praktijktests bijzonder waardevol. Een voorbeeld-WAV-bestand kan laten zien wat de decoder met een bekende opname doet. Het kan niet de volledige variatie aan echte bedrijfsomstandigheden weergeven: een station dat op een lang pad in en uit fading raakt, een operator die iets naast de frequentie zendt, een drukke band of een contestuitwisseling die precies tijdens een interferentiepiek wordt verstuurd. De release candidate biedt operators de gelegenheid te ontdekken hoe de modus zich in zulke situaties gedraagt en hun bevindingen met de ontwikkelaars te delen.
Contesten zonder het toetsenbord los te laten
De functietoetsen van JTTY zijn gericht op operators die een snel contesttempo willen. De toetsen F1 tot en met F8 ondersteunen de vertrouwde run- en search-and-pounce-werkwijze. De modus biedt macro’s voor het callsign van de operator, het callsign van het tegenstation, de uitwisseling en het volgende callsign dat in een wachtrij staat. Die bouwstenen zijn herkenbaar voor iedereen die digitale contestsoftware heeft ingesteld.
De macrovariabelen die voor de release candidate worden beschreven, zijn onder meer %M voor het eigen callsign van de operator, %H voor het callsign van het tegenstation, %E voor de uitwisseling en %Q voor het volgende callsign in de wachtrij. De uitwisseling is momenteel gebaseerd op een rapport van 599 en een serienummer. Operators kunnen berichten in de wachtrij plaatsen terwijl een uitzending nog bezig is. Dat helpt pauzes te verkorten wanneer een verbinding snel verloopt.
De wachtrij is meer dan een handige gebruikersinterfacefunctie. Tijdens een contest moeten de handen en aandacht van de operator worden verdeeld over luisteren, stations identificeren, de logger bedienen en bepalen wat er vervolgens wordt verzonden. Als het volgende antwoord kan worden voorbereid terwijl het huidige bericht in de lucht is, kan de tijd tussen de ene en de volgende uitwisseling korter worden. Daardoor kan de modus meer aanvoelen als een instrument dat je bespeelt dan als een verzameling losse berichten die één voor één worden verstuurd.
Berichten in een wachtrij vereisen echter ook dat de software de juiste status bijhoudt. Een macro moet het juiste callsign en de juiste uitwisseling gebruiken; de logger en de radiobesturing moeten overeenkomen over welk station wordt gewerkt; en de operator moet weten wat de software na een druk op een toets gaat uitzenden. Dit zijn bekende aandachtspunten bij contesten, maar een nieuwe modus brengt nieuwe mogelijkheden voor configuratiefouten met zich mee. Tijdens de eerste tests moeten operators elke macro controleren en de uitzendingen buiten de ether of op een dummyload verifiëren voordat ze erop vertrouwen tijdens een liveverbinding.
De keuze voor asynchrone communicatie is bepalend voor de beoogde ervaring van JTTY. Bij FT8 verloopt de uitwisseling volgens een reeks getimede berichttypen. Omdat de timing en formaten gestandaardiseerd zijn, kunnen de software en operators een groot deel van die reeks automatiseren. Bij JTTY kan de operator een uitzending starten zodra die er klaar voor is en de uitwisseling met de functietoetsen bedienen. De operator blijft sterk op software vertrouwen, maar de software ondersteunt de timing van de QSO in plaats van die voor te schrijven.
Dat verschil kan operators aantrekken die snelheid in contesten waarderen, maar de directheid van RTTY missen. Sommige radioamateurs houden van het tactische tempo van een runfrequentie zoeken, CQ roepen en antwoorden afhandelen met een vertrouwde reeks macro’s. Anderen geven juist de voorkeur aan FT8 omdat de automatisering en timing het nodig maken om voortdurend het toetsenbord te bedienen. JTTY heft dat verschil in voorkeur niet op. De modus biedt een andere manier om een digitale QSO te organiseren, waarna operators zelf kunnen bepalen of de balans bij hen past.
Er speelt ook een culturele kwestie. RTTY-contests hebben in de loop der tijd hun eigen bedieningsconventies, macro’s, loggerintegraties en gewoonten ontwikkeld. Een nieuw protocol kan dat niet automatisch overnemen alleen omdat het op de oude modus lijkt. Het moet zijn plaats verdienen met voorspelbaar gedrag, voldoende ondersteuning voor logsoftware, een bruikbaar frequentieplan en genoeg activiteit om stations daadwerkelijk met elkaar in contact te brengen. De voorlopige dialfrequenties van JTTY bieden een startpunt, maar de acceptatie bepaalt of die plekken ook echte ontmoetingspunten worden.
Een contestmodus moet bovendien duidelijk vastleggen wat als een uitwisseling geldt. Het huidige gebruik van een rapport van 599 en een serienummer biedt een vertrouwd sjabloon. Dat kan de leercurve verkorten, al moeten operators nog steeds begrijpen hoe de applicatie invoer van callsigns, wachtrijen, hertransmissies en bevestigingen afhandelt. De release candidate is het moment om verschillen tussen de aannames van de software en de manier waarop operators in echte contesten werken, aan het licht te brengen.
De eerste frequentievoorstellen van het ontwikkelteam bestrijken banden van 160 meter tot en met 2 meter. De voorgestelde gemeenschappelijke ontmoetingsplek voor vroege JTTY-activiteit is 14,090 MHz op de 20-meterband. De voorgestelde dialfrequenties zijn uitdrukkelijk voorlopig. Als de modus populair wordt, kunnen sommige of alle frequenties veranderen wanneer operators ontdekken waar de activiteit het beste werkt en hoe interferentie met ander bandgebruik kan worden voorkomen.
Deze getallen verwijzen naar dialfrequenties, niet noodzakelijk naar de exacte RF-positie van elke uitgezonden toon. Bij een digitale modus via de geluidskaart bepalen de dialfrequentie van de transceiver en de audiofrequentie die naar de radio wordt gestuurd samen de RF-frequentie van de uitzending. Operators moeten daarom de frequentie-instellingen van de software volgen en letten op de plaatsing van het uitgezonden audiosignaal, in plaats van aan te nemen dat de dialfrequentie alleen de volledige positie van het signaal in het doorlaatgebied beschrijft.
Volgens de releasenotes kunnen veel van de voorgestelde frequenties in de standaardfrequentielijst van WSJT-X verschijnen nadat de optie Reset in de tabel Settings | Frequencies is gebruikt. Dat kan handig zijn voor een nieuw station, maar het resetten van een frequentietabel kan waarden overschrijven die de operator handmatig heeft ingevoerd. Wie een zorgvuldig bijgehouden lijst heeft, kan overwegen alleen de benodigde JTTY-frequenties toe te voegen in plaats van de volledige tabel te resetten. Dat is een praktisch advies: vroege tests hoeven niet ten koste te gaan van bestaande configuratie-instellingen.
JTTY in een bestaand software-ecosysteem
WSJT-X is geen applicatie die uitsluitend voor JTTY is bedoeld. De softwarefamilie van het project omvat modi en programma’s voor verschillende soorten zwak-signaalcommunicatie. WSJT-X ondersteunt een reeks modi die op HF, VHF, UHF en voor andere toepassingen worden gebruikt. MAP65 is geoptimaliseerd voor breedbandige ontvangst van JT65- en Q65-signalen, vooral bij EME-activiteiten. QMAP werkt samen met WSJT-X om breedbandige Q65-ontvangst binnen een EME-subband te ondersteunen.
De release 3.2.0 breidt dus een bestaand platform uit in plaats van een afzonderlijk programma met een eigen bedieningsmodel te introduceren. Dat is relevant voor radioamateurs die hun audioapparatuur, radiobesturing, logging en digitale workflow al hebben ingesteld. Een nieuwe modus in een vertrouwde applicatie is misschien eenvoudiger te testen dan een nieuw zelfstandig pakket, al kunnen grote versiewijzigingen nog steeds gevolgen hebben voor de configuratie en moeten operators de releasenotes zorgvuldig lezen.
Volgens de releaseaankondiging bevat de update nieuwe mogelijkheden voor Q65, MAP65 en QMAP, evenals vele andere verbeteringen en foutoplossingen. Die toevoegingen zijn ook relevant voor operators die voorlopig geen belangstelling hebben voor JTTY. Q65 wordt gebruikt voor veeleisende zwak-signaalcommunicatie, waaronder EME en ionosferische verstrooiing; MAP65 en QMAP richten zich op breedbandontvangst en bandkaartfuncties in gespecialiseerde systemen. De aankondiging beperkt de release niet tot JTTY, en operators van die modi moeten de volledige wijzigingslijst doornemen voordat ze upgraden.
Voor versie 3.2 is een nieuwe WSJT-X User Guide gepubliceerd. De hoofdstukken over JTTY en de voorbeeldopname bieden een eerste houvast bij de configuratie en het beluisteren van de modus. Het ontwikkelteam waarschuwt dat de handleiding nog wordt bijgewerkt: sommige schermafbeeldingen kunnen verouderd zijn en sommige teksten ontbreken nog. Die waarschuwing is vooral nuttig voor gebruikers van de release candidate, omdat ze duidelijk maakt wat ze van de documentatie mogen verwachten. Een instructie die niet overeenkomt met de huidige interface kan te maken hebben met de onvoltooide handleiding en hoeft geen bedieningsfout te betekenen.
Het voorbeeld-WAV-bestand is bijzonder nuttig omdat een toekomstige gebruiker daarmee de decoder kan verkennen voordat die zelf gaat uitzenden. Het laat zien hoe JTTY-tekst tijdens het verwerken van de opname verschijnt en geeft operators een indruk van de berichtframing. Een bekende opname beluisteren helpt ook om bepaalde configuratieproblemen te onderscheiden van onzekerheden tijdens het gebruik in de ether. Als het voorbeeld niet wordt gedecodeerd, kan de operator eerst software-instellingen en audio-instellingen controleren voordat de transceiver en het propagatiepad aan de lijst met variabelen worden toegevoegd.
Voor logsoftware beschrijven de releasematerialen een MMTTY-compatibele interface voor N1MM Logger+ versie 1.0.11449 of hoger. Volgens de beschreven werkwijze kan de operator “JTTY” in het callsignveld van N1MM typen om WSJT-X in de JTTY-modus te starten. Er is ook een voorbeeldbestand met functietoetsen opgenomen om de eigen berichtformaten van JTTY te demonstreren. Dat is een belangrijke brug voor contestoperators, omdat logsoftware geen bijkomstigheid is: daar worden callsigns, uitwisselingen, serienummers en contestgegevens beheerd.
Compatibiliteitsclaims moeten wel als versiegebonden worden beschouwd. Een interface die voor een bepaalde release van N1MM Logger+ wordt beschreven, kan afhankelijk zijn van configuratiedetails. Toekomstige versies van een van beide applicaties kunnen het gedrag veranderen. Gebruikers moeten de actuele softwaredocumentatie raadplegen en de koppeling vóór een contest testen. De eerste configuratie kan uitgaan van een werkende FT8-instelling, maar een succesvolle FT8-verbinding garandeert niet automatisch dat elke JTTY-toets, macro of loggerintegratie precies naar verwachting werkt.
De aanbevolen werkwijze is voorzichtig en vertrouwd: controleer eerst of de bestaande configuratie van WSJT-X en N1MM de transceiver kan besturen en PTT kan schakelen. Selecteer daarna JTTY en test de functietoetsen terwijl de radio op een dummyload is aangesloten. Met een dummyload kan de operator de uitgezonden berichtenreeks controleren zonder een ongeteste macro in de ether te brengen. Zodra de configuratie is bevestigd, kan de operator op de voorgestelde ontmoetingsfrequentie luisteren en op activiteit reageren.
Deze aanpak gaat niet alleen over het voorkomen van gênante uitzendingen. De signaalketen van een conteststation omvat de audio-uitgang van de computer, het modulatiepad van de radio, CAT-besturing, PTT, het zend-audioniveau en de versterker- of antenne-installatie. Een nieuwe modus kan een configuratiedetail blootleggen dat bij een eerdere modus niet opviel. Door de volledige keten met een beperkt risico te testen, wordt het eenvoudiger een JTTY-softwareprobleem te onderscheiden van een probleem met de stationsconfiguratie.
JTTY kan verzonden en ontvangen tekst opslaan in ALL.TXT, het vertrouwde activiteitenlogboek van WSJT-X. Dat bestand is handig bij het beoordelen van een testsessie omdat het tekst bewaart die niet direct opvalt wanneer je vluchtig naar de interface kijkt. Tijdens het testen van een release candidate kunnen zulke logbestanden operators helpen reproduceerbare problemen te melden. Een melding met de softwareversie, het besturingssysteem, de configuratie en relevante loggegevens is nuttiger voor de beheerders dan een algemene opmerking dat een bericht niet werkte.
Het project is open source en wordt verspreid onder de GNU General Public License, versie 3. De openbare repository bevat de ontwikkelingsgeschiedenis van het WSJT-project en biedt ruimte voor issues, discussies en bijdragen aan de code. Het project is opgebouwd door een gemeenschap van ontwikkelaars en radioamateurs. Bij de aankondiging worden onder anderen K1JT, K9AN, G4KLA, N9ADG, DL3WDG, W3SZ, KJ5HST en KD0BTO als bijdragers genoemd. Een release candidate maakt dat samenwerkingsproces zichtbaar: de software is bruikbaar genoeg om in de ether te experimenteren, terwijl de feedbackronde nog onderdeel is van het ontwikkelwerk.
Die openheid biedt technisch geïnteresseerde gebruikers ook een manier om te begrijpen hoe de modus in de bredere codebasis past. Het overzicht voor ontwikkelaars van het project beschrijft hoe mensen met relevante vaardigheden kunnen bijdragen. Niet iedere operator hoeft de broncode te lezen of aan te passen, maar de beschikbaarheid van de code en de ontwikkelingsgeschiedenis stelt onderzoekers, softwareontwikkelaars en ervaren gebruikers van digitale modi in staat het ontwerp te bekijken en aan tests deel te nemen.
De eerste test is of operators elkaar kunnen vinden
Een digitale modus heeft meer nodig dan een capabele decoder. Er moet ook een gemeenschappelijke plek zijn om te werken. Zonder gedeelde frequenties kunnen de eerste stations succesvol uitzenden zonder elkaar ooit te horen. Dat is vooral belangrijk bij een nieuwe asynchrone modus, waarbij stations niet automatisch op elkaar worden afgestemd door vaste tijdsloten en een gemeenschappelijk schema. De voorgestelde dialfrequentie van 14,090 MHz op 20 meter biedt vroege gebruikers een gezamenlijk richtpunt.
De frequentielijst in het releasemateriaal is uitgebreid. Voor 160 meter wordt 1838 kHz voorgesteld, voor 80 meter 3575 kHz, voor 40 meter 7090 kHz, voor 30 meter 10140 kHz en voor 20 meter 14090 kHz. Daarna volgen 18100 kHz op 17 meter, 21090 kHz op 15 meter, 24920 kHz op 12 meter, 28090 kHz op 10 meter, 50160 kHz op 6 meter en 144160 kHz op 2 meter. De ontwikkelaars omschrijven deze voorstellen als zeer voorlopig; ze kunnen veranderen naarmate de activiteit zich ontwikkelt.
Een voorlopige lijst is nuttig, maar moet niet worden aangezien voor een permanent bandplan of een officiële toewijzing van spectrum. Binnen de amateurbanden gelden verschillende nationale en regionale regels, bestaan gevestigde digitale activiteiten en zijn er contestpraktijken en lokale bedieningsconventies. Operators zijn zelf verantwoordelijk om ervoor te zorgen dat hun uitzendingen voldoen aan de regelgeving en bandplannen die op hun locatie van toepassing zijn. Een voorgestelde dialfrequentie is een ontmoetingspunt, geen vervanging voor dat eigen oordeel.
20 meter is een redelijke eerste ontmoetingsband omdat die vaak communicatie over uiteenlopende afstanden mogelijk maakt en veel gebruikers van digitale modi telt. HF-propagatie is echter nooit constant. Zonneactiviteit, lokale tijd, antenneprestaties, ruis en het pad tussen de stations bepalen allemaal welke banden open zijn. Een frequentie waarop de ene middag bruikbare activiteit te horen is, kan later op de dag of bij andere propagatieomstandigheden stil zijn.
De eerste sessies zullen waarschijnlijk evenzeer draaien om ontdekken als om communiceren. Operators moeten vaststellen waar JTTY-signalen in het doorlaatgebied verschijnen, hoe snel de decoder tekst weergeeft, of uitzendingen goed over elkaar heen kunnen vallen en hoeveel frequentieafstand geschikt is. Ook moeten ze ontdekken of de voorgestelde frequenties genoeg ruimte bieden voor activiteit of dat een andere indeling praktischer is. Dat zijn gewone beginvragen voor een nieuwe modus, maar ze zijn extra belangrijk wanneer die modus snel en asynchroon moet werken.
Overlappende signalen vormen een belangrijke test. De beschrijving van de release noemt signaalaftrekking en adaptieve decodering als hulpmiddelen om signalen bij overlap of fading terug te winnen. Bij signaalaftrekking probeert de ontvanger een gedecodeerd signaal te schatten en de bijdrage ervan uit de ontvangen audio te verwijderen, zodat een ander signaal eronder beter zichtbaar wordt. Adaptieve decodering kan zich aanpassen aan veranderende signaalomstandigheden in plaats van ervan uit te gaan dat het signaal volkomen stabiel blijft. Hoe effectief deze technieken zijn, hangt af van hoe goed de ontvanger elk signaal kan herkennen en hoe nauwkeurig die kan modelleren wat verwijderd moet worden.
In een druk contestsegment kunnen twee stations tegelijk uitzenden, bewust of toevallig. Een decoder die overlappende signalen kan scheiden, zou waardevol zijn, zeker als de modus meerdere snelle uitwisselingen rond één frequentie stimuleert. Signaalaftrekking brengt echter ook technische complexiteit met zich mee. Een slechte schatting van het ene signaal kan restsignalen achterlaten of een ander signaal vervormen. De ontvanger moet bepalen wanneer er voldoende bewijs is om een signaal te decoderen en wanneer een poging om overlappende gegevens terug te winnen onjuiste tekst kan opleveren.
Fading vormt een ander probleem. HF-signalen kunnen in sterkte variëren wanneer het propagatiepad verandert, en korte, diepe fades kunnen een deel van een uitzending uitwissen. Een geframed en gecodeerd bericht kan redundantie bevatten die helpt de bedoelde tekst terug te winnen, maar het resultaat hangt af van hoe de informatie over het frame is verdeeld en hoeveel ervan verloren gaat. Operators die de modus testen, moeten daarom niet alleen letten op de vraag of een bericht wordt gedecodeerd, maar ook of het correct en consistent wordt ontvangen.
Het onderscheid tussen succesvolle en nauwkeurige decodering is cruciaal. Een digitale modus die tekst weergeeft, levert niet noodzakelijk foutloze tekst. Bij contesten kan een foutief callsign of serienummer meer kosten dan een gemist bericht, omdat de fout ongemerkt kan worden overgenomen en later moet worden gecorrigeerd. De nadruk van de ontwikkelaars op een lager foutpercentage is daarom net zo relevant als de claim over zwakke signalen. Een goede test houdt bij hoe vaak herhaling nodig is, hoe vaak een verkeerd teken wordt weergegeven en hoe de operator onzekere ontvangst herkent.
Een release candidate is een geschikt moment voor dit soort praktische evaluatie. Operators kunnen de modus onder vergelijkbare omstandigheden vergelijken met hun eigen ervaring met RTTY, zonder aan te nemen dat één voorbeeldopname elke situatie vertegenwoordigt. Een bruikbare melding kan de band en frequentie beschrijven, de geschatte signaalsterkte, de modus en softwareversie van het tegenstation, eventuele signaaloverlap en wat de decoder weergaf. Ook zonder laboratoriummetingen kunnen zorgvuldig beschreven observaties problemen aan het licht brengen die ontwikkelaars kunnen reproduceren.
Het is net zo belangrijk te melden wanneer de modus goed werkt. Feedback over softwareontwikkeling richt zich vaak op fouten, maar een nieuwe modus heeft ook bewijs nodig over de omstandigheden waarin het ontwerp slaagt. Als JTTY duidelijke tekst oplevert op een signaalniveau waarbij RTTY herhaalde uitzendingen nodig zou hebben, of als de macrobediening een contestuitwisseling natuurlijk laat verlopen, helpen zulke observaties de sterke punten van de modus te bepalen. Het doel van testen is niet om een vooraf vaststaande conclusie te bevestigen, maar om het gedrag van het systeem in kaart te brengen.
Een release candidate met onvoltooide onderdelen
Het label 3.2.0-rc1 geeft een bepaalde fase in de ontwikkeling aan. Release candidates zijn bedoeld voor ervaren gebruikers die kunnen omgaan met onvolledige documentatie, nieuw gedrag kunnen testen en duidelijke feedback kunnen geven. Het zijn geen gewone promotionele previews en ze garanderen niet dat alles precies zo werkt als in de definitieve versie. Operators moeten rekening houden met problemen en die melden via de openbare repository of gebruikersforums van het project.
Die status beïnvloedt hoe de software het beste kan worden gebruikt. Een station dat zich voorbereidt op een belangrijke contest kan redelijkerwijs een stabiele versie blijven gebruiken totdat de nieuwe modus en loggerintegratie grondig zijn getest. Een operator die geïnteresseerd is in de ontwikkeling van digitale modi kan bereid zijn de release candidate te installeren en tijd te besteden aan het verkennen van het gedrag. Beide keuzes zijn geldig. Het belangrijkste is dat een release candidate gebruikers uitnodigt aan de evaluatie deel te nemen, in plaats van te doen alsof elk onderdeel van de software al af is.
De huidige staat van de User Guide bevestigt dat. Volgens het project zijn sommige schermafbeeldingen verouderd en ontbreekt er nog tekst terwijl de documentatie wordt bijgewerkt. Wie een onduidelijke instructie tegenkomt, moet daar rekening mee houden en controleren of er een bijgewerkte versie is. Ook feedback over de documentatie is welkom: onduidelijke configuratiestappen of ontbrekende uitleg zijn nuttige signalen voor het project, vooral wanneer ze een geïnteresseerde operator verhinderen de modus te testen.
De softwarepakketten zijn beschikbaar voor Windows, macOS en Linux. De Linux-builds omvatten x86_64 en aarch64; daarnaast keert ook een 32-bits armhf-build terug. Die brede ondersteuning is relevant omdat radioamateurstations uiteenlopende computers gebruiken, van desktopwerkstations tot kleine singleboardcomputers. Raspberry Pi-gebruikers kunnen vooral belangstelling hebben voor het armhf-pakket, omdat ze de applicatie dan mogelijk niet zelf hoeven te compileren. Gebruikers moeten vóór de installatie wel de actuele releasebestanden en systeemvereisten controleren, aangezien pakketten en afhankelijkheden per platform kunnen verschillen.
Een nieuwe hoofdversie kan ook gevolgen hebben voor bestaande configuratiebestanden. Operators moeten de releasenotes doornemen op wijzigingen die van invloed zijn op hun modi, audioapparaten, radiobesturing of loggingworkflow. Wie veel tijd heeft besteed aan het afstellen van een stationsconfiguratie, kan vóór het testen een back-up van de configuratiebestanden maken. Dat is gewone softwarezorg, maar wordt belangrijker wanneer een release een nieuwe bedrijfsmodus en wijzigingen in meerdere programma’s bevat.
De Release Notes geven een gedetailleerd overzicht van de wijzigingen sinds versie 3.0.2. Dat overzicht is waardevol omdat een featureaankondiging vanzelf de nadruk legt op wat nieuw is, terwijl operators ook willen weten wat er is veranderd in onderdelen die ze al gebruiken. De bredere update bevat verbeteringen voor Q65, MAP65 en QMAP en veel foutoplossingen. De volledige releasenotes zijn daarom de aangewezen plek om te beoordelen of versie 3.2.0-rc1 voor een bepaald station ook buiten JTTY gevolgen heeft.
De feedbackkanalen van het project maken eveneens deel uit van het testproces. Gebruikers kunnen een issue openen of deelnemen aan een discussie in de openbare repository, of contact opnemen via een van de gebruikersforums. Een goede melding moet voldoende specifiek zijn om onderzoek mogelijk te maken: vermeld de build van de release candidate, het besturingssysteem, relevante instellingen, de radio-interface en de stappen die tot het gedrag leiden. Gaat het om een signaal, beschrijf dan de band, de omstandigheden en of het probleem met de voorbeeldopname kan worden herhaald.
Bij een nieuwe modus kunnen de eerste nuttige meldingen eenvoudig zijn. Start de software in JTTY wanneer die via N1MM Logger+ wordt aangeroepen? Versturen de functietoetsen het verwachte bericht? Gaat de wachtrij correct naar het volgende bericht? Wordt ontvangen tekst weergegeven op een manier die de operator kan volgen? Maakt de voorgestelde frequentielijst het gemakkelijk een ander station te vinden? De antwoorden op die vragen kunnen net zo belangrijk zijn als een gevoeligheidswaarde voor de kop, omdat ze bepalen of operators de modus daadwerkelijk zullen gebruiken.
Het open-sourcekarakter van het project maakt die feedback extra betekenisvol. Een gebruiker die een reproduceerbaar probleem ontdekt, kan de beheerders helpen het programma voor iedereen te verbeteren. Een programmeur kan verder gaan door de broncode te bekijken of een oplossing bij te dragen. Ook een radioamateur zonder programmeerervaring kan waardevolle testresultaten leveren, vooral wanneer die de omstandigheden in de ether duidelijk beschrijft. Het ontwikkelproces is afhankelijk van zowel softwarekennis als operationele ervaring.
Wat JTTY kan veranderen en wat niet
De belofte van JTTY is niet simpelweg “RTTY, maar beter”. Die beschrijving zou voorbijgaan aan de verschillen in framing, codering, gegevensdoorvoer en software-integratie. Een nauwkeuriger omschrijving is dat JTTY de bedieningservaring van toetsenbordradio op menselijk tempo en met asynchrone communicatie probeert te behouden, terwijl het een signaalverwerkingsaanpak toepast die samenhangt met de zwak-signaalmodi van het WSJT-project.
Als de modus slaagt, kan die contestoperators een nieuwe optie bieden voor snelle uitwisselingen wanneer gewone RTTY-ontvangst onbetrouwbaar wordt. De voordelen zullen het duidelijkst zijn wanneer een gecodeerde uitzending herhalingen kan voorkomen en de gestructureerde berichtformaten aansluiten op de uitwisseling die een contest vereist. Hoe vaker een operator een callsign en serienummer in één keer correct kan ontvangen, hoe groter de kans dat de theoretische snelheid van de modus zich vertaalt in een hogere praktische contestopbrengst.
Snelheid is echter meer dan bits per seconde of woorden per minuut. Contestprestaties hangen af van de tijd die nodig is om een station te identificeren, een uitwisseling te starten, het antwoord te ontvangen, fouten te corrigeren en de verbinding te loggen. Een modus die een compacte uitwisseling snel verzendt, maar ingewikkeld is om in te stellen of vaak herstelwerk vereist, presteert in de praktijk mogelijk niet beter dan een langzamere modus. Evenzo kan een sterk geautomatiseerd systeem voor de ene operator efficiënter zijn dan een live toetsenbordworkflow, ook al voelt die laatste directer aan.
De gestructureerde formaten van JTTY zijn een bewust compromis. Ze maken veelvoorkomende contestberichten efficiënter, maar beperken de vrijheid van willekeurige tekst. Een lang gesprek is nog steeds mogelijk, maar de snelheid van vrije tekst bedraagt ongeveer 30 woorden per minuut en elk frame bevat slechts vijf willekeurige tekens. Dat is traag vergeleken met de gestructureerde contestformaten en kan beperkend aanvoelen tijdens een uitgebreid gesprek. De sterkste toepassing van de modus blijft een korte, gestandaardiseerde uitwisseling in plaats van onbeperkte digitale chat.
Er is niets tegenstrijdigs aan een toetsenbordmodus die minder geschikt is voor lange gesprekken. Veel radiomodi zijn geoptimaliseerd voor een specifiek doel: snelle contestuitwisselingen, zwak-signaal-DX, noodverkeer, gesprekken via toetsenbord of geautomatiseerde propagatierapportage. JTTY lijkt zich te richten op het raakvlak tussen prestaties bij zwakke signalen en contesten. Operators die langere berichten willen sturen, kunnen daarvoor andere digitale modi blijven gebruiken; JTTY hoeft niet elk doel te dienen om nuttig te zijn.
De modus heeft ook een stabiel frequentieplan nodig dat door de gemeenschap wordt gedeeld. De voorlopige voorstellen zijn een uitnodiging om te beginnen, maar operators kunnen uiteindelijk behoefte krijgen aan regionale afstemming, contestgerichte richtlijnen en afspraken om overlap te vermijden. De invoering van een digitale modus heeft netwerkeffecten: elk extra station maakt de modus nuttiger voor alle anderen, maar vroege gebruikers hebben voldoende gezamenlijke activiteit nodig om het leren ervan de moeite waard te maken. Een gemeenschappelijk ontmoetingspunt op 20 meter is een praktische eerste stap.
De nieuwe mogelijkheden voor Q65, MAP65 en QMAP kunnen een ander publiek aantrekken. EME-operators, liefhebbers van VHF-zwak-signaalcommunicatie en gebruikers van breedbandige SDR-systemen hebben andere behoeften dan HF-RTTY-contestoperators. De opname van deze wijzigingen in dezelfde release laat zien dat WSJT-X 3.2.0 niet alleen om de introductie van JTTY draait. Het project zet ook het bredere werk aan zwak-signaalcommunicatie over verschillende banden en gebruiksomgevingen voort.
Die bredere context is van belang omdat JTTY daarmee deel wordt van een volwassen ecosysteem van modi, in plaats van een op zichzelf staande nieuwigheid. Het project heeft al laten zien dat verschillende protocollen in één applicatie naast elkaar kunnen bestaan, elk afgestemd op een bepaald propagatiepad, een bepaalde berichtstructuur en een specifiek gebruiksdoel. JTTY voegt daar een nieuwe mogelijkheid aan toe: een modus waarin de operator direct handelt, terwijl het signaal gestructureerd genoeg blijft voor robuuste decodering.
Of JTTY een vaste plaats in contesten krijgt, zal in de ether worden beslist. Operators moeten elkaar vinden, de software testen, ervaringen vergelijken en bepalen of de manier van werken de belofte waarmaakt. De release candidate biedt daarvoor een concrete mogelijkheid. De modus komt in handen van gebruikers terwijl de implementatie, documentatie en bedieningsconventies nog kunnen veranderen.
Voor een eerste test is het praktisch om de voorbeeldopname te beluisteren, de logger- en radiobesturing te controleren, de functietoetsen op een dummyload te testen en vervolgens op 14,090 MHz dial op 20 meter te luisteren. Operators die bugs vinden of vragen hebben, kunnen die melden via de issues, discussies of gebruikersforums van het project. De voorgestelde bandfrequenties kunnen veranderen; vroege gebruikers moeten ze daarom zien als ontmoetingsplaatsen voor experimenten, niet als permanente toewijzingen.
De bredere betekenis van JTTY ligt mogelijk minder in het verdringen van FT8 of RTTY dan in het uitbreiden van de manieren waarop radioamateurs digitale radio kunnen gebruiken. FT8 liet zien hoe aantrekkelijk sterk gestructureerde, getimede verbindingen met zwakke signalen kunnen zijn. RTTY biedt nog altijd een directe, door de operator gestuurde contestervaring. JTTY stelt voor dat die eigenschappen niet onverenigbaar hoeven te zijn: een live toetsenborduitwisseling kan gecodeerde frames en adaptieve decodering gebruiken om moeilijke signalen beter op te vangen.
Dat is een waardevol experiment, ook voordat duidelijk is welke plaats de modus uiteindelijk krijgt. Nieuwe modi maken afwegingen zichtbaar die gemakkelijk over het hoofd worden gezien wanneer software eenmaal routine is geworden: de balans tussen automatisering en controle door de operator, tussen willekeurige tekst en efficiënte codering, tussen smalle bandbreedte en robuuste ontvangst, en tussen vaste timing en flexibele communicatie. WSJT-X 3.2.0-rc1 nodigt operators uit die afwegingen te testen in plaats van ze alleen theoretisch te beoordelen.
Image(s) used in this article are either AI-generated or sourced from royalty-free platforms like Pixabay or Pexels.
This article may contain affiliate links. If you purchase through these links, we may earn a commission at no extra cost to you.