von Da ich in der letzten Zeit etwas mehr Freizeit zur Verfügung hatte als gedacht, habe ich noch etwas am deskHPSDR weitergearbeitet. Im Grunde habe ich nun erstmal alles ein- und umgebaut, was so meine Vorstellungen in Sachen effektiv benutzbarer SDR-Applikation für macOS und Linux waren. Es sind noch einige Ideen bzw. Feature-Requests von Anwendern eingeflossen, danke nochmals für diese Zuarbeiten.
Lösung eines subtilen Problems mit dem Hermes Lite 2
Sowohl im piHPSDR als auch im deskHPSDR gab es ein subtiles Problem, was bei der Re-Synchronisation des HPSDR-Protokolls speziell beim Hermes-Lite 2 dazu führte, das der SDR unkontrolliert auf Sendung ging und auch blieb und zwar solange, bis man einmal die MOX aktivierte. Meist passierte das beim ersten Programmstart oder wenn man PureSignal aktivierte. Ich hatte dieses Problem schon länger beobachtet und auch mit Christoph/DL1YCF, dem Entwickler des vom deskHPSDR zu Grunde liegenden piHPSDR, ausgiebig besprochen. Wir hatten hier und da gemeinsam einiges versucht, das Problem zu patchen, was aber zuerst nur einen Teilerfolg hervorbrachte. Christoph/DL1YCF hat sich dann nochmals ausgiebig „Hardcore-Debugging“ betrieben – mit Erfolg. Das Problem konnte lokalisiert und damit auch abschließend beseitigt werden, der entsprechende Patch ist jetzt sowohl im piHPSDR als auch im deskHPSDR enthalten. Das ist also als gelöst anzusehen und damit sollten nun keine unvorhersehbaren Effekte mehr auftreten. Der entsprechende Commit stammt vom 20.1.2025, also alles, was danach veröffentlich wurde, hat diesen Patch drin. Das gilt sowohl für piHPSDR wie auch für deskHPSDR.
Code-Merging piHPSDR → deskHPSDR wird eingestellt
Bisher habe ich, soweit es möglich war, alle aktuellen Änderungen und Patches vom piHPSDR auch ins deskHPSDR übertragen. Dieses „Code-Merging“ stelle ich jetzt jedoch ein. Warum ? Der Grund, warum deskHPSDR überhaupt das Licht der Welt erblickt hat, waren unterschiedliche Vorstellungen zwischen Christoph/DL1YCF, dem Entwickler des piHPSDR und mir. Wir beide haben an vielen Stellen einfach unterschiedliche und von Grund auf verschiedene Auffassungen, was und welche Funktionen eine solche SDR-Applikation haben muss oder besser sollte.
Während ich mich bei der Entwicklung vom deskHPSDR mehr auf den SSB-Betrieb konzentriert habe, liegt Christophs Fokus samt piHPSDR wohl mehr im Bereich CW – so zumindest mein Eindruck, was ich so aus unseren gemeinsamen Konversationen zwischen den Zeilen entnehmen konnte.
Damit laufen nun beide Entwicklungen fortschreitend in verschiedene Richtungen, so daß ich inzwischen keine Zeit mehr aufwenden kann oder besser will, deskHPSDR irgendwie so hinzubiegen, um aktuelle Änderungen vom piHPSDR unterzubringen. Die Schere ist inzwischen so weit offen, dass das auch nicht mehr so einfach umsetzbar ist wie es das anfangs war, als ich mit dem Umbau des deskHPSDR auf der Basis des piHPSDR begann.
Letzte Entwicklungen des piHPSDR zielten in erster Linie auf die neuen ANAN-SDR-Geräte wie den ANAN-G2 ab, wofür Christoph im piHPSDR Erweiterungen wie das G2-Panel eingebaut hat. deskHPSDR wird diese Erweiterungen allerdings nicht bekommen, soviel kann ich schon mal sagen. Gründe dafür sind unter anderem, das mir das Geschäftsgebahren des Herstellers der ANAN schlicht zuwider ist und das sehe nicht nur ich so. Technisch sicher sehr gute SDR-Transceiver, jedoch muss man sich bei den Preisen, die für die G2 aufgerufen werden und alles andere als „günstig“ sind, vor Augen halten, sie machen keine eigene SDR-Software für diese Geräte. Im Gegenteil, im Grunde ist es den OpenSource-Entwicklern von SDR-Applikationen wie Thetis oder auch piHPSDR geschuldet, das diese Geräte überhaupt für den Amateurfunk benutzbar sind. Bei FlexRadio ist das anders – sie haben wenigstens für ihre Käufer auch eine eigene SDR-Applikation im Angebot, deren Entwicklung sie auch finanziert haben. Sowas erwarte ich, wenn ich ehrlich bin, ebenfalls in gleicher Weise auch vom Hersteller der ANAN. Danach sieht es aber leider nicht aus. Das ist mein Beweggrund, hier keine weitere Mühe in spezielle Anpassungen für die ANAN im deskHPSDR umzusetzen, so leid es mir auch tut. Dafür werde ich keine Zeit investieren. Sie laufen natürlich mit deskHPSDR, aber es wird keine Extras oder Komfortfunktionen für diese Geräte im deskHPSDR geben, so wie das Christoph im piHPSDR inwzischen umgesetzt hat.
Mein Fokus gilt in erster Linie eher OpenSource-Hardware wie speziell dem Hermes Lite 2, den ich selbst verwende und auch Geräten wie den Red Pitaya, wobei auch bei letzteren inzwischen Preise aufgerufen werden, die deren Einsatz als DIY-SDR-Tranceiver schon in Frage stellen, ob sich das überhaupt noch lohnt. Es bleibt also bei dem, warum ich mit deskHPSDR startete, im Fokus und damit meine klare Nr.1 ist und bleibt der Hermes Lite 2, der inzwischen eine riesige, internationale Community hat und sich großer Beliebtheit erfreut, Tendenz steigend. Und die Orientierung am Thetis, was für mich immer noch eine der besten SDR-Applikationen darstellt und ich dort eine Menge Anleihen für das genommen habe, was und wie ich mit deskHPSDR umzusetzen gedenke bzw. bereits umgesetzt habe.
Letzte Änderungen und neue Funktionen im deskHPSDR
Eine der Funktionen, die ich von Anfang an plante, war ein Äquivalent zu den TX-Profilen wie im Thetis. Das habe ich jetzt umgesetzt, wenn auch in einer etwas reduzierten Form. Ich habe die Möglichkeit geschaffen, im TX-Menü drei verschiedene Mic-Profile zu speichern und auch wieder zu laden. Gespeichert werden alle Einstellungen des CFC, des TX-EQ, des Baseband-Compressors, des Limiters und des Phase Rotators. Damit lassen sich verschiende Einstellungen speichern und aufrufen für den Fall, das man verschiedene Mikrofone verwenden möchte, die alle verschiedene EInstellungen erfordern. Bisher musste man jedesmal beim Wechsel eines Mikrofons alles neu einstellen. Das nervte mich schon lange und deswegen habe ich jetzt diese Möglichkeit geschaffen, drei verschiedene Mic-Profile zu speichern bzw. wieder zu laden. Diese werden jeweils in einer eigenen .prop-Datei im Arbeitsverzeichnis gespeichert, wo sich auch bereits die zentrale Konfig-Datei des verwendeten SDR befindet. Gespeichert werden diese Einstellungen allerdings nur für die Modi LSB, USB und DSB und können auch nur geladen werden, wenn man sich in einem dieser drei Modi befindet. Das ohnehin zentrale Speichern aller Settings wie bisher in der zentralen Gerätedatei bleibt dabei unverändert bestehen. Es erfolgt auch keine automatische Speicherung der Mic Profile, es gibt eine Auswahl zwischen Profil 0,1 und 2, was dann mit einem Klick auf LOAD bzw. SAVE bestätigt werden muss. Das verhindert versehentliches Überschreiben bereits vorhandender Mic Profile. Lediglich beim Verlassen des EQ-Menüs, was ja nicht Teil des TX Menüs ist, erfolgt eine Abfrage, ob der Anwender jetzt die TX-EQ Settings im aktuell ausgewählten Mic Profile speichern will. Drückt man da nur auf ENTER, entspricht das NO und es wird nichts gespeichert, ansonsten kann man das Speichern mit YES bestätigen. Mit dem Mic Profile wird auch der Name des Audio-Input-Devices gespeichert, der dann bei der Auswahl des Mic Profiles mit angezeigt wird. Damit weiß man später noch, was man in dem entsprechenden Profil eigentlich an Settings für welches Audio-Device hinterlegt hat.
Kommt ein Hermes-Lite 2 zum Einsatz, zeigt der Slider für TX Pwr jetzt 0-5W an – wie es der Ausgangsleistung des Hermes Lite 2 mit seiner aktiven PA entspricht. Die Skalierung zur Einstellung der Ausgangsleistung ist in 0.1W-Schritten möglich. Mir gefiel einfach diese 0-100 Segmentierung nicht, das störte ich mich schon an meinem IC705. Wenn ich 2W Output brauche, will ich nicht erst überlegen müssen, wieviel von 100 (der Wert 100 entspricht beim Hermes Lite 2 dann 5W Ausgangsleistung) nun denn 2W sind – da will ich einfach 2W einstellen können.
Die letzte Änderung, die ich deskHPSDR implementiert habe, ist ein UDP Listener. Ich habe ein umgebautes SWR- und Power-Meter RX200, was ich mit einem ADC bestückt habe, der an einem ESP32 angeschlossen ist. Dieser ESP32 ist per WiFi an meinem Netzwerk angeschlossen und sendet aller 0.5s per UDP-Broadcast Statusmeldungen wie SWR, Pfwd und Pref (ähnlich einer Bake) im JSON-Format ins Netzwerk. deskHPSDR kann diese Statusmeldungen empfangen und stellt diese, wenn gültig auswertbar, auf dem Panadapter als Text-Overlay rechts oben in weißer Schrift dar. Somit habe ich mein SWR, meine vorlaufende und rücklaufende Leistung immer im Blick, denn das RX200 befindet sich nach der PA. Allerdings ist diese Funktion derzeit fest im Code implementiert und ermöglicht keine anwenderspezifischen Einstellmöglichkeiten. Wenn man das anders verwenden wollte, muss man einiges im Code vom deskHPSDR händisch anpassen bzw. ändern.
Sofern keine Daten von diesem UDP Listener empfangen werden können, weil es keine gibt, die Daten nicht zu dem definierten UDP-Port geschickt werden oder diese nicht auswertbar sind, wird stattdessen die Uhrzeit in UTC an dieser Stelle eingeblendet. Als kleines optisches Goodie habe ich noch das digitale S-Meter etwas aufgehübscht und mit einem Farbverlauf von Grün über Gelb nach Orange und am Ende Rot versehen.
Ebenfalls habe ich die Anzahl der Buttons in der unteren Leiste, die mit FUNC(x) bezeichnet wird, um zwei zusätzliche Buttons erhöht. Damit stehen jetzt 9 anstatt 7 Buttons zur Verfügung, die sechs Umschaltoptionen FUNC(0) bis FUNC(5) sind so geblieben.
Bei deaktiviertem Wasserfall wird jetzt eine Art Statusleiste angezeigt bzw. eingeblendet, die links das aktuell ausgewählte Audio-Input-Device anzeigt und ab der Mitte eine kleine Hilfe zu Tastaturkurzbefehlen, wo ich gegenüber denen vom piHPSDR ein paar neue hinzugefügt habe (nach einer Idee und Wunsch von DH0DM). Wird der Wasserfall auch aktiviert, wird diese Statusleiste wieder ausgeblendet.
Auch das neue PEAK Label Feature habe ich noch von piHPSDR übernommen, allerdings mit der zusätzlichen Option, die Peaklabel anstatt nur in dbm wie bei piHPSDR auf Wunsch auch in S-Werte (nur deskHPSDR) umgerechnet anzuzeigen. Die Konfigurationsoptionen für das PEAK Label Feature finden sich im Display-Menü (für den RX Panadapter) bzw. im TX-Menü (für den TX-Panadapter).
Noch ein Hinweis zu den zusätzlichen Shortcuts, die nicht als Hilfe in dieser Statusleiste angezeigt werden:
- Mausrad: Mit dem Mausrad kann man den VFO schrittweise entsprechend der eingestellten Schrittweise im Menü VFO bewegen. Drückt man während der Benutzung des Mausrades die SHIFT-Taste, erhöht sich die Schrittweite um den Faktor 10. Mit dem Tastaturkurzbefehl „s“ bzw. „S“ kann man diese Schrittweite auch sofort ändern, ohne erst ins VFO-Menü gehen zu müssen.
Für bzw. unter macOS gibt es allerdings eine Besonderheit: Wenn man die Apple Magic Mouse benutzt, hat diese zwar eine Art Mausradfunktion, aber kein echtes Rad. Das erfolgt bei dieser Maus quasi per Touch. Das führt jedoch häufig zu dem Problem, das schon beim Berühren der Maus der VFO bewegt wird und damit meist „aus Versehen“ die QRG verstellt wird. Das ist natürlich im QSO-Betrieb unglücklich. Aus diesem Grund habe ich diese Funktion unter macOS geändert: Um die Maus bzw. dessen Rad-Funktion nutzen zu können, muss man gleichzeitig die OPTION-Taste gedrückt halten. Mit OPTION+CONTROL gleichzeitig erfolgt auch bei macOS das Bewegen des VFOs durch die Maus mit dem Faktor 10. Unter Linux bleibt es bei der normalen Mausradfunktion bzw. der zusätzlich geschaffenen Option bei gedrückter SHIFT mit Schrittweite x10 den VFO zu bewegen. - Tastaturkurzbefehl „s“ bzw „S“: Damit kann man sofort die Schrittweite des VFO verringern bzw. erhöhen ohne erst das VFO-Menü aufrufen zu müssen. Die aktuelle Schrittweite wird auf der GUI unter der QRG als „Step xxx“ angezeigt.
- Änderung der Funktionsweise SPACE als MOX: Bisher war es so, das wenn man grade TUNE aktiviert hat und dann die SPACE-Taste betätigte, der SDR-Transceiver sofort von TUNE auf normales Senden umschaltete (also sofort auf MOX wechselte), wenn man TUNE nicht beendet hatte. Das ist jetzt nicht mehr so, betätigt man jetzt während einem aktiven TUNE-Vorgang die SPACE-Taste, wird erstmal nur wieder zurück auf RX-Betrieb gewechselt. Ein erneutes Drücken der SPACE aktiviert dann die MOX-Funktion. Aus einem sind also zwei Schritte geworden. Das gilt nur für die SPACE-Taste als MOX-Funktion, andere PTT-Leitungen wie die externe PTT per GPIO oder auch die nur im deskHPSDR mögliche PTT per serieller Schnittstelle und die per MIDI-Control steuerbare PTT sind davon nicht betroffen.
Funktionen, die beim Compilieren des deskHPSDR zuätzlich aktiviert werden können
deskHPSDR verfügt über drei zusätzliche Funktionen, die man nur beim Compilieren von deskHPSDR aktivieren kann, also nicht als Grundbestandteil der Basisversion verfügbar sind. Hier noch mal kurz die Beschreibung dieser Zusatzoptionen:
- TCI=ON:
Das aktiviert den TCI-Server. TCI ist ein netzwerkfähiges CAT-Protokoll, was Expert Electronics entwickelt hat und bei deren SDR-Transceivern wie u.a. dem SunSDRPro und anderen SDR-Geräten dieses Herstellers zum Einsatz kommt. Jedoch verfügen auch immer mehr Applikationen wie Logbuchprogramme über einen TCI-Protokollsupport. Damit lässt sich also deskHPSDR auch mit diesem CAT-Protokoll betreiben. Programme, die ich erfolgreich mit TCI und deskHPSDR getestet habe, sind u.a. RumLogNG für macOS, Log4OM, MacLoggerDX und auch JTDX. Aktuell ist die TCI-Implementation noch unvollständig, die wichtigsten Funktionen sind aber verfügbar. Man kann die PTT via CAT steuern, man kann die QRG des VFOs wechseln, um nur einige Hauptfunktionen zu nennen. Diese TCI-Unterstützung wird noch ausgebaut, das wird allerdings noch ein wenig Zeit in Anspruch nehmen. Grundsätzlich kann man sie aber bereits jetzt verwenden. - ATU=ON:
Das war eine Idee von mir, die sich etwas auf mein Setup mit meinem Hermes Lite 2 und der dahinter geschaltenen LDMOS-PA bezieht. Meine PA ist immer mit dem Hermes Lite 2 verbunden, was bedeutet, jeder TX-Vorgang geht immer durch die PA. Auch das Abstimmen meines externen automatischen Antennentuners muss ich mit aktiver PA machen, denn die 5W des Hermes Lite 2 allein reichen nicht, meinen ATU abzustimmen. Er braucht zwischen 20-30W zum Tunen, was bedeutet, ich muss das also mit der PA machen. Um Fehlfunktionen oder Beschädigungen der PA durch „vergessenes Abstimmen“ zu vermeiden, habe ich folgendes eingebaut: Nach jedem Bandwechsel wird der TX-Output auf das mögliche Minimum abgesenkt, die vorher eingestellte Leistung merkt sich aber deskHPSDR. Dann muss man einmal die TUNE-Prozedur durchlaufen, was auf der GUI dann die Darstellung TUNED von Rot auf Grün wechseln lässt. Nach diesem Abstimmen wird die anfangs gemerkte urspüngliche TX-Leistung wieder auf den Ursprungswert zurückgesetzt. Also nochmals die ganze Prozedur zum Verständnis:
Wir haben 4W TX Pwr und wechseln das Band > TX Pwr wird auf 100mW reduziert > jetzt betätige ich den TUNE Button und mein ATU stimmt sich auf das gewählte Band neu ab (100mW Input an meiner PA erzeugen ca. 25W nach der PA) > TUNED geht auf grün und die anfänglichen 4W sind wieder aktiv. So ist das gedacht, wenn man ATU=ON aktiviert. - COPYMODE=ON
Hier habe ich eine Funktion eingebaut, die sich pro Mode das eingestellte Audio-Input-Device merkt, pro Mode speichert und nach Wechsel des Modes automatisch umstellt, wie es mal gespeichert war. Also eine Art automatische Audioquellen-Umschaltung. Das brauche ich deswegen, weil ich beim Verwenden von Digimode-Programmen wie WSJT-X oder JTDX auf virtuelle Audiokabel umschalten muss. Dann ist nicht das Mic das Eingangsgerät, sondern das virtuelle Audiokabel, was deskHPSDR mit z.B. JTDX verbindet, da prakisch beide Programme ihren Audio gegenseitig austauschen müssen. Was deskHPSDR empfängt muss also in den Eingang vom JTDX geschickt werden und zurück umgekehrt. Deswegen die virtuellen Audiokabel, die genau das machen können. Um aber nicht jedesmal erst im TX-Menü das Eingangsgerät händisch umschalten zu müssen, habe ich das automatisiert. Wähle ich also DIGL oder DIGU als Mode, setzt deskHPSDR automatisch das virtuelle Audiokabel als Eingang, schalte ich wieder auf LSB oder USB, ist dann wieder das Mic ausgewählt. Gleichzeitig wird bei DIGU bzw. DIGL – und nur in diesen beiden Fällen – der Micgain automatisch auf 0db gesetzt, unabhängig von dem, was man am Micgain-Regler eingestellt hat. Auch alle Audiofunktionen wie TX-EQ, Kompressor, Leveler usw. werden im Falle DIGU bzw. DIGL werden vollständig deaktiviert. Digimode-Betrieb erfordert lineare NF-Frequenzgänge und diese dürfen nicht durch Sachen wie EQ beinflusst werden ! Auch die Pegel sind im Digimode-Programm einzustellen, jedes Programm hat da Regler drin, wo man das machen kann. Die SDR-Applikation soll in diesem Fall immer mit 0db Eingangspegel fix sein.
Diese eben nochmals erklärten Zusatzfunktionen muss man also vor dem Compilieren erst in der make.config.deskhpsdr aktivieren, wer sie nicht benötigt, lässt diese Optionen auf OFF, sie werden dann im deskHPSDR nicht aktiviert bzw. bleiben inaktiv. Die Option DEVEL bitte immer auf OFF lassen, das ist zu internen Testzwecken gedacht, wenn ich Sachen ausprobiere, die aber noch nicht zu 100% funktionieren.
Welche Funktionen des piHPSDR fanden nicht den Weg ins deskHPSDR ?
Nicht alle Erweiterungen, die Christoph dem piHPSDR spendiert hat, fanden den Weg ins deskHPSDR oder wurden entfernt. Das hat verschiedene Gründe, meist sah ich da keinen wirklichen Nutzwert bzw. die Darstellung anderer Werte auf der GUI erschienen mir wichtiger:
- Speichern des Mic Gain pro Mode (auch nach langem Überlegen sehe ich da keinen Nutzwert)
- ANAN G2 Panel (zu der ganzen ANAN-Geschichte und dessen Hersteller Apache Labs habe ich mich bereits geäußert)
- dynamisches Anpassen der Schriftart (ich liefere für macOS und Linux Fonts für das deskHPSDR mit, die eine gut lesbare Darstellung ermöglichen, das wurde ausgiebig und unter verschiedenen Darstellungsoptionen lange getestet und optimiert und bedarf keiner weiteren Änderung)
- Anzeige der gewählten Filtereinstellungen als Grafik (diesen Platz brauchte ich für andere Darstellungen)
- Auswahl einer möglichen Fenstergröße kleiner 1280 x 600 (schränkt die GUI Darstellungsmöglichkeiten zu stark ein)
Wer also auf diese genannten Funktionen nicht verzichten möchte, muß dann piHPSDR verwenden. Ich werde bei deskHPSDR keine der genannten Funktionen wieder einbauen, nicht jetzt und auch nicht später. Diese Entscheidung ist final gefallen. Es war nie meine Idee oder Vorstellung, das alles, was piHPSDR kann, auch immer deskHPSDR können muss.
deskHPSDR und piHPSDR auf dem gleichen Computer ist bzw. wäre möglich
Durch die Anpassung der Verzeichnisse, wo piHPSDR und deskHPSDR seine Daten ablegt und speichert, ist die Installation beider Applikationen auf ein und demselben Rechner möglich:
- deskHPSDR:
unter LINUX$HOME/.config/deskhpsdr
unter macOS$HOME/Library/Application Support/deskHPSDR - piHPSDR:
unter LINUX$HOME/.config/pihpsdr
unter macOS$HOME/Library/Application Support/piHPSDR
$HOME steht dabei für das Home-Verzeichnis des angemeldeten Benutzers, z.B. für den Benutzer hans:
Linux: /home/hans
macos: /Users/hans
Bitte beachtet, das beide Betriebssysteme, LINUX wie auch macOS, zwischen Groß- und Kleinschreibung unterscheiden, was bei WINDOWS normalerweise nicht der Fall ist.
Damit lassen sich beide Applikationen auf dem gleichen Computer installieren und nutzen – jedoch muss das Setup für jede Applikation separat gemacht werden. Besitzt man nur einen SDR, kann man natürlich nur mit der einen oder der anderen Applikation auf den SDR zugreifen, gleichzeitig wäre nicht möglich. Besitzt man allerdings zwei SDR, z.B. einen SDR-TRX und einen SDR-RX, könnte man für den SDR-TRX deskHPSDR verwenden und für den SDR-RX piHPSDR – sofern es keine Konflikte oder Kollisionen bei der evtl. gleichzeitigen Benutzung der Audiointerfaces gibt. Eine Garantie, dass das immer sauber funktioniert, wenn man zwei SDR verwenden möchte, kann ich allerdings nicht zusichern. Theoretisch ja, praktisch müsste man das testen.
Die (vorerst) finale Version vom deskHPSDR
Somit habe ich nun fast alles ins deskHPSDR reingebracht, was mir leider im piHPSDR fehlte – aber nach 1 ½ Jahren intensiver Nutzung von Thetis unter WINDOWS nützlich erschien, denn dort war das alles bereits drin, was ich jetzt dem deskHPSDR mit an Neuem auf den Weg gab. Das wollte ich alles unter Linux und macOS auch so nutzen können, denn dort gibt es ja Thetis nicht, da es nur unter WINDOWS lauffähig ist. Selbstverständlich wird deskHPSDR nie den Leistungsumfang von Thetis erreichen können, dafür müsste man alles von Grund auf neu programmieren. Aber ich habe mich, so gut es eben ging, Thetis weitgehend angenähert. Das war der Ausgangspunkt und gleichzeitig das Ziel für das Projekt deskHPSDR. Das Ziel ist fast erreicht, was bedeutet, deskHPSDR nähert sich seiner (ersten) finalen Version, denn bisher war das alles mehr oder weniger Beta-Status. Bugs sind alle weitgehend beseitigt, Fehler konnte ich vorerst keine mehr ausmachen. Nachdem ich deskHPSDR final setzen werde, dann die Versionsnummer 2.6 (derzeit 2.5.8b) bekommen wird, lege ich erstmal eine längere Pause ein. Was danach noch kommt – wir werden sehen.
Vermutlich werde ich dann erstmal eine längere Zeit wieder aktiv funken – mit deskHPSDR auf meinen Macs und meinem Hermes Lite 2. Man kann ja nicht nur an der Software „schrauben“ – man muss auch testen, ob die Arbeit am Ende erfolgreich war und keine Fehler auftreten, auch die Praxistauglichkeit der Funktionen muss natürlich ausreichend überprüft werden.
Was sich später daraus noch an neuen Ideen oder Änderungen ergibt – ich werde es zu gegebener Zeit entscheiden. Wenn ich deskHPSDR mit der Version 2.6 final setze, kommen vorerst keine neuen Funktionen hinzu. Es kann Fehlerkorrekturen, also Updates geben, die dann der Versionierung 2.6.x folgen werden. Neues beginnt dann ab Version 2.7.x (erkennbar immer an der zweiten Ziffer der Version, gerade Zahlen bedeuten finale Versionen, ungerade Zahlen bedeuten Beta-/Entwickler-Versionen).
Abschließend möchte ich mich auch bei allen Anwendern bedanken, die eigene Ideen zur möglichen Umsetzung ins deskHPSDR eingebracht haben und bei denen, die immer fleißig mit getestet haben, wenn ich eine neue Funktion implementiert hatte. Durch dieses Feedback konnten Fehler oder Problem schnell erkannt und beseitigt werden. Natürlich ist eine Software nie wirklich fertig, man muss auch sehr darauf achten, damit man sie nicht „kaputt optimiert“ – also jeden Wunsch kann man am Ende nicht umsetzen, weil es auch immer eine Frage von Aufwand und Nutzen darstellt. Aus einem VW Golf wird nun mal kein Ferrari. Und denkt bitte immer daran, das alles sind reine Freizeitprojekte, veröffentlicht als Open Source und damit für jeden frei und offen zugänglich in Bezug auf den Programmcode, aber es sind keine kommerziellen bzw. professionellen Projekte – etwas einzufordern geht also nicht, das gilt auch insbesondere für den Support. Letzteres kann schlicht aus Zeitgründen nur sehr stark eingegrenzt bis teilweise gar nicht geleistet werden, versteht das bitte.
Wem die Applikation also nicht gefällt, muss sie ja auch nicht nutzen. Es gibt ja eine gewisse Auswahl, also nutzt, wenn ihr unzufrieden seid, einfach die für Euch „bessere“ oder eine andere Lösung.
