Puntje in QSO / FT8 - FT4

[Louwrens PD3LPA]

Geen idee hoe ik dit moet uitleggen.
Maar laatste tijd zie ik steeds vaker puntjes in QSO's.
Bijgevoegd schermafdruk maakt denk ik wel duidelijk wat ik bedoel.

Iemand enig idee?
Ik zat te denken aan slechte verbindingen waardoor hij niet helemaal goed decodeerd.

Ik zet net de radio aan en het was nu wel heel even erg.
Daarna was het minder.

[ex-F0NVA]

Dat zijn 'speciale' roepletters zoals bv. pa0stayathome en dergelijke. Als die cq roepen ziet ge wel de volledige roepletters.

[Louwrens PD3LPA]

Goed bedoeld hoor die stay home callsigns.. Maar eerlijk gezegd vind ik het een rommeltje zo.
Ik vind dat we de callsigns wat sirieuzer moeten gaan nemen.

[PA2S]

Goed bedoeld hoor die stay home callsigns.. Maar eerlijk gezegd vind ik het een rommeltje zo.
Ik vind dat we de callsigns wat sirieuzer moeten gaan nemen.

Daar ben ik het van harte mee eens.

Wat die puntjes betreft, lange calls kunnen niet tegelijk met de rest van het bericht worden gezonden zoals rapport en locator. Er wordt in plaats daarvan een z.g. hash code gebruikt, die is afgeleid van de langere call. Als je die call een keer hebt ontvangen, dan weet de computer ook de hash en dan kan hij de <..> terugvertalen naar de bijbehorende call.

Voor meer info even zoeken op Google...

73, Henk

[Louwrens PD3LPA]

Bedankt Henk!

[PA2S]

Bedankt Henk!

Graag gedaan uiteraard.

Nog een aanvulling:

Hier is een prima (Engelstalige) handleiding te vinden:
https://www.g4ifb.com/FT8_Hinson_tips_for_HF_DXers.pdf

De laatste versie is van j.l. maart. Zowel WSJT-X als JTDX worden erin toegelicht. Van A tot Z, wat er nodig is, hoe je het aan de praat maakt en allerlei handige tips. Prachtig stuk werk!

Op pagina 45 en volgende wordt nadere uitleg gegeven over speciale roepletters.

Bij alle JT modes is ernaar gestreefd om het aantal bits zoveel mogelijk te beperken. Dit idee kwam van W3IWI en KA9Q. Er is bijvoorbeeld gekeken naar de structuur van roepletters en de conclusie was dat er 28 bits nodig zijn om alle ca. 262 miljoen combinaties te coderen. Als je alle tekens in de call apart zou verzenden, zou je (ongeveer) 6x6=36 bits nodig hebben. Ook grid locators zijn op die manier "gecomprimeerd". Voor 4 tekens zouden 4x6=24 bits nodig zijn, maar als je per locatorvak een code bepaalt, heb je maar 32.400 codes nodig en daarvoor zijn 15 bits voldoende. Specials zoals CQ, QRZ, rapporten en dergelijke zijn ook vertaald naar binaire codes en uiteindelijk omvat een FT bericht dus veel minder bits dan je nodig zou hebben om alles als apart teken te coderen. Vergeet ook niet dat vanwege de vaste structuur van de berichten ook geen spaties nodig zijn en die bits ook vervallen.

Bij afwijkende calls moeten vaste onderdelen van het bericht vervallen en dat gebeurt tijdens CQ en het aanroepen van een station. Het maakt overigens nog verschil of je bijvoorbeeld F/PA2S zendt (toevoeging volgens een lijst) of een toevoeging die niet in de lijst staat, in het laatste geval valt er nog meer weg. Ik sla vaker het grid over bij aanroepen dus roep meteen PD3LPA PA2S -05. Dat werkt ook nog als F/PA2S, maar met een hele rare call gaat dat niet meer.

In de handleiding worden voorbeelden gegeven, die op een begrijpelijke manier laten zien hoe het "onder de motorkap" werkt. Zie daartoe o.a. pagina 66 en verder. Ook mooie voorbeelden van enkele onvolkomenheden, zoals calls die niet voldoen aan de ITU specificatie waardoor de software in de war raakte. Een reden temeer om "normale" calls te gebruiken en die rare calls af te schaffen.

Belangrijk is ook dat door middel van z.g. Forward Error Correction (FEC) fouten in de transmissie kunnen worden hersteld. Daardoor kan een deels verminkt bericht (QRM, fading etc.) toch correct worden gedecodeerd. Een Cyclic Redundancy Check (CRC) helpt mee om "Chinese" decodes te vermijden.

Eem mooie toevoeging (zover ik weet is Igor van JTDX daarmee begonnen) is de z.g. signal substraction, waarmee een gedecodeerd signaal in de software opnieuw wordt gecodeerd en van de andere signalen wordt "afgetrokken" waardoor zwakkere signalen onder de sterkere vandaan kunnen worden gehaald. JTDX doet dit verbluffend goed, WSJT-X vind ik in dat opzicht minder.

Alles bij elkaar dwingt het in mijn ogen respect af, zowel voor wat betreft te prachtige toepassing van fundamentele (signaal- en informatie)wetenschap en fantastische software die daaruit is voortgekomen. Laten we ook blij zijn dat het in public domain is gepubliceerd en we dus niet te maken hebben met aasgieren die veel geld vragen voor slechte software (hè Bill?). Nu spoort het mensen aan om door te ontwikkelen.

Fijn weekend allemaal,
Henk

[Louwrens PD3LPA]

Nadeel van dat forum... ik mis een duimpje