von In diesem Artikel will ich nochmals auf die Unterschiede zwischen dem „Original“ piHPSDR und meiner angepassten Version deskHPSDR eingehen.
1. Bildschirmgröße
Ursprünglich war piHPSDR – deswegen auch sein Name – für den Raspberry Pi gedacht und gemacht, denn der Urvater dieses Stücks Software John/G0ORX hatte noch weitere Versionen veröffentlicht, unter anderem linHPSDR für Linux-Desktop-Systeme und gHPSDR für eine Linux-GNOME-Umgebung – aber eben auch piHPSDR für die kleinen Raspberry Pi SoC-Minicomputer. Die Entwicklung bei linHPSDR und auch bei gHPSDR scheint zum Stillstand gekommen zu sein, auch der eigentliche Master des piHPSDR hat schon seit 2021 keine Updates mehr bekommen. Christoph/DL1YCF hat sich aber zumindest dem piHPSDR angenommen und pflegt es weiter – somit ist mit seinem Fork des piHPSDR wenigstens das am Leben geblieben und wird aktiv von ihm weiterhin gepflegt. Das bildete auch die Grundlage meines deskHPSDR zum Zeitpunkt meines „spin-offs“ in Form des deskHPSDR. Also ein Fork des Forks, hi.
Das zur Vorgeschichte. piHPSDR hatte immer den Anspruch, auch auf die früher sehr verbreiteten kleinen Displaygrößen 640×480, 800×400 und 1024×640 und was es da alles noch für Abwandlungen gab, lauffähig zu sein und zu bleiben. Im Grunde gilt das bis heute. Nun leben wir aber bereits im Jahr 2024 und die Displayentwicklung hat schon ordentliche Sprünge gemacht. Im Grunde will ich heute nicht mehr mit solchen geringen Auflösungen arbeiten, sieht nicht schön aus und man bekommt auch nix auf den Screen. Es ist einfach alles zu klein und limitiert durch diese geringen Auflösungen.
Moderne Displays, auch das offizielle Pi-Display 2 bringen bereits 1280×720 mit – und da ziehe ich mit deskHPSDR auch die Grenze. Minimum ist also eine Displaygröße von 1280×600, alles andere habe ich aus dem deskHPSDR entfernt, es lässt sich nicht mehr unter 1280 Pixel horizontal verkleinern. Größer ist natürlich kein Problem, gerne bis in den 4k Bereich hinein.
Also der erste Unterschied zum piHPSDR ist: Screen muss mindestens 1280×600 haben, sonst wird das nix.
2. Anpassungen der Programmbedienoberfläche
Die Untergrenze von 1280×600 dient nämlich dem Zweck – wir können mehr Informationen in dem Programmfenster darstellen. Deswegen habe ich auch dieses Stück Software in deskHPSDR umbenannt, denn „desk“ steht für nichts anderes als Desktop oder besser Desktop-Bildschirmgrößen, das trifft es besser.
Hier mal der erste Screenshot des deskHPSDR. Was ich geändert habe, wird folgende Tabelle erklären:
| Bildschirmdarstellung | Bedeutung |
|---|---|
| graue Schrift bzw. grüne oder gelbe Schrift | grau bedeutet, Funktion ist deaktiviert und grün oder gelb bedeutet Funktion ist aktiviert |
| CFC +3 -9 | CFC aktiv/aus, +3 = Pre-CFC-Gain, -9 = Post-CFC-Gain in db |
| PROC +4 | PROC bedeutet Basebandkompressor aktiv/aus, +4 = +4db Kompressorverstärkung |
| CESSB | CESSB (Controlled-envelope single-sideband modulation) ist aktiviert |
| S=Peak bzw. S=Avg | Anzeige, welches S-Meter genutzt wird, Average oder Peak-Anzeige |
| S9+5db | hinzugefügte Anzeige in konkreten S-Werten gemäß der korrekten S-Meter-Skala, soll die reine dbm-Anzeige also ergänzen |
| Mic PreAmp +20db | neu hinzugefügter, schaltbarer und einstellbarer zusätzlicher Mic Gain |
| TUNED | eine sich noch in Entwicklung befindliche Tuner- bzw. Abstimmhilfe ROT bedeutet „noch nicht abgestimmt“, GRÜN bedeutet „abgestimmt“ |
| EXIT Button | damit kann man das Program jetzt direkt von der Programmoberfläche beenden |
Das S-Meter als Balkenanzeige habe ich optisch etwas verändert, das man es nun auch ablesen kann. Das vorher nicht gut designt und kaum nutzbar oder besser kaum ablesbar, was die Skalierung anging. Ich habe einige Dinge auch neu benannt, damit klarer ist, was das für ein Parameter eigentlich ist. So gibt es eben beim Hermes Lite 2 kein RX Gain, das ist eine Gainregelung des ADC und so heisst das jetzt auch.
Auch im TX-Betrieb habe ich etwas Designpflege der Programmoberfläche bei deskHPSDR betrieben, so sind unter anderem zusätzliche Levelanzeigen im Bereich oben rechts hinzugekommen. Diese stellen die einzelnen Audioparts dar:
Mic = Inputlevel des Mic-Eingang, EQ = Ausgangslevel am TX-EQ, Lev = Ausgangslevel am Leveler, CFC = Ausgangslevel nach dem CFC-Compressor, PROC = Ausgangslevel am Basebandkompressor und Out = Ausgangslevel, der in den Modulator geschickt wird. Um korrekte Einstellungen zu haben, MUSS man diese Level anzeigen, denn sie sollten nie über 0db „schwappen“. Das übersteuert und verzerrt das Audiosignal und das kann eben an jedem Glied der ganzen Audiokette passieren. Das kann man nun also im deskHPSDR kontrollieren, ob das alles passt. Die angezeigten Werte sind als dbV zu verstehen, was bedeutet 0db sind 1V Bezugsspannung – und nicht wie in der Heimelektronik 0,775V, denn dann wäre das nämlich dbu. Die Profis benutzen aber dbV. Der Studiopegel der ARD beträgt z.B. 1,550V, was +3,78dbV entspricht – nur mal so als Beispiel.
Hier habe ich die Funktion Local Mic PreAmp Gain hinzugefügt und einstellbar gemacht, was bedeutet, das zum Mic Gain Regler auf der Programmoberfläche diese Verstärkung hinzugefügt wird. Wir haben jetzt in der Summe also mehr Mic Gain und damit mehr mögliche Verstärkung zur Verfügung. Die Funktion Tune use drive habe ich lahmgelegt. Damit kann es nicht mehr passieren, „aus Versehen“ mit vollem TX PWR abzustimmen. Halte ich für gefährlich, besonders beim Einsatz von MOSFET-PA.
Hier habe ich die im piHPSDR nicht(!) einstellbaren Dinge wie Leveler und Phase Rotator zugänglich und schaltbar gemacht. Der Wert 15 beim Leveler bedeutet seinen Regelbereich in db, der Wert 500 bedeutet seine Regelzeit in ms, hier also 500ms. Er kann auch deaktiviert werden. Beim Phase Rotator bedeutet 8 die stages und 338 die sog. Corner-Frequenz in Hz. Auch der kann hier ein- oder ausgeschalten werden. Das ist bei piHPSDR alles nicht drin, sondern da wurde alles „hard-gecoded“, was ich für grundlegend falsch halte – denn der Nutzer kann da nichts einstellen. Aber wenn Dinge nun mal einstellbar vorgesehen sind, muss man diese auch einstellen können, da habe ich eine glasklare Meinung dazu.
Hier habe ich deskHPSDR um eine Option ergänzt, die Jörg/DD8JM angefragt hatte. Es ist eine weitere COM/serielle Schittstelle hinzugekommen, auf der deren RTS-Signal im Falle der Funktion TUNE aktiviert werden kann. Das ermöglicht Anwendern mit automatischen Antennentunern, die ein Startsignal benötigen, genau dieses verfügbar zu haben. RTS ist H-active, bedeutet wenn die Funktion TUNE aktiviert wird, geht RTS dieser seriellen Schnittstelle auf H Pegel, wobei dieser bis +15V an echten, klassischen RS232 betragen kann. Im Falle von L ist diese Spannung, gemessen gegen GND, allerdings nicht 0, sondern negativ und auch auch bis zu -15V betragen. Das sind einfach Spezifikationen einer RS232. Haken gesetzt bedeutet also, RTS dieser RS232 wird gesteuert, Haken raus bedeutet Steuerung per RTS auch aus.
Update 17.12.2024: Parallel zum RTS-Pin der RS232 wird jetzt auch das DTR-Signal aktiviert. Das werde ich noch wählbar machen, so daß man am Ende folgende Optionen haben wird: a) nur RTS b) nur DTR oder c) beide gleichzeitig, also RTS + DTR. Im aktuellen Masterbranch des deskHPSDR werden derzeit BEIDE Signale aktiviert, also Option c) RTS + DTR. Das wird aber noch, wie bereits dargestellt, auswählbar gemacht.
3. Dinge „unter der Haube“
„Unter der Haube“, also für den Nutzer unzugänglich, habe ich eine Änderung eingebaut, die im Falle der Betriebsarten DIGI-U und DIGI-L den Mic Gain, also das Audio-IN-Level grundsätzlich auf 0db stellen, und zwar unabhängig davon, was am Mic Gain Regler eingestellt ist oder ob noch der zusätzliche Mic Gain PreAmp aktiviert ist. Normalerweise laufen die entsprechenden Anwendungen wie JTDX, WSJT-X & Co. eh auf dem gleichen Rechner wie deskHPSDR und werden per virtuellem Audiokabel ans deskHPSDR angebunden. Diese haben alle einen eigenen Gain-NF-Out Regler, das sollte also Fehleinstellungen weitgehend vermeiden.
CURSOR RECHTS bzw. CURSOR LINKS bewegt den VFO entsprechend seiner gewählten Schrittweise. CURSOR HOCH bzw. CURSOR RUNTER kann die Slider bewegen, alternativ zur Mausbedienung. Im piHPSDR bewegten alle Cursor-Tasten grundsätzlich nur die Slider. Die VFO-Bewegung mit „u“ und „d“ gehen natürlich auch – allerdings halte ich für diese Tastenzuweisung für unpraktischer als wie die Benutzung der Cursortasten, auch wenn „u“ für up und „d“ für down natürlich den Bewegungen in englischer Sprache entspricht und nach wie vor auch geht. Cursor rechts oder links ist in diesem Fall aber einfach „logischer“ und auf der Tastatur besser bedienbar. Natürlich lässt sich darüber hinaus das Ganze auch per Rotary Encoder (via MIDI-Funktion) als „komfortabler VFO Knopf“ umsetzen.
Unter macOS muss man, wenn man die auf der Apple Magic Mouse per Touch nachempfundene Funktion Wheel verwenden will, zusätzlich auf dem Keyboard OPTION oder COMMAND gedrückt halten. Damit kann man den VFO entsprechend seiner eingestellten Schrittweite bewegen. Es kam leider unter macOS häufig vor, das das Berühren der Magic Mouse bereits den VFO „verstellte“. Deswegen geht das unter macOS jetzt nur bei gleichzeitig gedrückt gehaltener OPTION oder COMMAND Taste. Unter Linux mit normaler Maus (mit Mausrad) geht das weiterhin ohne zusätzliche Tastenbetätigung.
Getestet wird derzeit noch eine Funktion für das TUNING eines ATU. Wechsle ich das Band, wird TX PWR immer auf den Wert 1 runtergeregelt – und zwar solange, bis ich 1x die TUNE-Funktion benutzt habe, danach ist der bisherige TX PWR Wert wieder hergestellt. Das soll verhindern, das man im Falle einer PA und Bandwechsel das Abstimmen des ATU „vergisst“ und aus Versehen mit voller PA-Leistung in ein unabgestimmtes System reinbläst. Ist mir leider schon selbst passiert – danach war Austausch der MOSFETs in der PA angesagt. Diese Funktion ist aber per default (noch) nicht aktiv.
Ebenfalls im Test befindet sich eine Option, beim Modewechsel automatisch Audioquellen für den NF-Eingang umzuschalten. Das macht u.a. dann Sinn, wenn man wie in meinem Fall für digitale Betriebsarten auf das virtuelle Audiokabel wechseln muss, bei SSB-Betrieb aber den Mic-Eingang benötigt.
So, das mal ein kleiner Überblick dessen, was deskHPSDR anders macht und welche geänderten Funktionen von mir in dieser Applikation umgesetzt worden sind im Vergleich mit piHPSDR. Wem das nicht gefällt, der kann ja weiterhin piHPSDR verwenden. Wer allerdings meine zusätzliche Funktionalität benötigt, kann gerne deskHPSDR ausprobieren und verwenden.
Grundsätzlich versuche ich immer, auch die aktuellen Änderungen, die bei piHPSDR einfliessen, ebenfalls ins deskHPSDR zu übernehmen. Bisher ist immer gelungen, es ist also eine Art Rückportierung. Stand heute sind also grundsätzlich beide Versionen auf gleichem Funktionslevel, was piHPSDR kann, kann auch deskHPSDR.
4. Dokumentation deskHPSDR
Hier bin ich leider nicht so fleissig wie Christoph/DL1YCF mit seinem piHPSDR, seine stetige und zeitnahe Pflege des piHPSDR Manuals bei Funktionsänderungen bzw. -erweiterungen verdient meine größte Hochachtung. Das kostet nämlich viel, viel Zeit und Arbeit – fast mehr als das eigentliche Programmieren. Da kann ich derzeit nicht mithalten, auch ich pflege deskHPSDR in meiner knappen Freizeit – die leider in meinem Fall nicht ausreicht, auch noch ein Manual für deskHPSDR aufzubauen. Ich denke aber, das Meiste ist selbsterklärend und meine Erfahrung zeigt leider, so ein Manual eh nur Wenige lesen, die Meisten probieren alles einfach aus. Also nochmals sri – Doku für deskHPSDR gibt es aktuell nicht und das wird sich leider auch nicht so schnell ändern. Aber die piHPSDR Anleitung eigenet sich auch ganz gut, da beide Versionen mehr oder weniger gleich sind, was die Bedienung der Applikation angeht. Ich habe ja piHPSDR mehr oder weniger mit deskHPSDR nur erweitert, aber keine grundlegend neue Applikation daraus gemacht.
5. Wo und womit läuft deskHPSDR ?
Getestet wurde – erfolgreich – von mir und einigen anderen Mitstreitern bisher die Lauf- und Funktionsfähigkeit wie folgt:
a) Hostrechner, auf der die SDR-Applikation deskHPSDR läuft:
- macOS 14.x und macOS 15.x (iMac, Macbook Air, Macbook Pro – sowohl Intel als auch ARM)
- Arch-Linux und Ubuntu, Kali-Linux in einer VM
- Raspberry Pi 3B+ (mit gewissen Einschränkungen, u.a. einer notwendigerweise runtergestellten Framerate Panadapter und Wasserfall auf 10fps, bei mehr wurde es hakelig)
- Raspberry Pi5 mit NVMe-HAT und 256GB SSD und PiOS 64bit („Bookworm“) plus Touchdisplays 1280×800 und 1920×1200 per HDMI und USB (für Touch) – meine klare Empfehlung, falls der Einsatz auf einem Raspberry Pi in Erwägung gezogen werden solle. Einen Pi5 mit SSD sehe ich als Muss, sonst macht es keine Laune
b) RF-seitig, also eingesetzte/verwendete SDR-Hardware:
- mir steht nur ein Hermes-Lite 2 und meine 600W Eigenbau-LDMOSFET-PA inkl. RF-Sampler nach der PA für PureSignal (=Predistorsion) als SDR-System zur Verfügung, andere auf dem HPSDR-Protokoll basierende SDR-Systeme kann ich also nicht testen
Prinzipiell sollte es also auf jedem Linux mit X11-Umgebung funktionieren (sofern alle benötigten Libraries installiert und damit verfügbar sind), auch macOS in seinen aktuellen Versionen ist dank Homebrew-Paketmanager für Open Source Software gut dabei und funktioniert ebenfalls ganz ausgezeichnet.
WAVESHARE 7″ Touchdisplay 1280×800 mit laufendem deskHPSDR im Vollbildmodus unter PiOS 64bit
WAVESHARE 7″ Touchdisplay 1280×800 mit rückseitig montierten Raspberry Pi5 und SSD-HAT
Die beiden schwarzen, ovalen Teile sind Lautsprecher, denn wir können per HDMI auch Audio übertragen. Natürlich ist die Wiedergabequalität dieser kleinen Lautsprecher nur mittelmässig – aber immerhin, wir hören schon mal was damit.
Ein ähnliches 7″-Touchdisplay mit 1280×720 gibt es als offizielles „Pi-Display 2“ (wird wohl auch von WAVESHARE produziert), dieses wird allerdings per DSI am Pi angeschlossen, was zwar auch Touch ermöglicht, jedoch keine Audioübertragung wie das mit HDMI möglich ist.
Hermes-Lite 2 SDR-TRX 5W mit offenem Gehäuse und dem angedockten N2ADR-LowPass-Filter hinter dem Hermes-Lite 2 Mainboard
RF-Sampler (von SV1AFN) nach meiner LDMOSFET-PA zur Signalrückführung an den Hermes-Lite 2 SDR-TRX für die Nutzungsmöglichkeit von PureSignal ( = Digital Predistortion)
Die Möglichkeit, MIDI-Controller zur komfortabelen Steuerung des deskHPSDR habe ich ebenfalls unter Linux und macOS getestet, das geht auf beiden System weitgehend reibungslos über die Bühne. Eine weitere Steuerung per GPIO ist leider nur dem Raspberry Pi vorbehalten, andere Hardware hat ja meistens keine solcher GPIOs zur Verfügung. GPIO habe ich mangels Anwendungsnotwendigkeit bisher nicht getestet, da ich deskHPSDR zu 90% nur auf meinen Macs nutze und weniger auf Dingen wie einem Raspberry Pi oder einem Desktop-Linux samt PC-Plattform.
Im Grunde wäre auch eine Compilierung unter WINDOWS möglich mittels der MinGW-Umgebung. Das würde allerdings zusätzliche Anpassungen im Code erfordern, die ich zumindest bei deskHPSDR nicht einarbeiten werde. Wir haben unter WINDOWS ja mit OpenHPSDR-Thetis und auch mit SDR Console zwei leistungsfähige SDR-Applikation bereits verfügbar, da sehe ich keinen Sinn, jetzt auch noch deskHPSDR mehr oder weniger WINDOWS-tauglich zu machen.
6. Gibt es fertige Binärpakete vom deskHPSDR ?
Die Antwort ist einfach und klar – und lautet NEIN. deskHPSDR wird nur als Quellcode veröffentlicht, der ist per Github.com unter der GPLv3-Lizenz allen zugänglich. Daraus ein lauffähiges Programm auf einer entsprechenden Plattform zu erzeugen – das nehme ich Euch leider nicht ab und müsst Ihr schon selbst tun. Es ist eben wie vieles in dieser SDR-Spielwiese auch eine Art DIY bzw. Eigenbau. Ganz ohne Eigeninitiative gehts also nicht – auch wenn hier mal nicht der Lötkolben im Fokus steht.
