qdx FT8-Config am Apple Mac

    • New

    Hallo Forum, hallo Welt,

    ich habe vor einer Weile einen qdx für einen befreundeten OM aufgebaut. Bei mir unter Windows funktioniert der qdx mit WSJT-X einwandfrei.

    Der befreundete OM nutzt ein Apple Mac Laptop und hat neben WSJT-X noch eine alternative Anwendung installiert. An seinem Rechner bekommen wir den qdx nicht stabil zum Laufen:

    Zwischenzeitlich hat es nach dem x-ten Anlauf funktioniert, seit einem letzten Ausschalten/Reboot wieder nicht mehr. Probleme mit dem USB-Kabel wurden zwischenzeitlich durch Wechsel des Kabels gelöst.

    Aktueller Stand:

    - Mit WSJ-X funktioniert der Empfang der FT8-Signale, aber nicht die Ansteuerung zum Senden, der qdx blinkt nicht und sendet keine hf, obwohl AFAIR der Vor-Test in den Einstellungen "Grün" liefert.

    - Mit der anderen FT8-Anwendung (?) funktioniert der Empfang nicht, aber im Sendebetrieb blinkte die LED und hf ging auch raus.

    Die config des qdx unterMacOS sollte konzeptionell ja identisch sein: Für die Ansteuerung das richtig tty.serial mit passender BAUD-Rate wählen, für Audio das passende Audio-Interface des Systems wählen.

    Wer nutzt den qdx am Mac und kann helfen?

    vy73

    Thilo

    • New

    Moin,
    wenn der QDX partout nicht senden will könnte das evtl. an zu geringem Audiopegel liegen. Möglicherweise ist der Mac da mit seinem Signal etwas geizig.
    Ich kann das leider nicht mehr nachprüfen, da ich zwar zwei QDX habe aber mein Macbook leider den Geist aufgegeben hat.

    73 de Eike KY4PZ / ZP5CGE

    • New

    Moin,

    ich habe weder QDX noch Mac, das aber mal aus Interesse überflogen. Ich würde bei groups.io in den Gruppen von QRPLabs und WSJT-X nachfragen, Anwender scheint es reichlich zu geben, die auch keine Probleme haben. Um welchen Mac geht es eigentlich? Ein älteres Gerät noch mit Intel Prozessor oder eines mit Apple Silicon? Das sollte man bei einer Anfrage angeben und auch die Firmware Version des QDX.

    Eine Zusammenfassung hat mal Gemini erstellt ;)

    Das ist ein klassisches und extrem nerviges Phänomen bei der Kombination aus macOS, dem QDX (bzw. dessen virtuellen COM-Ports) und WSJT-X. Da der QDX hardwareseitig läuft (Empfang klappt in WSJT-X, Senden klappt in der anderen App), liegt das Problem definitiv in den Untiefen der macOS-Treiberverwaltung und den Berechtigungen der Apps.

    Bei macOS verhalten sich serielle USB-Schnittstellen (CDC-ACM) leider manchmal wie eine Diva, besonders nach einem Reboot oder wenn zwei Programme um dieselbe Schnittstelle buhlen.

    Hier sind die typischen Stolpersteine und Lösungen, die du und der OM Schritt für Schritt durchgehen solltet:

    1. Das /dev/cu. vs. /dev/tty. Dilemma (Wichtig für WSJT-X CAT)

    Unter macOS gibt es für jedes serielle Gerät zwei Einträge im System. Für den QDX sieht das meistens so aus:

    • /dev/tty.usbmodem...
    • /dev/cu.usbmodem...

    Die goldene Regel für WSJT-X unter macOS: Nutzt unbedingt den Port, der mit cu.usbmodem... beginnt (CU steht für Call Up).

    • Die tty.-Ports warten historisch gesehen auf ein "DCD"-Signal (Carrier Detect) und blockieren das Programm (es friert ein oder der Test wird zwar grün, aber im echten Betrieb geht kein Befehl durch), wenn das Signal nicht passt.
    • Die cu.-Ports blockieren nicht und erlauben WSJT-X die sofortige Kontrolle.

    2. Phantom-Verbindungen und die "andere App"

    Wenn die andere FT8-Anwendung (evtl. MSHV oder JTDX) noch im Hintergrund läuft oder deren Hintergrund-Prozess die serielle Schnittstelle blockiert, kann WSJT-X den Port nicht öffnen – selbst wenn der "Test CAT"-Button kurz grün leuchtet, weil er die Schnittstelle für Millisekunden erwischt hat.

    • Test: Die andere App komplett schließen (wirklich mit Cmd + Q, nicht nur das rote X-Fenster klicken). Am besten nach einem Mac-Reboot nur WSJT-X starten.

    3. Audio-Rechte (Mikrofon-Berechtigung) unter macOS

    Da der Empfang in WSJT-X klappt, sind die Audiorechte für den Eingang wohl da. Aber macOS trennt das manchmal strikt.

    • Schaut unter Systemeinstellungen -> Datenschutz & Sicherheit -> Mikrofon nach. Ist WSJT-X dort explizit freigeschaltet? Wenn der Mac das QDX-Audio-Interface als "Mikrofon" blockiert, bleibt der Wasserfall leer (was das Problem der anderen App erklären könnte).

    4. PTT-Methode in WSJT-X prüfen

    Wenn CAT (Frequenzwechsel) funktioniert, aber das Senden nicht anspringt:

    • In den WSJT-X Einstellungen unter Radio schauen, was bei PTT Method eingestellt ist.
    • Beim QDX sollte das idealerweise auf CAT stehen.
    • Steht es versehentlich auf VOX oder DTR/RTS auf einem separaten Port, sendet WSJT-X keinen PTT-Befehl über die CAT-Verbindung.

    5. Die Samplerate des macOS-Audio-Subsystems (Sehr häufiger Fehler!)

    Der QDX erwartet auf der Soundkarte zwingend 48000 Hz (48 kHz) Stereo oder Mono (je nach Firmware-Version, meistens 48kHz/16-Bit). macOS neigt dazu, USB-Audiogeräte ungefragt auf 44100 Hz umzustellen. Das führt zu unregelmäßigen Aussetzern oder komplettem Verweigern des Audio-Streams.

    1. Öffnet am Mac das Programm "Audio-MIDI-Setup" (zu finden über die Spotlight-Suche oder unter Programme -> Dienstprogramme).
    2. Sucht in der linken Spalte das Audio-Interface des QDX (Eingang und Ausgang).
    3. Stellt das Format bei beiden (Eingang und Ausgang) strikt auf 48.000 Hz.

    Empfohlene Test-Reihenfolge:

    1. Mac neu starten.
    2. NUR WSJT-X öffnen.
    3. In den Radio-Settings den /dev/cu.usbmodem... auswählen.
    4. Baudrate auf den Wert einstellen, der im QDX-Konfigurationsmenü hinterlegt ist (meist 19200 oder 38400, je nach Einstellung im QDX-Textmenü).
    5. Handshake: None.

    Probiert das mal aus – besonders der Wechsel auf den cu.-Port und die 48-kHz-Prüfung im Audio-MIDI-Setup bewirken bei macOS und Amateurfunk-Software oft Wunder.

    Da MacOS im Prinzip ein unixoides Betriebssystem ist, kann ich das mit den tty Interfaces nachvollziehen. Das ist aber weder eine Mac noch eine Linux Eigenheit, nur ist unter unioxiden Systemen alles eine Datei (auch die Hardware, wie Keyboard, Schnittstellen usw.) für die man die Berechtigungen benötigt und es gibt symbolische Links auf die jeweiligen Devices mit entsprechenden Berechtigungen. Daher sind die Hinweise der KI in diese Richtung nicht aus der Luft gegriffen. In groups.io habe ich auch einige Beiträge gelesen, das richtige tty Device zu verwenden, blocking und non-blocking¹ gibt es eigentlich immer. Wenn ich mich entsinne, musste ich auch irgendwo mal 48kHz fix einstellen, weiß aber aus dem Kopf gerade nicht, ob das beim Signalink oder FTDX-10 war, der ja ebenfalls USB-Sound und USB-Serial über ein Interface macht.

    Das Problem der Einstellungen ist übrigens kein Problem des Betriebssystems sondern der Anwendung. Es ist kein Problem einer Anwendung, die bestimmte Interfaces mit bestimmten Parametern verwendet, die Daten mitzugeben und serielle Ports kann man scannen. So machen wir es z.B. in der Modellbahnsteuerungssoftware für CBUS/VLCB, was über CAN läuft. Die Software findet selbst die korrekten Einstellungen.

    73, Tom

    ¹ Das unixoide Systeme so umfangreiche Konfigurationsoptionen für serielle Schnittstellen haben, liegt an der Historie, wo alle Terminals (Monitore mit Tastatur), Drucker und eigentlich alle anderen Geräte auch seriell über RS232/RS422/RS485 betrieben wurden