Nachdem wir heute im Labor unsere Spuren der letzten paar Monate beseitigt haben werden wir uns jetzt der Weiterentwicklung und Fertigstellung unserer LED Matrix widmen.
Um die Verdrahtung und Fertigung deutlich zu beschleunigen wird Christian hierzu die LED Treiberplatine überarbeiten, so dass die LED Stripes direkt angelötet werden können.
Ich werde ein Layout für eine FPGA Platine mit HDMI Eingang und Ausgang für die LED Treiber erstellen. Einsetzen wollen wir einen Spartan 6, da dieser einige wichtige Bausteine die zur Verarbeitung eines HDMI Videosingals nötig sind integriert hat. Auf der Platine werden dann auch die 4 (oder mehr) ADCs platz finden. Evtl. wird die Samplerate reduziert um hier günstigere einsetzen zu können. Das müssen aber erst Versuche zeigen.
Wir hoffen, dass wir neben Masterstudium bzw. Arbeit genügend Zeit finden werden, dieses Projekt weiter zu verfolgen und dass im Laufe der Zeit noch einige weitere Projekte hinzu kommen!
Dienstag, 19. März 2013
Samstag, 16. März 2013
Und schon vorbei
So Stefan und ich hatten am Donnerstag unseren großen Tag.
Die Bachelorarbeit war gedruckt und ist gebunden und anschließend gleich abgegeben worden. Zeitgleich war der Bachelorseminarmarathon. Von 9 bis um 16:30 waren zwölf Bachelorvorträge. Unter anderem haben wir natürlich auch unser Projekt vorgestellt.
Es war recht hell in dem Vorlesungssaal, selbst bei der niedrigsten Helligkeit der LED-Treiber. Naja was soll man sagen, die Sache ist vorbei. Erfolgreich vorbei. Oder sogar sehr erfolgreich gell Stefan.
Ein kleines Gimmik, dass wir die ganze Zeit vorenthalten haben, war die Implementierung von Snake. Dies wurde von mir komplett auf dem FPGA gebastelt. Steuern lässt es sich über die Pfeiltasten, oder wem das zu konventionell ist, der stellt sich vor Stefans Mikrofone und macht n bisschen Verrenkungen um im richtigen Augenblick nach oben, links, unten oder rechts zu klatschen. In gut 95% der Fälle läuft die Schlange dann auch in die gewünschte Richtung weiter.
Hier wird jetzt allerdings keine Stille einkehren, des Ding ist zu schade ums im Schrank versauern zu lassen. Ich mach jetzt im Anschluss mit einem Master Studium weiter und Stefan geht ein bisschen Geld verdienen. Haben uns aber fest vorgenommen, zumindest einmal im Monat ein Bastelsamstag zu machen.
Wir werden also in Kürze wieder berichten.
Die Bachelorarbeit war gedruckt und ist gebunden und anschließend gleich abgegeben worden. Zeitgleich war der Bachelorseminarmarathon. Von 9 bis um 16:30 waren zwölf Bachelorvorträge. Unter anderem haben wir natürlich auch unser Projekt vorgestellt.
Es war recht hell in dem Vorlesungssaal, selbst bei der niedrigsten Helligkeit der LED-Treiber. Naja was soll man sagen, die Sache ist vorbei. Erfolgreich vorbei. Oder sogar sehr erfolgreich gell Stefan.
Ein kleines Gimmik, dass wir die ganze Zeit vorenthalten haben, war die Implementierung von Snake. Dies wurde von mir komplett auf dem FPGA gebastelt. Steuern lässt es sich über die Pfeiltasten, oder wem das zu konventionell ist, der stellt sich vor Stefans Mikrofone und macht n bisschen Verrenkungen um im richtigen Augenblick nach oben, links, unten oder rechts zu klatschen. In gut 95% der Fälle läuft die Schlange dann auch in die gewünschte Richtung weiter.
Hier wird jetzt allerdings keine Stille einkehren, des Ding ist zu schade ums im Schrank versauern zu lassen. Ich mach jetzt im Anschluss mit einem Master Studium weiter und Stefan geht ein bisschen Geld verdienen. Haben uns aber fest vorgenommen, zumindest einmal im Monat ein Bastelsamstag zu machen.
Wir werden also in Kürze wieder berichten.
Samstag, 9. März 2013
FPGA über USB/UART am Raspberry Pi
Leider konnte ich diese Woche nur am Montag an die FH, da mich eine Erkältung erwischt hatte, aber ich war Zuhause fleißig und heut waren wir bis 21 Uhr an der FH im Labor.
Das Nexys 3 Board ist nun über die USB Schnittstelle mit dem Raspberry Pi verbunden. Beim Pi meldet es sich als usb 1-1.3.4: FTDI USB Serial Device converter an und ist über ttyUSB0 ansprechbar wie eine normale serielle Schnittstelle. Hier ein kurzer prinzipieller lesender Zugriff:
Das Nexys 3 Board ist nun über die USB Schnittstelle mit dem Raspberry Pi verbunden. Beim Pi meldet es sich als usb 1-1.3.4: FTDI USB Serial Device converter an und ist über ttyUSB0 ansprechbar wie eine normale serielle Schnittstelle. Hier ein kurzer prinzipieller lesender Zugriff:
unsigned char rx_buffer[256];
int hSerial = open(„/dev/ttyUSB0“,
O_RDWR);
struct termios options;
tcgetattr(hSerial, &options);
options.c_cflag = B115200 | CS8 | CLOCAL |
CREAD;
tcflush(hSerial, TCIFLUSH);
tcsetattr(hSerial, TCSANOW, &options);
unsigned char rx_buffer[256];
rx_length = read(hSerial,
(void*)rx_buffer, 256);
Am FPGA sind 4 ADCs, die das Signal von 4 Mikrofonen die im Quadrat im Abstand von 36cm angeordnet sind mit 1MS/12Bit aufnimmt und bei einem Klatschen 3 Laufzeiten errechnet. Anschließend werden 7 Byte an das Pi übertragen. Das 1. Byte enthält das Mikrofon, auf das der Schall zuerst getroffen ist. Danach kommen je 2 Byte mit den 3 Laufzeiten. Diese Laufzeiten ergeben sich aus der Zeitdifferenz vom Eintreffen des Schalls bei den drei übrigen Mikrofonen bezogen auf das erste Mikrofon.
Am Pi wird daraus dann errechnet, wo vor dem Mikrofonquadrat geklatscht wurde. Momentan werden 9 Sektoren unterschieden: Oben links, oben mitte, oben rechts, links, mitte, rechts, unten links, unten mitte und unten rechts.
Damit lässt sich die LED Matrix eigentlich schon vollständig bedienen. Bis zu unserer Präsentation am Donnerstag will ich allerdings noch versuchen mit 4 weiteren Mikrofonen - also insgesammt 8 Mikrofonen - eine genau Berechnung der Koordinaten wo geklatscht wurde zu realisieren.
Montag, 4. März 2013
Endspurt
Guten Morgen ;)
So mir is grad als ich beim Schreiben meiner Bachelorarbeit zum Thema LED-Treiber gekommen, bin brennend heiß eingefallen, dass ich noch ein Layout der Treiberplatine hochladen wollte. Da ich mich jetzt ins Bett begeben werde, dachte ich mir lad ich das noch schnell hoch.
Morgen gehts dann in Coburg weiter. Und morgen Abend ist die Arbeit hoffentlich geschrieben. Bis dann
So mir is grad als ich beim Schreiben meiner Bachelorarbeit zum Thema LED-Treiber gekommen, bin brennend heiß eingefallen, dass ich noch ein Layout der Treiberplatine hochladen wollte. Da ich mich jetzt ins Bett begeben werde, dachte ich mir lad ich das noch schnell hoch.
Morgen gehts dann in Coburg weiter. Und morgen Abend ist die Arbeit hoffentlich geschrieben. Bis dann
Samstag, 2. März 2013
Neues Video von der LED Matrix
Diese Woche waren wir wieder fleißig und konnten die LED Matrix fertig stellen. Jetzt haben wir nur noch ein paar EMV Probleme, welche mit ein paar Kondensatoren aber sicherlich zu lösen sind.
Donnerstag stand ein Besuch bei der embedded world in Nürnberg auf dem Programm. Heute hab ich den halben Abend und die halbe Nach an meiner Bachelorarbeit geschrieben... jetzt werde ich auch gleich schlafen gehn.
Hier aber noch das Video, aufgenommen am Dienstag abend.
Momentan wird die Laufschrift einfach auf einer HTML Seite auf dem Raspberry Pi angezeigt, über HDMI ausgegeben, vom Atlysboard eingelesen und anschließden an der LED Matrix ausgegeben.
Die Steuerung des ganzen mittels Klatschgesen ist momentan noch nicht möglich, wird aber hoffentlich kommende Woche realisiert.
Fürs Wochenende steht jetzt aber erstmal hardcore-Bacheloararbeit-schreiben an ;-) gn8
Donnerstag stand ein Besuch bei der embedded world in Nürnberg auf dem Programm. Heute hab ich den halben Abend und die halbe Nach an meiner Bachelorarbeit geschrieben... jetzt werde ich auch gleich schlafen gehn.
Hier aber noch das Video, aufgenommen am Dienstag abend.
Momentan wird die Laufschrift einfach auf einer HTML Seite auf dem Raspberry Pi angezeigt, über HDMI ausgegeben, vom Atlysboard eingelesen und anschließden an der LED Matrix ausgegeben.
Die Steuerung des ganzen mittels Klatschgesen ist momentan noch nicht möglich, wird aber hoffentlich kommende Woche realisiert.
Fürs Wochenende steht jetzt aber erstmal hardcore-Bacheloararbeit-schreiben an ;-) gn8
Dienstag, 26. Februar 2013
Bilder von der Nachtschicht
Der Christian hat ja bereits von unserer Nachtschicht berichtet... hier ein paar Bilder als Zusammenfassung:
Um so lange Zeit stupides Löten durchzuhalten und bei Laune zu bleiben muss man sich natürlich erstmal stärken...
Anschließend ging es dann im Akkord los... Freundlicherweise hat uns der Fabi geholfen
Um so lange Zeit stupides Löten durchzuhalten und bei Laune zu bleiben muss man sich natürlich erstmal stärken...
Anschließend ging es dann im Akkord los... Freundlicherweise hat uns der Fabi geholfen
Wir konnten uns natürlich nicht nur flüssig ernähren:
Zwischenzeitlich hab ich auch an meiner Schallerkennung weiter gearbeitet. Hier ein Bild vom Testaufbau mit den 4 Mikrofonen im Abstand von 36cm, wie es auch später in der LED Matrix sein soll:
Um halb 11 hat dann endlich die halbe LED Matrix geleuchtet:
und 10 Stunden später warn wir dann mit dem Verdrahten endlich fertig:
Hier kann man auch die verflochtenen Masseleitungen schön sehn.
Es war eine heiden Arbeit, für den nächsten Aufbau werden wir uns wohl eine Lösung mit Leiterbahnen zum verdrahten ausdenken ;)
Montag, 25. Februar 2013
Der Aufbau ist vollendet
So eine Woche Funkstille, allerdings keine Woche Pause. Wir waren sehr fleißig in der letzten Woche.
64 Pixel x 3 Stripes x 4 Anschlussleitungen x 2 Aderenden, abschneiden, ab isolieren, durch die Löcher fädeln, den Stripe festkleben und anschließend noch die Leitungen verlöten. Eine sehr, wirklich sehr mühselige Arbeit. Gut kurz und knapp reden wir von 1536 Leitungsenden und 2 vollen Tagen Arbeit.
Zu guter Letzt mussten wir die einzelnen Farben der Pixel natürlich noch mit 12V versorgen und die geschaltene Masse auf unsere Treiberplatine führen. Wir reden wieder von Unmengen an Leitungen. Die 12V haben wir in der Reihe der Pixel durchgebrückt, was schonmal einiges an Aufwand ersparte. Mussten nur noch die 192 Massekabel bei den Treibern ankommen. Wir haben anfangs für jeweils 8 Pixel einen Zopf gepflochten aus den Leitungen um etwas Ordnung auf der Rückseite beibehalten zu können. Als wir uns dann stetig der Platine näherten, sind wir auf 4 Pixel je Zopf umgestiegen. Das bedeutete insgesamt weniger Klingelversuche um die richtige der farbigen Leitungen zu finden.
Apopros Farbcode, gelb ist für grün, weiß für rot und braun für blau. Selbsterklärend oder ;)
Dann ist uns noch ein kleines Missgeschick passiert, als wir von Donnerstag morgen bis zum Freitag mittag die Nacht über im Labor mit dem Auflegen der Treiberplatine beschäftigt waren. Da die Platine in 2 Reihen zu jeweils 6 Treibern aufgebaut ist und ich eigentlich von links nach rechts springen wollte, Stefan allerdings erst links von oben nach unten und dann rechts von oben nach unten gelötet hat, musste ich meine Ansteuerung aus dem RAM im FPGA nochmal etwas modifizieren. Naja ganz klarer Abstimmungsfehler, aber sowas passiert schon mal.
Langer Rede kurzer Sinn, ich sitze wieder im Labor und wenn der Stefan nachher kommt, werden wir euch mal ein paar Bilder hochladen. Gestern Abend hatte ich allerdings schon das erste Erfolgserlebnis zu Hause. Mein LED Rahmen hat Hallo zur Welt gesagt!! Ist das nicht ein nettes Kind?
64 Pixel x 3 Stripes x 4 Anschlussleitungen x 2 Aderenden, abschneiden, ab isolieren, durch die Löcher fädeln, den Stripe festkleben und anschließend noch die Leitungen verlöten. Eine sehr, wirklich sehr mühselige Arbeit. Gut kurz und knapp reden wir von 1536 Leitungsenden und 2 vollen Tagen Arbeit.
Zu guter Letzt mussten wir die einzelnen Farben der Pixel natürlich noch mit 12V versorgen und die geschaltene Masse auf unsere Treiberplatine führen. Wir reden wieder von Unmengen an Leitungen. Die 12V haben wir in der Reihe der Pixel durchgebrückt, was schonmal einiges an Aufwand ersparte. Mussten nur noch die 192 Massekabel bei den Treibern ankommen. Wir haben anfangs für jeweils 8 Pixel einen Zopf gepflochten aus den Leitungen um etwas Ordnung auf der Rückseite beibehalten zu können. Als wir uns dann stetig der Platine näherten, sind wir auf 4 Pixel je Zopf umgestiegen. Das bedeutete insgesamt weniger Klingelversuche um die richtige der farbigen Leitungen zu finden.
Apopros Farbcode, gelb ist für grün, weiß für rot und braun für blau. Selbsterklärend oder ;)
Dann ist uns noch ein kleines Missgeschick passiert, als wir von Donnerstag morgen bis zum Freitag mittag die Nacht über im Labor mit dem Auflegen der Treiberplatine beschäftigt waren. Da die Platine in 2 Reihen zu jeweils 6 Treibern aufgebaut ist und ich eigentlich von links nach rechts springen wollte, Stefan allerdings erst links von oben nach unten und dann rechts von oben nach unten gelötet hat, musste ich meine Ansteuerung aus dem RAM im FPGA nochmal etwas modifizieren. Naja ganz klarer Abstimmungsfehler, aber sowas passiert schon mal.
Langer Rede kurzer Sinn, ich sitze wieder im Labor und wenn der Stefan nachher kommt, werden wir euch mal ein paar Bilder hochladen. Gestern Abend hatte ich allerdings schon das erste Erfolgserlebnis zu Hause. Mein LED Rahmen hat Hallo zur Welt gesagt!! Ist das nicht ein nettes Kind?
Sonntag, 17. Februar 2013
Das Flackern ist weg
So ich hab mich nun ja auch schon eine ganz lange Zeit nicht mehr gemeldet. Soll allerdings nicht heißen, dass ich in der Zeit nichts für unsre Bachelorarbeit gemacht habe. Ich hab endlich dieses nervige Flackern weg bekommen, welches beim Stefan seinem Video noch zu sehen war.
Leider keine Absicht gewesen, dass da die LEDs geflackert haben. Sollten eigentlich nur konstant rot und eine grün sein. Aber dieses Problem ist nun mit einer neuen Adressberechnung Geschichte.
Am Raspberry bin ich nun auch voran gekommen. Problem war, dass das Atlys-Board keine EDID Datei senden kann. Somit wurde die Auflösung immer auf 1280x720 gestellt. Aber wir wollten ja 640x480. Ist eigentlich egal, da wir sowieso nur die ersten 8x8 Pixel nutzen, aber ich wollte es eben so. Also kurzerhand die EDID vom Monitor zu hause ausgelesen, auf dem Pi gespeichert und diesem gesagt, dass er die nutzen soll anstelle der des Atlys-Boards. Und siehe da, das Pi startet mit 640x480, egal was angeschlossen ist. Selbst bei keinem angeschlossenem HDMI Kabel. Ach ja, zudem hab ich es geschafft den Bildschirmschoner und die Energiesparfunktion des HDMI Ports abzustellen. Hat auch nur durch einen kleinen Workaround mit zwei verschiedenen INIT Skripts funktioniert. Aber nun geht es.
Morgen geht es erstmal zwecks Master-Arbeit nach Nürnberg. Anschließend werde ich mich dann etwas an der Vorbereitung der Pixel auslassen, das ist genug Arbeit für einen Euro Jobbler, aber wir haben leider keinen gefunden. Bleibt es also doch an mir hängen...
Leider keine Absicht gewesen, dass da die LEDs geflackert haben. Sollten eigentlich nur konstant rot und eine grün sein. Aber dieses Problem ist nun mit einer neuen Adressberechnung Geschichte.
Am Raspberry bin ich nun auch voran gekommen. Problem war, dass das Atlys-Board keine EDID Datei senden kann. Somit wurde die Auflösung immer auf 1280x720 gestellt. Aber wir wollten ja 640x480. Ist eigentlich egal, da wir sowieso nur die ersten 8x8 Pixel nutzen, aber ich wollte es eben so. Also kurzerhand die EDID vom Monitor zu hause ausgelesen, auf dem Pi gespeichert und diesem gesagt, dass er die nutzen soll anstelle der des Atlys-Boards. Und siehe da, das Pi startet mit 640x480, egal was angeschlossen ist. Selbst bei keinem angeschlossenem HDMI Kabel. Ach ja, zudem hab ich es geschafft den Bildschirmschoner und die Energiesparfunktion des HDMI Ports abzustellen. Hat auch nur durch einen kleinen Workaround mit zwei verschiedenen INIT Skripts funktioniert. Aber nun geht es.
Morgen geht es erstmal zwecks Master-Arbeit nach Nürnberg. Anschließend werde ich mich dann etwas an der Vorbereitung der Pixel auslassen, das ist genug Arbeit für einen Euro Jobbler, aber wir haben leider keinen gefunden. Bleibt es also doch an mir hängen...
Aufbau der LED Matrix
In den letzten Tagen haben wir mit dem Aufbau der LED Matrix begonnen. Als Trägerplatte haben wir eine 8mm starke weiße Pressspanplatte mit 47x47cm Größe. Ein Pixel haben wir auf Grund der LED Stripes auf 5x5cm festgelegt.
Der Anschluss der LED Stripes erfolgt von hinten durch die Platte durch. Dadurch sieht man von vorne keine Leitungen.
Pro Stripe müssen 4 Löcher in die Pressspanplatte gebohrt werden, pro Pixel 12, macht pro Rahmen 768 Löcher! Eine recht eintönige Arbeit, die ich da am Mittwoch hatte... leider ist mir der Bohrer auf die letzten 4 Pixel abgebrochen:
Am Donnerstag hab ich dann auch noch die letzten 48 Löcher gebohrt ;)
Währenddessen hat sich der Christian weiter um die Ansteuerung der LED Stripes gekümmert. Hier haben wir mal ein kleines Video, wo man den Testaufbau von "10 Pixel" sieht und das neue Atlys Board von Xilinx:
Der Anschluss der LED Stripes erfolgt von hinten durch die Platte durch. Dadurch sieht man von vorne keine Leitungen.
Pro Stripe müssen 4 Löcher in die Pressspanplatte gebohrt werden, pro Pixel 12, macht pro Rahmen 768 Löcher! Eine recht eintönige Arbeit, die ich da am Mittwoch hatte... leider ist mir der Bohrer auf die letzten 4 Pixel abgebrochen:
Am Donnerstag hab ich dann auch noch die letzten 48 Löcher gebohrt ;)
Währenddessen hat sich der Christian weiter um die Ansteuerung der LED Stripes gekümmert. Hier haben wir mal ein kleines Video, wo man den Testaufbau von "10 Pixel" sieht und das neue Atlys Board von Xilinx:
Freitag, 8. Februar 2013
4x ADC funktioniert
Die Regelungstechnikprüfung am Mittwoch lief leider bescheiden, obwohl ich wie ein Blöder gelernt hab... aber es gibt Wichtigeres,wie z.B. ne Bachelorarbeit :)
Und hier gibts gute Nachrichten. Die Fehler in der ADC Platine ließen sich ohne Probleme beseitigen, so dass es nichtmal auffällt, dass ein Fehler im Layout war. Heute habe ich noch schnell die VHDL Files und die Software für die Messwertvisualisierung angepasst und tata... es läuft... ein Klatschen mit 4 Mikrofonen:
Und hier gibts gute Nachrichten. Die Fehler in der ADC Platine ließen sich ohne Probleme beseitigen, so dass es nichtmal auffällt, dass ein Fehler im Layout war. Heute habe ich noch schnell die VHDL Files und die Software für die Messwertvisualisierung angepasst und tata... es läuft... ein Klatschen mit 4 Mikrofonen:
Freitag, 1. Februar 2013
4 ADCs auf gemeinsamer Platine
Nachdem ich am Dienstag das Layout für die ADC Platine erstellt habe, konnte ich heute die fertig gefräste Platine bestücken:
Als ich die Leitungen für die 4 Mikrofone anlöten wollte, ist mir aufgefallen, dass ich blöderweise einen Fehler in meinem Layout habe. Die je übereinander liegenden Löcher muss ich jetzt mit Brücken durchkontaktieren und unten noch 4 Löche für meine Masseanschlüsse für die Mikrofone bohren. Zum glück lässt sich die Platine so leicht noch verwenden :)
Hier noch eine Detailaufnahme unserer LED Stripes. Der Christian ist schon recht weit mit der Software für die Treiberansteuerung. Auf dem Bild ist eine der geringsten PWM eingestellt :D
Als ich die Leitungen für die 4 Mikrofone anlöten wollte, ist mir aufgefallen, dass ich blöderweise einen Fehler in meinem Layout habe. Die je übereinander liegenden Löcher muss ich jetzt mit Brücken durchkontaktieren und unten noch 4 Löche für meine Masseanschlüsse für die Mikrofone bohren. Zum glück lässt sich die Platine so leicht noch verwenden :)
Hier noch eine Detailaufnahme unserer LED Stripes. Der Christian ist schon recht weit mit der Software für die Treiberansteuerung. Auf dem Bild ist eine der geringsten PWM eingestellt :D
Mit der Erkennung der Laufzeitunterschiede bin ich auch deutlich weiter gekommen. Dazu werde ich bald Details hier posten. Nur jetzt muss ich erstmal Regelungstechnik lernen... am Mittwoch ist nämlich Prüfung!
Erst gucken, dann drucken...
Tja, wurde leider nichts mit meinem voll funktionsfähigem Layout. Das Package unserer MBI5030 ist leider kein SSOP24 wir von mir angenommen. Allerdings ist es auch kein SOP24 sondern ein SSOP24-L. Das heißt gleiche Breite, aber andere Länge. Nun haben wir eine Ausschussplatine hier herum liegen. Das neue Layout ist dann am Montag fertig zum bestücken.
Aber eine gute Nachricht haben ich heute auch. Das Atlys-Board von Digilent ist nun in meinem Besitz. Der Vorteil ist, dass auf diesem Board bereits HDMI-Buchsen vorhanden sind. Die Videodaten können wir nun also aller Voraussicht nach doch mit der GPU unserer Raspberry Pies berechnen lassen.
So mal ein bisschen das Design auf HDMI umschreiben.
Aber eine gute Nachricht haben ich heute auch. Das Atlys-Board von Digilent ist nun in meinem Besitz. Der Vorteil ist, dass auf diesem Board bereits HDMI-Buchsen vorhanden sind. Die Videodaten können wir nun also aller Voraussicht nach doch mit der GPU unserer Raspberry Pies berechnen lassen.
So mal ein bisschen das Design auf HDMI umschreiben.
Dienstag, 29. Januar 2013
Raspberry Pi
Da ich leider selbst noch überhaupt keine Ahnung zur Grafikprogrammierung mit C++ mit OpenGL (und dazu noch unter Linux!) habe, bin ich gerade am googeln und Quellen suchen. Ein paar Grafik Beispielprograme sind zwar auf dem RasPi, allerdings sind diese alle in Python geschrieben.
Eine interresante alternative zu C++ wäre noch einfach HTML5 im Browser auszuführen und das ganze mit Javascript zu schreiben... für unsere 64 Pixel würde das allemal reichen :) allerdings will ich auch auf die GPIOs bzw. die serielle Schnittstelle zugreifen und das wiederum wird aus dem Browser herraus eher schwierig. Es müsste auf dem RasPi dann ein Script (vielleicht in PHP geschrieben) laufen, dass die Verbindung mit der seriellen Schnittstelle herstellt und dann über Ajax mit meinem JS bzw. der HTML5 Seite im Browser kommuniziert...
Das Beste währe wohl eine Mischung aus beidem. Um mit dem Smartphone später die LED Matrix steuern zu können ein kleiner schlanker Webserver, der dann (wie auch immer) mit einem in C++ geschriebenen Programm kommuniziert. Spontan würde mir die Kommunikation über XML Files oder eine MySQL Datenbank einfallen. Mit C++ und OpenGL könnte man dann wunderbar Performant irgend welche Grafiken rendern :)
Bei meiner Suche bin ich auf ein interresantes Themenspecial zum RasPi gestoßen:
http://www.golem.de/specials/raspberry-pi/
Eine interresante alternative zu C++ wäre noch einfach HTML5 im Browser auszuführen und das ganze mit Javascript zu schreiben... für unsere 64 Pixel würde das allemal reichen :) allerdings will ich auch auf die GPIOs bzw. die serielle Schnittstelle zugreifen und das wiederum wird aus dem Browser herraus eher schwierig. Es müsste auf dem RasPi dann ein Script (vielleicht in PHP geschrieben) laufen, dass die Verbindung mit der seriellen Schnittstelle herstellt und dann über Ajax mit meinem JS bzw. der HTML5 Seite im Browser kommuniziert...
Das Beste währe wohl eine Mischung aus beidem. Um mit dem Smartphone später die LED Matrix steuern zu können ein kleiner schlanker Webserver, der dann (wie auch immer) mit einem in C++ geschriebenen Programm kommuniziert. Spontan würde mir die Kommunikation über XML Files oder eine MySQL Datenbank einfallen. Mit C++ und OpenGL könnte man dann wunderbar Performant irgend welche Grafiken rendern :)
Bei meiner Suche bin ich auf ein interresantes Themenspecial zum RasPi gestoßen:
http://www.golem.de/specials/raspberry-pi/
Montag, 28. Januar 2013
Volle Kraft vorraus
So heute hab ich die letzte Prüfung in meinem Bachelorstudiengang zu Papier gebracht (also theoretisch zumindest). Nun sind noch die Fertigstellung der Bachelorarbeit und die dazu gehörenden Seminare zu bewältigen.
Allerdings nicht mehr heute, jetzt genieße ich erst ein wenig die freie Zeit. Morgen in aller Frühe werde ich dann meine Treiberplatine bestücken.
Bei Fertigstellung werde ich dann ein Bild posten und falls es EMV technisch wenig Probleme gibt dann auch das Layout.
Allerdings nicht mehr heute, jetzt genieße ich erst ein wenig die freie Zeit. Morgen in aller Frühe werde ich dann meine Treiberplatine bestücken.
Bei Fertigstellung werde ich dann ein Bild posten und falls es EMV technisch wenig Probleme gibt dann auch das Layout.
Donnerstag, 24. Januar 2013
ADC misst "so gut" wie Oszi
Während der Christian mit den LED-Messungen fleißig war, hab ich alle anwesenden Personen im Labor mit ständigem Klatschen geärgert ;-)
Um die aufgenommenen ADC Werte zu validieren habe ich einen 24 Bit breiten Blockram im FPGA angelegt, welcher 16384 Werte speichern kann, um einen Zeitraum von 16,3ms aufzuzeichnen.
Momentan wird beim einschalten der Spannungsversorgung für 1s ein Mittelwert über die gemessene Spannung am Mikrofon gebildet und gespeichert. Anschließend wird ständig kontrolliert ob die Spannung bei einem der beiden Mikrofone 200mV über diesem Mittelwert liegt. Falls dies der Fall ist wird in einem Fenster von 4 ms ein Maximalwert gesucht.
Der Blockram ist als Ringspeicher angelegt, der ständig mit neuen Werten gefüllt wird. Falls ein Mikrofon die Schwelle überschreitet, werden noch 14384 Werte gesichert, so dass ich 2ms "in die Vergangenheit" blicken kann, um zu sehen wie die Mikrofone angeschwungen sind.
Auf dem Oszi sieht das ganze beispielsweise so aus, wenn man zentrisch im Abstand von ca. 40cm klatscht:
Den RAM lese ich über die "RS232" Schnittstelle (hardwaretechnisch beim Eva-Board als USB realisiert) aus und speicher die Rohdaten mit hterm ab. Anschließend kann ich die Daten mit einer kleinen Software die ich in C++ geschrieben habe laden und anzeigen lassen. Hier will ich dann verschiedene Algorithmen zur Laufzeitmessung testen und wenn sich ein geeigneter gefunden hat, diesen dann im FPGA umsetzen.
Gut zu erkenne ist, dass der ADC Wert mit dem Oszibild gut übereinstimmt. Die vertikalen gestrichelten schwarzen Linien sind die 4ms in denen der Maximalwert ermittelt wird. Die horizontalen gestrichelten Linien sind jeweils die 200mV grenzen nach oben und unten, wobei momentan nur bei +200mV eine Messung gestartet wird.
Der Abschnitt zeigt allerdings nur 8,8ms vom aufgezeichneten Klatschen. Hier entspricht jetzt 1 Pixel in der x-Achse 8µs und 1 Pixel in der y-Achse 6,4mV.
Über die Scrollbars an der Seite kann ich die beiden Signale verschieben und somit übereinander legen:
oder aber auch die Position des angezeigten Ausschnits im "Maßstab 1:1" verändern (0,8mV bzw. 1µs pro Pixel:
Ich hab noch ein Bild mit realer Auflösung von 16384 x 4096 Pixel (67 Megapixel!) generiert, allerdings kam leider eine Fehlermeldung beim Upload, obwohl es als png nur 263KB groß ist.
Morgen gehts dann weiter... ich freu mich schon :D
Um die aufgenommenen ADC Werte zu validieren habe ich einen 24 Bit breiten Blockram im FPGA angelegt, welcher 16384 Werte speichern kann, um einen Zeitraum von 16,3ms aufzuzeichnen.
Momentan wird beim einschalten der Spannungsversorgung für 1s ein Mittelwert über die gemessene Spannung am Mikrofon gebildet und gespeichert. Anschließend wird ständig kontrolliert ob die Spannung bei einem der beiden Mikrofone 200mV über diesem Mittelwert liegt. Falls dies der Fall ist wird in einem Fenster von 4 ms ein Maximalwert gesucht.
Der Blockram ist als Ringspeicher angelegt, der ständig mit neuen Werten gefüllt wird. Falls ein Mikrofon die Schwelle überschreitet, werden noch 14384 Werte gesichert, so dass ich 2ms "in die Vergangenheit" blicken kann, um zu sehen wie die Mikrofone angeschwungen sind.
Auf dem Oszi sieht das ganze beispielsweise so aus, wenn man zentrisch im Abstand von ca. 40cm klatscht:
Den RAM lese ich über die "RS232" Schnittstelle (hardwaretechnisch beim Eva-Board als USB realisiert) aus und speicher die Rohdaten mit hterm ab. Anschließend kann ich die Daten mit einer kleinen Software die ich in C++ geschrieben habe laden und anzeigen lassen. Hier will ich dann verschiedene Algorithmen zur Laufzeitmessung testen und wenn sich ein geeigneter gefunden hat, diesen dann im FPGA umsetzen.
Gut zu erkenne ist, dass der ADC Wert mit dem Oszibild gut übereinstimmt. Die vertikalen gestrichelten schwarzen Linien sind die 4ms in denen der Maximalwert ermittelt wird. Die horizontalen gestrichelten Linien sind jeweils die 200mV grenzen nach oben und unten, wobei momentan nur bei +200mV eine Messung gestartet wird.
Der Abschnitt zeigt allerdings nur 8,8ms vom aufgezeichneten Klatschen. Hier entspricht jetzt 1 Pixel in der x-Achse 8µs und 1 Pixel in der y-Achse 6,4mV.
Über die Scrollbars an der Seite kann ich die beiden Signale verschieben und somit übereinander legen:
oder aber auch die Position des angezeigten Ausschnits im "Maßstab 1:1" verändern (0,8mV bzw. 1µs pro Pixel:
Ich hab noch ein Bild mit realer Auflösung von 16384 x 4096 Pixel (67 Megapixel!) generiert, allerdings kam leider eine Fehlermeldung beim Upload, obwohl es als png nur 263KB groß ist.
Morgen gehts dann weiter... ich freu mich schon :D
Mittwoch, 23. Januar 2013
Den Wald vor lauter Bäumen, oder die Welt vor lauter Punkten nicht sehn.
So, mittlerweile ist schon viel Zeit vergangen. Wir haben zwei Treibertestplatinen zusammengeschalten und mit LEDs bestückt. Jeweils 9 LEDs pro Kanal. 32 Kanäle bei 3 Farben, ergeben 10 Pixel mit 2 leeren Kanälen. Jedes Pixel sind 9 LEDs. Hier ein Bild vom Aufbau:
Wie man sieht, können wir auch schon bunt und uns mal wieder selber blenden bei so viel Licht ;)
Hier leuchten gerade 90 LEDs und ein Oszi hängt dran. Wir sind bei einer PWM-Frequenz von etwa 3 kHZ mit ganz ganz hässlichen Spannungsspitzen beim Ein-/Ausschaltvorgang... guckst du hier:
Hier haben wir eine mittlere Spannung (orange) von etwa 13V. Die Einbrüche beim Einschalten des LED Stroms (grün) gehen bis auf 4V runter. Die Spannungsspitzen beim ausschalten betragen sogar 25V. Das ist natürlich alles andere als eine konstante Spannung. Ein Kondensator mit 100nF direkt an der Treiberplatine zwischen den 13,5V und GND brachte schon eine Reduzierung dieser Ausreißer.
Jetzt sind allerdings währen der Strom fließt immer noch Schwingungen auf unserer Spannung gewesen, die wir gerne auch beseitigt hätten. Also einen 4,7mF Elko direkt an die Spannungsquelle.
Nun kommen wir der Sache schon erheblich näher. Apopros näher kommen, hier noch eine Pulsbreite (hier ca. 10%) etwas höher gesampled.
Für den Testaufbau ist das ausreichend, wie wir fanden. Auf unserem Platinenlayout haben wir 30 Plätze für SMD Keramik Kondensatoren vorgesehen, um die Spitzen in den Griff zu bekommen. Für die Glättung während der Stromflussphase sind 7 Elkos vorgesehen. Wir hoffen es reicht, wenn nicht hängen wir noch eine Elko Platine zwischen.
Ansonsten ist zum Design relativ wenig zu sagen, 12 Treiber auf einem Board, alle SDI/SDOs in Reihe und Pinheader (nutzen allerdings nur deren Löcher) um die LED-Leitungen an die Treiber zu bekommen. Platine sollte morgen fertig sein, dann bestücken und wir können unseren ersten Testaufbau mit 64 Stribes wagen.
Wie man sieht, sind wir schon fast fertig. Naja, ich sagte ja fast, oder?
Wie man sieht, können wir auch schon bunt und uns mal wieder selber blenden bei so viel Licht ;)
Hier leuchten gerade 90 LEDs und ein Oszi hängt dran. Wir sind bei einer PWM-Frequenz von etwa 3 kHZ mit ganz ganz hässlichen Spannungsspitzen beim Ein-/Ausschaltvorgang... guckst du hier:
Hier haben wir eine mittlere Spannung (orange) von etwa 13V. Die Einbrüche beim Einschalten des LED Stroms (grün) gehen bis auf 4V runter. Die Spannungsspitzen beim ausschalten betragen sogar 25V. Das ist natürlich alles andere als eine konstante Spannung. Ein Kondensator mit 100nF direkt an der Treiberplatine zwischen den 13,5V und GND brachte schon eine Reduzierung dieser Ausreißer.
Jetzt sind allerdings währen der Strom fließt immer noch Schwingungen auf unserer Spannung gewesen, die wir gerne auch beseitigt hätten. Also einen 4,7mF Elko direkt an die Spannungsquelle.
Nun kommen wir der Sache schon erheblich näher. Apopros näher kommen, hier noch eine Pulsbreite (hier ca. 10%) etwas höher gesampled.
Für den Testaufbau ist das ausreichend, wie wir fanden. Auf unserem Platinenlayout haben wir 30 Plätze für SMD Keramik Kondensatoren vorgesehen, um die Spitzen in den Griff zu bekommen. Für die Glättung während der Stromflussphase sind 7 Elkos vorgesehen. Wir hoffen es reicht, wenn nicht hängen wir noch eine Elko Platine zwischen.
Ansonsten ist zum Design relativ wenig zu sagen, 12 Treiber auf einem Board, alle SDI/SDOs in Reihe und Pinheader (nutzen allerdings nur deren Löcher) um die LED-Leitungen an die Treiber zu bekommen. Platine sollte morgen fertig sein, dann bestücken und wir können unseren ersten Testaufbau mit 64 Stribes wagen.
Wie man sieht, sind wir schon fast fertig. Naja, ich sagte ja fast, oder?
Mittwoch, 16. Januar 2013
Erste Ortung eines Klatschens
Letzte Woche ging es weiter und ich hab den Testaufbau neu verdrahtet um weniger EMV-Probleme zu haben. Die CLK und CS Leitungen der zwei AD Wandler habe ich jetzt Parallel an einem Pin des FPGAs und ich kann jetzt beide ADCs gleichzeitig betreiben.
Auf dem Steckbrett sind jetzt 2 Mikros im Abstand von ca. 12cm angeordnet. Als erstes will ich sicher erkennen, ob rechts oder links der Mikrofone geklatscht wurde. Wenn das funktioniert versuche ich die Genauigkeit der gemessenen Laufzeitdifferenz zu erhöhen.
Hier ein Bild der beiden Mikrofonspannungen beim aktuellen Messaufbau. Man kann auch gut ein Echo sehn, dass durch eine Wand reflektiert wurde:
Leider sieht man hier auch gut die unterschiedlichen Signalformen der billigen Mikrofone, obwohl sie ja die selbe Signalquelle hatten. Die Ruhespannung der beiden Mikros unterscheidet sich auch deutlich mit 0,99V bei dem Einen und 1,42V bei dem Anderen.
Die nachfolgenden zwei Bilder zeigen ein Klatschen, dass mit 1MS aufgezeichnet wurde, so wie es auch die ADCs machen:
Das zweite Bild zeigt ein relativ großes Rauschen, was zumindest eine Maximalwertsuche schwierig macht. Über eine Mittelung über 3-5 ADC Werte im FPGA hoffe ich ein möglichst "richtiges" Maximum finden zu können. Dies werden Tests in den kommenden Tagen zeigen.
Wegen der großen Streuung bei den Mikrofonen ermittle ich als erstes für ca. 1 Sekunde beim Starten einen Mittelwert der Ruhespannung. Falls anschließend der Spannungswert des Mikrofons 200mV ansteigt wird in einem Zeitfenster von 4ms je Mikrofon ein Maximalwert gesucht und der Samplecounter je Wert abgespeichert. Für ca. 100ms werden danach keine neunen Messwerte ausgewertet um nicht durch Echos fehlerhafte Messergebnisse zu generieren.
Über den Wert der beiden Samplecounter wird zuletzt bestimmt, aus welcher Richtung das Klatschen kam. Zur Zeit wird in den meisten Fällen bereits die richtige Richtung erkannt, allerdings kommt es hier sehr drauf an, wie man klatscht. Es ist also noch einiges an Entwicklungsarbeit nötig.
Auf dem Steckbrett sind jetzt 2 Mikros im Abstand von ca. 12cm angeordnet. Als erstes will ich sicher erkennen, ob rechts oder links der Mikrofone geklatscht wurde. Wenn das funktioniert versuche ich die Genauigkeit der gemessenen Laufzeitdifferenz zu erhöhen.
Hier ein Bild der beiden Mikrofonspannungen beim aktuellen Messaufbau. Man kann auch gut ein Echo sehn, dass durch eine Wand reflektiert wurde:
Leider sieht man hier auch gut die unterschiedlichen Signalformen der billigen Mikrofone, obwohl sie ja die selbe Signalquelle hatten. Die Ruhespannung der beiden Mikros unterscheidet sich auch deutlich mit 0,99V bei dem Einen und 1,42V bei dem Anderen.
Die nachfolgenden zwei Bilder zeigen ein Klatschen, dass mit 1MS aufgezeichnet wurde, so wie es auch die ADCs machen:
Das zweite Bild zeigt ein relativ großes Rauschen, was zumindest eine Maximalwertsuche schwierig macht. Über eine Mittelung über 3-5 ADC Werte im FPGA hoffe ich ein möglichst "richtiges" Maximum finden zu können. Dies werden Tests in den kommenden Tagen zeigen.
Wegen der großen Streuung bei den Mikrofonen ermittle ich als erstes für ca. 1 Sekunde beim Starten einen Mittelwert der Ruhespannung. Falls anschließend der Spannungswert des Mikrofons 200mV ansteigt wird in einem Zeitfenster von 4ms je Mikrofon ein Maximalwert gesucht und der Samplecounter je Wert abgespeichert. Für ca. 100ms werden danach keine neunen Messwerte ausgewertet um nicht durch Echos fehlerhafte Messergebnisse zu generieren.
Über den Wert der beiden Samplecounter wird zuletzt bestimmt, aus welcher Richtung das Klatschen kam. Zur Zeit wird in den meisten Fällen bereits die richtige Richtung erkannt, allerdings kommt es hier sehr drauf an, wie man klatscht. Es ist also noch einiges an Entwicklungsarbeit nötig.
Abonnieren
Posts (Atom)