Montag, 28. November 2016

#UpConverter Debugging results

Die letzen Tage habe ich damit verbracht meine UpConverter-Schaltung in Betrieb zu nehmen. Leider war der erste Test ernüchternd. Immerhin hat das Umschalten per Wechselschalter auf die Stellung "Überbrücken" direkt funktioniert. Bei der restlichen Schaltung war ich mir zunächst unsicher was hier überhaupt funktioniert. Im Grunde genommen habe ich für den ersten Test auch keine spezifische Umgebung geschaffen sondern die Platine einfach an mein rad1o angeschlossen und die ersten Empfangsversuche vorgenommen. Mit der Schalterstellung welche die UpConverter-Funktionalität der Platine überbrückt konnte ich direkt diverse QSO empfangen, darunter einige die per CW (Morsen) geführt wurden.

Nach dem umschalten auf den eigentlichen Betriebsmodus waren diese Signale dann nicht mehr im Spektrum meines SDR zu erkennen. Der Filter am Ausgang des Mixers scheint also offensichtlich zu funktionieren, ein erster Erfolg. Im Frequenzspektrum 110 MHz höher sollte darauf hin jedoch zu erkennen sein dass die Signale vom Mixer korrekt umgesetzt werden. Hier ist von den zuvor empfangenen Signalen jedoch nichts zu sehen gewesen. Diverse Messungen mit dem Oszilloskop und dem Multimeter ergaben mir jedoch keine Erkenntnisse die das Verhalten erklären würden. Zurück auf Überbrückung geschaltet waren die Signale auch wieder auf der Ursprungsfrequenz vorhanden.

Es musste zunächst eine definierte Testumgebung eingerichtet und ein Plan für einen ordentlichen Test aufgestellt werden.
Mein Plan war es nun also ein fixes Signal in den UpConverter einzuspeisen und daraufhin mit der SDR-Software das Verhalten weiterhin zu beobachten. Als Signalgenerator für das benötigte Signal habe ich mein SWRMeter verwendet. Dieses ist in der Lage Signale/Frequenzen im Bereich von 800 kHz bis zu 160 MHz zu erzeugen, was den Gewünschten Kurzwellenbereich vollständig und darüber hinaus abdeckt. Im folgenden Bild ist der Aufbau der Komponenten zu sehen.
Rad1o, UpConverter, SWRMeter
Das SWRMeter gibt während den Messungen ein Signal im Frequenzbereich der Kurzwelle aus. Das Signal verändert über die Zeit die Frequenz und wird direkt in den UpConverter eingespeist. Das verhalten des Signals kann dann, wie bereits beschrieben, per SDR-Software beobachtet werden. Für eine Bewertung der Funktionalität wird in diesem Schritt hauptsächlich die Differenz der Signalstärke - in dB über dem Grundrauschen - aus dem Frequenzspektrum abgelesen. Die tatsächliche Signalstärke ist bei den Tests nicht relevant, da diese nicht mit den Signalen vergleichbar ist welche ich bisher empfangen habe.

Das folgende Video zeigt die eine Messung exemplarisch. Eine Messung der Dämpfung des Schalters werde ich bei Gelegenheit noch nachreichen, sofern diese relevant wird.


Die folgenden Erkenntnisse sind aus den Messungen hervorgegangen:

Schalter auf BeipassSchalter auf UpConvert
+0 MHz+110 MHz+0 MHz+110 MHz
Verstärkung0 dB-30 dB-30 dB-20 dB

Von der ersten Spalte abgesehen sind ausschließlich negative Werte in der Tabelle enthalten. Eigentlich muss man bei diesen Werten eher von einer Dämpfung (Abschwächung) als von einer Verstärkung reden.
Die dB-Angaben sind nicht 100% genau, zeigen jedoch deutlich warum in den oberen Frequenzen (+110 MHz) bei Aktivierung des UpConverters keine Signale aus den originalen Frequenzbereichen zu sehen sind.
Selbst wenn in der SDR-Software die Verstärkung auf mehr als 30 dB einstellen würde wird dies nicht funktionieren, da das rad1o quasi kein Signal mehr aus dem Rauschen heraus aufnimmt. Das originale Eingangssignal ist nicht mehr messbar/vorhanden.

Bei der Verwendung des UpConverters und im originalen Frequenzbereich ist das Signal sogar um 30 dB geringer - 1000-mal kleiner als zuvor. Diese Eigenschaft können wir jedoch als positiv ansehen, da der Frequenzbereich unterhalb von 110 MHz nicht weiter benötigt wird und nur Störungen erzeugen würde.

Auch positiv zu sehen ist das das Test-Signal auf der neuen Frequenz ebenfalls zu sehen. Es wurde jedoch um 20 dB abgeschwächt, was einem 100ten Teil der vorherigen Signalstärke entspricht. Daher konnten die sehr schwachen Signale der QSOs auch nicht gesehen werden da die Eingangspegel weit unter 20 dB über dem Rauschen lagen - sofern die Anzeige von GQRX korrekt ist...

Auch zu vermuten ist das auch im Beipass-Modus wohl eine Kopplung des Eingangssignals in die UpConverter-Schaltung, als auch wieder auf das Ausgangssignal, stattfindet. Dies kann man durch das im oberen Frequenzbereich (+110 MHz) sichtbare Test-Signal zumindest vermuten. Es sollte dort nicht sichtbar sein.

Die Frage ist nun wie ich an dieser Stelle weiter vorgehen kann!?
Zum einen könnte ich die Qualität der Schaltung versuchen zu verbessern um die Dämpfung von 20 dB auf einen deutlich besseren Wert zu bekommen und zum anderen ggfls. einen Vorverstärker verwenden welcher die Dämpfung ausgleicht.
Alternativ könnte ich auch eine noch bessere Antennen bauen und diese im Freien und großer Höhe aufhängen, damit der Empfang deutlich verbessert werden würde. Noch habe ich hier aber keine Entscheidung getroffen.

Ergebnis: Die Schaltung an sich ist funktionstüchtig, wenn auch mit der unvorteilhaften Eigenschaft - der enormen Dämpfung von etwa 20 -30 dB. Verwenden kann ich sie so nur leider (noch) nicht.

Sonntag, 20. November 2016

#UpConverter für das #rad1obadge

Mein Rad1o-Badge vom CCC lag nun bestimmt mehr als ein Jahr lang in der Schublade. Es handelt sich dabei um ein SDR, also ein Funkgerät welches komplett per Software bedient wird. Empfangsfrequenz, Übertragungsrate zum Rechner als auch Leistungsverstärkung oder auch Bandbreite des Eingangsfilters wird komplett vom PC aus festgelegt. Software für die Bedienung gibt es einige verschiedene, ich verwende beispielsweise GQRX. Alternativ kann man auch #SDR verwenden. Mehr Informationen zum Rad1o gibt es übrigens hier.

Das hört sich nun erstmal sehr gut an, im Detail gibt es mit diesem Gerät jedoch ein Problem. Der Frequenzbereich den dass SDR empfangen kann bewegt sich im Bereich von 40 MHz bis 4 GHz. Damit sind nur die Frequenzbänder des Amateurfunks in Deutschland ab 6m (50,08 MHz) bis einschließlich 9cm (3,475) abgedeckt. Jetzt umfasst der Amateurfunk - welchen man in Deutschland auch ohne Amateurfunklizenz empfangen darf - noch weitere Frequenzbänder. Die aus meiner Sicht spannenderen Bänder befinden sich allesamt unterhalb der minimalen Frequenz die das rad1o empfangen kann - 40 MHz. Eine Übersicht über die Frequenzbänder des Amateurfunks in Deutschland kann man hier entnehmen.

Nun ist es zwar möglich in der Software wie GQRX die Limitierung der Hardware zu ignorieren (no limits Checkbox), was zum einen Schäden an der Hardware hinterlassen könnte und zum anderen einfach nicht so gut funktioniert da die Hardware und die eingesetzten Filter nicht auf die Frequenzbereiche abgestimmt sind. Per Software kann man dann noch die Eingangssignale allesamt stark verstärken lassen, was dann aber in fast jedem Fall zu einer extremen Übersteuerung führt. In der Regel habe ich auf diese Weise noch kein SSB-Signal verstehen können und auch mit den Digimodes gibt es größere Probleme.

Ich kann dennoch einige Erfolge mit dieser Betriebsweise des rad1o verzeichnen, so ist es mir beispielsweise möglich gewesen von N6PEQ ein QSO - welches mit Kanada über RTTY geführt wurde - zu empfangen. Alleine N6PEQ ist von meinem privaten Standort 9426 km entfernt (USA - Los Angeles). Und wenn man sich überlegt das meine Antenne eine im Wohnzimmer aufgehängte Groundplane war - ausgelegt für das 2m Band - dann wird die Tatsache des Empfangs immer unwahrscheinlicher. Beeindruckend - jedenfalls für mich!

Es sind also Erfolge zu erzielen, aber insgesamt ist das Empfangsgerät trotzdem nicht optimal ausgenutzt wenn man es ständig im undefinierten oder gar vollständig übersteuerten Modus betreibt.

Um die Frequenzen unterhalb von 40 MHz optimal empfangen zu können (den Kurzwellenbereich) benötigt man im ersten Schritt eine gut abgestimmte Antenne. Meine Groundplane ist für 2m abgestimmt. Also für 144 MHz bis 146 MHz was offensichtlich nicht passt.

Meine zweite Antenne ist eine MagnetLoop-Antenne, welche auf die Frequenzen von 2,5 MHz bis etwa 19 MHz abgestimmt werden kann. Sie ist für die unteren Frequenzen der Kurzwelle deutlich besser geeignet. Kurz: Mit dieser Antenne wird die Anzahl der Eingehenden Funksignale sowie deren Eingangspegel bereits deutlich besser.
Dennoch muss ich das rad1o weiter außerhalb seines Frequenzbereiches betreiben. Auf die Details beim Aufbau oder beim Kauf einer Antenne gehe ich an dieser Stelle nicht ein da man sich auch hierbei schnell im Detail verlieren kann.

Um nun aber das Problem mit dem Frequenzbereich in den Griff zu bekommen, genauer gesagt den Kurzwellenbereich mit dem rad1o sinnvoll empfangen zu können, gibt es eine Lösung. Man verwendet entweder einen Transverter oder einen UpConverter.

Ein Transverter ist wie auch der UpConverter ein Gerät welches man zwischen Antenne und Empfangsgerät in die Zuleitung einsetzt. Der Transverter setzt eingehende und ausgehende Signale von einer Frequenz auf eine andere um.
Das bedeutet das zum Beispiel das 40m Band (7 - 7,2 MHz) um eine definierte Frequenz nach oben verschoben wird. Also zum Beispiel von 7 MHz auf 107 MHz sofern die 100 MHz der Frequenz zweiten Frequenz entspricht.
Damit bewegt sich das zu empfangene Signal durch diese Verschiebung im normalen Arbeitsbereich des rad1o und kann ohne spezielle Einstellungen direkt empfangen werden. Jetzt könnte man auch statt 100 MHz nur 40 MHz verwenden, was uns aber mehr Probleme beim herausfiltern unerwünschter Signale bereiten würde.

Ein UpConverter realisiert diese Frequenzumsetzung quasi identisch. Der Unterschied zwischen UpConverter und Transverter ist dass der UpConverter nur in Empfangsrichtung funktioniert. Mit dem Transverter findet auch eine Anpassung der Sendefrequenz nach unten statt, so dass Funksprüche vom Funkgerät aus auf z.B. 107 MHz gesendet werden - tatsächlich aber auf 7 MHz ausgesendet werden.
Bild Schema
Die technischen Details halten sich für den UpConverter sehr in Grenzen (siehe Schema im vorherigen Bild). Eigentlich besteht dieser nur aus einem Eingangsfilter an den die Antenne angeschlossen ist. Dann aus einem Oszillator welcher einem die neue Mindestfrequenz erzeugt. Und einem Mixer der einem auf den Empfangs-Frequenzbereich die Frequenz des Oszillators aufaddiert. In meiner Schaltung ist die minimale Eingangsfrequenz bedingt durch den Mixer auf 0,5 MHz limitiert. Der Eingangsfilter filtert alle Eingangssignale oberhalb von ~60 MHz heraus. Dies hat den Vorteil das auch lokale FM-Sender die schwächeren Eingangssignale nicht überlagern.

Da ich auch für den UpConverter nicht unbedingt das Rad/die Schaltung neu erfinden wollte habe ich mich mit meiner Schaltung stark an ein anderes Projekt angelehnt. Dort ist die Umsetzung recht umfangreich beschrieben. Aufgrund der Umstände bei der Organisation mancher Bauteile habe ich ein paar Teile ersetzen müssen. Die schwierig zu beschaffenden oder unnötig teure Teile habe ich wieder in China bestellt.

Die unverschämte Einstellung deutscher Webshops/Firmen zum einen Versandkosten in der Höhe von um die 7 € zu verlangen (für einen Brief) und zum anderen für Bauteile welche sie ebenfalls aus China beziehen/in China fertigen lassen den 10-20 fachen Preis zu verlangen will ich - zumindest privat - nicht unterstützen. Mein Mixer aus China mit gleicher Güte kostet 70 Euro-Cent inkl. Versandkosten, und in Deutschland bestellt wäre dieser insgesamt bei etwa 14€.

Den Aufbau der Schaltung habe ich in diesem kurzen Video auf YouTube dargestellt. Dort ist zu sehen das ich auch dieses Mal wieder eine Lochrasterplatine verwende.
Die Spulen habe ich wie in der originalen Anleitung beschrieben von Hand gewickelt. Dazu wickelt man jeweils 0,8mm dicken Kupferlackdraht mit je 8 Windungen auf einen 6mm dicken Körper und berechnet die Länge der Spule un Abhängigkeit zur gewünschten Induktivität.


l = µ * n^2 * (A / L)

Wobei ich als Wert für µ 1nH eingesetzt habe und für L die Induktivitäten von 151nH, 143nH und 141nH eingesetzt habe.
Sofern verfügbar kann man die Abstimmung der Spulen mit einem Messgerät durchführen. Der Autor des Originalprojekts schreibt dazu jedoch dass es aber auch mit der einfachen Wicklung der Spule getan sein kann, da sie gut genug sind so wie man sie gewickelt hat.
Nun ja... lieber einmal mehr gemessen als an dieser Stelle an der Qualität der Schaltung Zeit gespart aber ohne entsprechendes Messgerät muss man hoffen das es einigermaßen passt.


Wie man im Video oben sieht wird die Schaltung per USB mit Spannung versorgt. Ausschließlich der Oszillator ist an dieser angeschlossen. Alle weiteren Bauteile der Schaltung werden nur passiv betrieben. Eine weitere Änderung in der Schaltung ist dass ich einen Schalter verwende um die Schaltung auch überbrücken zu können, also um den Eingang der Platine direkt mit der Ausgangsbuchse zu verbinden. Damit kann man auch die oberen Frequenzbänder verwenden ohne Antenne und Geräte an- und abschrauben zu müssen.

Im Video erkennt man ebenfalls das ich sehr viele Kondensatoren parallel betreibe. Das liegt daran das ich nicht alle Werte der benötigten Kondensatoren zur Hand hatte und auch nicht teuer bestellen wollte. Rechnerisch passt das soweit.

Der Schaltplan ist im folgenden Bild zu sehen, und das vollständige Projekt im GIT. Ich verwende übrigens mittlerweile KiCad für das Schaltungs- und Layout-Design.
Schaltplan
Hier noch ein Bild der fertig aufgebauten Platine von oben und unten. Gut zu sehen sind hier die oben genannten parallel geschalteten Kondensatoren und die Spulen.
Fertige UpConverter-Platine (oben)
UpConverter-Platine (unten)
Aktuell bin ich dabei die Platine in Betrieb zu nehmen. Meine letzten Aktivitäten lagen bei der Planung und beim Aufbau der Platine (siehe Oben). Momentan funktioniert die Platine nur partiell, mit einem Nachbau würde ich daher noch warten... Sobald es an dieser Stelle Neuigkeiten gibt werde ich davon berichten.

Ich möchte hier am Ende dieses Artikels noch einmal darauf hinweisen das man mit diesem Gerät nicht in der Lage ist in den Kurzwellenbereichen zu senden! Es geht hierbei rein um den Empfang und das mithören.

Wer senden möchte benötigt für das rad1o einen Transverter und die dazugehörige Amateurfunklizenz.

Freitag, 18. November 2016

Stehwellenmessgerät frei nach ZL1CVD - #SWRMeter

In diesem Beitrag geht es um ein Stehwellenmessgerät. Es handelt sich dabei - im wesentlichen - um ein ähnliches Gerät wie auch ZL1CVD in seinen Videos auf Youtube zeigt. Allerdings sehe ich es - im Vergleich zu Ihm - nicht so kritisch mit der Veröffentlichung der Software und der Hardware.
Wer das Gerät also nachbauen möchte kann dies gerne tun. Ich würde jedoch gerne um eine Rückmeldung zum Aufbau und auch die Messungen mit dem Gerät bitten. Auch Verbesserungen der Schaltung und der Software sind absolut gerne gesehen und auch erwünscht.
Es gibt neben der Umsetzung von ZL1CVD sehr viele andere Umsetzungen und Ausführungen eines solchen Messgerätes im Internet, so dass es keinen Sinn ergeben würde auch nur daran zu denken meine Arbeit zurück halten zu müssen.
Auch gibt es für einige hundert Euro kommerzielle Produkte, für beispielsweise diejenigen welche sich den Aufwand und Spaß des selbst basteln ersparen wollen.
Die Varianten für die im Internet vorhandenen Messgeräte bestehen aus verschiedenen Ausführungen, angefangen mit einem Stück Koaxialkabel und wenigen Bauteilen (einfachste Variante) bis hin zum vollautomatischen Messgerät mit Display, Mikrocontroller, Tasten und Batterie.

Was macht nun aber ein solches Gerät?

Antwort: Es liefert Informationen über die Anpassung einer Antennenanlage an einen Sender. Hierzu muss man wissen dass eine Antennenanlage an den Wellenwiderstand des Senders angepasst werden muss.
Ist sie das nicht werden die hochfrequenten Signale von der Antenne, oder auch dem Kabel in das Gerät zurück reflektiert. Man bringt also durch das aussenden von Signalen wieder Energie in den Sender ein, die eigentlich aber von der Antenne abgestrahlt werden soll.
Schlimmer noch entstehen durch diese Reflexionen im Kabel sogenannte Mantelwellen, die unerwünschte Nebenaussendungen auf anderen Frequenzen erzeugen.
Das Messgerät ermittelt nur den Grad der Anpassung für eine oder mehrere Frequenzen. In der Regel misst man mit einem solchen Gerät die Anpassung für einen ganzen Frequenzbereich.

Das Ergebniss wird dann entweder auf angeschlossenen Zeigergeräten oder wie im Fall des Messgeräts von ZL1CVD sogar auf einem kleinen Display dargestellt. Worauf ich aber aufgrund des Aufwandes der Implementierung momentan verzichte.

Was benötigt man nun also um eine solche Messung durchführen zu können?

Antwort: Eine Einheit welche in der Lage ist ein Signal in einer bestimmten Frequenz und mit einer guten Stabilität zu erzeugen. Dabei sollte die Frequenz des Signals anpassbar sein. Dann eine Messschaltung um die Reflexionen als auch das in das Antennensystem eingebrachte Signal hinreichend zu erfassen.
Und zuletzt noch eine Möglichkeit die gemessenen Daten zu erfassen, abzuspeichern oder auch weiter an einen PC zu transferieren. Alternativ einen integrierten Puffer der die Messdaten bis zum Abruf vorhält.

Auf meinem Git kann die Schaltung für das Gerät heruntergeladen werden. Eine Platine habe ich dazu nicht erstellt. Mein Aufbau befindet sich auf einer beidseitigen Lochraster-Platine. Lediglich die grundlegenden Positionen der diskret aufzubauenden Komponenten habe ich im Layout der Schaltung skizziert. Dies hilft mir beim Aufbau auf einer Lochrasterplatine ungemein.
Das folgende Bild zeigt die fertig aufgebaute Platine von oben. Das darauf folgende Bild die Platine von oben.

Platine von oben
Platine von unten
Hier ist zu sehen das ich für die Verbindungen Leiterbahnen aus Draht und Lötzinn erstellt habe und die Abstände zwischen den Bauteilen recht großzügig gestaltet habe. Für die Messbrücke (Wheatstone) habe ich möglichst genaue Bauteile (Bauteile mit geringer Toleranz) verwendet - zumindest für die verwendeten 50 Ohm Widerstände.

Die zu messenden Signale werden mittels einem LM358 um den Faktor 11 verstärkt, die gemessene Spannung also angehoben. Der LM358 ist ein Operationsverstärker welcher zwar bereits in die Jahre gekommen ist, jedoch trotzdem gute Ergebnisse liefert. Den von ZL1CVD verwendeten OPAMP erwarte ich noch per China-Mail, ich bin gespannt wie sich die Messergebnisse verändern werden.
Als Signalgenerator - welcher einen Frequenzbereich von etwa 800kHz bis 160MHz ausgeben kann - verwende ich wie auch ZL1CVD einen Si5351 Chip.
Breakoutboard Si5351
Allerdings verzichte auch auf die Erstellung einer Schaltung um den Si5351 und verwende direkt ein Breakout-Board von adafru.itDieses kann mit verschiedenen Eingangsspannungen verwendet werden und ist 5V tolerant an den I2C Eingangsleitungen. Dies ist im besonderen wichtig, da der Mikrocontroller ein Arduino Nano ist der mit 5V betrieben wird.
Die maximale Stromstärke, mit der das hochfrequente Signal aus dem Signalgenerator ausgegeben wird, liegt bei 8mA. Als Spannungsquelle wird der USB-Anschluss eines Rechners verwendet, mit dem das Gerät auch gesteuert wird.

Der Ablauf der Messung(en) erfolgt in etwa wie folgt:


Zunächst beginnt der Signalgenerator ein Signal auszusenden, getriggert durch den Arduino. Hierbei entstehen die oben beschriebenen Reflexionen, oder auch nicht. Eine Wheatstone-Messbrücke teilt die fortlaufenden und zurücklaufenden Signale auf und speist diese (gefiltert) in den Operationsverstärker, den LM358. Die Aufteilung geschieht durch die beiden in der Schaltung enthaltenen Germaniumdioden (1N60).
Der Operationsverstärker verstärkt die beiden Signale jeweils um den Faktor 11, so dass die Messwerte vom Mikrocontroller in einer für Ihn besseren Auflösung messbar werden.

Der Mikrocontroller misst - sobald der Signalgenerator sein HF-Signal aussendet - eine vom Anwender zu definierende Zeit lang die vorlaufenden und zurücklaufende Reflektionen. Genauer gesagt die Spannungen welche von Operationsverstärker ausgegeben werden.
Die Anpassung der Antenne an den Sender ermittelt man nun durch die Bildung des Verhältnisses aus den beiden Messwerten. Das VSWR ist immer größer gleich dem Wert 1, daher muss immer durch den größeren Wert geteilt werden.

VSWR = Umax / Umin

Mein SWRMeter kann, wie im Folgenden Bild zu sehen ist, bis in den VHF - Bereich, also dem 2m Band arbeiten. Der VSWR-Wert ist übrigens nicht linear, so wird bei einem VSWR von drei (Zahlenwert 3) 25% der eingebrachten Leistung reflektiert. Und bei einem Zahlenwert von 1.5, 4% und bei einem VSWR von 2 = 11%.

Der Vorgang des Messens wird dann normalerweise für einen ganzen Frequenzbereich wiederholt, so dass eine Aussage für die Anpassung eines Antennensystems auf diesen Messbereich getroffen werden kann. Das folgende Bild zeigt die Messung einer selbst gebastelten Groundplane-Antenne welche für das 2m Band und 70cm ausgelegt worden ist.
Messung 2m - Band einer Groundplane
Ein Vergleich zu anderen Messgeräten und eine Kalibrierung bleibt momentan noch aus, der Signalgenerator ist jedoch in der Lage Kalibrierungswerte anzunehmen und auch anzuwenden. Auch die Genauigkeit der Messungen werde ich bei Gelegenheit einem anderen Messgerät gegenüberstellen.

Als Interface für den Anwender verwende ich kein Display und Taster sondern die USB-Schnittstelle des verwendeten Arduino. Ich habe ein Python-Script geschrieben welches in der Lage ist alle Funktionen des Messgerätes zu bedienen zu können.
Es können Messungen über Frequenzbereiche definiert und durchgeführt, Standard-Einstellungen gespeichert, die Signal-Ausgabestärke in mA gesetzt und die drei Ausgabekanäle des Breakoutboards separat angesteuert werden. 

Mögliche Script-Parameter
Weiter gibt das Script wenn erwünscht eine grafische Darstellung der Messung und oder auch eine CSV-Datei aus. Die grafische Darstellung wird dabei zur Laufzeit der Messung aktualisiert. Wird das Script ohne die Ausgabe der grafischen Ausgabe gestartet wird lediglich ein Fortschrittsbalken auf der Konsole angezeigt.
Wer nun aber ein Problem damit hat eine Kommandozeile zu bedienen findet diverse Windows-Batch-Files und Scripte welche dazu verwendet werden können um die einzelnen Amateurfunk-Bänder scannen zu können.
Die Skripte verwenden Standard-Parameter, welche jedoch durch bearbeiten geändert werden können.

Ausgabebeispiel einer Messung
Es existiert auch ein Script über das per PIP alle benötigten Python-Module nachträglich installiert werden können. Wichtig ist nur das python 2.7.x bereits installiert ist.

Wie bereits erwähnt ist es auch möglich die drei Ausgabe-Kanäle des Signalgenerators einzeln zu aktivieren und deaktivieren, um diese auch separat verwenden zu können. Wichtig bei der Verwendung dieser ist es zu wissen das nur der Kanal "0" an der Messbrücke angeschlossen ist, dass die Ausgabefrequenz per Angabe der Start-Frequenz definiert wird, und dass die Stromstärke der sekundären Kanäle aktuell fest bei 2mA liegt.

Hier ein Video mit einer Messung:


Schlussendlich muss ich noch dazu sagen: Die dargestellten Messungen habe ich nicht selbst durchgeführt sondern mir von einem befreundeten und lizenzierten Funkamateur helfen und durchführen lassen.

Mittwoch, 2. November 2016

New look for #chinacluster monitoring UI #grafana


Das Webinterface für das Monitoring meines ChinaCluster habe ich nochmal überarbeitet. Die wichtigen Details sind nun deutlich besser zu erkennen. Zudem ist zu sehen in wie weit das neue 150 Watt Netzteil ausgelastet ist. Das vorherige hatte lediglich 60 Watt und war bei Vollauslastung des Systems bereits am Limit seiner Kräfte angelangt.

Mit dem neuen ist nun eine deutliche Reserve verfügbar und es können weitere Komponenten in das System eingebaut werden - wie zum Beispiel ein Belüftungssystem und die bereits eingebaute SSD-Festplatte.

An dieser Stelle möchte ich nochmal Aaron danke sagen der mir sehr geduldig das Gehäuse nochmal umgebaut hat um all meine Sonderwünsche umzusetzen, vielen Dank!

Mittwoch, 28. September 2016

USB serial multiplexer - #USB2SerialMux

Wieder ein neues Thema - ist bei der Verwendung meines ChinaClusters aufgekommen. Es passiert das die Node2 und Node4 nicht bei Einschaltvorgang starten. Warum ist mir momentan noch unbekannt, dem muss ich noch nachgehen. Wie stellt man das nun aber richtig an?

Jedes der OrangePi PC- und OrangePi One-Systemen besitzen jeweils über einen 3-Pin-Header an dem ein UART-Anschluss (3,3V LVTTL) mit jeweils einer Rx-/Tx und GND-Leitung ausgeführt ist. An diesem Port kann mit einer adäquaten Gegenstelle der Bootprozess des Linuxsystems, sowie den zuvor ausgegebenen Meldungen des Bootloaders etc. empfangen werden. Sollte also an einer Stelle - innerhalb der ersten Sekunden - des Bootvorgangs ein Problem auftreten kann dies dort, zumindest Theoretisch oder auch mit Glück, abgelesen werden.


Nun ist der Aufbau des Clusters aber nicht unbedingt so gestaltet dass man ohne Probleme die Hand hinein stecken kann um ein Kabel auf einen 3-Pin-Header aufstecken zu können.


Es wird also ein Kabel benötigt das dort dauerhaft angebracht bleiben kann. Nun man könnte jeweils umstecken, sollte ein Problem auftreten sein.
Da aber die Probleme nicht wiederholt sondern jeweils nur einmal ausgegeben werden, müsste man nun bei jedem Start je ein Gerät und auch nacheinander und über einen Adapter, vor dem Einschalten der Node anschließen und die BootUp-Meldungen einzeln beobachten.

Da mir persönlich aber solche wiederkehrenden und immer gleichen Aktivitäten furchtbar großen Spaß machen, kam mir die passende Idee.

Ich benötige nicht nur eine Möglichkeit mit der die UART-Verbindungen der Embedded-Systemen einzeln aus dem Cluster-Gehäuse heraus verfügbar zu machen, sondern auch gleich intern automatisch mitloggt und für einen späteren Zeitpunkt zur verfügbar stellt.

Nun soll dabei das zuverlässigste Teil im Cluster der Master sein, welcher im idealen Fall nicht beobachten muss. Das definiere ich mal so, unabhängig davon ob der Cubietruck tatsächlich das stabilste System ist in dem Rechner-Verbund.

Da dieser aber nicht über die benötigten sechs U(S)ART-Eingänge verfügt, muss auch hier noch eine Lösung gefunden werden.
Man könnte nun sechs USB zu UART-Wandler kaufen und diese mittels einem USB-Hub an den Master anschließen was aber leider nur zu noch mehr Kabel im Gehäuse führt und ich absolut vermeiden möchte (man denke an den Platzmangel).

Die nächste Alternative, welche mir sehr schnell in den Sinn gekommen ist, ist eine Art Multiplexer für UART zu benutzen. Also ein Gerät dass in der Lage ist zwischen mehreren U(S)ART-Leitungen umzuschalten oder parallel puffern zu können.
Die Letztere Variante bedeutet jedoch deutlich mehr Aufwand bei der Umsetzung und beide Varianten sind am Markt schlicht nicht verfügbar.

Der nächste Schritt ist es nun also gewesen eine Elektronik zu entwerfen die in der Lage ist den eben genannten ersten Fall umzusetzen. Ein Gerät das in der Lage ist zwischen mehreren U(S)ART-Schnittstellen umzuschalten und am besten gleich noch mit integrierter USB-Schnittstelle, über die das System auch steuerbar ist.

Dabei herausgekommen ist meine USB2SerialMux - Schaltung. Auf diesem befindet sich ein AVR ATMega32U4 Mikrocontroller von ATmel, ein Spannungsregler, diverse Kondensatoren, LEDs und zwei HCT7451 8-Kanal Multiplexer.
Die Multiplexer sind jeweils mit acht Pins einer Pinheader-Reihe verbunden, eine weitere Reihe von 8 Pins ist für den GND-Anschluss vorhanden.
Einer der Muxe ist mit der USART-RX-Leitung des Mikrocontrollers verbunden und der andere Mux mit der TX-Leitung des AVR.
Weiter sind die beiden Multiplexer jeweils parallel mit insgesamt drei Steuerleitung des AVR verbunden. Damit sind die 8 Steuerleitungen der Muxe einzeln auswählbar.


Auf der ersten Version der Platine ergaben sich trotz der einfachen Schaltung ein paar grobe Fehler welche vermieden hätten werden können. So hatte ich schlichtweg den ISP-Header nicht eingeplant, die Ground-Leitungen des AVR gar-nicht erst verbunden und an dern Multiplexern einen weiteren Spannungs-definierenden Eingang mit VCC statt GND verbunden.
Diese Fehler waren jedoch schnell korrigiert, das Ergebnis kann sich trotzdem sehen lassen.

Auf dem neuen Layout der Platine sind diese Fehler natürlich allesamt behoben. Weiter habe ich diverse optionale Widerstände verschiedene Leitungen eingeführt um die Multiplexer ggfls. etwas schützen zu können.

Die Software des Mikrocontrollers besteht im wesentlichen aus einem LUFA Dual VirtualSerial Demo-Programm, welches ich so angepasst habe dass man auf dem einen virtuellen seriellen Port die empfangenen Daten meiner Nodes sehen kann, und auf einem zweiten seriellen Port mittels Steuerkommandos den Multiplexer-Kanal auswählen und die benötigte Baudrate festlegen kann.

Da die Bedienung per Terminal-Programm und der Verwendung eines binären Kommunikationsprotokolls - welches ich dazu implementiert habe - jedoch nicht ganz komfortabel ist, habe ich zudem ein Python-Script geschrieben mit dem die Einstellungen problemlos per Kommandozeile vorgenommen werden können.
Der findige Windows-Anwender kann sich die entsprechenden Script-Aufrufe natürlich auch in verschiedenen Batch-Files per Klick verfügbar machen. Hier die Ausgabe der verfügbaren Parameter:


Wie im vorhergegangenen Screenshot zu sehen ist kann mittels diesem Script die Baudrate der Verbindung zu den angeschlossenen Systemen verändert werden, sowie die aktuell zu verbindende Multiplexer-"Leitung" gesetzt und jeweils ausgelesen werden. Damit sind auch unterschiedliche Baudraten möglich, indem man vor dem umschalten bereits die Baudrate auf die benötigte umstellt.

Für den Cluster bedeutet dies nun das lediglich die sechs 3-Pin-Header mit der USB2SerialMux - Platine verbunden werden müssen und diese dann mit dem Cluster-Master. Und dieser kann dann mit Hilfe von verschiedenen Tools - zeit-gesteuert ab dem Zeitpunkt des Einschaltens der ersten Node - durch die einzelnen Kanäle des Multiplexers schalten und die empfangenen Daten entsprechend für die spätere Verwendung loggen. Auch hierzu existiert bereits ein kleines Shellscript welches ebenfalls im Tools-Ordner im Repository liegt. 

Das Projekt ist wie gewohnt auf git.okoyono.de verfügbar. Ebenfalls ist die aktuelle Version des benötigten des Bootloaders verfügbar und diverse Screenshots wie die Fuses des AVR über den ISP-Header gesetzt werden müssen, NACHDEM der neue Bootloader per ISP auf den AVR übertragen worden ist.

Die Platinen können direkt von OSHPark bestellt werden. Eine Liste der benötigten Bauteile kann dem Schaltplan (KiCAD) entnommen werden.

Hier noch ein Bild der fertigen Platine in der ersten Version, mit den oben genannten Korrekturen...



Und hier noch eine 3D-Darstellung der aktuellen Version v0.2, welche bei OSHPark bestellt werden kann.


Eine fertig aufgebaute Version inklusive aller Bauteile und deren Aufbau und Test kann ich aus zeitlichen Gründen leider nicht anbieten.

Montag, 11. Juli 2016

#ChinaCluster impressions

Die neue Frontplatte im schlichten Aluminium-Lochblech, mit dem 2.2" TFT, drei Tastern und zwei USB- und einem HDMI-Anschluss. Das lila Leuchte ist eine Kombination der roten Power-LEDs und der ultra-hellen blauen LED des eingebauten USB-Hubs.


Hier nochmal deutlich heller aufgenommen.


In der Rückwand sind zwei Ethernet-Anschlüsse eingebettet. Einer führt auf den Cubietruck und der zweite direkt auf den internen Netzwerk-Switch.


In meinem vorherigen Post habe ich  über die Strommessung geschrieben. Der neu montierte OrangePi One (mit der rot leuchtenden LED) fungiert als Datenbank-Server.


Hier eine Übersicht über alle Messdaten die per Grafana dargestellt werden, damit entgeht einem keine Auffälligkeit.


Im dunkeln entfaltet sich dann ein ganz andere Atmosphäre.



Da Aaron mit ja ein schickes Gehäuse für den Cluster baut, benötige ich einige Adapterplatinen. Unter anderem habe ich einen um den HDMI-Anschluss des Cubietrucks nach außen an der Gehäuse zu führen. Leider ergaben sich dabei kleinere Störungen die ich aber mit ein klein wenig Aluminiumfolie beheben konnte.


Dienstag, 28. Juni 2016

ChinaCluster - Strom messen

Aus reinem Interesse habe ich von einer weile beschlossen den Stromverbrauch zu messen. Und da ich vor einigen Jahren, während meines Studiums, bereits solche Messungen an E-Bikes mittels eigens entwickelter Hardware durchgeführt habe, konnte ich mir die Suche nach einer brauchbaren Lösung ersparen.

Meine Umsetzung basiert dabei auf der Verwendung eines Messwiderstandes in Verbindung mit einem 'Current Shunt Monitor' und einem Mikrocontroller. 

Und da ich noch ein paar Arduino Nano hier herumliegen habe wird es einer von diesen werden. Das folgende Bild zeigt den aktuellen Aufbau.

Arduino Nano und Shunt Monitor

Das Prinzip hinter meiner umgesetzten Strommessung ist folgendes:
Ein Messwiderstand wird in die Zuleitung zwischen dem Netzteil des ChinaCluster und den restlichen Komponenten gebaut. In die 'plus'-Leitung. Wer im Physik-Unterricht aufgepasst hat weiß nun das an diesem eine Spannung anliegt, die in Abhängigkeit zum Widerstand und Strom steht. Also U=R*I, was dem Ohmschen Gesetzt entspricht. Mann kann also die Spannung einfach messen und über das Ohmsche Gesetz den aktuell fließenden Strom berechnen, sofern man den Widerstandswert weiß.


Skizze mit Shunt, Stromquelle und Verbraucher

Ein wichtiger Punkt, bei dieser Art der Messung, ist dabei jedoch folgender: Je höher der Wert des Messwiderstandes ist, desto höher ist auch die an diesem anliegende Spannung. Und genau die an diesem anliegende Spannung fehlt dann an den restlichen Komponenten des Clusters.

Vorstellen kann man sich das wie eine einfache Reihenschaltung, einen Spannungsteiler. Am Messwiderstand liegt die Spannung Us=Rs*I an. Der Strom I ist in der Reihenschaltung immer gleich. Und die Spannung an den Verbrauchern ist dann Uverb=5V-Us. Das Verhältnis der Aufteilung hängt letztlich vom Verhältnis des Messwiderstandes zum Widerstand der restlichen Verbraucher ab.
Und da die restlichen Verbraucher aber - beim ChinaCluster allesamt eine recht stabile und genaue 5V Spannung benötigen ist da eigentlich kein Spielraum für den Messwiderstand, oder?

Doch der ist da, jedoch nicht im Volt-Bereich, sondern eher im Millivolt- oder Mikrovolt-Bereich. Das bedeutet also das man sinnvollerweise einen Widerstand wählt der deutlich unter einem Ohm liegt.

Das Ohmsche Gesetzt kann einem helfen da einen Überblick zu bekommen wie Groß denn der Widerstand sein darf, damit die benötigten 5V an den Verbrauchern möglichst wenig verringert wird.

Beispiel:

Rs = 0.001185 Ohm
I = 2 Ampere
Us = 0.001185 Ohm *2 Ampere = 0,00237 Volt

Damit würden bei diesem Widerstand lediglich 0,00237 Volt von den benötigten 5V am den Verbrauchern fehlen, was etwa den Wert 4,99V ergibt. Also eine minimale Veränderung mit der man leben kann.

Leider besteht an dieser Stelle jedoch ein weiteres Problem. Der Mikrocontroller muss über seinen eingebauten ADC (Analog Digital Comparator) diese Spannung messen.

Und ein zweites Problem haben wir uns damit auch noch auferlegt, ohne es bis jetzt zu merken. Woher bekommt man einen Widerstand von beispielsweise  0.001185 Ohm? Bei diversen Online-Händlern kann man verschiedene kaufen, um die 1Ohm und kleiner. Diese sind jedoch meist sehr teuer und nicht immer in vielen verschiedenen Größen verfügbar.

Das gute ist jedoch das man so einen Messwiderstand ganz einfach selbst machen kann. Je nachdem wie hoch die Spannung ist, welche das Netzteil liefert und wie hoch der maximale Strom ist der durch den Widerstand Fliesen soll ist, kann man auch einfach ein kurzes und dickes Stück Draht nehmen. In meinem Fall des ChinaCluster ist es ein Stück 1,5qmm isolierte Flexleitung, die für 230V Wechselspannung ausgelegt ist. Die Länge beträgt etwa 6,5cm, was über Umwege gemessen einen Widerstand von etwa 0.001185 Ohm ergibt.

Der Shunt - Das blaue Kabel
An diesem Punkt muss ich jedoch zugeben das meine Messung fehlerhaft sein kann. Gegebenenfalls werde ich an dieser Stelle den Widerstandswert noch korrigieren und beschreiben wie man den Wert genau ermitteln kann. Im Moment reicht mir persönlich diese Annäherung an den korrekten Widerstand jedoch aus.

Meine Bessung basiert darauf mit einem Multimeter und einem Oszilloskop den Wert indirekt zu ermitteln. Das Oszilloskop hat dabei die Spannung am den Messwiderstand gemessen und das Multimeter den aktuell fließenden Strom. Der Widerstandswert kann so relativ genau ermittelt werden indem man das Ohmsche Gesetzt anwendet.

Damit hätten wir nun das zweite Problem gelöst und stehen noch vor dem ersten, dass der Mikrocontroller per ADC die Spannung am Shunt - wie man den Messwiderstand auch oft nennt - messen soll.

Hierzu muss man jedoch zunächst grob verstehen was der ADC eigentlich tut. Er wandelt einen Spannungswert einer Quelle in einen Zahlenwert um. Der Zahlenwert ist dabei jedoch nicht identisch mit dem der anliegenden Spannung. Der ADC wird also nicht den Wert 4,5 liefern wenn die angelegte Spannung 4,5V entspricht.
Die Werte welche ausgegeben werden bewegen sich in einem definierten Wertebereich. Im Fall von meinem Mikrocontroller im Bereich von 0 bis 1023, man spricht hierbei auch von einer 10Bit Auflösung (2^10 -1).
Zudem gibt es oft die Möglichkeit eine Referenzspannung festzulegen. In meinem Fall habe ich eine externe Spannung von 3,3V gewählt. Hierbei gibt es einige Regeln wie hoch diese maximal sein kann, woher diese kommt usw. aber das soll hier nicht das Thema sein. Wichtig an dieser Stelle ist für uns nur das eine Spannung von 3,3 V dem Zahlenwert 1023 entspricht und 0V dem Zahlenwert 0.

Rechnen wir uns nun aus welche Spannung maximal an unserem 0.001185 Ohm Shunt anliegt:

U = Rs * Imax = 0.001185 Ohm * 12 A = 0,01422 V

Jetzt sind 0,01422 Volt drastisch viel kleiner als 3,3V. Und die 3,3V Referenzspannung dividiert durch die Auflösung des ADC, von 10 Bit, ergibt einen Spanungshub von 0,00322265625V pro Count. Man kann also sagen dass jedes Mal wenn die gemessene Spannung am Shunt um etwa 0,0032...V erhöht wird der ADC den Ausgabewert um den Zahlenwert (Count) von 1 erhöhen.
Im Fall von den oben berechneten 0,01422 V wird dieser also einen Count von maximal 4-5 ausgeben.
 Und das wenn der maximale Strom von 12 Ampere fließt. Wenn der ChinaCluster also im Leerlauf ist und gerade mal zwei Ampere benötigt wird der ADC eine Null ausgeben, da für diesen die Spannung einfach zu klein ist.

Oben habe ich bereits beschrieben das ich einen Current Shunt Monitor zur Messung verwende. Im Grunde kann man sich das als einen Verstärker oder Multiplikatoren vorstellen.
Dieser bekommt eine Eingangsspannung angelegt und liefert an dessen Ausgang eine um einen Faktor erhöhte Spannung. Der Faktor ist bei meinem Bauteil fest vorgegeben, es handelt sich dabei um den Faktor 50, da ich einen INA194 von Texas Instruments verwende.

Mit diesem kleinen Trick bringen wir den Spannungsbereich von 0,01422 V maximal auf das fünfzigfache davon, also etwa 0,7 V. Das ist zwar immer noch nicht hoch, aber besser als zuvor. Damit würden die 12 Ampere die das Netzteil maximal liefern kann als Zahlenwert vom ADC etwa der Zahl 217 entsprechen. Im Vergleich zu dem Wert 4-5 ist das eine deutliche Verbesserung.

An dieser Stelle möchte ich nochmals darauf hinweisen das sich hierbei an einigen Stellen der Berechnungen und Messungen Fehler in der Genauigkeit einschleichen. Für mich sind diese akzeptabel, da ich lediglich einen Groben Wert in eine Datenbank logge und mir daraus nur einen Grafen anzeigen lasse. In diesem Grafen ist nicht genau ersichtlich wie der exakte Wert ist, wichtig ist mir dabei nur das sich die Auslastung meines Netzteils in definierten Bereich bewegt.

Grafana Strom-Kurve

Um mehr Detailschärfe bei der Strommessung zu erhalten kann man zum einen eine kleinere Referenzspannung verwenden, die deutlich näher an der maximal zu messenden liegt. Sofern der Mikrocontroller dies zulässt. Oder man verwendet einen anderen Current Shunt Monitor mit einem höheren Multiplikator. Alternativ kann man sich auch mit einem OPAMP einen Spannungsfolger basteln und diesen auf einen exakt berechneten Faktor einstellen. Dies hat dann einige Vor- und Nachteile auf die ich jedoch hier nicht eingehen möchte.

Schlussendlich bleibt zuletzt, nachdem nun alle Probleme gelöst sind, nur noch die Werte des ADC wieder in den fließenden Strom umzurechnen.

I = Ushunt / Rshunt wobei Ushunt = Uadc / 50

Dieses Bild zeigt eine Liste von Messwerten des Mikrocontrolles, als Hex und Dezimalzahl, deren Umrechnung in die anliegende Spannung und der Umrechnung in den fließenden Strom.
Das Python-Script welches über eine Serielle-Verbindung (USB zu Seriell) die Daten von einem Arduino empfängt ist hier verfügbar. Die Firmware für den Arduino kann hier heruntergeladen werden.


Mittwoch, 22. Juni 2016

Cubietruck GPIO with python und SWIG

Um für meinen ChinaCluster diverse externe Hardware steuern und auslösen zu können benötigte ich vor einiger Zeit eine Möglichkeit auf das GPIO-Subsystem des Cubitrucks zugreifen zu können. Dieser ist das Master-System im Cluster.

Für die Implementierung von Software in C/C++ sind die beiden folgenden Quellen die grundlegenden Informationen zum Ziel. Das allgemeine Cubietruck Tutorial und das Cubieboard GPIO tutorial. Ich jedoch würde gerne per Python - und das ohne möglichst alles neu implementieren zu müssen - auf das GPIO-System zugreifen.

Theoretisch gibt es bereits ein WiringCB-Projekt, welches theoretisch ein GPIO-Interface für Cubieboards bereitstellen sollte, in meinem Fall funktionierte dies jedenfalls in keinem meiner Tests.

Was tun also wenn es keine adäquate Lösung gibt? Selbst umsetzen. Daher habe ich hier bereits ein Repository eingerichtet mit dem per Python auf das GPIO-Subsystem - zumindeste meines Cubitrucks - zugegriffen werden kann.

Letztendlich basiert diese Lösung darauf das ich um die C-Implementierung von Stefan Mavrodiev einen Python-Wrapper gelegt habe. Der gängige Weg ist dabei wohl diesen mittels SWIG, unter Zuhilfename eines .i-Files in dem alle zu exportieren Elemente aus der ursprünglichen Library aufgelistet bzw. definiert werden, den Wrapper automatisch generieren und kompilieren zu lassen. Wichtig ist hierbei ein Setup-File manuell erzeugt zu haben in dem die Eigenschaften der neuen GPIO-Library definiert sind. Das Repository beinhaltet eine sehr übersichtliche Umsetzung und kann so ggfls. theoretisch als Beispiel dienen.

Spezielle Software-Pakete habe ich auf dem Armbian des Cubitrucks nicht installiert. Lediglich Python, pypy swig und make und der gcc sollten installiert sein.

Meine Software kann simpel mittels make durchgeführt werden. Achtung, es wird jeweils die Python und pypy-Version der Library kompiliert. Benötigt man beispielsweise die Python-Version kann man diese Zeile einfach im Makefile auskommentieren. Hat man make als normaler User ausgeführt und bereits ausreichend Rechte auf das GPIO-Subsystem wird zudem der automatisch ausgeführte Library-Test ohne Fehlermeldungen ausgeführt. Ansonsten bleibt einem nur der Weg über den User root.

Dienstag, 21. Juni 2016

Genetische Algorithmen und OpenMPI

Dinge die passieren - einen aber ärgerlich stimmen - wie zum Beispiel das ich diesen Artikel bereits geschrieben hatte und ich ihn nun komplett schreiben muss, da die Datei in der er stand leider bei einem unerwarteten Zwangs-Reset meines Rechners verloren ging.

In dem verlorenen Artikel hatte ich darüber geschrieben das es etwas wie genetische Algorithmen gibt, welche dazu herangezogen werden könne Probleme zu lösen für die man z.B. keinen Lösungsansatz besitzt aber das Ziel kennt. Außerdem habe ich über Affen geschrieben die auf Schreibmaschinen tippen und per Evolution in der Lage wären einen Text wie Shakespeares Sommernachtstraum zu schreiben. Bei diesem so genannten Infinite-Monkey-Theorem kann mathematisch, auch ohne Evolution, bereits bewiesen werden das dies möglich ist. Die Evolution soll dabei nur den Fortschritt unterstützen. Diese Aufgabe ist in Etwa gleichzustellen wie ein erstes "Hello World" bei der Verwendung einer neuen Programmiersprache. Aber vielleicht auch ein klein wenig aufwändiger umzusetzen.

Schlussendlich, mal von den ganzen Affen abgesehen, wollte ich nur darüber berichten das ich nun endlich für meinen Cluster eine Software geschrieben habe die alle Elemente des Systems einmal gründlich ausnutzt. Also das Netzwerk, die 20 Prozessor-Cores der OrangePis und auch den RAM gut ausgelastet.

Die Programmiersprache meiner Wahl bei der Umsetzung ist in diesem Fall python - bzw. pypy - in Verbindung mit MPI4PY und OpenMPI. Die Laufzeit ist durch die Verwendung von pypy deutlich reduziert und durch die Möglichkeit der verteilten Berechnungen und Aktivitäten, welche per OpenMPI ermöglicht werden, kann diese weiter reduziert werden. Leider musste ich bei meinen Tests feststellen das mein Notebook mit dem Intel i7 Quadcore - Prozessor der 16GB RAM zur Verfügung hat immer noch schneller ist als der Cluster - aber schnelle und Moderne Hardware kaufen kann ja jeder.

Mein Script ist unterteilt in zwei Bestandteile, einen generischen Teil der für die Ausführung des genetischen Algorithmus zuständig ist und einem ausführenden Hauptteil der unter anderem für MPI zuständig ist. Weiter gibt es seit kurzem einen weiteren generischen Teil welcher den Aufwand der MPI-Kommunikation (welche per SSH realisiert ist) dadurch reduziert indem ein Node-lokales Multiprozessing verwendet wird.

Der Grundlegende Ablauf bei einem solchen genetischen Algorithmus ist immer gleich. Zunächst wird eine initiale Population von DNA-Elementen erzeugt, auf diese einzelnen DNA-Stränge dann eine Fitness-Funktion angewandt, daraufhin aus den besten n-Stück und durch Rekombination eine neue Population (Generation) erzeugt und schlussendlich Mutationen in dieser neuen Population erzeugt. Danach wird der Vorgang beim ausführen der Fitness-Funktion neu begonnen und fortgefahren bis entweder im Idealfall eine Lösung ermittelt worden ist, oder eben eine maximale Anzahl von Versuchen den Vorgang beendet.

Da es genug Tutorials, Beispiele und Quellen zu finden gibt verzichte ich hier auf weitere Details zu meiner Implementierung. Es war eben auch nur ein Test um die Funktionalität des Clusters zu verifizieren. Die Performance kann in dieser Software an einigen Stellen optimiert werden.

So ist die Verwendung der Sprache Python und des pypy-Interpreters sicher nicht performanter als wenn man eine Hochsprache wie C oder C++ verwenden würde. Weiterhin ist ein häufiges austauschen von Daten zwischen den Nodes und des Masters per SSH, unter Berücksichtigung das es sich bei meiner Hardware um Embeddedsystems handelt, vielleicht auch eher ein Flaschenhals. Ebenso wie das 100MBit Netzwerk, aber um die Hardware geht es hier nicht. Weiterhin wird in meiner generalisierten Implementierung des Multiprocessings für jede anstehende Berechnung einer oder mehrere Prozesse neu gestartet und diese daraufhin wieder beendet, was weiteren Overhead auf der CPU erzeugt den man durch geschickte Verwendung eines anderen Prozessschemas verringern könnte.
Auch die Implementierung der Datenstrukturen in Python-spezifischen Datentypen wie Listen und Dictionaries anstatt der Verwendung von numpy wirkt sich vermutlich nicht positiv auf die Performance aus.

Hierbei muss man sich in jedem Fall vermutlich selbst für sich überlegen ob es einen Sinn ergibt seine Software im Nachhinein zu optimieren oder gleich von Anfang an die Beste der Besten der Besten Verfahren, Datenstrukturen und Soft- und Hardwarekomponenten verwendet. In meinem Fall würde ich noch hinzufügen - Hauptsache es macht Spaß und es gibt neues zu entdecken.

Insgesamt bin ich dennoch zufrieden, da der Cluster bewiesen hatte das er zuverlässig, auch unter Volllast mit einem System-Load von 8 (bei 4 CPU-Cores) und mehr trotzdem weiterhin korrekt Arbeitet.