Neptune PA und (meine) Problemlösung

Wie ich ja schon berichtet hatte, habe ich mir zwei Endstufen, 50W und 100W mit dem Namen „Neptune“ aus der Ukraine gekauft. Sehr ordentlich designte HF-Verstärker von Paul, UU0JR, die ich mit meinen 5W-QRP-Geräten und dem Hermes-Lite 2, der ebenfalls bis 5W Leistung macht, verwenden wollte.

Die Freude war groß als sie endlich hier eintrafen, schnell die nötigen PowerPole-Verbindungskabel und PTT-Leitungen hergestellt und dann ging es ans testen. Besonders die Tatsache, das beide PA eine automatische Bandwahl haben, kam mir sehr entgegen, musste ich doch für meine XIEGU XPA125B extra einen kleinen ESP32 programmieren, der mir die notwendige Bandspannung mit einem DAC erzeugte, die benötigt wird, wenn man nicht manuell die Bänder des LowPass-Filters der PA umschalten will.

Abstimmen 🙂

Ich beginne immer bei neuen, unbekannten PA erstmal mit wenig Leistung abzustimmen, auch um ein Gefühl für das richtige Input-Output-Verhältnis zu bekommen. Abstimmen bedeutet CW-Signal oder reiner Träger. Hier verhielten sich beide PA gut, das ausgewählte Band wurde zuverlässig erkannt und das schon etwa ab 250-400mW Eingangsleistung. Bis hierher sah das alles gut aus, neues Band wurde sofort ekannt, der LPF schaltete schnell um.

Erste CW-QSO 🙂

Wenn man schon mal in CW ist bei den ganzen Abstimmversuchen, kann man auch gleich mal ein paar CW-QSOs machen. Ich brauchte eh noch ein paar Pünktchen für die 100FK-Aktivität, also gleich mal in CW mitgemischt. Die PA erzeugt die 100W bereits so zwischen 2,5-3W Input, das sah alles gut aus, Umschaltung PTT ging auch schnell genug. Bis hierhin alles super – dachte ich.

SSB und Digimodes 🙁

Tja, nichts ist perfekt und leider galt das auch für die beiden Neptune PA. Meine ersten SSB-QSO liefen leider etwas anders, als ich das erwartet hatte. PTT gedrückt, PA ging kurz auf Sendung und fiel sofort wieder zurück auf Bypass. Nanu – hatte ich irgendwas verstellt, habe ich HF auf der PTT-Leitung, EMV-Probleme ?

Leider nichts dergleichen, da war alles in Ordnung. Nach ein paar weiteren Tests war die Ursache schnell klar, es lag an der automatischen Frequenzmessung für das LPF. Diese läuft über einen Schmitt-Trigger-IC in den Mikroprozessor, Typ STM32G030, der dann die Frequenzmessung umsetzt. Das ist in SSB so eine Sache, denn wir haben ja einen unterdrückten Träger, also im Falle von nur PTT ein kommt noch lange keine HF aus dem Transceiver, erst wenn ich ins Mikrofon spreche und moduliere, wird auch ordentlich HF erzeugt. Damit haben leider beide Neptune PA, sowohl die 50W- als auch die 100W-Version ein deutliches Problem, denn hier versagt offensichtlich die Messung der Frequenz und damit die sich anschließende korrekte Bandwahl bzw. die Wahl des richtigen LPF. Sende ich auf ein falsch ausgewähltes, für die Sendefrequenz nicht vorgesehenes Filter, kann es dort wie bei Tunern zu Spannungsüberhöhungen kommen und man riskiert die meist nicht allzu spannungsfesten Kondensatoren im Filter zu zerstören. Aus diesem Grund hat auch der Entwickler eine Schutzfunktion in die Firmware eingebaut, wenn es zu einer fehlerhaften Messung der Sendefrequenz kommt, schalten die Neptune sofort wieder zurück in den Bypass-Mode. Das war genau das, was bei SSB leider ständig passierte. Leider, wie sich schnell herausstellte, auch bei Digimodes wie FT8 – es war jedesmal eine Lotterie, ob die PA auf Sendung ging oder blieb.

Also kontaktierte ich den Entwickler und schilderte die Probleme. Mir war klar, das ist nicht so einfach zu lösen, im schlechtesten Fall ist es ein generelles Hardware- oder Softwareproblem. Paul fixte etwas an der Firmware der PA und spielte mir das Update in beide PA ein – leider ohne nenneswerte Verbesserungen. Das Problem in SSB blieb bestehen.

Ich machte ihm den Vorschlag, die Firmware dahingehend anzupassen, dass im Fehlerfall die PA NICHT einfach wieder abschaltet, sondern schlicht die bisherigen Einstellungen des LPF beibehält, denn Abstimmen funktionierte ja immer korrekt und damit auch die korrekte Bandwahl.
Leider wollte er meinem Vorschlag bzgl. dieser Firmwareänderung nicht folgen, was ich leider schon geahnt hatte. Diese Änderung in der Firmware hätte das Problem auf einfache Art und Weise sofort und abschließend lösen können.
Den Grund seiner Ablehnung kenne ich leider nicht – im Sinne seiner weiteren Kunden mit dem gleichen Problem ist eine solche Entscheidung aus meiner Sicht unverständlich und für mich auch nicht nachvollziehbar.

Damit war ich wieder an einem Punkt, wo ich bereits an anderer Stelle mit einem anderen Gerät stecken blieb – weil ich auf die Zuarbeit des Herstellers schlicht angewiesen bin, wenn es Probleme mit der Software solcher Geräte gibt. Da kaum jemand seinen Quellcode veröffentlicht, ist also nur Hoffen, vor allen Dingen aber Warten und Geduld bis zur Problemlösung angesagt.

Also muss nun eine andere Lösung her…

Mich ärgert es schon ziemlich, wenn ich schon eine Lösung kenne, diese aber aufgrund der Abhängigkeit vom Hersteller nicht umgesetzt bekomme. Abwarten und Tee trinken zählt leider nicht zu meinen Stärken. Ich hatte auch nicht vor, diese PA wieder zurück zu schicken, obwohl beide eigentlich im Originalzustand so nicht wirklich benutzbar waren (für meine Zwecke).
Inzwischen hatte ich auch erfahren, das ich nicht der Einzige mit diesen Problemen war, andere mit den gleichen Neptune PA berichteten genau das gleiche, was ich auch herausgefunden hatte. Also doch ein generelles Konstruktionsproblem ohne schnelle Lösungsmöglichkeit ?

So, dachte ich nun, es muss doch einen anderen Weg geben. Glücklicherweise hatte Paul die Schaltpläne beider PA veröffentlicht, also war nun das Studium dieser Schaltpläne angesagt. Ich bin ja kein Neuling in Sachen Elektronik und gebaut hatte ich auch schon einiges. Auch mit SMD-Technik stand ich inzwischen nicht mehr auf „Kriegsfuß“. Gut, komplette MOSFET-Endstufen hatte ich bis dato noch nicht selbst gebaut, aber schon die eine oder andere Modifikation an solchen durchgeführt. Also machte ich mich noch etwas genauer mit dem Funktionsprinzip solcher MOSFET-PA bekannt und stellte schnell fest, im Grunde arbeiten sie alle nach dem gleichen Schema. Ich verglich einige Schaltpläne miteinander – ja, das ist so, im Grunde alles ähnlich. Man kocht eben doch auch nur mit Wasser. Nach dem Studium also zurück in die Praxis – Multimeter und Logicanalyzer rausgekramt und das Funktionsprinzip beider Neptuns geprüft. Ja, alles so wie ich dachte.

Wenn der Berg nicht zum Propheten kommt…

…muss der Prophet eben zum Berg kommen. Ein weises Sprichwort – aber zurück zum Thema.

Beide PA besitzen einen STM µC, einen häufig eingesetzten Mikrocontroller, der die Steuerung der PA übernimmt. Meist alles digitale Signale bis auf eben die Frequenzmessung, die ist etwas anders gelagert. Es sollte doch – so meine Überlegung inzwischen – kein Problem sein, diese Steuerung durch eine eigene Prozessorsteuerung zu ersetzen. Also die PA zerlegt, die Platinen studiert – ja, ein machbarer Weg, wenn auch etwas „Hardcore“, gleich eine neue Steuerung für die PA selbst zu entwickeln. Da ich inzwischen einige Erfahrungen mit den ESP32 erfolgreich gesammlt hatte und sich meine C++-Kenntnisse inzwischen auch deutlich verbessert hatten, gings also ans Werk.

Man nehme einen ESP32-S3 Zero, der ist klein oder kleiner wie eine Briefmarke. Ausreichend GPIO sind vorhanden. Also den ESP32 in die PA reingefummelt, die drei wichtigsten Steuersignale verdrahtet (1x PTT-Eingang, 1x BIAS an/aus für die MOSFETs und 1x RX/TX-Relais). Kurz ein kleines Programm zur korrekten Ablaufsteuerung dieser Signale für den ESP32 entwickelt, die drei Signale auf der Platine angezapft und an den ESP32 geführt. Ein erster Test – leider kein Output. Also Nachkontrolle, BIAS für die MOSFETs schaltet nicht. Ich hatte einen 4N25 Optokoppler zur Sicherheit dazwischen geschalten, leider zog der die +3.3V nur bis +1.8V gegen Masse, wie ich feststellen musste. Das reichte nicht, um den elektronischen Schalter für die BIAS-Spannung auf L-Signal zu bekommen. Wir waren noch im H-Bereich. Also den 4N25 durch einen simplen Schalttransistor BC547D ersetzt und siehe da, jetzt war das BIAS-Steuersignal bei 15mV und damit klar L. Ein erneuter Sendetest – JA, wir haben Verstärkung, jetzt kommen da die 100W raus. Gleich mal SSB getestet, abschalten konnte ja nix mehr durch meine eigene Steuerung, auch alles tipp-tipp. Gleich noch FT8 hinterher, auch alles ok, 10 QSOs im Log. Stabiler Betrieb wie zu erwarten. Nun also noch die Sache mit dem LPF, denn das musste ich ja nun irgendwie auch noch ansteuern – ohne Automatik. Die Schaltsignale für die 7 LPF-Relais waren zum Glück über die Front-LEDs direkt zugänglich. Also alle 7 Steuerleitungen an 7 GPIO des ESP32, da ein Treiber-IC mit +3.3V Ansteuerung vor den Relais mit 12V plaziert war. Da mein TRX eine analoge Bandspannung ausgibt, habe ich diese gleich mal dem ESP32 über dessen ADC zugeführt, ausgewertet und eine Schaltlogik für die 7 LPF-Relais programmiert. Damit war das Thema Bandumschaltung auch erledigt – auch wenn die Vollautomatik mit der Frequenzmessung damit Geschichte war.
Aber die Bandspannung ersetzt ja das automatische Verfahren in ähnlicher Weise.

Gleich noch einen Webserver im ESP32 integriert, WiFi aktiviert und damit war der Status der Neptune auch gleich im Webbrowser verfügbar, das brauche ich für den Remotebetrieb.

Hier die Ausgabe des Status der Neptune PA im Webbrowser, sämtliche Daten werden durch Websocket-Technologie in Echtzeit dargestellt.

Hier beide Schaltpläne meiner Umbauten an den PA Neptune 50W und Neptune 100W (Bedingung: Verständnis der beiden PA-Original-Schaltpläne erforderlich – beide sind auf 60dbm.com frei erhältlich und als Download dort verfügbar) als PDF:

Source-Code des ESP32 für den Umbau der 50W-Version (ohne WiFi/Webinterface):
https://github.com/dl1bz/NepControl50W

Source-Code des ESP32 für den Umbau der 100W-Version (mit WiFi + Webinterface):
https://github.com/dl1bz/NepControl100W

Am Ende des Weges…

…habe ich nun zwei Neptune PA, die jetzt so funktionieren, wie ich das immer wollte und auch erwartet hatte. Das hier war der Umbau der 100W-Version, bei der 50W habe ich einige Änderungen vorgenommen, diese arbeitet noch mit der automatischen Bandumschaltung, denn im Falle von Tunen klappte das ja. Ausserdem will ich die 50W-Version auch an TRXen verwenden, die keinen analogen Bandspannungsausgang haben. Im Grunde habe ich da aber ein ähnliches Konzept mit eigenen ESP32-Controller umgesetzt, der ebenfalls – dort allerdings in Kombination mit dem internen STM32, der parallel zum ESP32 weiterarbeitet – die Hauptkontrolle der PA übernommen hat. Der STM32 dient dort lediglich zur automatischen Bandumschaltung, denn das ist einer der wenigen Punkte, die mit dem ESP32 schwierig bis gar nicht umzusetzen gehen. Finde ich dafür auch eine Lösung mit dem ESP32, baue ich das später ggf. noch um.

Fakt ist, nach meinen Modifikationen arbeiten jetzt beide Neptune PA perfekt – in allen Modi inkl. SSB und FT8.

HF-seitig war eh nie etwas an beiden zu bemängeln, technisch sind beide tipp-topp, was die HF-Parameter angeht. Es war sicher nicht der eleganteste Weg, aber er funktionierte so, wie ich es geplant und erwartet hatte.
Am Ende zählt das Ergebnis – und die Zielstellung wurde zu 100% erreicht.

Da ich bereits selbst genug Projekte mit µC umgesetzt habe, ärgern mich solche Softwaredesigns wie die in den beiden Neptune PA sehr. Theoretisch kann ich ja den „Nutzen“ dieser Schutzfunktion verstehen und nachvollziehen – nur führt er in der Praxis zu einem Desaster und das teilweise bis zur Unbenutzbarkeit der PA. Und genau dieses Softwaredesign – so meine strikte Entscheidung – habe ich mit meinen Modifikationen praktisch umgangen und außer Kraft gesetzt – mit dem positiven Ergebnis, das es jetzt kein „Problem“ mehr gibt.

Würde ich diese PA erneut kaufen ? Auch wenn es mancher nicht verstehen wird, die Antwort ist ein klares JA.
Das HF-Design ist super umgesetzt und die Steuerung ist kein Hexenwerk – und eine inzwischen praxisbewährte Lösungsmöglichkeit liegt nun auch vor. Und im Preisvergleich zu Ihren unmittelbaren Konkurrenten, der XIEGU XPA125B oder der JUMA PA-100D, bleibt die Neptune immer noch die Günstigste aller drei.