Hermes Lite 2 unter macOS

Während wir ja unter WINDOWS zwei mächtige und sehr leistungsfähige SDR-Applikationen mit OpenHPSDR-Thetis und auch SDR Console zur Verfügung haben, sieht das auf Apples macOS leider nicht so rosig aus. Hier ist die Auswahl leider deutlich geringer. Schon als ich damals meinen SDRplay RSP2Pro auf meinen Macs verwenden wollte, machte sich schnell Ernüchterung breit – denn ähnliche gute SDR-Applikationen wie unter WINDOWS sind auf Apples Betriebssystem bisher leider eher Mangelware. Damals gab es im Grunde nur CubicSDR, was einigermaßen an Software wie SDR-Console heranreichte. Inzwischen gibt es mit SDR Connect sicher zumindest für die SDRPlay SDR-RX eine Alternative, die sich aber noch arg im Beta-Stadium befindet. Auch SparkSDR ist inzwischen unter macOS verfügbar – also es tut sich langsam etwas.

Wir haben aber mit unserem Hermes Lite 2 nicht nur einen SDR-Empfänger, sondern einen ganzen SDR-Transceiver – wir wollen also damit auch Funkbetrieb machen. Folgende Applikationen hätten wir da derzeit zur Auswahl:

• QUISK, eine auf Python 3 basierende SDR-Applikation von N2ADR, läuft auf verschiedenen OS
• SparkSDR, läuft auf verschiedenen OS, leider Closed Source
• LinHPSDR (G0ORX) und dessen Raspberry Pi-Adaption piHPSDR (G0ORX, besser die optimierte Version von DL1YCF)
• GNU Radio, Experimentalsoftware

Auswahl für macOS

Ich bin im Amateurfunk kein Freund von Closed Source Software, das will ich gleich mal vorweg nehmen. Nur wenn sie so gut umgesetzt ist, dass sie gerechtfertigt nicht im Quellcode veröffentlicht wird oder kann, akzeptiere ich das. Das gilt im Wesentlichen eigentlich für Logging- und Contestsoftware, sowas zu entwickeln und zu pflegen ist extrem viel Arbeit und die kann sich der/die Programmentwickler ja durchaus auch vergüten lassen.

Es geht hier primär um Software für sendefähige SDR-Geräte, also um SDR-Applikationen, die auch Sendebetrieb ermöglichen. Andere SDR, wie die SDRplay sind reine Empfänger und werden in diesem Artikel nicht berücksichtigt.

Anders sieht das allerdings beim Hermes Lite 2 aus. Dieser ist als Open Source Hardware veröffentlicht, jeder hat also Einblick in Schaltung, Platinenlayout, Quellcode der Firmware. Hier erwarte ich auch eine SDR-Applikation, die auf Open Source basiert. Im Grunde trifft das auch bis auf SDR-Console (WINDOWS) und SparkSDR (Multi-OS) zu. SDR-Console gibt es nicht für macOS und SparkSDR ist aufgrund seiner Closed Source-Strategie bei mir aus dem Rennen.

Ohne jetzt hier alle Pros und Cons zu beleuchten, meine Auswahl fiel zunächst auf piHPSDR und zwar die von Christoph/DL1YCF angepasste und optimierte Version. Eigentlich mal speziell für den Raspberry Pi 3/4 und inzwischen auch 5 gedacht, läuft diese Version allerdings auch unter macOS und ebenfalls auf den Linux-Desktop-Versionen wie Ubuntu oder Debian. Im ursprünglichen, originalen piHPSDR-Repository von G0ORX sehe ich schon länger leider keine Bewegung mehr, somit ist DL1YCF’s Version also die vermutlich derzeit am Besten gepflegte. Den Quellcode der Version von DL1YCF gibt es hier:

https://github.com/dl1ycf/pihpsdr

Vorbereitung des macOS

Um es gleich vorweg zu nehmen, eine fertige Programmdatei, die man nur starten braucht, gibt es in Falle piHPSDR nicht. Wir müssen also selbst aktiv werden und ähnlich wie unter Linux das Programm selbst compilieren.

Apples macOS nutzt als „Unterbau“ ein UNIX-Derivat namens Darwin. Es basiert allerdings auf BSD und nicht auf Linux. Da wir also damit schon mal eine gewisse ähnliche Basis wie unter Linux – ebenfalls ein UNIX-Derivat – zur Verfügung haben, besteht auch unter macOS durchaus die Möglichkeit, viele der als Open Source für Linux veröffentlichen Programme auch unter macOS zum Einsatz bringen zu können. Viele wissen gar nicht um diese Möglichkeit, sie kennen nur die grafische Oberfläche von macOS und sind sich gar nicht bewusst, das da „untendrunter“ so was ähnliches wie ein Linux werkelt.

Für die folgenden Schritte ist eine der Voraussetzungen, mit einer Shell, also einer Eingabe per Text, umgehen zu können. Das ist also nichts für absolute Einsteiger und Unerfahrene. Grundlagen zum macOS und Basiswissen im Umgang auch außerhalb der grafischen Oberfläche sind ab hier zwingend erforderlich.

Getestet wurde das alles unter von mir unter macOS 14.7.1, einmal auf einem Apple Macbook Air mit Silicon M1-CPU und einmal auf einem Apple Macbook Air mit Intel-CPU.

Als erstes benötigen wir einen X11-Server, den wir als .pkg von https://www.xquartz.org herunterladen und installieren. Nach dem Download installieren wir die XQuartz-2.8.5.pkg wie gewohnt durch Doppelklick.

---

Jetzt gehts ins Terminal. Startet unter PROGRAMME > DIENSTPROGRAMME die TERMINAL genannte App. Es öffnet sich ein Fenster mit einer Art Eingabeaufforderung. Dort geben wir folgendes ein:

xcode-select --install

Falls dafür administrative Rechte erforderlich sein sollten, wird es zur Aufforderung Eures Passwortes kommen, welches Ihr verwendet, wenn Ihr den Mac einschaltet und Euch am System anmeldet. Also dieses Passwort eingeben und mit ENTER bestätigen. Installiert wird eine Art minimaler Entwicklungsumgebung für macOS inkl. dem benötigten Compiler, aber nicht das komplette Xcode-Anwendungspaket. Der Download und die anschließende Installation kann einige hunderte MB groß sein, das kann also etwas dauern.

Wenn das erfolgreich war, geht es weiter. Als nächstes benötigen wir Homebrew, eine Art Paketmanager (ähnlich wie apt unter Debian/Linux):

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

Bitte immer alles genau so eingeben, anders als WINDOWS unterscheidet UNIX grundsätzlich zwischen Groß- und Kleinschreibung. Das ist also nicht egal, ganz im Gegenteil.

Solltet Ihr bereits mit Homebrew vertraut sein und das bereits früher installiert worden sein, dann bitte einmal alles auf aktuellen Stand bringen:

brew update && brew upgrade

---

Damit wären die Vorbereitungen abgeschlossen. Weiter geht’s mit unserer eigentlichen piHPSDR-Installation im Terminal auf der Shell:

cd $HOME
mkdir src
cd src
git clone https://github.com/dl1ycf/pihpsdr
cd pihpsdr
./MacOS/libinstall.sh
make app
mv pihpsdr.app $HOME/Desktop

Nun sollten wir auf unserem macOS-Desktop ein Symbol pihpsdr haben, was wir starten können. Neben den SDR, die das OpenHPSDR-Protokoll 1 (älter, nutzt u.a. der Hermes Lite 2) oder 2 (neuer) verwenden, können auch SDR verwendet werden, die vom SoapySDR-Projekt bzw. dessen verfügbaren Modulen unterstützt werden. Dazu muss man im Makefile die gewünschte Unterstützung entsprechend aktivieren, indem man die gewünschte Option auf ON setzt:

GPIO=ON
MIDI=ON
SATURN=ON
USBOZY=OFF
SOAPYSDR=OFF
STEMLAB=OFF
EXTENDED_NR=
SERVER=OFF
AUDIO=PULSE

#######################################################################################
#
# Explanation of compile time options
#
# GPIO         | If ON, compile with GPIO support (RaspPi only)
# MIDI         | If ON, compile with MIDI support
# SATURN       | If ON, compile with native SATURN/G2 XDMA support
# USBOZY       | If ON, piHPSDR can talk to legacy USB OZY radios
# SOAPYSDR     | If ON, piHPSDR can talk to radios via SoapySDR library
# STEMLAB      | If ON, piHPSDR can start SDR app on RedPitay via Web interface
# EXTENDED_NR  | If ON, piHPSDR can use extended noise reduction (VU3RDD WDSP version)
# SERVER       | If ON, include client/server code (still far from being complete)
# AUDIO        | If AUDIO=ALSA, use ALSA rather than PulseAudio on Linux
#
# If you want to use a non-default compile time option, write them
# into a file "make.pihpsdr.config". So, for example, if you want to
# disable GPIO and have AUDIO=ALSA, create a file make.config.pihpsdr in
# the pihpsdr directory with two lines that read
#
# GPIO=OFF
# AUDIO=ALSA
#
#######################################################################################

Lest Euch dazu bitte unbedingt auch die Hinweise im piHPSDR-Manual durch, welches DL1YCF leider nur in englischer Sprache beigefügt hat.

piHPSDR vs. Thetis

Eigentlich ist Thetis (früher PowerSDR) für mich DIE SDR-Applikation für den Hermes-Lite 2 und auch die Messlatte. Jedoch läuft diese nur unter WINDOWS, aber nicht unter Linux oder macOS. piHPSDR kann allerdings durchaus, zumindest unter macOS, als fast gleichwertige Alternative angesehen werden. Beide SDR-Applikationen nutzen die von Dr. Warren C. Pratt, NR0V, entwickelte WDSP-Softwarebibliothek, die im Grunde die Basis beider SDR-Applikationen darstellt. Beide, sowohl Thetis als auch piHPSDR, sind – mehr oder weniger – grafische Bedienoberflächen zu den Funktionen, die diese WDSP-Bibliothek bereitstellt. Hier mal eine kurze, allerdings unvollständige Übersicht, was BEIDE Versionen können:

• Pure Signal (auch Pre-Distortion genannt)
• MIDI-Support, der u.a. den Einsatz entsprechender MIDI-Controller ermöglicht, um u.a. einen VFO-Knopf bereitzustellen oder andere Softwarefunktionen steuern zu können
• Rauschunterdrückungsverfahren wie SNB, NR und die beliebte aus Thetis bekannte NR2
• Broadcast Quality Audio Tools wie den CFC(Multibandkompressor), TX und RX Equalizer, Phase Rotator, Baseband-Kompressor
• Auto Notch-Filter Funktion
• VOX und DEXP
• AGC und RF-Gain regelbar
• CAT
• Unterstützung inkl. Steuerung der N2ADR-LP-Filtererweiterung beim Hermes-Lite 2

Unterschiede zwischen Thetis und piHPSDR

Auch wenn beide praktisch auf der gleichen WDSP-Bibliothek aufsetzen und damit am Ende vergleichbare Funktionen besitzen, muss der Programmentwickler am Ende den Zugriff auf diese WDSP-Funktionen zugänglich machen. Bei Thetis wurde das vollumfänglich realisiert, bei piHPSDR leider nur in einer etwas abgespeckten Form. Hier mal eine kurze Übersicht der wesentlichen Unterschiede:

Funktion	Thetis	piHPSDR (Stand 11/24)
CAT	– drei serielle CAT-Schnittstellen, die entweder einen TS-2000, einen TS-480 bzw. PowerSDR selbst emulieren können – TCI als netzwerkfähige CAT-Option	– drei serielle CAT-Schnittstellen, die alle einen TS-2000 oder einen Andromeda-SDR emulieren – RigCtl als CAT over TCP, ebenfalls mit TS-2000-Emulation bzw. Andromeda – kein TCI-Support
Audio Tools	alle möglichen Optionen verfügbar und einstellbar	– TX und RX EQ 10-Band-Version, einstellbar – Leveler leider fix und hard-gecoded (fix +6db), NICHT einstellbar – CFC (Pre und Post) 10-Band, einstellbar – Phase Rotator auch hard-gecoded, NICHT einstellbar – Baseband-Compressor, einstellbar
RF Gain	manuell einstellbar oder Automatik	nur manuell, KEINE Automatik
Gestaltung der Bedienoberfläche	– fast alle Funktionen direkt per Button oder Slider erreichbar – feste Parameter im Setup-Menü – erweiterte Anzeigen per Container-Konzept möglich	– wegen Raspberry Pi mit kleinen Displays Gestaltung der Oberfläche etwas limiert – viele Parameter leider nur per Menü erreichbar bzw. per umschaltbare 6-Ebenen-Funktionsleiste, alternativ allerdings auch per MIDI auswählbar und teilweise steuerbar – fehlende Bildschirmanzeigen gewisser Einstellparameter, Werte nur im Menü sichtbar
TX Leistung	– nur in 0.5db Schritten einstellbar bis max. -7.5db – Wert wird pro Band gespeichert, ebenfalls das Tuninglevel bis max. -16.5db	– stufenlos einstellbar bis 0 – EIN Wert für alle Bänder, Tuning-Level ebenfalls EIN Wert für alle Bänder

Grundsätzlich steht also bei piHPSDR das Meiste auch zur Verfügung, da es aber auch auf kleine Displays mit 640×480, die meist mit einem Raspberry Pi zum Einsatz kommen, abzielt, sind der Gestaltung und Darstellbarkeit der Oberfläche leider ein paar Grenzen gesetzt und das nicht immer zum Vorteil des Operators, der damit Funkbetrieb macht. Auch das „hard-coding“, also die fixe Programmierung einiger Parameter, die bei Thetis einstellbar sind (u.a. Leveler, Phase Rotator) halte ich für nicht optimal in der Umsetzung. Parameter sind Einstellwerte, die ich als Operator selbst konfigurieren möchte und nicht als feste Werte im Programmcode erst suchen und dann dort anpassen muss.

Hervorzuheben bei piHPSDR wäre die im Grunde stufenlose Leistungsregelung von max. Sendeleistung bis 0, die möglich ist, weil auch das I/Q-Signal angepasst wird. Bei Thetis ist das nicht umgesetzt worden, dort erfolgt die Leistungsregelung in Stufen zu 0.5db und bei -7.5db ist Schluss. Auch werden nicht alle, meist im Menü eingestellten Werte auf der Bedienoberfläche sichtbar gemacht und abgebildet. Das ist etwas ungünstig, muss ich doch dafür jedesmal ins entsprechende Menü um da nachzuschauen, welcher Wert eigentlich aktiv ist.

Auch besitzt piHPSDR keine cmASIO bzw. ASIO-Unterstützung, auch die Audio-Buffer – bei Thetis alle einstellbar – sind „hard-gecoded“ und lassen damit erstmal keine Verbesserung der bei SDR-Systemen nun mal systembedingten vorhandenen Latenz durch Anpassungen dieser Buffer-Werte im Audio-Bereich zu.

Ich habe also diesbezüglich einiges an Konversationen mit DL1YCF geführt, die teilweise gewisse Erfolge aufzuweisen haben. So wurde durch DL1YCF der CFC (pre und post) zusätzlich hinzugefügt, ebenfalls der DEXP und der Phase Rotator. Der RX und TX Equalizer wurde fix auf 10 Bänder umgestellt und einige dieser neuen Funktionen bekamen eine Signalisierung auf der Bedienoberfläche. Jedoch wurde auch klar, das DL1YCF als der sicher derzeitige einzige Entwickler des piHPSDR an gewissen Konzepten seiner Softwaregestaltung keinen Änderungsbedarf sah und diese als nicht veränderbar betrachtete. Das stellte mich leider nicht so wirklich zufrieden, also suchte ich nach einer Lösung, um einige der meiner Meinung nach unvollständigen Implementationen so zugänglich und verwendbar zu machen, wie das u.a. bei Thetis der Fall ist. Dazu jetzt mehr.

Der Vorteil von piHPSDR als Open Source Software – ich baue meine eigene Version

piHPSDR ist wie Thetis auch Open Source. Das bedeutet, jeder der es benötigt, hat Zugriff auf den Quellcode der gesamten Applikation und kann diesen anpassen, erweitern oder verändern wie es einem gefällt. Das ist nun mal Teil der GPL, der General Public License, unter der piHPSDR veröffentlicht ist. Man muss niemanden erst fragen oder wie meist im kommerziellen Umfeld, sog. NDA (engl. non-disclosure agreement = dt. Vertraulichkeitsvereinbarung) unterzeichnen. Ich kann also jederzeit – entsprechende Fähigkeiten und Fachwissen in Sachen Programmierung vorausgesetzt – solche Open Source Applikationen nach meinen Vorstellungen „umbauen“ und als eigene Version weiterführen, weil mir die GPL genau das erlaubt.

Die Geburtsstunde von deskHPSDR

Fakt ist, in der Originalversion piHPSDR von DL1YCF sind einige Funktionen nicht konfigurierbar und „hard-gecoded“, was also bedeutet, einige Werte sind fest im Programmcode hinterlegt und können nicht vom Nutzer während der Programmbenutzung geändert werden, wie es eigentlich von den Funktionen vorgesehen ist.
Das ist nach meiner Auffassung leider etwas unzureichend umgesetzt – oder baut Ihr auch einen CW-Keyer, dessen Gebegeschindigkeit man nicht verändern kann ??? Das glaube ich wohl kaum. Da muss man leider anmerken, der Wille war da, aber die Umsetzung hätte durchaus umfangreicher sein können.

Da ich also mit DL1YCF kein Agreement aushandeln konnte – aus Gründen, die mir sicher für immer verborgen bleiben werden, musste also eine andere Lösung her. 3/4 des Weges waren bereits absolviert, also sollte das letzte Viertel wohl keine größere Hürde werden.

Kurzum, ich traf also die Entscheidung, piHPSDR in Form einer von mir jetzt „deskHPSDR“ genannten Version etwas umzubauen und die meiner Meinung nach fehlenden Dinge selber hinzuzufügen bzw. anzupassen. Der Fokus lag, wie man schon vermuten kann, in dem Ausbau einer auf große Desktops optimierten Variante. Große Desktops bedeutet in diesem Fall, Bildschirmgrößen ab 1280×720. Auf kleinere Displays kann ich aufgrund meiner gesetzten Ziele leider keine Rücksicht mehr nehmen. Auch liegt der Fokus meiner Abspaltung auf den Einsatz von deskHPSDR unter macOS mit Mausbedienung, wobei auch ein Linux-Desktop genauso geeignet sein sollte.

Meine geänderte Version, nennen wir sie einfach „improved version“, findet man bei Github.com unter

https://github.com/dl1bz/deskhpsdr

Folgende Änderungen gegenüber dem Original von DL1CYF sind bereits in dieser (meiner) Version umgesetzt:

• Umbennung von piHPSDR in deskHPSDR, das „pi“ im Namen passt nun grade nicht mehr
• Änderung des Verzeichnisses, wo deskHPSDR Daten ablegt
• Darstellung der Empfangsfeldstärke neben der Angabe in dbm auch als S-Wert entsprechend korrekter Umrechnung
  zwischen dbm und S-Wert bis 30 MHz
• Anpassungen Schriftgröße einiger Elemente der Bedienoberfläche zur besseren Lesbarkeit
• Leveler EIN/AUS und sein Einstellwert zugänglich gemacht im TX-Menü, Unterpunkt CFC
• „Channelizing“ des 60m-Bandes entfernt und damit ebenfalls Entfernung der bisherigen Regionseinstellung für 60m im Radio-Menü, damit wird 60m wie jedes andere KW-Band behandelt im Bereich 5.25 – 5.45MHz
• Erweiterung der beiden Buttons Hide und Menü auf der Bedienoberfläche um einen zusätzlichen Button Exit, der ein Beenden des Programms ohne erst ins Menü gehen zu müssen ermöglicht
• Anpassung der Balkenanzeige des digitalen S-Meters zur besseren Ablesbarkeit
• Anpassen einiger Default-Werte wie die Frequenzen des CFC, um dem Anwender eine Art sinnvolle Anfangseinstellung zu ermöglichen, diese lassen sich aber grundsätzlich jederzeit wieder verändern
• Entfernen der Optionen Reboot und Shutdown bei Desktop-Systemen wie macOS oder Linux-Desktops im Exit-Menü
• Cursor rechts bzw. Cursor links ermöglicht Bewegen des aktiven VFO entsprechend seiner eingestellten Schrittweite, Cursor hoch bzw. Cursor runter kann wie bisher zum Verstellen der Schieberegler verwendet werden
• Q (also großes Q) funktioniert wie Exit
• Mausrad steuert den aktiven VFO nur noch bei gleichzeitig gedrückter STRG-Taste, um ein versehentliches Verstellen der VFO-Frequenz beim Betätigen des Mausrades zu verhindern
• Tune use drive wurde deaktiviert, damit man – falls diese Option unabsichtlich aktiv war – nicht mit voller Sendeleistung abstimmt, es gilt nun grundsätzlich nur die Einstellung Tune drive level im TX-Menü beim Betätigen der TUNE-Funktion
• Sonderfunktion TUNED, die extra per Option ATU=ON im Makefile eingeschalten werden muss:
  Bei jedem Bandwechsel wird die aktuelle Sendeleistung TX Drive gespeichert und gleichzeitig auf 1, also minimal, runtergestellt – solange bis man einmal die TUNE-Funktion benutzt hat, dann wird die ursprüngliche Sendeleistung wieder hergestellt. Hintergrund sind vollautomatische Antennentuner, die zum Abstimmen nach Bandwechsel einmal ein HF-Signal zum Neuabstimmen benötigen, wobei der Abstimmvorgang niemals bei voller Sendeleistung erfolgen darf. Da in meinem Fall die PA immer aktiv ist, also der Abstimmvorgang mit der PA erfolgt, stellt diese Funktion sicher, das nicht „aus Versehen“ mit voller PA-Leistung bei vergessenen oder fehlenden Abstimmen des ATU gesendet wird
• Sichtbarmachen verschiedener eingestellter Werte und Status aktiv/inaktiv des CFC(CFC), des Levelers(LEV), des RX- und TX-EQ(RxEQ, TxEQ) , der TUNED-Funktion und des Sprach-Prozessors(PROC) auf der Bedienoberfläche, jeweils daneben werden die aktuellen Werte der Funktionen angezeigt, gelb bedeutet aktiv, also AN und grau bedeutet inaktiv, also AUS

Weitere Anpassungen werden folgen, meine Entwicklung ist noch nicht abgeschlossen. Veränderungen der Master-Version von DL1YCF, auf der meine modifizierte Version beruht, werden – soweit machbar und sinnvoll – auch in meine Version regelmässig eingearbeitet. Trotzdem handelt es sich nicht um einen „Fork“ im eigentlichen Sinn, es ist mehr eine im Detail erweiterte, angepasste Version der Master-Version von DL1YCF, die nicht in Konkurrenz zur Version DL1YCF treten soll. Es sind meine Ideen und meine Vorstellungen für die jetzt deskHPSDR genannte Version, die ich umgesetzt habe und die mir in DL1YCF’s Original nicht gefielen oder einfach fehlten.