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/
Dienstag, 29. Januar 2013
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)