Neu im Shack: SDR-TRX Brick2 14bit

Nachdem mich nun eine lange Zeit mein Hermes Lite 2 SDR-TRX sehr zuverlässig begleitet hatte und ich ja durch meine Entwicklung meines Software-Projekts deskHPSDR inzwischen international gut vernetzt bin, brauchte ich für dessen weitere Entwicklung einen SDR-TRX, der das neuere OpenHPSDR Protokoll 2 „spricht“, denn der Hermes Lite 2 wird noch mit dem älteren OpenHPSDR Protokoll 1 betrieben.

Da es schwierig ist, Softwareentwicklungen trocken und ohne Verifikation in der Praxis umzusetzen, besonders bei solchen umfangreichen Software-Projekten wie einer SDR-Applikation, ging ich also auf die Suche nach einem preiswerten SDR-TRX, der mit dem neueren OpenHPSDR Protokoll 2 läuft.

Obwohl ich dieses Projekt bereits längere Zeit beobachtet hatte und kannte, hatte ich mich nun für den Kauf eines „Brick2“ genannten SDR-TRX entschieden, da dieser mit ca. 500€ angeboten wird, was so meiner Preisvorstellung entsprach.

Bei dem Brick2 handelt es sich um eine Entwicklung aus Osteuropa, speziell Ukraine und Weissrussland. Im Grunde ist es ein ANAN-10E Klone, er wird also als ANAN-10E in den SDR-Applikationen erkannt und auch entsprechend konfiguriert.

Hier seine wichtigsten technischen Daten:

• DUC/DDC SDR-Transceiver
• 2 Empfänger , 1 Sender
• Ausgangsleistung 160-6m bis max 15W, DIGI empfohlen max. 10W (2x RD16HHF)
• Eingebauter CW-Keyer
• LNA +20 dB
• Stufendämpfungslied 0-31 dB, einstellbar in 1db-Schritten
• Dynamic Range: 110 dB
• TCXO-Frequenzstabilisierung (0.1 ppm)
• eingebautes 7 LPF + 1 HPF für 6m Band
• 14bit ADC (Version mit 16bit ADC ist ebenfalls erhältlich mit einem entsprechend höherem Preis)
• ACC-Buchse mit YAESU BCD Bandswitching, XIEGU Bandspannung und PTT für eine externe PA
• Anschluß per Ethernet 100Mbit full-duplex, verwendet OpenHPSDR Protokoll 2
• zweiter Antennenanschluß für Feedback-Signal zur Nutzung PureSignal/Pre-Distortion

Der „bessere“ Hermes Lite 2 ?

Das würde ich so nicht behaupten wollen, „besser“ ist immer eine relative Aussage. Der Brick2 hat sicher einige Vorzüge gegenüber dem Hermes Lite 2 wie mehr Ausgangsleistung oder die Möglichkeit, auch das 6m-Band nutzen zu können.

Das für viele wichtigste Argument 14bit des Brick2 vs. 12bit Hermes Lite 2 könnt Ihr aber völlig unter den Tisch fallen lassen, denn das ist im praktischen Betrieb, zumindest auf der Kurzwelle, Verhalten beider Empfänger ist nahezu identisch, Unterschiede würde man vermutlich nur auf dem Messplatz sehen. Ich jedenfalls merke im direkten Vergleich beider SDR weder einen Nachteil der 12bit des Hermes Lite 2 noch einen Vorteil der 14bit des Brick2 bei deren Betrieb unter realen Bedingungen auf der Kurzwelle.

Allerdings hat der Brick2 eben nicht die Erweiterungsmöglichkeiten eines Hermes Lite 2, wo man ein sog. IO Board einbauen kann und damit zusätzliche externe und interne Steuerungs- und Controlleroptionen umsetzen kann. Hier geht der Punkt klar an den Hermes Lite 2, der Brick2 hat fixe Signale an dessen ACC-Buchse, die sich beschränken auf Bandausgabe nach YAESUs BCD-Schema, Bandspannung nach XIEGU und einem PTT-Ausgang zur Steuerung einer externen PA. Mehr gibts nicht, erweitern lässt sich da auch nichts mehr. So flexibel wie der Hermes Lite 2 mit seinem (optionalen) IO Board ist der Brick2 nicht.

Geliefert bekommt man ein fertiges Gerät im Metallgehäuse, beim Hermes Lite 2 wurden hingegen die einzelnen Baugruppen geliefert, die man selber in das ebenfalls gelieferte Metallgehäuse einbauen musste. Das war zwar in 15min erledigt, aber manche bevorzugen eben Fertiggeräte wie es der Brick2 eben ist.

Der Brick2 hat ausserdem einen Kopfhörer- und Mikrofonanschluss, demzufolge also einen Audio-Codec onboard. Sowas gibt es für den Hermes Lite 2 auch, genannt Hermes Lite 2+. Dort ist es ein Extension-Board, was man nachträglich einbauen kann und dann ebenfalls Audio und CW-Keying bereitstellt. Beim Hermes Lite 2 ist diese Erweiterung allerdings etwas umstritten, denn sie ist nicht Teil des eigentlichen Hermes Lite 2 Projekts selbst, sondern wird kommerziell von einem OM aus USA angeboten und verkauft.

Während auch die Firmware, die meist Gateware genannt wird, beim Hermes Lite 2 als Open Source und damit auch als Quelltext verfügbar ist, reden wir beim Brick2 eher von Closed Source. Quellen für dessen Firmware gibts also nicht. Allerdings stellt der Entwickler die wichtigsten Schaltplanunterlagen zur Verfügung, was ich als positiv bewerten würde. Das halten inzwischen nicht mal die sog. „kommerziellen“ Hersteller wie YAESU oder ICOM für nötig. Für den Hermes Lite 2 hingehen ist alles verfügbar, da es sich ebenfall um Open Hardware handelt, also sowohl Hard- wie auch Software vollumfänglich inkl. Platinenlayout zur freien Verfügung bereitgestellt wird.

Aus meiner Sicht haben beide SDR-TRX durchaus ihren Reiz, je nach gewünschtem Anwendungsfall ist aber keiner von beiden der „Bessere“. Im praktischen Betrieb erreiche ich mit beiden im Grunde die gleichen Ergebnisse.

Einen gewissen Vorteil besitzt der Brick2 mit seinem ab Werk bereits eingebauten TXCO, was man beim Hermes Lite 2 nur mit dem Anschluss eines externen Referenzoszillators erreichen kann. Dafür hat der Hermes Lite 2 einen extra Anschluss, der Brick2 verfügt über einen solchen nicht.

Betrieb mit SDR-Software

Beide SDR laufen natürlich mit Thetis, wobei für den Brick2 hier die ANAN-Version von MW0LGE zu verwenden ist, während der Hermes Lite 2 nur mit der speziell angepassten Thetis-Version vom MI0BOT läuft.

Mit meiner eigenen Entwicklung deskHPSDR hingegen laufen beide, entsprechendes Setup für den jeweiligen SDR vorausgesetzt.

Möglicher Bug in der Brick2 Firmware im Netzwerkstack

Im Rahmen der Inbetriebnahme des Brick2 mit meinem deskHPSDR bin ich allerdings auf ein Problem gestossen, was sich darin zeigte, das der Brick2 korrekt erkannt wurde, jedoch teilweise die Daten-Streams nicht starteten.

Eine genauere Analyse ergab dann, das der Brick2 beim Betrieb an einem Ethernet-Switch Schwierigkeiten mit ARP (aka „Address Resolution Protocol“) hat, indem er offensichtlich notwendige ARP Requests falsch oder gar nicht beantwortet. Dann kennt zwar die Software die richtige IP, jedoch nicht die MAC Adresse des Brick2 und kann somit nicht den notwendigen UDP Datenverkehr in Gang setzen. Das Problem konnte sowohl unter macOS wie auch unter Linux reproduziert werden. Den Entwickler habe ich über diesen möglichen Bug bereits in Kenntnis gesetzt.

Als „Workaround“ muss man also ggf. die ARP-Tabelle auf dem Rechner, wo die SDR Applikation läuft, händisch ergänzen bzw. modifizieren:

1. IP des Brick2 muss bereits bekannt sein, hier im Beispiel ist es die 192.168.253.26

2. Die MAC Adresse ist wohl wie bereits beim Hermes Lite 2 bei allen Brick2 immer die Gleiche, hier
wäre es 00:1c:c0:a2:22:5c

3. Bekannt muss ebenfalls die Bezeichnung des Netzwerk-Interfaces sein, über welches der Brick2 erreicht werden kann - bei Linux ist das meist eth0 und beim macOS meist en0 (ist aber systemabhängig, neuere Linux-Systeme nutzen nicht mehr eth0, sondern andere Bezeichnungen wie ens016, die Befehle sind also entsprechend anzupassen)

4. Hier die ARP "Nachhilfe" per Hand:

Linux:
Prüfen: sudo ip neigh show 192.168.253.26
Setzen: sudo ip neigh replace 192.168.253.26 lladdr 00:1c:c0:a2:22:5c dev eth0 nud permanent
Löschen: sudo ip neigh del 192.168.253.26 dev eth0

macOS:
Prüfen: arp -a | grep 192.168.253.26 oder nur arp -a (zeigt alle Einträge)
Setzen: sudo arp -s 192.168.253.26 00:1c:c0:a2:22:5c
Löschen: sudo arp -d 192.168.253.26

Diese Einträge erfolgen im Kernel des jeweiligen OS normalerweise automatisch, wenn sich das Gerät richtig im Netzwerk meldet und die ARP Requests korrekt beantwortet. Im Falle des Brick2 scheint das aber nicht so zu sein, deswegen müssen wir da von Hand etwas nachhelfen. Ist das erfolgt, lässt sich der Brick2 auch anpingen und die SDR-Software hat keine Probleme mehr, die Streams zu starten. Wenn man also diese Lösung kennt, ist die Inbetriebnahme kein Problem. Andere Probleme konnte ich nicht ausmachen, der Rest läuft so, wie es den Spezifikationen des OpenHPSDR Protokolls 2 entspricht.

Prüft also zuerst, ob sich der Brick2 unter seiner IP anpingen lässt. Schlägt das bereits fehl, muss ARP händisch wie eben beschrieben eingetragen werden. Da das immer administrative Rechte auf dem jeweiligen OS erfordert, kann ich diesen Fix oder Workaround leider nicht in die SDR-App deskHPSDR fest einbauen, muss also ausserhalb der App erfolgen.

PA Kalibrierung auf 10W

Ich habe den TX Output pro Band für den Brick2 auf 10W eingestellt. Im PA Menü meines deskHPSDR sieht das dann so aus:

Hinweis:
Den maximalen Output erreicht man bei einem Wert von 38.8
Erhöht man den Wert, sinkt der Output. So kann man mittels eines Dummy-Load und eines Leistungsmessers den Output pro Band einstellen. Ich habe mich für 10W entschieden, dann ist die Leistungseinstellung 1-100% gleich 1-10W. Ich benötige eigentlich die 10W nicht, da meine LDMOSFET-PA bereits um die 3W Output vollen Output liefert. Aber zum Tunen ist das schon hilfreich, besonders wenn man automatische Antennentuner verwendet, denn viele brauchen so um die 10-15W zum korrekten Abstimmen, denn wir wollen ja nicht mit aktiver PA abstimmen. 5W wie beim Hermes Lite 2 können aber zu wenig sein, u.a. hatte da mein früher benutzer CG3000 bereits Probleme, eine korrekte Abstimmung zu finden (der Hersteller gab 15W Abstimmleistung als Minimum an).

Erstes Fazit nach ein paar Tagen Funkbetrieb mit dem Brick2

Von dem ARP Netzwerkproblem mal abgesehen, macht der Brick2 einen sehr guten, soliden Eindruck. Die Anschaffung hat sich auf jeden Fall gelohnt und der Preis mit 500€ geht meiner Meinung nach in Ordnung. Den Hermes Lite 2 gibts allerdings bereits für knapp über 300€, was dann ein echter „No Brainer“ ist. Empfehlen kann ich beide, wer ein Fertiggerät erwerben will und mehr als 5W Output benötigt und ungern auf 6m verzichten möchte, greift zum Brick2. Wer etwa 15min Zusammenbau in Kauf nimmt, sich mit 5W zufrieden gibt und auf 6m verzichten kann, ist mit dem Hermes Lite 2 genauso gut bedient. Beide liefern im RX Vergleich nah aneinander liegende Ergebnisse im Praxisbetrieb ab, denn beide sind Directsampler. Die 14bit des Brick2 sind kein merklicher Vorteil gegenüber den 12bit des Hermes Lite 2. Ähnlich wird sich das vermutlich mit der allerdings zum Preis von dann schon 799€ erhältlichen 16bit Version des Brick2 verhalten. Die höhere Dynamik dürfte sich eher nur unter speziellen Einsatzbedingungen bezahlt machen, z.B. Transverterbetrieb oder ähnliche Anwendungsbereiche. Zumindest auf der Kurzwelle kommt dieser kleine Vorteil kaum zum Tragen. Da auch kommerzielle Transceiver wie der IC-705 oder der IC-7300 hier auf 14bit ADC setzen, konnte ich mir im Vergleich mit dem 12bit ADC des Hermes Lite 2 bereits früher ein solches Urteil 12bit vs. 14bit bilden, der Brick2 bestätigte das letztlich erneut.

Es gäbe ja noch einen weiteren Kandiaten in diesem Reigen, das wäre der in Tschechien entwickelte und dort erhältliche Hermes Lite 2 Klone Square SDR bzw. dessen kürzlich vorgestellte Überarbeitung Square SDR 2 (die jetzt im Grunde dem Hermes Lite 2+ entspricht). Auch er ist ein als Fertiggerät erhältlicher SDR Transceiver, Preis wie beim Brick2 um die 500€. Hier würde ich mich allerdings bei gleichen Preis eher für den Brick2 entschieden, da bekomme ich dann doch etwas mehr fürs gleiche Geld. Hier wäre mir der Aufpreis von knapp 200€ mehr gegenüber dem originalen Hermes Lite 2 vermutlich etwas zu hoch, zumal ich da ja ein identisches Gerät zum Hermes Lite 2 (gleicher 12bit ADC-Chip wie im Hermes Lite 2 verbaut) bekäme und keinen ANAN-10E Klone.

Wer also einen preiswerten Einstieg in das SDR-Universum sucht, hat inzwischen schon eine gewisse Auswahl im
Preissegment < 1000€:

• Hermes Lite 2 ≈ 340€
• Square SDR bzw. Square SDR2 als Hermes Lite 2 bzw. Hermes Lite 2+ Klone ≈ 500€
• Brick2 14bit bzw. Brick2 16bit als ANAN-10E Klone ≈ 500€ bzw. 799€
• und in Kürze der Brick3 mit 2x 16bit ADC als ANAN-100 Klone ≈ z.Z. noch 799€, später vermutlich 999€

Alle benutzen inzwischen praxis-bewährte SDR-Plattformkonzepte, man bekommt also keine Exoten, sondern bereits zig-fach eingesetzte Hardware mit einer ziemlich aktiven Community um jeden dieser SDR. Man bekommt also solide SDR-Hardware, deren Konzepte bereits in den Jahren 2012-2016 entwickelt worden und nur leicht angepasst und modernisiert wurden. Man spielt also nicht Beta-Tester für neue Hardware, sondern kann sich weitgehend darauf verlassen, das alles gut funktioniert.

Das trifft ebenfalls auf die inzwischen große Auswahl an SDR Applikationen zu, meist Open Source, die ebenfalls durch die Zeit mitgewachsen und immer weiter verbessert wurden. Beides zusammen ist eine solide Basis für den Einsatz im Amateurfunk, die sich keinesfalls hinter kommerziellen Transceivern von YAESU oder ICOM verstecken muss. Im Gegenteil, wer da einmal Blut geleckt hat und die Vorteile dieser SDR-Systeme zu schätzen verstanden hat, trennt sich wie ich dann von den bisher eingesetzten kommerziellen Transceiver-Komplett-Lösungen zugunsten der flexibleren SDR-Systeme, die heute zweifelsfrei den Stand der Technik wiederspiegeln. Natürlich kann ich auch mit 40 Jahre alter Technik funken – ich zumindest möchte aber auch im Amateurfunk moderne Technologien nutzen, die den heutigen Technikstand repräsentieren und Möglichkeiten bieten, die die alte Technik nun mal nicht mehr hergibt oder hergeben kann. Das Schöne am Ende ist doch einfach, beides – also Alt und Neu – kann heute immer noch miteinander kommunizieren.