3D Drucker der zweite Akt

Ein paar Drucke sind erfolgreich beendet worden, es sind sogar ein paar brauchbare Sachen dabei herausgekommen. Aber was wäre denn ein RepRap, wenn er nicht direkt mit besseren Teilen erweitert wird. Wie im ersten Bericht schon beschrieben sind die Zahnräder für die Z-Achse bereits ersetzt. Heute habe ich das Flachbandkabel für das beheizte Druckbett mit einem 1,5 mm² Kabel ersetzt. Das ist jetzt wesentlich leichter zu verlegen und blockiert nicht die komplette Steuerplatine. Weiterhin habe ich das Netzteil so angeschlossen, dass ich über G-Code Befehle die 12V Steuerspannung zu und abschalten kann. Das benötigt allerdings eine angepasste Firmware. Ich habe es heute mit der Version von dc42 versucht. Die bringt auch gleich eine neue Weboberfläche mit. Somit ist jetzt lediglich die Logik mit dem Standbystrom des Netzteil verbunden und bei bedarf wird die komplette Energie des Netzteils hinzugeschaltet.

Ormerod 1 mit erhöhtem Druckbett und neuem Kabelbaum für den Heizer

Das Software update hat allerdings auch seine Nachteile mit sich gebracht. Einmal führte es dazu, dass der X-Achsen Motor falsch herum angesteuert wurde. Im Nachhinein sind jetzt alle Achsenmotoren gleich angeschlossen und es funktioniert wieder. Ein weiteres Problem, das leider weiterhin besteht ist, dass der Vorgang des Nullens der Z-Achse das Koordinatensystem verschiebt. Und das führt dazu, dass die Punkte für den automatischen Bettabgleich nicht mehr an den ursprünglichen Punkten zu finden sind. Ich hatte aber heute keine Zeit mehr die Punkte anzupassen und zu testen, ob ich mit neuen Referenzpunkten auf ein annehmbares Ergebnis komme. Laut dc42 liegt dieser Fehler an einem Bug in der RepRapPro Firmware, die auch in sinem Fork nicht behoben wurde. Der Bug tritt auf, wenn Achsenkompensation verwendet wird. Eine weitere Untersuchung folgt. Update: Die heute erschienene Version 0.78t zeigt dieses Verhalten nicht mehr.

Geplant sind weitere Erweiterungen, wie ein Schwingungsdämpfer, sowie ein Schutz für den Lüfter. Auch werde ich auf lange Sicht den optischen Sensor gegen einen kapazitiven tauschen, ich habe nämlich heute einige Tests gemacht, die sehr vielversprechend auf die Reproduzierbarkeit der Ergebnisse gelaufen sind. Das Problem des optischen Sensors ist, neben der Empfindlichkeit gegenüber Tageslicht, die ungleichen Refektionseigenschaften der unterschiedlichen Tastpunkte. Mit dem kapazitiven Sensor habe ich an zwei unterschiedlichen Stellen den Nullpunkt einwandfrei bestimmen können.

Ein weiterer geplanter Umbau ist die Neustrukturierung des X-Auslegers. Dort wird im Moment eine M5 Gewindestange verwendet um den Arm nach obern und unten zu verfahren. Ich habe mir überlegt die vorhandenen Kunststoffteile so neu zu drucken, dass die Kraft nicht mehr von der Seite, sondern zwischen Führungslinie und Biegekraft liegt, also auf einer Achse mit dem Ausleger. Außerdem soll die M5 Spindel gegen eine stabilere und spielfreie Tr10x2 Trapezspindel getaucht werden. Der Motor wird auch nicht über Zahnräder die Achse antreiben, sondern direkt über eine Kupplung. Dieser Umbau benötigt allerdings einen funktionierenden Drucker, also erst einmal die Fehler der Achsenkompensation auftreiben und eliminieren.

3D Drucker Ahoy!

Ich habe mir vor einigen Tagen ein RepRap Ormerod Bausatz gekauft. Das Aufbauen war nicht sonderlich schwer und die Verkabelung ebenfalls sehr einfach. Innerhalb von 6 Stunden stand der Drucker komplett zusammengebaut auf dem Tisch. Probleme gab es dann beim Einstellen der Software. Die Kommunikationsschnittstelle mit dem Board ist nicht sonderlich stabil. Teilweise gehen Nachrichten verloren und so sind die ersten Tests nicht sonderlich viel versprechend gewesen. Die Elektronik dann aber vom 5V Pfad des Netzteils zu betreiben und die 12V lediglich für Heizung und Motoren zu verwenden hat die Stabilität wieder zurück gebracht. Das nächste Problem, das konstant aufgetreten ist, hat mit dem Infrarot-Sensor der Z-Achse zu tun. Die Z-Achse soll Berührungslos genullt werden. Dazu befindet sich an einer bestimmten Stelle eine weiße Fläche auf der Druckplatte. Der Sensor wird von oben zu dieser Fläche bewegt und die reflektierte IR-Strahlung wird registriert. Daraus ergibt sich für ein knappen Berühren der Oberfläche mit dem Druckkopf ein Wert von ungefähr 980 mit einem Rauschen im bereich von +- 3. Dabei sitzt der Sensor ca. 2 mm über dem Druckbett. Wenn der Druckkopf ein Zehntel Millimeter weiter hochgefahren wird, sinkt der Wert um ungefähr 2, was bei dem vorherrschenden Signal-Rausch-Abstand keine gut detektierbare Messwertänderung ist. Die Sensitivität des Sensors ist im Abstand von 4 mm am größten. Da werden dann Messwerte im Berich 650 generiert die pro Zehntel Millimeter um 10 bis 15 abnehmen. In diesem Bereich kann dann mit dem vorherrschenden Offset genullt werden. Interessanterweise ist der Wert des Sensors aber abhängig von welcher Richtung man auf die Stelle fährt. Wenn der Sensorkopf von untern, also von hohen Sensorwerten auf die Stelle gefahren wird, zeiugt er einen höheren Wert an, als wenn er von oben auf die gleiche Stelle gefahren wird. Dieses Verhalten hat zu einigen Abdrücken im Druckbett geführt. Ich habe es jetzt zumindest reproduzierbar hinbekommen. Die Nulk-Funktion der X-Achse liefert immer wieder den gleichen Punkt über dem Druckbett. Allerdings 0,5 mm zu hoch. Diese waren so reproduzierbar, dass ich mir nicht die Mühe gemacht habe herauszufinden weshalb. Sogar die automatische Druckbettabgleichung funktioniert mit diesem Offset jetzt auch einwandfrei.

RepRapPro Ormerod mit Tower of Pi

Eine Bewertung zum Ormerod und weitere Baudetails spare ich mir an dieser Stelle. Es gibt genügend davon im Internet zu finden. [0] [1] [2] Allerdings werde ich in der Nächsten Zeit einige Veränderungen an dem Drucker vornehmen. Darunter fällt das Auswechseln der Zahnräder, sowie der Gewindestange, die hat nämlich eine leichte Biegung. Auch der Druckbettschlitten wird ersetzt, sobald ich die Achsen kalibriert habe.

Links: Originale Zahnräder für die Z-Achse
Rechts: Neue Zahnräder mit Pfeilverzahung für mehr Laufruhe und Stabilität

Wie in den Bildern nicht unbedingt sichtbar ist, sind die Zahnräder gerade verzahnt und haben auf Grund der Fertigungstoleranzen der gedruckten Bauteile teilweise sehr große Reibungskräfte, wenn man sie unglücklich kombiniert. Die Teile auf der rechten Seite werden die Ersatzteile für die Zahnräder sein. Allerdings laufen die gerade relativ gut und ich werde die neue Gewindestange für die neuen Zahnräder verwenden. Erstaunlicherweise sind die Drucke so präzise, dass es bis auf die Kante der ersten Schicht keine Nachbearbeitung der Teile benötigt. Und das waren eine der ersten Drucke ohne Kalibrierung der Achsenlänge und der Winkel.

Pläne für den nächsten 3D Drucker stehen schon, denn jetzt kann ich mir den selbst drucken.

Dual-Energy Radiographie

Grundlagen

Die Möglichkeiten verschiedene Gewebedichten in Röntgenstrahlung darzustellen sind begrenzt. Knochen haben eine wesentlich höhere Dichte als Gewebe. Das führt bei Röntgenaufnahmen zum Abdecken von Gewebeinformationen. Eine Methode diese Informationen zu erhalten ist, die Knochenstrukturen in Röntgenaufnahmen zu isolieren und zu subtrahieren. Diese Technik wird Dual-Energy Radiologie genannt, da zwei Aufnahmen mit unterschiedlicher Strahlungsenergie dafür benötigt werden. Eine Aufnahme mit geringer Energie bildet Gewebestrukturen und Knochen ab. Eine zweite Aufnahme mit höherer Energie bildet nur Knochenstrukturen ab. Mit Hilfe der Dämpfungskoeffizienten der verschiedenen Gewebe bei verschiedener Energie können die Dicken der Gewebeschichten ermittelt werden.

Dämpfungen von Knochen und Gewebe bei verschiedenen Energien [0]

Berechnung

Die Intensität einer digitalen Röntgenaufnahme wird für jedes Pixel bestimmt als:
$$ I_{lo} = \mu_{tlo} x{t} + \mu_{blo} x_{b} $$
Und
$$ I_{hi} = \mu_{thi} x{t} + \mu_{bhi} x_{b} $$
Wobei mit \(\mu_{tlo}\) der lineare Dämpfungskoeffizient der niederenergetischen Röntgenstrahlung in Gewebe , mit \(x_{t}\) die Gewebedicke, mit \mu_{blo} der lineare Dämpfungskoeffizient der Knochenstruktur bei niederenergetischen Röntgenstrahlung und mit \(x_{b}\) der Dicke der Knochenstruktur bezeichnet wird. Ebenfalls gelten diese Werte für die Hochenergetische Strahlungsaufnahme mit \(\mu_{thi}\) und \(\mu_{bhi}\) als Dämpfungskoeffizienten. Beide dieser Bilder beinhaltet Informationen über Knochendicke und Gewebedicke.

Wenn nun die gewichtete Addition beider Bilder mit dem Korrekten Faktor \(k_{lo}\) oder \(k_{hi}\) durchgeführt wird:
$$ I = k_{lo} I_{lo} + k_{hi} I_{hi} $$ (1)
Kann entweder die Kochenstruktur, oder die Gewebestruktur ausgebledet werden.
Aus (1) ergibt sich
$$ I = ( k_{lo} \mu_{tlo} + k_{hi} \mu_{thi} ) x_{t} + ( k_{lo} \mu_{blo} + k_{hi} \mu_{bhi} ) x_{b} $$
 Bei korrekter Wahl der Koeffizienten kann zum Beispiel \(x_{t} = 0\) erreicht werden und das Gewebe aus der Aufnahme ausgeblendet werden.
\( k_{lo} \mu_{tlo} + k_{hi} \mu_{thi} = 0\). Daher, \(k_{lo} \mu_{tlo} = – k_{hi} \mu_{thi}\), und
$$\frac{k_{hi}}{k_{lo}} = – \frac{\mu_{tlo}}{\mu_{thi}}$$

Dies zeigt, dass das Ausblenden der Gewebestruktur im Ergebnisbild erreicht werden kann, wenn das Verhältnis der Faktoren das negative Verhältnis von Gewebe bei beiden Strahlungsenergien ist. Gleiches gilt für das Ausblenden der Knochenstruktur.

Software

Das ganze wird nun in Software abgebildet [1]. Es stehen zwei Röntgenaufnahmen mit unterschiedlichem Energiewerten zur Verfügung. Die Aufnahmen sind im 8bit BMP Format abgespeichert. Jedes Pixel hat also einen Wert von 0 … 255. Beide Bilder werden als Bitmap-Objekt geladen:
https://gist.github.com/anonymous/d5e8d7776dc396d2b03b.js
Um auf den Speicherbereich der Bitmap-Objekte zugreifen zu dürfen, müssen diese daraufhin gesperrt werden. Mit einem direkten Zugriff auf die Speicherbereiche der beiden Bilder kann eine Schleife schneller jeden Pixelwert bearbeiten, als würde jeder Pixel einzeln geladen werden müssen.

Um die Werte abspeichern zu können steht noch ein Array mit double Werten und eins mit int Werten zur Verfügung. Der erste Schritt ist es die beiden Bilder zu addieren. Dabei werden die Pixelwerte des niederenergetischen Bildes mit dem Faktor \(k_{lo}\) multipliziert und die Werte des hochenergetischen Bildes mit \(k_{hi}\).
Anschließend wird der Minimal und Maximalwert des Ergebnisses ermittelt und die neuen Werte in das Integer-Array eingetragen.
https://gist.github.com/anonymous/c156e6ed0097feb82274.js
Das Integer-Array dient als Quelle für die Ergebnisbilddaten und nach erfolgreichem Kopieren derselben können die drei Speicherbereiche wieder freigegeben werden.

https://gist.github.com/anonymous/9f1eb25a96af15409999.js

[0] http://www.icru.org/
[1] https://github.com/DasBasti/dual-energy-imaging

PHYTEC liveDVD Installation updaten

Beim starten des Software-Centers oder des Updates kommt es zum Absturz des Programms. Das Problem sind fehlerhafte Schlüssel in apt.

Mit Hilfe von

sudo apt-get clean
sudo mv /var/lib/apt/lists /var/lib/apt/lists.old
sudo mkdir -p /var/lib/apt/lists/partial
sudo apt-get update
sudo apt-get upgrade

kann das Problem der Schlüssel gelöst werden. Sollte es bei dem letzten Befehl zu keinem Fehler kommen, kann mit

sudo rm -rf /var/lib/apt/lists.old

Die Sicherungskopie entfernt werden. Wenn es weiterhin nicht funktioniert, muss man in der Datei /etc/lsb-release der Wert von PHYliveDVD auf Ubuntu ändern.

Funkstrom? Aw Yis!

Qi Empfänger
Qi (Aussprache: [ˈt͡ʃiː]) ist chinesisch und steht für Lebensenergie. Es ist aber auch ein Standard des Wireless Power Konsortiums um drahtlose Energieübertragung durch elektromagnetische Induktion für kurze Strecken zu vereinheitlichen und kompatibel zu halten. Es gibt mittlerweile eine Vielzahl von billigen chinesischen Sende- und Empfangsgeräte, die diese Art der Energieübertragung zum Laden eines Mobiltelefons verfügbar machen, ohne dass dafür die Garantie des Handys erlischt. Diese Module gibt es in verschiedenen Ausführungen und für viele verschiedene Positionen. Wie in den Bildern zu erkennen, sind sie so aufgebaut, dass das Flachbandkabel entsprechend der Konfektion des Moduls angelötet wird. Das Basismodul mit der Sendespule verfügt über einen Micro-USB Buchse und kann somit mit den gewohnten Ladegeräten verwendet werden.


Wie beim Empfänger zu sehen ist, besteht das Modul eigentlich nur aus einem Chip, dessen Beschriftung nicht lesbar ist und einigen passiven Bauteilen. Den größten Teil nimmt die Antennenspule in Anspruch. Sie ist zwischen den beiden Klebeflächen eingeklebt und somit auch ziemlich flach. Das Löten der Steckerverbindung ist jedoch nicht ganz einfach, da die Masseverbindung direkt auf die Kupferfläche der Platine geht und so eine große Wärmemenge aufgenommen werden kann. Nach ein paar Versuchen habe ich allerdings die Lötverbindung so hinbekommen, dass der Anschluss zur Seite des Moduls richtig herum und vor allem in der richtigen Länge herausschaut. Alles wieder zusammengeklebt, auf die Rückseite meines HTC One S geklebt und auf die Basisstation damit. Siehe da, es funktioniert nicht, das Ladelicht blinkt und das Telefon lädt nicht.

Die Basisstation des Ladegerätes ist in einem rechteckigen Kunststoff Gehäuse untergebracht. Das Gehäuse an sich ist sehr leicht und es macht nicht den stabilsten Eindruck. Die Angaben in der Bedienungsanleitung sind auf Chinglish und nicht sehr hilfreich. Nur das Netzteil, das dort erwähnt wird, war nicht in der Packung. Mist. Auf der Rückseite des Tischgeräts sind neben ‚Made in China‘ die üblichen Angaben gemacht, die darauf hinweisen, wo das Problem liegen könnte. Ich habe das Ladegerät an meinem Laptop betrieben. Da kommen aus dem USB Anschluss nur 500mA Strom und somit nicht genug für dieses energiehungrige Teil. Laut USB Spezifikation ist der Maximalstrom der über einen Port kommt 500mA aber das Gerät möchte 2A Eingangsstrom sehen. Also schnell einen der nicht standardkonformen chinesischen USB-Steckdosengeräte dran und siehe da, mit genug Power geht es. Das blaue Ladelicht ist dauerhaft an und das Telefon zeigt an, dass es geladen wird.

Der Inhalt der so leichten Ladestation hat mich dann doch gewundert. Ich habe damit gerechnet, dass eine schlecht gewickelte Spule mehr schlecht als recht an eine Platine gelötet ist auf der ein Schwingkreis das Ladesignal erzeugt. Dem ist nicht ganz so.

Innenleben der Ladestation

Neben einer durchaus ansehnlichen Spule (dieser Aufbau wird auch bei uns in der Firma verwendet) die auf einer Ferrit-Platte sitzt und stabil ins Gehäuse geklebt ist befindet sich ein Board mit mehreren ICs. Der Gehäusedeckel hat an der Stelle an der die Spule sitzt sogar eine Verjüngung, sodass die elektromagnetischen Wellen nicht unnötig durch das Gehäuse gedämpft werden. Die Zentrale Steuerung des Ladegeräts dürfte wohl der Microcontroller U3 im 20 Pin Gehäuse sein.

IC U3: Der Controller?

Die Beschriftung sagt, es handelt sich um einen MSP430G2558. Allerdings hat Texas Instruments keinen MSP mit dieser Bezeichnung im Programm, der Controller, der dieser Modellnummer am nächsten kommt ist der MSP430G2553. Auch das Datenblatt des 2553 zeigt an, dass Das hier verwendete Package nicht zweizeilig, sondern einzeilig beschrieben ist. Also weiter bei Ti.com nach Informationen zu dieser Controllerfamilie gesucht und auch einiges gefunden. Der Teil ‚G2‘ steht für einen Controller aus der Value Line Familie. Aber auch hier findet sich kein Exemplar, dass mit einer 8 im Namen endet. Ich gehe davon aus, dass es sich hier um eine Kopie eines MSP430 handelt, selbst wenn dazu ein Datenblatt existiert, besteht keine Garantie, dass die dort genannten Werte eingehalten werden können.

MOSFET
Betrachten wir ein weiteren Chip auf der Baugruppe. Die Spule wird von zwei ziemlich starken MOSFETs getrieben. Die DTM4606 sind in der Lage über 5A zu steuern. Jeder Chip beinhaltet zwei dieser FETs, jeweils ein P- und ein N-Kanal. Allerdings ist der P-Kanal bei beiden nicht verbunden. Weiterhin sind pro Spulenseite 4 NPN Transistoren verbaut, von denen aus der Controller die MOSFETs steuert.

Operationsverstärker

Eine weitere sehr interessante Baugruppe ist auf der Platine zu finden. Ein vier in einem Gehäuse Operationsverstärker, was die auffallend vielen Kondensatoren und Widerständen erklärt. Es sieht so aus, als würde die Spule neben der reinen Aussendung der Energie auch noch eine Überwachung des Ladezustands durchführen. Das erklärt, weshalb das Ladegerät in der Lage ist zu erkennen, ob ein Gerät in Reichweite der Sendespule ist, aber nicht genügend Energie übertragen wird um im Empfänger einen Ladestrom zu erzeugen, wie es mit dem Betrieb am USB-Port offensichtlich der Fall war.

Statusupdate April

Lange Zeit gab es nun schon keine neuen Beiträge, das wird sich in der nächsten Zweit ändern, denn ich bin zur Zeit mit zwei sehr interessanten Projekten beschäftigt. Das erste Projekt ist die Miniaturisierung eines USB-Repeater. Dazu wird es in die Wafer Level Chip Scale Technologie, sowie in die USB2.0 Spezifikationen gehen. Das Andere Projekt hat mit kapazitiven Touchsensoren zu tun. Vor allem in Betracht auf Sicherheitsanforderungen im Bereich Medizintechnik.

Das Projekt Kaffeeautomat mit WLAN wurde beendet, leider ist die Dokumentation für die Weitergabe an Dritte gesperrt. Bei Gelegenheit werde ich die Arbeit mit einem Gerät eines anderen Herstellers noch einmal durchführen und die Dokumentation diesmal frei zur Verfügung stellen.

Weiterhin habe ich noch ein paar Ideen, die ich in den nächsten Monaten umsetzen möchte, dazu aber später mehr.

Using the ‚Console‘ to talk to the Yún MCU from Python

Playing around with the Yún led me to the problem that I had a Sketch up and running on the MCU that could be controlled from the Arduino serial console. To move the commanding part to a python script all I had to do was to do this communication from the Linux side of the Yún-Bridge system.

To initialize the Bridge all you have to do is call the Bridge.begin(); function in the setup part of the sketch. After that we initialize the Console with Console.begin(). To stop the execution of further commands we can poll the Console to become ready.
void setup() {
// put your setup code here, to run once:
Bridge.begin();
Console.begin();
while (!Console) {
;
}
}
You can now use the print functions as usual:
  if(Console.available()) {
c = Console.read();
.
.
.
}
On the Linux side we have a python script that will conncet to the bridge server and do the same as the Arduino serial console.
import telnetlib, time

tn = telnetlib.Telnet("localhost", 6571)

while True:
print "w"
tn.write("test")
print tn.read_eager()
time.sleep(1)

WLANKaffee Code Repository

Wir haben vom Hersteller der Maschine die Auflage bekommen, die Informationen nicht öffentlich zur Verfügung zu stellen. Daher wird das Projekt und der Quellcode nicht mehr zur Verfügung stehen.

Ich habe den Code für den Arduino auf einer Google Code Projektseite hochgeladen. Der Code ist teilweise ungetestet, da die Kaffeemaschine noch nicht vollständig verdrahtet ist. Diese Arbeit wir nächste Woche beendet. Der Zeitpunkt für den ersten Release ist dann auch der nächste Dienstag.
Aktuell sind für den ersten Release diese Funktionen geplant:

  • Yún
    • Arduino
      • Firmware die über die Console Klasse gesteuert werden kann.
      • Steuerung der Menüknöpfe am HID
      • Drehencoder wird ausgewertet
      • Drehencoder Impulse werden simuliert
    • Linino
      • Python mit Django
      • Webseite mit Benutzerverwaltung
      • Steuerung über Console Klasse des µController
  • Dokumentation
    • Python
      • SPI Protokoll für Display Frames

Arduino Yún, Linux mit Arduino auf einem Board

Für unsere Projektarbeit haben wir entschieden, dass ein Linux fähiges Board und ein Arduino Mikrocontroller zum Einsatz kommen soll. Um das ganze möglichst klein zu halten haben wir den Arduino Yún ausgewählt. Der Yún hat neben den Funktionen, die auch ein Leonardo mitbringt zusätzlich einen voll funktionsfähigen Computer an Board, der mit einem speziellen openWRT Distribution läuft. Das Besondere ist, dass die beiden Geräte miteinander kommunizieren können und somit beide Geräte direkt miteinander verbunden sind. Auf der Linuxseite bietet die Linino Distribution einiges an Funktionalität, wie zum Beispiel eine REST-Full API um die Pins des Arduinos direkt anzusteuern. Eine weitere großartige Funktion wird in der Bridge Bibliothek zur Verfügung gestellt. Die Kommunikation zwischen Mikrocontroller und Programmen auf der Linuxseite.

SSH Konsole des Yún mit Erweiterung für die Kaffeemaschine

In unserem Falle wird der Mikrocontroller die Ansteuerung der Kaffeemaschine übernehmen und bestenfalls den SPI Bus abhören und die übertragenen Displaydaten in einen seriellen Bytestream umwandeln. Die Linuxseite wird die komplette Benutzerschnittstelle bereitstellen, also ein Webinterface mit dem die Kaffeemaschine gesteuert werden kann. Außerdem wird die Webseite den Inhalt des Displays darstellen. Wie die Daten von der Maschine in ein Bild gewandelt werden, habe ich letzte Woche schon beschrieben.

Diese Woche habe ich mich mit dem SPI Interface beschäftigt. Die Displaydaten werden über den SPI Bus vom Benutzerpanel an den Displaycontroller gesendet. Diese Daten können vom Arduino aufgezeichnet werden. Um klein anzufangen, habe ich verschiedene Ansätze ausprobiert. Die Grundvoraussetzung war, dass der Bustakt von 1 MHz eingehalten wird. Dann werden alle 0,1 Sekunden 541 Bytes übertragen. Der genaue Aufbau des Protokolls lässt sich relativ kurz beschreiben. Zuerst bekommt das Display den Wert 0x89 übertragen. In den Datenblättern, die etwas mit dem Display zu tun haben könnten habe ich diesen Befehl leider nicht finden können. Weiter geht es mit dem Byte 0xB4 was laut Datenblatt die Speicherseite 4 als Startadresse angibt. Darauf folgen 134 Bytes mit Bilddaten, bis dann 0xB5 (page 5) übertragen und die nächste Speicherseite ausgewählt wird. Nach weitern 134 Bytes folgt 0xB6 (page 6) und nach weiteren 134 Bytes folgt 0xB7 (page 7). Die abschließende Speicherseite und somit die letzte ‚Zeile‘ des Displays hört auch hier nach genau 134 Bytes auf. Da das Display auf dem Benutzerpanel auf dem Kopf stehend eingebaut ist, sind auch die Daten ‚gekippt‘ Eine einfache Spiegelung hilft das Bild wieder sichtbar zu machen.

Der Arduino Yún

Um mit dem SPI Bus zu arbeiten, ohne die Maschine dabei zu haben, habe ich die Daten eines Frames in ein Arduino-Sketch geladen. Dieser Arduino macht nichts als ein und dasselbe Bild immer und immer wieder alle 0,1 Sekunde über den SPI Bus zu übertragen. Die nächste Aufgabe ist jetzt, die Daten mit dem Yún zu empfangen und zu verarbeiten. Da ich bis jetzt nur einen funktionierende SPI Kommunikation mit Yún als Master und einem Nano als Client zum Laufen gebracht habe, kann ich noch nicht davon berichten, in wieweit sich die Idee mit der Bildgenerierung verwirklichen lässt.

Das SPI Protokoll für das Kaffeemaschinen Display

Dieses Wochenende haben wir im Projektteam die Kommunikation vom Controller auf dem Benutzerboard zum Display genauer unter die Lupe genommen. Da wir keine genauen Informationen über die verwendeten Bauelemente hatten sind wir mit google auf die Suche nach Datenblättern von Displays ähnlicher Bauart gegangen. Die meisten Displays mit SPI Interface verstehen das gleiche Protokoll zum Setzen der Kofigurationswerte und Übertragene der Daten. Die Daten haben wir mit Hilfe des Logic Analyser ja schon das letzte mal aus der Maschine extrahiert. Nach einigen Anläufen haben wir im Datenbaltt eines Displaycontrollers (ST7565R) die Konfiguration des Display RAMs gefunden. Mit dem Wissen wie das Bild, das im Display angezeigt wird zu übertragen ist, gelang es uns den Datenstream so zu formatieren, dass wir das Bild des Displays gespiegelt auf dem Bildschirm sehen konnten. Mit ein wenig Bearbeitung der
Daten ist es gelungen das Bild, das am Display angezeigt wird zu rekonstruieren.

Der Inhalt des Datenstreams in serieller Formatierung

Datenübertragung in der Maschine

Die Maschine kommuniziert einmal mit der Steuerplatine und dann mit dem Display. Dabei ist die Verbindungsleitung zwischen den Platinen mit einem Enable
Signal verehen. Wenn dieses Signal High ist, ignoriert die Steuerplatine die Daten; wenn der Pin auf Low gelegt wird, sind die Daten am Bus für die Steuerplatine.
Vom Controller gehen, neben der Datenleitung MOSI, nicht nach Außen geführte Leitungen an das Display. Es ist also anzunehmen, dass dort auch eine Enable und/oder
Clock Leitung dabei ist. Die Daten, die über den SPI Bus bei dauerhaftem High Zustand auf Enable an der Controllerplatine gehen sind somit aller Wahrscheinlichkeit
nach an das Display gerichtet. Genauer betrachtet wurden jedes Paket 541 Bytes übertragen. Das Display hat eine Bildmatrix von 128 * 32 Pixeln, somit werden
4096 Bit zum Darstellen eines monochromen Bildes benötigt. Die übertragenen Bytes beinhalten diese Datenmenge und zusätzlich noch einige Steuerbefehle.

Das Bild steht noch auf dem Kopf und die Page-Select Befehle sind noch links sichtbar

Display RAM

Wichtig ist dabei zu beachten, dass die Pixelreihen des Display nicht wie erwartet seriell mit Daten bestückt werden, sondern der serielle Kommunikationsport nur vor den parallelen geschaltet wurde. Dadurch ergibt sich die Eigenschaft, dass die Daten ‚Zeilenweise‘ in den Speicher des Displays geladen werden. Zeilenweise
bedeutet dabei, dass der Speicher in 8 bit breite Pages eingeteilt wird. Jede Page wird zuerst ausgewählt und dann von Spalte 0 an aufgefüllt. Dadurch erscheinen die Bilddaten nicht waagerecht, sondern senktrecht und werden so zusammen gesetzt. Nachdem der Aufbau des Speichers bekannt war, konnten wir unsere Software danach ausrichten und haben den Displayinhalt ‚CAPPUCCINO‘ in den sortierten Matrxwerten erkennen können. Jede Zeile oder Page begann mit einem Page-Select Befehl, der getroßt ignoriert werden konnte. Der letzte Schritt war es, die Matrix der Bilddaten in ein PNG zu gießen um es später als Bild in einer Webseite verwenden zu können.

Die rekonstruierte Grafik des Maschinendisplays

Analyse des Protokolls zur Maschinensteuerung

Nachdem jetzt die Übertragung der Displaydaten bekannt ist, müssen noch die vorherigen 10 Bytes der Maschinensteuerung in einen Kontext gebracht werden. Mit Hilfe eines kleinen Scripts habe ich die Logic Analyser Mitschnitte in Kommando- und Bildabschnitte zerlegt. Das Bild wird generiert und die Kommandodaten werden daneben in einer Tabelle abgebildet. Jetzt müssen wir nur die passenden Befehle herausfinden. Dazu gibt es dann nächste Woche mehr.