von Wie ich ja schon im letzten Beitrags dieses Blogs berichtet hatte, habe ich begonnen, die als Open Source Software erhältliche SDR Applikation piHPSDR, ursprünglich von John/G0ORX entwickelt und inzwischen weitergeführt von Christoph/DL1YCF, etwas für meine Bedürfnisse umzubauen und einige eigene Anpassungen und Erweiterungen in dieses Stück Software zu implementieren.
Da ich den Entwicklungsfokus nicht auf Mini-Computer wie dem Raspberry Pi oder ähnliche Geräte lege, sondern auf normale Desktops, die unter macOS oder Linux auf einem großen Monitor laufen, habe ich entschieden, das „pi“ aus dem Namen zu entfernen und dafür „desk“ zu verwenden, so dass jetzt das Ganze also als deskHPSDR weitergeführt wird.
Der Quellcode meiner Arbeit bzw. meiner angepassten Version kann immer von hier bezogen werden:
https://github.com/dl1bz/deskhpsdr
Warum piHPSDR und nicht linHPSDR oder gHPSDR ?
John/G0ORX hatte neben der eigentlich für SoC wie dem Raspberry Pi angepassten Version piHPSDR auch Versionen für den Desktop-Einsatz entwickelt, das war einerseits linHPSDR und ebenfalls gHPSDR. Im Grunde ständen mit diesen beiden Versionen also bereits Desktop-fähige Versionen zur Verfügung. Doch auch wie bei der Originalversion des piHPSDR (nicht der bereits weiterentwickelten Version von Christoph/DL1YCF) liegen hier die letzten Änderungen bereits über 2 Jahre zurück, es scheint zumindest so, das John/G0ORX hier seine Aktivitäten eingestellt hat. Einzig der piHPSDR-Fork von Christoph/DL1YCF wurde und wird nach wie vor gepflegt und enthält einiges an wichtigen und nützlichen Erweiterungen und Korrekturen, die leider nicht in den Master von G0ORX zurückgeflossen sind. Kurzum, piHPSDR in der gepflegten Version von DL1YCF ist von dem ganzen *HPSDR-Reigen die aktuellste und auch mit den meisten Funktionen ausgestattete Version, da sie nach wie vor von Christoph/DL1YCF bearbeitet und mit regelmässigen Updates versehen wird.
Zweitens, was mir sehr gefiel, ist piHPSDR ist eine sog. Single-Window-Applikation, was bedeutet, wir haben EIN Hauptfenster, mit dem man die Applikation bedient und nicht zig kleine Fenster, die über den Desktop verteilt sind. Das ist nämlich bei linHPSDR sowie bei gHPSDR der Fall, was mir persönlich überhaupt nicht zusagt. Die kompakte Lösung wie bei piHPSDR – im Übrigen ist das auch bei OpenHPSDR-Thetis so, ebenfalls eine Single-Window-Applikation – ist nach meiner Auffassung wesentlich besser und schneller bedienbar und man hat nicht das Problem, jedesmal den Fokus (also das grade aktive Fenster, welches auch Eingaben annimmt) eines Fensters „suchen“ oder klicken zu müssen oder zig kleine Fenster auf dem Desktop „sortieren“ zu müssen. Bedienbarkeit ist bei solchen SDR-Applikationen, die ja einen Teil des Funkgerätes auf einem Computer darstellen, einer der wesentlichen Punkte, um ähnlich arbeiten zu können wie man das vielleicht mit einem klassischen Transceiver kann. Aus diesem Grunde habe ich mich also entschieden, piHPSDR als Grundlage bzw. Basis meines deskHPSDR zu verwenden und eben nicht linHPSDR oder gHPSDR. Lebende Softwareprojekte sind immer besser als vermeintlich „tote“, denn sowohl linHPSDR als auch gHPSDR waren alles andere als ausentwickelte Versionen, sie sind eigentlich nie über den Status „beta“ herausgekommen und wenigstens zu einer finalen Version geworden. Drei verschiedene Versionen, die eigentlich für den gleichen Einsatzzweck konzipiert sind, zu pflegen ist eine ziemliche Herausforderung, da man praktisch alles 3x machen muss.
Hoch zu schätzen ist allerdings die Portierung der eigentlich nur für WINDOWS entwicklelten WDSP-Softwarebibliothek auf UNIX-Systeme, die ja Grundlage aller drei Versionen ist (piHPSDR, linHPSDR und gHPSDR) und ebenfalls die Basis für die WINDOWS-Applikation OpenHPSDR-Thetis, vorher PowerSDR, bildet. Das ist die eigentliche Leistung von John/G0ORX, was ich sehr hoch wertschätze, das er das umgesetzt hat. Das war einer der wichtigsten Schritte überhaupt, um auf Systemen wie Linux oder auch macOS eine leistungsfähige SDR-Applikation entwicklen und bereitstellen zu können, immerhin als Open Source, was also irgendwelche Lizenz- oder Patentprobleme von vorneherein ausschließt.
Was ist bei deskHPSDR anders als bei piHPSDR ?
Christoph/DL1YCF hatte in der letzten Zeit Einiges an neuen Funktionen im piHPSDR hinzugefügt, u.a. den CFC („Continous Frequency Compressor“) und auch den DEXP, eine Art Kombination aus VOX und Noise-Gate. Andere Teile wie der Leveler, die CESSB-Funktion und den am Ende der Audio-Kette sitzenden Baseband-Compressor waren bereits vorhanden, jedoch nicht direkt zugänglich und nicht mit ihren eigentlich vorhandenen Parametern einstellbar. Sowas kann man machen, Christoph war der Meinung, das ist ok so „um den Anwender nicht zu überfordern“. Gut, das kann man so sehen, entspricht jedoch nicht ansatzweise meinen persönlichen Vorstellungen, wie man das in Software zu implementieren hat. Wenn etwas einstellbar ist – denn das hat ja Gründe – muss man es auch einstellen können. Ebenfalls benötigt man auf der Programmoberfläche gewisse Signalisierungen und Rückmeldungen, was aktiviert oder deaktiviert wurde bzw. mit welchen Einstellungen man gerade arbeitet. Sowas muss man im Funkbetrieb ohne Umwege erkennen können und sich nicht erst jedesmal durch zig Menüs „wurschteln“, um herauszufinden, was wie eingestellt ist oder wurde.
Da begann meine Arbeit an dieser Software, um genau diese Mankos – so weit es möglich und sinnvoll erschien – zu beseitigen und damit den möglichen Funktionsumfang zu erweitern und zu verbessern. Alle diese Funktionen kommen aus einer Softwarebibliothek namens WDSP, die praktisch für den Nutzer unsichtbar die eigentliche Arbeit verrichtet und eben diese Funktionen zur Verfügung stellt. Das eigentliche Programm ist mehr oder weniger nur die Bedienoberfläche für diese Softwarebibliothek WDSP. Im Übrigen verwendet auch OpenHPSDR-Thetis (früher PowerSDR) genau diese, also gleiche Softwarebibliothek WDSP, so dass man im Grunde sowohl mit Thetis als auch mit piHPSDR gleiche, wenn nicht sogar identische Ergebnisse erzielen kann. Im Thetis hat man wirklich ALLE Funktionen dieser WDSP dem Nutzer zugänglich gemacht, deswegen ist das auch so eine anspruchsvolle Software, die vielleicht den einen oder anderen Nutzer schon etwas überfordern könnte. Aber diese gibt es eben nur für WINDOWS und steht unter Linux oder macOS nicht zur Verfügung. Die Alternative – im Grunde gleichwertig und auf ähnlichem Niveau – ist eben piHPSDR. Das ist sowohl unter Linux wie auch unter macOS lauffähig.
Meine Programmentwicklung orientiert sich also primär am OpenHPSDR-Thetis und ich versuche, soweit es umsetzbar ist, viele Dinge, die derzeit nur im Thetis verfügbar waren, auch dem piHPSDR oder besser in meinen eigenen Zweig deskHPSDR nachzurüsten, um näher an die Möglichkeiten von Thetis zu rücken. Das wird nie bei 100% landen, aber ich werde versuchen, so weit wie es möglich sein wird und programmtechnisch umsetzbar, die wichtigsten Sachen hinzuzufügen.
Kurzum, mein deskHPSDR bekommt also einiges an Funktionen mehr, die im piHPSDR fehlen oder nur rudimentär hinzugefügt worden sind. Christoph hat ziemlich deutlich gemacht, das er auch die Unterstützung kleiner Displays ab 640×400 weiterhin beibehalten will – ich allerdings muss mit dieser Vorgabe brechen, in meinem deskHPSDR geht es erst ab einer Displaygröße von 1280×800 los, denn anderenfalls müsste ich mit den Darstellungsmöglichkeiten auf der Programmoberfläche zu große Kompromisse eingehen. Mein deskHPSDR – dewegen auch die Namensgebung – zielt auf normale Linux- oder macOS-Desktops ab. Dazu gehören Notebooks mit Displaygrößen ab 1366×768 wie auch normale Desktop-Systeme mit Monitoren ab einer Auflösung von 1280×800. Heutige Monitore liefern aber fast alle mindestens Full-HD mit 1920×1080 oder höher. Damit stellt sich diese Frage eigentlich kaum – ausgenommen Nutzer mit Raspberry Pi und kleinen Display mit 640×480 oder 800×600. Diese muss ich leider von meiner Entwicklung ausschließen – es ist auch nicht meine Zielgruppe. Diese Anwender können weiterhin piHPSDR im Original verwenden und müssen auf meine Version deskHPSDR leider verzichten, eine mögliche Re-Implementation bei deskHPSDR schließe ich meinerseits vollständig aus.
Wie man erkennen kann (für Vergrößern bitte auf das Bild klicken), habe ich rechts im S-Meter neben der dbm-Anzeige (original) noch eine S-Meter-Angabe (nur deskHPSDR) hinzugefügt. Auch der grüne Balken des RX-Meters ist vergrößert worden, um ihn besser ablesbar zu machen. Auch farblich habe ich das etwas angepasst. Für korrekte Bildschirmdarstellung ist unbedingt im Screen-Menü die „VFO bar 1280px“ auszuwählen, andernfalls gibt es Probleme mit der Darstellung bzw. Positionierung meiner hinzugefügten GUI-Elemente. Leider wurde beim piHPSDR eine pixelgenaue Positionierung verwendet und nicht, wie heute eher üblich, eine auflösungsabhängige DPI-Skalierung. Das macht die GUI-Gestaltung leider etwas restriktiver – im Grunde müsste man die gesamte GUI noch einmal von Grund auf komplett neu designen. Aber sowas kostet Zeit, seeehr viiiiieeeel Zeit…
Über den beiden VFO-Anzeigen befinden sich jetzt viele neue Angaben. Wenn diese gelb dargestellt werden, bedeutet das diese Funktion aktiviert ist. Die Zahlenangaben dahinter zeigen aktuelle Einstellwerte, z.B. LEV +15 bedeutet, das der Leveler aktiv ist und mit 15db eingestellt wurde. RxEQ und TxEQ zeigen, das diese beiden ebenfalls aktiv sind. Die Angabe +4 hinter dem TxEQ bedeutet, er ist mit +4db Signalverstärkung aktiv. Ebenso der CFC, die beiden Angaben +3 und -9 bedeuten, +3db Signalanhebung am Eingang des Pre-CFC und -9 bedeutet -9db Signalabsenkung am Post-CFC. Der Baseband-Kompressor wird als PROC dargestellt, das ist der zweite Kompressor am Ende der ganzen Audio-Kette.
Hier ein Screenshot des überarbeiteten TX-Meters (nur im Sendefall so zu sehen). Hinzugefügt wurden die Levelanzeigen des Mikrofoneingangs (Mic), das Tx-EQ-Level (EQ), der Leveler (Lev), der CFC an seinem Ausgang (CFC), der Baseband-Kompressor (PROC) und das Ausgangssignal (Out) nach all den Bearbeitungsfunktionen der TX-Audio-Kette, wie es in den Modulator geschickt wird. Die Zahlenangaben bedeuten dbV, einer Referenzangabe aus der professionellen Audiotechnik, wobei 0 dbV einer Spannung von 1,0Veff entsprechen. Des entsprechende Audio-Teilsystem, z.B. der EQ ist also so einzustellen, das er 0 dbV nicht überschreitet, um Verzerrungen des Audiosignals zu vermeinden.
Hier nochmals eine Gesamtübersicht über alle Optionen der TX-Audio-Kette, wie sie in der WDSP-Softwarebibliothek vorhanden ist. Man kann sowohl alles als auch nur Teile davon benutzen, je nachdem, ob man ein Glied dieser Kette aktiviert. Also jedes Stück dieser Kette hat also einen EIN- bzw. AUS-Schalter.
Hier ein Screenshot des TX-Menüs. Wenn die Option „Local Microphone“ ausgewählt wird, ihr also das Mikrofon Eures Computers verwendet, sind die beiden anderen Optionen jetzt von mir deaktiviert worden. Bei denen handelt es sich nämlich um Audio-Eingänge am SDR-Transceiver direkt wie sie bei einigen SDR-Geräten verfügbar sind. In meinem Fall mit dem Hermes-Lite 2 gibt es diese am SDR-Gerät selbst nicht, ich habe also nur die Option „Local Microphone“. Aus diesem Grunde habe ich gegenüber dem piHPSDR diese beiden Punkte jetzt mit „SDR Radio Input“ und „SDR LineIn (db)“ umbenannt, damit klar wird, es handelt sich hier NICHT um Eingänge des eigenen Computers, auf dem deskHPSDR läuft. Deaktiviert man „Local Microphone“, schließt das TX Menu mit CLOSE und öffnet es erneut, sind die beiden SDR Radio Input und SDR LineIn (db) wieder verfügbar. Es geht nämlich nur entweder oder und nicht sowohl als auch. Das war im piHPSDR leider nicht ganz klar dargestellt, deswegen meine Korrektur im deskHPSDR.
Hier die zweite Seite des TX Menu, die CFC-Settings. Hier konfigurieren wir den Pre- und Post-CFC, hinzugefügt habe ich (nur deskHPSDR) den Phase Rotator, den Leveler, die Option CESSB (wird automatisch aktiviert wenn aktiv ausgewählt) und den Baseband Speech Prozessor (früher auf der ersten Seite des TX Menu im piHPSDR als Compr bezeichnet und hierher verschoben).
Wichtiger Hinweis: Die Funktion CESSB ist nur nutzbar, wenn der Baseband Speech Prozessor ebenfalls aktiv ist. Bedeutet, kein Baseband PROC aktiv, wird CESSB ebenfalls deaktiviert. Das wurde so im Design der WDSP-Softwarebibliothek vorgesehen oder besser vorgeschrieben und ist kein Fehler.
Im nächsten Beitrag wird es darum gehen, wie man unter macOS das deskHPSDR compiliert und damit auf dem Mac in ein lauffähiges Programm wandelt, denn ich veröffentliche ja nur den Quellcode von deskHPSDR und kein fertiges, startbares Programm. Das muss der Anwender leider selbst auf seinem Mac machen. Wie das geht, gibt’s im nächsten Beitrag von mir.
