von Nachdem ja nun meine 600W LDMOSFET-PA bereits ein paar Monate erfolgreich in Betrieb ist, stand nun noch die Aufgabe an, das Schalten des Lowpass-Filters (notwendig zur Unterdrückung der Oberwellen) hinter der PA vom bisher händischen Schaltbetrieb auf Automatik umzustellen, da ja im Falle von Remote-Betrieb mit dem Hermes-Lite 2 und der PA kein Zugriff auf den Selektions-Schalter des Filters möglich wäre.
Selektion der Möglichkeiten für die Gewinnung der Bandinformation
Grundsätzlich gibt es drei Optionen direkt am Hermes Lite 2, um die Information über das aktuell gewählte Band zu erhalten:
- Ausgabe einer analogen Bandspannung, sofern in der SDR-Software diese Option aktiviert ist
- Abgriff der aktuellen Frequenz an der internen UART-Schnittstelle des Hermes-Lite 2
- I²C „Sniffing“ der optionalen N2ADR-Filterplatine, die per I²C gesteuert wird
Alle drei Optionen lassen sich verwenden, um entweder direkt das eingestellte Band zu signalisieren oder aus der Frequenzinformation des VFO diese zu extrahieren.
Versuch 1 – Nutzung der analogen Bandspannung
Das hatte ich bereits für meine Modifikation der Neptune-100W-PA erfolgreich umgesetzt, also lag es nahe, das erneut zu nutzen, zumal die notwendige Softwareentwicklung und damit der erforderliche Sourcecode von mir bereits vorlag. Ich nutzte also wieder einen ESP32-S3-Zero als µC und deren ADC, um die Bandspannung auszuwerten und per GPIO die Steuersignale zum Schalten des Filters zu erzeugen. Also alles entsprechend verdrahtet, den µC programmiert und getestet. Das sah erstmal alles gut aus – dachte ich zumindest zu diesem Zeitpunkt.
Als ich dann abends noch etwas FT8 machen wollte, war das gleich mal der Praxistest. Meine Station steht in einem anderen Zimmer, also gleichmal Remotebetrieb ohne Zugriff oder Sicht auf die Technik. Das 17m-Band gewählt, die Antenne abgestimmt, alles ok wie immer. Dann gleich mal einen Test mit FT8 und PA – TX an – auf einmal zeigte mein SWR-und Powermeter 0W Ausgangsleistung. Also ab zur Technik, es sah alles normal aus, aber keine Leistung mehr aus der PA. Kurze Messung des Ruhestroms der MOSFETs, der eigentlich bei 400mA liegen muss. Nee, nur noch 100mA zu messen. Tja, es sah wohl aus, als wären die MOSFETs durch. Stand allerdings die Frage, wieso bzw. warum, meine Tests am Nachmittag waren alle positiv und zeigten keine Probleme. Nun denn, erstmal eine Nacht darüber schlafen und am nächsten Morgen gehts dann wieder frisch ans Werk.
Da ich ja vorgesorgt hatte mit Ersatzteilen, wurde also am nächsten Morgen kurzerhand die PA einer Reparatur unterzogen, die zwei offensichtlich defekten MRF300 ausgelötet. Da ich auch die preisgünstigeren MHT1803 vorrätig hatte, nutzte ich gleich mal die Gelegenheit, diese in die PA anstatt der MRF300 einzubauen. Alles eingelötet, Ruhestrom neu eingestellt, LPF-Automatik allerdings erstmal wieder abgeklemmt. Kompletter Testdurchlauf durch alle Bänder – Leistung wieder vollständig da, kein Unterschied mit den MHT1803 zu den MRF300 festzustellen. Die PA hatte also keinen weiteren Schaden genommen, es bleib beim Ausfall der MRF300.
Blieb also die Frage offen, was denn nun passiert war. Also die LPF Automatik wieder installiert und erneuter Test, erstmal mit ca. 200W. Geht offensichtlich alles, keine Auffälligkeiten zu erkennen. Also nun das Ganze nochmal mit vollem Output, also den 600W. 80m – 40m – 20m, geht auch. Jetzt 17m. Bei diesem Band fing die LPF Automatik auf einmal an, wie wild den LPF zu schalten. Warum ? Mit den 200W im ersten Test war da nix festzustellen, bei 600W sah das allerdings anders aus. HF-Problem aufgrund Einstreuung ? EMV Problem ? Nochmals kurzer Test, ja Problem ist reproduzierbar. Keine klare Bandselektion bei 17m und voller Leistung. Gut, damit war erstmal klar, was meine MOSFETs eigentlich gekillt hat – das wilde Rumschalten des LPF haben sie nicht überlebt. Eine genauere Untersuchung ergab dann, die vom Hermes Lite 2 gelieferte Bandspannung veränderte sich drastisch bei den 600W auf 17m, was die Software dazu bewegte, zwischen 20m und 17m & 15m und sogar auf 12m & 10m zu wechseln. Es könnten auch bei QRO die 18MHz irgendwie den ESP32 aus dem Tritt gebracht haben, was natürlich auch Auswirkungen auf dessen ADC-Messungen zur Folge haben könnte und die per ADC gemessenen, aber stark variierenden Daten erklärt. Eine Kontrolle mit dem Multimeter zeigte nämlich keine Schwankungen der Spannung an der Quelle, dem Hermes Lite 2.
Damit traf ich erstmal die Entscheidung, analoge Bandspannung fällt als Option erstmal raus. QRO hat eben immer seine Tücken, meist dort, wo man sie nicht erwartet.
Versuch 2 – Nutzen der UART des Hermes Lite 2
Auch das hatte ich bereits früher schon einmal umgesetzt, auch in diesem Fall war der Sourcecode bereits vorhanden. Der Hermes Lite 2 sendet auf seiner intern zugänglichen UART bei 9600Bd-8-N-1 immer Frequenzinformationen im Format FA0000007150000; – was also einfach zu detektieren ist per Software. Und – es ist eben eine digital übertragene Information und keine per analoger Spannung. Da kann also weniger schiefgehen – dachte ich. Also alles geändert und den ganzen Tag nebenbei getestet. Alle Bänder bei voller Leistung wurden jetzt korrekt am LPF geschalten. Zusätzlich hatte ich noch die PTT-Leitung angezapft und meine Software dahingehend angepasst, das bei aktiver PTT-Leitung, also TX an, auf keinen Fall ein Schaltvorgang des LPF ausgelöst werden kann. Dummerweise hatte ich das bei Versuch 1 mit der Bandspannung noch nicht so umgesetzt – jetzt aber schon. Damit konnte eigentlich nix mehr schiefgehen – was sich kurz darauf als Trugschluß herausstellen sollte. Auch gab es eine Art Notauswahl bei unklaren Bandinformationen, dann wird der höchste LPF, also 12m & 10m gewählt und geschalten. Es ist ja ein LowPass-Filter, der dann also unter 30MHz alles durchlässt.
Als ich den nächsten Tag alles wieder einschaltete, musste ich feststellen, das der LPF nun gar nicht mehr schaltet mit der Automatik – allerdings die immer noch vorhandene manuelle Umschaltung funktionierte weiterhin. So langsam nervte mich diese Geschichte. Also wieder prüfen, was denn nun wieder passiert sein könnte. Das Problem war schnell entdeckt, es kamen keine Daten mehr von der UART des Hermes Lite 2. Ich hatte lediglich die TX-Leitung des Hermes Lite 2 an den RX-Eingang des Arduino Nano verdrahtet. Diese liefert etwa 2.5V TTL-Pegel und kommt direkt vom FPGA des Hermes Lite 2. Der Arduino Nano arbeitet jedoch mit 5V TTL-Pegel, aber da ich ja nur 2.5V „einliefere“, kann das also nicht zu einem Problem werden, er ist ja nur „Empfänger“, sendet also nichts auf dieser Leitung, das erfolgt ja bei UART getrennt auf der TX-Leitung. Die war aber gar nicht verdrahtet. Kurios. Also einen UART-2-USB-Adapter angeschlossen, auf 3.3V gestellt (das hatte ich früher bereits so lange in Betrieb, als ich die UART-Funktion des Hermes-Lite 2 untersuchte) – nein, auch da kamen keine Daten mehr auf der UART. Tja, dann ist wohl aus mir bis jetzt unerklärlichen Gründen die UART des Hermes Lite 2 bzw. dessen FPGA gestorben. Also den Hermes Lite 2 komplett durchgetestet – nein, keine sonstigen Funktionsstörungen zu erkennen, er tut alles noch, was er tun muss. Gut, wenn es denn nur die UART erwischt hat, ist das kein allzu großes Problem. Ausser den Frequenzinformationen, die da ausgegeben wurden, hatte diese UART keine weitere Funktion. Allerdings fiel damit also auch Option 2 leider auch wieder weg. Was allerdings die UART in den Tod gerissen hat, bleibt mir ein völliges Rätsel. Ich bin mir da keines Fehlers bewusst. Aber es ist nun mal so wie es ist.
Versuch 3 – I²C-Anzapfung und Sniffing des internen I²C-Busses des Hermes Lite 2
Nun denn, dann also erneut frisch ans Werk, verwenden wir also nun die I²C-Daten. Also wieder den ESP32 verwendet, mit dem hatte ich schon einige Experimente hinsichtlich I²C gemacht wie externe ADC oder OLED-Displays per I²C angebunden und zwar erfolgreich. Also den Hermes Lite 2 seinen internen I²C verdrahtet und dem ESP32 zugeführt. Kurzer I²C Scan – ja, 0x20 ist sichtbar. Diese Adresse müssen wir „überwachen“, denn da werden die Steuerinformationen für den N2ADR-LPF des Hermes Lite 2 gesendet.
und über dem auch die I²C Kommunikation zwischen beiden Komponenten stattfindet
Tja – da kommt nix. Software gecheckt, nee, alles richtig und korrekt. Also kurzerhand den ESP32 durch den Arduino Nano ersetzt – der Programmcode geht für beide – JA, jetzt bekomme ich die richtigen Daten. Also scheint das mit dem ESP32 leider so nicht zu funktionieren, mit dem Arduino Nano allerdings schon. Nun gut, nehmen wir also den Arduino Nano für diese Aufgabe. Das stellte mich allerdings vor das Problem, das der Arduino Nano leider weder Bluetooth noch WiFi onboard hat, der ESP32 allerdings schon. Immerhin will ich ja am Ende den Status des LPF für die PA auf einem Webbrowser darstellen, also brauche ich den ESP32 schon dafür. Also kurzerhand beide µC per UART untereinander verbunden und ein kleines Übertragungsprotokoll entwickelt. Der Arduino Nano sendet jetzt per UART die I²C-Daten an den ESP32 und schaltet auch gleich das LPF mit. Der ESP32 wertet diese Schaltvorgänge aus und stellt sie auf einem Webbrowser mittels Websocket-Technologie dar. Damit ist also die Aufgabe erfüllt. Leider sind nun zwei µC erforderlich, aber was solls, davon habe ich genügend verfügbar.
Umsetzung auf Hardwareebene
Anbei die verwendete Schaltung, wie ich sie jetzt verwende (bitte auf das Bild zum Vergrößern klicken).
Praktischer Aufbau
Ich habe die ganze Schaltung auf einer Universal-Platine aufgebaut, dafür extra eine Platine zu entwickeln, lohnt den Aufwand nicht wirklich. So viele Bauelemente sind es ja nicht. Das Ganze habe ich dann via 8pol. Buchsen einmal mit dem Hermes Lite 2 und dessen 9pol. SUB-D Connector und einmal ebenfalls mit einer 8pol. Buchse an meinem LPF verbunden. Verwendet wurden geschirmte Datenleitungen aus der Netzwerktechnik.
So sieht das Ganze dann im Betrieb aus:
Links der umgebaute Low Pass Filter ARF-1000 von Ameritron, wo ich hinten eine 8pol. Buchse zum Zuführen der Signalleitungen zu den Relais nachgerüstet habe. In der Mitte, auf dem Hermes Lite 2 stehend, die Controller-Platine mit dem Arduino Nano und dem ESP32, eingebaut in ein Aluminium-Gehäuse. Hinten wurde noch eine SMA-Buchse montiert, an der eine WiFi-Antenne angeschlossen ist, denn in dem mehr oder weniger geschirmten Gehäuse funktioniert natürlich der ESP32 mit seiner auf die Platine gelöteteten Mini-WiFi Antenne nicht gut. Also habe ich diesen Antennenanschluß nach Außen verlagert samt einer externen WiFi-Antenne. Die manuelle Schaltung des LPF ist weiterhin möglich, jedoch habe ich den Wahlschalter um eine Schaltmöglichkeit erweitert, die mit Automatik gekennzeichnet ist. In dieser Stellung schaltet also der LPF-Controller sämtliche Relais des LPF extern. Zur Kontrolle der Schaltstellung habe ich noch ein paar LED an der Front des Controllers hinzugefügt, damit man sieht, welches Filter grade ausgewählt ist.
Alle Bauteilkomponenten sind u.a. bei Mouser bzw. Amazon verfügbar.
Die Software für beide µC, den Arduino Nano und den ESP32, sind Eigenentwicklungen von mir.
Hier der Sourcecode für beide µC, einmal dem Arduino Nano und einmal dem ESP32-S3-Zero als ein ZIP-Archiv.
Beide sind mit der Arduino IDE 2.x entwickelt, der ESP32 verwendet die ESP-Boardunterstützung noch in der Plattform-Version 2.x, inzwischen gibt es bereits eine 3.x, womit ich den Code allerdings nicht getestet habe und auch nicht testen werde. Auch sind für den ESP32 zusätzliche Bibliotheken erforderlich, hier müsst Ihr Euch kümmern. Schaut in den Code, dort erklärt sich das selbst.
Wie immer – es gibt keinen Support von mir, die Bereitstellung der Sourcen erfolgt „so wie sie ist“, denn andernfalls müsste ich dann künftig grundsätzlich auf solche Bereitstellungen / Veröffentlichungen verzichten.
Auch wenn man auf dem Bild diesen AMERITRON LPF ARF-1000 sieht, den es leider nicht mehr zu kaufen gibt und auch nicht mehr produziert wird, würde das Konzept auch mit jedem anderen LPF, der über Relais geschalten wird, funktionieren. Die Ausgabe des Controllers sind 12V Steuerspannungen, die direkt mit Relais zum Schalten verbunden werden können. Die notwendigen Schutzdioden beim Schalten von Relais sind bereits in den verwendeten Treiber-IC integriert, müssen also nicht extra bestückt werden. Das liesse sich also auf jeden LPF mehr oder weniger adaptieren. Ich habe mich bewusst für eine Art modulares Konzept entschieden, bei dem ich PA und LPF getrennt betreiben kann. Das lässt mir die Option offen, ggf. eine andere PA zu verwenden, ohne größere Umbauten vornehmen zu müssen. Der LPF kann ca. 1kW CW, liesse sich also auch mit PA höherer Leistung verwenden.
Nach nun einigen Tagen umfangreichen Testbetrieb kann ich sagen, dieses Projekt war am Ende erfolgreich – trotz aller Widrigkeiten und Problemen zu Beginn – und kann jetzt im Produktivbetrieb eingesetzt werden. DIY-Projekte haben eben immer eine steile Lernkurve und auch „Lehrgeld“ muss man einplanen. Allerdings hat mich das mehr Zeit gekostet als der (Eigen-)Bau der eigentlichen 600W PA, hi.
Da auch das im Bild zu sehende SWR- und Powermeter RX-200 einen µC samt hochauflösenden ADC bekommen hat, kann ich ebenfalls vorlaufende und rücklaufende Leistung plus SWR in einem Webbrowser darstellen. Kombiniert mit meinem ebenfalls vollautomatisch arbeitenden Outdoor-Antennentuner ist die ganze Station damit vollautomatisiert und eignet sich damit ebenfalls für den Remote-Betrieb von Außerhalb. Kombiniert mit einer VPN-Lösung kann ich den Hermes Lite 2 samt allem Monitoring per Netzwerk also von irgendwo auf der Welt bedienen – Internetzugang vorausgesetzt.
Die letzte Projektmaßnahme, Nutzung der PureSignal-Funktion – auch Predistortion genannt, erfolgt in Kürze auch noch, dieses Verfahren ist in der Lage, durch eine Art Feedback, also der Rückführung des (stark abgedämpften) Sendesignals nach der PA in einen speziellen RX-Eingang des Hermes Lite 2, den IM3 einer PA in den Bereich von etwa -45dbc per Software zu verbessern und damit ein „saubereres“ Sendesignal zu erzeugen. Dazu jedoch mehr in einem gesonderten Beitrag.
