von Die Feiertage sind vorbei, diese habe ich allerdings genutzt, um einiges Neues ins deskHPSDR einzubauen. Welche das genau sind, beschreibe ich in diesem Blogbeitrag.
Serielle Schnittstellen für einen Antennentuner und eine externe PTT
Ich habe zwei neue Schnittstellendefinitionen für serielle Schnittstellen hinzugefügt, die wie folgt genutzt werden können:
- Schalten der Signale RTS und DTR während des TUNE-Vorgangs:
Eine der beiden neuen seriellen Schnittstellen dient dazu, wenn man den TUNE-Vorgang vom deskHPSDR startet, werden auf dieser Schnittstelle die Signalleitungen RTS und DTR aktiv geschalten und zwar genau so lange wie der TUNE-Vorgang aktiv ist. Das war eine Anfrage vom Jörg/DD8JM, dessen automatischer Antennentuner ein Startsignal benötigt, wenn der TUNE-Vorgang gestartet wird. Bitte beachtet, das wir hier keine 5V oder 3.3V Signale haben, eine RS232 hat im L-Zustand zwischen -6..-13V und im H-Zustand entsprechend +6…+13V. Das müsst ihr also in Euren Steuerschaltungen entsprechend berücksichtigen und diese Spannungen entsprechend verarbeiten, wir haben also kein(!) klassisches TTL-Pegel 0V..3.3V bzw. 5V auf diesen Signalleitungen der RS232. - Auswerten des Signals CTS als externe PTT:
Wenn man deskHPSDR auf einen Raspberry Pi benutzt, stehen uns externe PTT-Steuerleitungen an dessen GPIO-Ports zur Verfügung. An einem PC oder einem Mac haben wir so etwas leider nicht. Eine Möglichkeit wäre die Steuerung per MIDI, jedoch sind solche MIDI-Controller nicht so einfach umzusetzen. MIDI lässt sich zwar auch mit µC wie den ESP32 oder Arduino umsetzen, jedoch muss man dann auch eigene Software dafür entwickeln – wofür nicht jeder dazu in der Lage sein dürfte.
Die andere Option, also als einfachere Alternative, die ich jetzt eingebaut habe, ist die Nutzung einer klassischen, seriellen Schnittstelle als PTT-Eingangssignal, genauer gesagt deren CTS-Signal. Damit kann man eine externe PTT, z.B. einen Fußschalter oder ähnliches auch am PC oder Mac als PTT einsetzen.
Die Geschwindigkeit der seriellen Schnittstelle spielt im Übrigen bei beiden Funktionen keine Rolle, da wir nur mit den Statussignalen RTS & CTS bzw. DTR & DSR arbeiten, aber keine Daten übertragen, wie man es normalerweise via RS232 machen würde.
Hier ein externer Taster, der zwar für einen PC gedacht ist, aber sich auch gut als PTT-Taster eignet.
Benötigt wird noch ein USB-to-Serial-Adapter, wo die Signale RTS & CTS bzw. DTR & CTS zugänglich sind. Das ist nicht immer der Fall, also prüft solche Adapter vorher.
Hier ein robuster Fußtaster aus Metall, auch der eignet sich gut als PTT.
Hier die Schaltung, wie mittels eines USB-to-Serial-Adapters eine solche PTT geschalten werden muss. Benutzt für die externe PTT beim deskHPSDR bitte Option 2, also die PTT zwischen PIN 7 (RTS) und PIN 8 (CTS) als Taster.
Wenn RTS und CTS ( PIN 7 und PIN 8 einer 9pol. SUB-D) kurzgeschlossen werden, aktiviert das die PTT oder besser die MOX in der Software. Während des Sendens muss die PTT gedrückt bleiben, nur solange bleibt auch der TX-Vorgang aktiv. Lässt man die PTT wieder los, geht der TRX auf Empfang. Also genauso wie eine PTT an einem Handmikrofon.
TCI als eine weitere Option für CAT
Expert Electronics, der Hersteller der SunSDR-Transceiver, hat für seine SDR-Transceiver bereits vor längerer Zeit ein CAT-Protokoll entwickelt. Das nennt sich TCI („Transceiver Control Interface“) und ist ein CAT-Protokoll für klassische serielle Schnittstellen oder Netzwerk. Heute dürfte man eigentlich nur noch die Option Netzwerk vorfinden. Es basiert auf der Websocket-Technologie und ist ein bidirektionales Protokoll, welches inzwischen in der Version 2.0 (Stand Januar 2024) vorliegt.
Die Beschreibung des TCI-Protokolls findet Ihr auf Expert Electronics Github-Seiten https://github.com/ExpertSDR3/TCI .
Ebenfalls lohnt sich ein Blick auf deren Seite zum Thema TCI https://eesdr.com/en/software-en/software-en, wo Ihr unter anderem auch Informationen findet, welche Software derzeit TCI bereits unterstützt.
Aus diesem Grund hatte Christoph/DL1YCF im piHPSDR begonnen, einen TCI-Server zu implementieren, um z.B. Logbuchsoftware, PAs oder andere Sachen mit CAT-Unterstützung auch mit diesem CAT-Protokoll am piHPSDR nutzen zu können.
Ich habe seine Basis genommen und diese inzwischen erweitert. piHPSDR kann derzeit nur als Reporting-System genutzt werden, meine Version in Form des deskHPSDR kann inzwischen etwas mehr, u.a. kann deskHPSDR bereits die PTT per TCI schalten, die Frequenz per TCI wechseln und noch einiges anderes. Nutzbar wäre das z.B. mit JTDX, denn JTDX kann schon länger TCI. Der Netzwerkport kann ab 40000 frei gewählt werden, emuliert wird im deskHPSDR ein SunSDR2Pro SDR-Transceiver für die Nutzung von TCI. Die Implementation ist noch nicht abgeschlossen und unvollständig, in der nächsten Zeit wird jedoch noch mehr an Befehlen im deskHPSDR hinzugefügt werden. Grundlegende Dinge gehen aber bereits und wurden auch getestet.
Als Logbuchprogramme haben wir derzeit nur die unter macOS laufenden Programme MacLoggerDX (kostenpflichtig, 95$) und RumLogNG (kostenfrei aus dem Mac Appstore) erfolgreich getestet, sowie wie bereits beschrieben, ebenfalls JTDX in der .159er Version – der bis jetzt immer noch aktuellen Release von JTDX. Hier geht bereits PTToverCAT und ebenfalls schaltet der TRX, welcher von deskHPSDR gesteuert wird, beim Bandwechsel im JTDX automatisch auf die richtige FT8- bzw. FT4-Frequenz.
Die bisherigen CAT-Emulationen eines TS-2000 per serieller Schnittstelle bzw. ebenfalls per Netzwerk mittels rigctl bleiben natürlich weiterhin verfügbar, TCI ist einfach eine Ergänzung zur bisherigen CAT-Implementation von piHPSDR bzw. meinem davon abgeleiteten deskHPSDR.
TCI ist sowohl im piHPSDR als auch im deskHPSDR verfügbar, jedoch hat deskHPSDR durch mich inzwischen eine wesentlich umfangreichere TCI-Unterstützung bekommen als piHPSDR, die kontinuierlich in der nächsten Zeit ausgebaut werden wird. Audiostreaming wie im aktuellen TCI 2.0 möglich, ist und wird nicht implementiert – nicht jetzt und auch nicht später !
Um diese Funktion nutzen zu können, muss
TCI=ON
im Makefile bzw. im make.config.deskhpsdr gesetzt werden !
Nochmals piHPPSDR und deskHPSDR oder warum es deskHPSDR überhaupt gibt
Als ich im Oktober 2024 piHPSDR auf meinen Macs ausprobierte, waren da einige Dinge, dir mir nicht so gut gefielen, was piHPSDR anging. Nach ein paar Konversationen mit dem Entwickler des piHPSDR, Christoph/DL1YCF – der dieses Softwareprojekt aktuell aktiv betreut und immer weiterentwickelt – und mir, wurde schnell klar, das sich unsere Vorstellungen nicht unbedingt decken und in verschiedene Richtungen gingen. Aus diesem Grunde habe ich begonnen, mit deskHPSDR einen eigenen Weg einzuschlagen und Erweiterungen ins deskHPSDR einzubauen, für die Christoph nicht bereit war, das im piHPSDR umzusetzen. Ich versuche jedoch, die Softwarekernkomponenten immer nah am piHPSDR auszurichten, sprich, ich implementiere soweit es möglich ist, auch Christophs Weiterentwicklungen aus piHPSDR. Auch aktuell ist deskHPSDR nah am piHPSDR und hat alle Patches drin, die den aktuellen Stand vom piHPSDR entsprechen. Das werde ich auch weiterhin so machen, sofern es nicht mit meinen eigenen Erweiterungen kollidiert. Bisher war das nicht der Fall. deskHPSDR ist also kein „Klon“ des piHPSDR, es geht seinen eigenen Weg – wenn auch soweit wie möglich ganz nah am piHPSDR.
Ich stehe mit Christoph in engem Austausch, teste Sachen und wenn ich Probleme finde, teile ich es Christoph mit, damit es gefixt werden kann. Wir arbeiten also auch weiterhin eng zusammen – aber jeder gestaltet „seine“ Version so, wie es jeder für richtig und notwendig erachtet. Beide Versionen haben ihre Daseinsberechtigung, Christophs Fokus liegt eher im Bereich CW, meiner dagegen mehr im Bereich SSB. Uns beide eint aber die gleiche Absicht, nämlich dieses Stück Software immer besser zu machen und mögliche Fehler zu beseitigen.
Es gibt also kein „das ist besser als dies“ – beide Versionen haben einfach unterschiedliche Ausrichtungen und zielen auf verschiedene Anwendergruppen ab, deswegen unterscheiden sie sich im Detail etwas und deswegen macht das auch durchaus Sinn, hier verschiedene Ansätze zu verfolgen.
Und vergesst nicht, es sind beides reine Freizeitprojekte und dafür opfern wir unsere nicht sehr üppig verfügbare freie Zeit. Beide Versionen sind OpenSource – somit kann jeder sie verwenden, wie er möchte. Ich für meinen Teil kann zumindest sagen, das was ich da entwickle, wende ich jeden Tag auch an, weil ich damit aktiv meinen Amateurfunk betreibe. Das wächst also alles auch an und aus der Praxis heraus. Das, was mir damals im piHPSDR so fehlte, habe ich inzwischen fast zu 100% im deskHPSDR umgesetzt und noch einiges mehr, als ich das urspünglich mal geplant hatte. Ich habe viel dabei gelernt und traue mir inzwischen auch komplexere Anpassungen zu, was anfangs nicht so ganz der Fall war. Welche neuen Ideen da noch schlummern – das wird sich noch zeigen. Es gibt solche Entwicklungen auch woanders – denkt nur an JTDX, was ja ebenfalls aus WSJT-X hervorgegangen ist und einige Dinge kann, die WSJT-X bis heute nicht kann. So in etwa muss man das auch mit piHPSDR vs. deskHPSDR verstehen.
