Unterschiede zwischen deskHPSDR und piHPSDR

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:

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.

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.

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.

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 Pflege des piHPSDR Manuals 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:

• 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

Prinzipiell sollte es also auf jedem Linux mit X11-Umgebung funktionieren, auch macOS in seinen aktuellen Versionen ist dank Homebrew-Paketmanager für Open Source Software gut dabei und funktioniert ebenfalls ganz ausgezeichnet.

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.

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.

deskHPSDR unter Linux auf einem Raspberry Pi5

Wie man mein überarbeitetes deskHPSDR, welches ja urspünglich auf piHPSDR basierte, auch unter Linux zum Einsatz bringt, werde ich in diesem Beitrag ausführlich beschreiben.

Da ich jedoch nach wie vor kein Desktop-Linux-System einsetze und das auch weiterhin nicht plane, wird dieser Beitrag in erster Linie für den Einsatz auf einem Raspberry Pi 5, also dem derzeit leistungsfähigsten Pi, Bezug nehmen. Grundsätzlich sollte sich das alles aber auch auf einem Desktop-Linux 1:1 umsetzen lassen, da sehe ich wenig bis gar kein „Konfliktpotential“.

Mein Background rund um Linux

Kurz zu meinem (beruflichen) Background. Ich bin von Berufswegen IT-Dienstleister im Bereich Business-IT, speziell Server, Datacenter, Netzwerke und was da alles dazugehört. Meine IT-Ausbildung fand in den 90er Jahren auf den damaligen UNIX-Derivaten IBM AIX, SunOS/Solaris, Dec Ultrix etc. statt. Linux kam etwas später – aber alle haben eines gemeinsam: sie sind UNIX-basierte Betriebssysteme. UNIX entstand Anfang der 70er Jahre und ist damit eines der ältesten Betriebssysteme, die es gibt. Inzwischen dominiert Linux klar dieses Segment, da auch die „Großen“ wie IBM ihre eigenen, meist speziell auf Serverhardware abgestimmten UNIX-Systeme zugunsten Linux eingestampft haben. Da ist im Nachhinein als auch viel professionelles Know-How ins Linux geflossen. Kurzum, was für viele WINDOWS darstellt, ist für mich UNIX, meist in der heutigen Form als Linux, aber auch als macOS, was ebenfalls ein UNIX-basiertes System als Basis hat. Das begleitet mich also schon mein ganzes Berufsleben und da verfüge ich inzwischen ein immenses Fachwissen. Das macht es mir allerdings immer etwas schwer, nicht ganz so fitten Anwendern Dinge rund um Linux zu erklären. Ich hoffe, mit diesem Beitrag tauche ich nicht zu tief ins Fachwissen und es bleibt einigermassen verständlich und nachvollziehbar.

Die Auswahl des „richtigen“ Raspberry Pi für den Einsatz mit deskHPSDR

Um es gleich vorweg zu nehmen, meine Empfehlung geht nach allen Tests klar in Richtung Pi5. Ich habe es ebenfalls auf einem Raspberry Pi 3B+ erfolgreich getestet, jedoch zeigten sich hier bereits gewisse Leistungsgrenzen, unter anderem habe ich mit der Darstellung des Panadapter-Spektrums grade so 10 Frames/s erreichen können (mit einem Pi5 allerdings locker > 50fps), darüber zeigte der Pi3B+ bereits Grenzen hinsichtlich seiner CPU-Rechenleistung. Einen Raspberry 4, den ich mal besaß, hatte ich bereits vor längerer Zeit wieder verkauft, zu groß waren nicht lösbare Probleme speziell mit Geräten am USB-Port des Pi4, die vermutlich mit seinem erstmalig zum Einsatz kommenden USB3-Controller bzw der ganzen USB-Lane zusammenhingen. Diese damaligen Probleme konnte ich an einem jetzt aktuellen Pi5 zum Glück nicht mehr feststellen.

Raspberry Pi 5
– als 2GB, 4GB und 8GB Modell verfügbar
– 2x USB 2.0, 2x USB 3.0
– 2x HDMI bis 4Kp60, 2x DSI
– PCI-Express Anschluß (z.B. NVMe-SSD)
– Wireless LAN 802.11ac
– Bluetooth 5.0/BLE
– Ethernet 1Gbps
– 5V USB-C
– POE-fähig
– 2.4GHz Quad-Core 64-bit Arm Cortex-A76 CPU
– 40 GPIO-Pin-Header

Zum Einsatz kommt also hier also ein Raspberry Pi 5 mit 4GB RAM, ausgestattet mit einem NVMe-HAT und einer 256GB-SSD am erstmalig auf einem Pi zur Verfügung stehenden PCI-Express-Bus. Damit erreicht man Lese- und Schreibgeschwindigeiten um die 800MB/s und ist endlich das leidige SD-Karten-Problem los, wobei ich nie wirklich Probleme damit hatte, da ich schon immer ausschließlich qualitativ hochwertige SD-Cards eingesetzt hatte und noch nie einen wirklichen Ausfall einer solchen zu verzeichnen hatte. Aber das ist beim Pi5 eh Geschichte, wir setzen hier jetzt klar auf SSD-Betrieb. Als Betriebssystem kommt PiOS 64bit „Bookworm“ zum Einsatz, welches also direkt von der SSD gebootet wird. Der SSD-Boot erfordert Anpassungen am Bootloader bzw. dessen genutzen EEPROM auf dem Pi5, das wird aber nicht Bestandteil dieses Beitrags sein. Ich gehe also davon aus, das Euer Linux bereits auf dem Pi5 voll funktionsfähig läuft. Einen Grundkurs Linux gebe ich hier also definitiv nicht.

Mit dem Raspberry Pi5 haben wir jetzt einen äußerst leistungsstarken SoC, wo ich zum ersten Mal sage, sowas taugt durchaus auch als Desktop-Rechner aufgrund seines PCI Express Busses und damit der Option, eine NVMe-SSD anstatt einer SD-Card zu verwenden. Alles, was vor dem Pi5 in der Raspberry-Serie kam, halte ich nach wie vor für nicht oder besser nur mit starken Einschränkungen als dafür geeignet.

Das „richtige“ Display am Pi

Wie ich bereits in früheren Beiträgen dargestellt habe, ist mein deskHPSDR für höhere Auflösungen angepasst worden. Das bedeutet, wir benötigen mindestens eine Auflösung von 1280×720, aber nicht geringer. Andernfalls können meine Anpassungen im Programmfenster des deskHPSDR nicht vollständig dargestellt werden. Das ist kein „Versehen“ oder Fehler, sondern beabsichtigt. Im Jahre 2024 sind nun mal Auflösungen wie 800×400 oder 1024×600 nicht mehr auf der Höhe der Zeit und ich werde diese bei deskHPSDR auch nicht mehr berücksichtigen. Wem das nicht gefällt, der verwendet bitte weiterhin piHPSDR von DL1YCF, da werden auch die geringer auflösenden Displays nach wie vor berücksichtigt. Ich werde über diese Anpassung im deskHPSDR keinerlei Diskussionen führen, sie ist final. Mindestvoraussetzung ist und bleibt 1280×720 oder höher bei deskHPSDR, so oder so.

Eine Option wäre entweder ein entsprechender normaler Monitor an einem der zwei HDMI-Anschlüsse oder ein Display wie das offizielle Pi Display 2 (NICHT das ältere Pi Display, denn das konnte nur 1024×600 !), welches an einem der zwei verfügbaren DSI-Anschlüsse angeschlossen wird.
Ich habe mich für das WAVESHARE 7EP-CAPLCD entschieden, einem 7″ Display mit Touchfunktion (per USB) mit einer Auflösung von 1280×800, welches per HDMI am Pi5 angeschlossen wird und damit auch seine ebenfalls zur Ausstattung dieses Displays gehörenden Lautsprecher nutzbar werden, die per HDMI-Audio angesteuert werden können.

WAVESHARE 7EP-CAPLCD
1280 x 800 (HDMI), 7″
kapazitives 10-Punkt-Touch-Display (via USB)
2x Audio via HDMI
IPS Panel mit 178° Blickwinkel
350cd/m²

Als ich das WAVESHARE 7EP-CAPLCD geliefert bekam, hatte ich zuerst Probleme mit diesem Display und war der Meinung, es ist vermutlich defekt. Nach einigen Rechnerchen stellte sich das etwas später jedoch als Irrtum heraus. Welche „Fallstricke“ es gab, werde ich hier kurz darstellen:

Weiter geht es auf der Webseite von Heiko DL1BZ