AmbiController v0.4.1 - Umfrage Sammelbestellung

Um es kurz zu machen, es gäbe da eine Möglichkeit vollständig aufgebaute AmbiController geliefert zu bekommen. Also von einer Firma professionell aufgebaute AmbiController - Systeme die ohne Kenntnisse über Elektronik und Löten direkt verwendet werden können.

Dazu benötige ich jedoch eine Liste von interessierten Personen um entsprechende Angebote einholen zu können. Die minimale Stückzahl, welche einen annehmbaren Preis ermöglichen würde, liegt jedoch im Bereich um die 30 - 40 Stück oder natürlich mehr.

Daher habe ich eine Umfrage eingerichtet in der sich jeder interessierte seine Wünsche eintragen kann.

Sollten mindestens 30 Personen Interesse signalisieren werde ich den Aufwand auf mich nehmen und versuchen ein passendes Paket zu schnüren.

AmbiController v0.4.1 - auf tindie.com

Es ist soweit, ich habe auf Tindie einen Artikel angelegt. Es handelt sich dabei um die die jeweils aktuelle Version der Platine. Heute die Version v0.4.1. Diese beinhaltet alle für die v0.4 - Hardware beschriebenen Funktionen.

Bei einer Bestellung lege ich voraussichtlich die folgenden Inhalte der Lieferung bei:

• Die Platine (siehe hier, nur ohne Bugs)
• Anleitung (deutsch) in der der Aufbau der Platine und der LED-Streifen beschrieben ist
• Liste der benötigten Werkzeuge (mechanische als auch elektronische)
• Liste der benötigten Bauteile für den Aufbau
• Liste der optional benötigten HDMI-Geräte
• Angaben zu dem benötigten LED-Streifen und zum Netzteil
• CDROM/DVD mit einem Snapshot der aktuellen Software und Konfigurationsdateien

Was die Lieferung nicht enthält:

• Bauteile/Kabel etc.
• Optionale HDMI-Hardware
• AVR XMega/Altera Cyclone IV kompatible JTAG-Programmieradapter
• Netzteil
• LED-Streifen
• Ein Gehäuse für den AmbiController

Die Lieferzeit wird einige Wochen dauern, da ich keine Platinen sowie keine der oben genannten Inhalte auf Lager habe. Als eine weitere Option werde ich voraussichtlich ein Paket an Bauteilen zusammenstellen welche optional mitbestellt werden kann. Weiterhin bin ich daran zu testen ob ich eine teilweise vorgefertigte Platine liefern kann, auf der zumindest die ICs aufgelötet sind und ggfls. die Software und das FPGA-Design bereits geflasht worden ist. Auch werde ich prüfen ob es mir möglich sein wird vorgefertigte LED-Streifen anzubieten.

Eine vollständig aufgebaute Platine werde ich nicht anbieten, dies liegt an den Bestückungskosten. Der Preis liegt für kleine prototypischen Stückzahlen bei ca. 350€ pro Platine.

Wie dem Aufmerksamen Leser sicher aufgefallen ist befindet sich das Ganze im Aufbau, Änderungen behalte ich mir also vor.

Ich freue mich auf die ersten Anfragen und vor allem auf konstruktive Rückmeldung/Anregungen.

AmbiController v0.4 - Bugfix

Wie ich in meinem letzten Post bereits angekündigt hatte war es mein Ziel LED-Streifen an meinem TV anzubringen. Das ist nun erledigt und die neue Hardware wurde ausgiebig getestet. Hier ein paar Bilder dazu.

Hierbei ist noch ein Problem aufgefallen das zu immer schlechter werdenden Farben der Beleuchtung und zu einem starken Flackern geführt hatte. Es handelte sich dabei um ein Temperatur-Problem das dazu geführt hatte, dass der FPGA vom Videoprozessor fehlerhafte Daten empfangen hat. Dies lag aber nicht, wie zu erwarten wäre, daran das der Videoprozessor falsche Daten gesendet hätte. Sondern der FPGA hatte scheinbar ein Problem damit das sich der Eingangs-Tackt des Videoprozessors zum FPGA in Abhängigkeit zu der Temperatur verändert hatte. Der Videoprozessor, inklusive einem der dazugehörigen Spannungsregler, innerhalb von 1-2 so warm das man diesen nicht mehr mit der Hand oder einem Finger berühren konnte.

Da man sich das ganze nur schwer vorstellen kann habe ich das Problem aufgezeichnet.
Man beachte das während der Aufnahme mehrmals das Signalkabel abgezogen und wieder verbunden wurde, so dass der Videoprozessor zeitweise ein komplett schwarzes Bild übertragen sollte. In den beiden Videos (siehe unten) ist gerade in diesen "schwarzen" Videoanteilen deutlich zu sehen das diese nicht schwarz sind, sondern mehr und mehr fehlerhafte Pixel enthalten. Das eigentlich dargestellte Bild, sobald ein Signal angelegt gewesen ist, war hier nicht relevant.

Hier im zweiten Video ist der Videoprozessor bereits sehr viel wärmer geworden, die Auswirkungen auf das Gesamtsystem sind deutlich zu sehen. 

Das Problem im FPGA wurde damit korrigiert das der der HDMI-Support komplett entfernt worden ist. Damit wurde das Timing in der Synthese deutlich toleranter gegenüber Veränderungen geworden. Als nächster Schritt wird jedoch noch jeweils ein passiver Kühler auf einem der Spannungsregler und auch auf dem Videoprozessor angebracht.

Mit dem entfernen des HDMI-Support aus der Synthese sind damit alle Bildprobleme, welche auf der neuen Hardware aufgetaucht waren, entfernt. Weiterhin habe ich nun noch die Kommunikation des AVR mit dem Flash des FPGA auf 7kB/s herauf optimiert, welche aufgrund eines Compiler-Upgrades zunächst gar nicht mehr funktionierte und zuletzt doch ganze 700 Byte/s erreicht hatte.

Ich bin nun zufrieden, wenn es auch wie immer etwas zu tun gibt ;)

Es wird in den kommenden Wochen voraussichtlich trotzdem eine neue Platine geben, da wie bereits in einem früheren Beitrag beschrieben, ein paar wenige Kleinigkeiten verbessert werden können. Das einzige größere Problem bei der aktuellen Version ist das die 5-Volt Eingangsspannung (von USB) nicht mit den Spannungsreglern auf der Platine verbunden ist. Das verhindert natürlich eine Verwendung bei der nur ein USB-Anschluss verwendet werden soll, hindert aber nicht daran das System mit einem der anderen beiden Anschlüsse mit Spannung zu versorgen. Alle weiteren Änderungen sind lediglich zur Verbesserung der Optik gedacht oder um beispielsweise die Wärme besser von den Chips abführen zu können.

Ich werde wie immer darüber berichten.

AmbiController v0.4 - Fertig

Nachdem ich doch eine ganze eine Weile an der Platine gearbeitet habe ist diese endlich fertig aufgebaut. Erfreulicherweise ergaben sich dabei keine gravierenden Probleme in der Platine selbst. Lediglich eine Leitung musste ich nachträglich - per Kupferlackdraht/Fädeldraht - einfügen. Insgesamt ein guter Schnitt, ich bin zufrieden!

Was meine Auswahl der Teile bei der Bestellung angeht sind mir zwei Fehlbestellungen untergekommen. Zum einen Waren die Taster minimalst größer als die benötigten.

Und zum anderen war das Quarz für den Videoprozessor nicht etwa ein einfaches Quarz, sondern ein Oszillator der mit Spannung versorgt werden muss und ein eigenartiges Rauschen erzeugt wenn man diesen dennoch verbaut hat. Die Alternative bot sich aus einem Quarz das ich noch als Ersatzteil für einen anderen Prototypen übrig hatte.

Was die Software angeht habe ich nach einem Update des AVR-GCC diverse Anpassungen machen müssen, damit die Firmware wieder vollständig funktionstüchtig ist. Zudem musste ich in der Routine - welche für das Update des FPGA-Flashes per USB zuständig ist - ein Delay in der Kommunikation einbauen um der USART-Verbindung zum FTDI-Chip die Möglichkeit zu geben die Daten auch tatsächlich übertragen zu können.

Den Schaltplan und das Layout der Platine habe ich bereits angepasst, so dass bei der nächsten Bestellung voraussichtlich keine Überraschungen mehr auftreten werden.

Das einzige was mich nun noch stört bei diesem Projekt ist der Aufbau der Hardware. Mir wäre es recht wenn die eine Firma für mich erledigt. Leider sind die Preise für die Bestückung von einzelnen Prototypen weit über dem Betrag welchen ich mir dafür vorgestellt habe.

Als nächstes werde ich einen weiteren Fernseher mit einem LED-Streifen ausrüsten, hinter meinem Monitor sieht es bereits sehr gut aus!

AmbiController v0.4 - Status zum Aufbau

Da ich schon auf Twitter sehr viele Bilder während dem Aufbau gepostet habe möchte ich diese hier nicht unbedingt vollständig nachreichen. Vorenthalten möchte ich die Bilder der (fast) vollständig aufgebauten Platine jedoch nicht...

Momentan arbeite ich an der Inbetriebnahme. Die meisten Elemente sind bereits vollständig eingerichtet und funktionieren.

AmbiController v0.4 - Platinen wurden ausgeliefert

Und sie sehen wirklich sehr gut aus... mehr muss man da nicht dazu sagen!

Ich werde auf Twitter in den folgenden Wochen den Fortschritt im Aufbau und der Inbetriebnahme regelmäßig online stellen.

AmbiController v0.4 Bestellung/Features

Heute habe ich die Bestellung für drei (3) Exemplare der neuen v0.4 Hardware aufgegeben.

Ich bin sehr gespannt wie diese aussehen werden.

Hier ein paar Fakten:

• Größe: 74x62mm
• Platinenhersteller: OSH Park
• Anzahl der Layer: 2
• Design-Spec: OSH Park
• Bestellte Platinen: 3
• Bauteile:
• FPGA: Altera Cyclone IV EP4CE6 (50 MHz Takt; 276480 Bit On-Chip-RAM; 6272 LogicCells)
• 2 MBit Flashspeicher
• Mikrocontroller: Atmel XMega 192A3 (8/16Bit MCU; 32MHz; 16kB RAM; 192kB Flash; 4kB EEPROM)
• USB: 1x USB Mini-B Buchse - FTDI 232 RL
• Video Prozessor: 1x TVP5146M2
• 1x CVBS - Eingang (Cinch)
• Reset-Taster
• Funktions-Taster
• 6x Status-LEDs (USB/FPGA/AVR)
• 4x Spannungsregler (1,2V; 1,8V; 2,5V; 3,3V)
• 1x DC-Buchse (5V)
• Die Platine kann per USB betrieben werden (ohne Beleuchtung)
• Kann häufig mit einem USB-Anschluss des TV betrieben werden
• Die LED-Streifen müssen gesondert mit Strom versorgt werden
• Die Platine kann ber den Anschluss der LED-Streifen mit Spannung versorgt werden
• Die Platine kann mit einem 5V Netzteil betrieben werden
• Software-Stand:
• Firmware 0.8 (für den v0.4 Hardware-Support)
• Unterstützung für WS2811/WS2812B LED-Streifen
• Maximal Anzahl der LEDs auf den LED-Streifen: 320 (~ 5,333 Meter länge bei 60 LEDs/Meter)
• Software-Update des AVR und FPGA per USB möglich
• Konfiguration der Software per USB möglich
• Verarbeitung von vollen 25 Bildern pro Sekunde
• Kommandozeilen-Tools für die Konfiguration und Steuerung
• TTY - Emulation
• Anzeige des verarbeiteten Bilddatenstroms mittels "FrameView"-fähiger Software (BCTool)
• Automatische Signalerkennung
• Energiesparmodus
• Diverse Einstellungsmöglichkeiten:
• Verarbeitungsgeschwindigkeit
• Helligkeit der LEDs
• Grundfarbe
• Sleep-Timer
• Weißabgleich
• Farbe beim verlust des Eingangssignals
• Unterstützung diverse Bildschirm-Größen (bis zu 55")
• Verwaltung der "Channel Config" (mit grafischer Oberfläche)

Die beschriebene Software liegt seit heute auf GitHub.

Fossil-SCM to gource converter

Seit nun mehr als 1 1/2 Jahren verwende ich als Source Control Management - System fossil-scm und visualisiere gerne den Verlauf in der Entwicklung per gource. Leider ist gource nicht in der Lage die sogenannte fossil Timeline direkt zu interpretieren, mal davon abgesehen das fossil diese auf verschiedene Arten ausgeben kann. Und nun suche ich seit einigen Monaten nach einer Möglichkeit die Timeline/History durch gource anzeigen lassen zu können, aber ohne erfolg...

Daher habe ich mir nun selbst einen kleinen Parser in Python implementiert, diesen gibt es auf github.

Usage:

# fossil timeline to txt with names changed files

fossil timeline -n 99999 -v > timeline.txt

# convert timeline to gource custom log format and pipe to gource

python fossil_timeline_to_gource.py timeline.txt | gource

Im Repository sind jedoch auch zwei Scripte enthalten welche die Anwendung des Tools exemplarisch abbilden. Zum einen das "test.sh" welches eine ".fossil" - Datei als Parameter erwartet, und lediglich gource aufruft um die Timeline per gource anzeigen zu lassen. Und zum anderen das "covnert.sh" welches zwei Parameter (".fossil" - Datei und der Video-Datei-Name) erwartet und direkt die Timeline direkt in ein per gource visualisiertes MP4-Video konvertiert.

Hier wieder ein Beispiel-Video...

Die AmbiController - Hardware geht in eine neue Runde

In den letzten Monaten gab es einige Erkenntnisse was den letzten Stand der meine AmbiController-Hardware angeht. Wie ich bereits auf Twitter gepostet habe gab es einige Fortschritte was den ADV7611 angeht, der sich um die HDMI-Verbindung kümmern soll. Leider ist die Software und Hardware hierbei noch nicht soweit voran geschritten um daraus einen neuen Hardware-Release erstellen zu können. Die Idee, an deren Entstehung auch wieder der fu86 stark beteiligt war, ist es dieses mal die bestehende Version v0.2.18 auf einen Stand zu überführen welcher stabil läuft und von jedem direkt benutzt werden kann.

Um dies bewerkstelligen zu können beinhaltet die dadurch entstandene v0.4 - Platine die folgenden Eigenschaften:

- USB 2.0

- Analoger CVBS - Eingang

- Software-Update per USB

- Konfigurations-Interface per USB

Heraus gefallen ist das folgende:

- Bluetooth

- Android App - Unterstützung

- HDMI

- RGB-/YPbPr- und mehrfache CVBS-Eingänge

Zu der Entscheidung die oben genannten Komponenten zu entfernen bin ich gekommen, da ich auch in meiner aktuellen v0.2.18 - Hardware nicht mehr verwendet habe. Dies erleichtert zudem die Bedienung des Gesamtsystems deutlich und man kann drastisch weniger "verkonfigurieren".

Zum UseCase: In meiner aktuellen "Multimedia-Hifi-Welt" existieren verschiedene Geräte wie eine Spielkonsole, ein Receiver und ein optionaler PC, welche alle an einem TV per HDMI angeschlossen werden sollen. Dies geschieht über einen HDMI-Switch. Und zwischen TV und Switch ist zudem ein HDMI-Splitter vorhanden, welcher das Signal zum einen an den TV sendet und zum anderen an einen HDMI zu CVBS - Wandler. Dieser Wandler wiederum ist an den CVBS-Eingang des AmbiControllers angeschlossen. Ganz einfach... siehe Skizze... ;-)

Damit können sämtliche Geräte mit dem AmbiController verwendet werden und da alle auch bereits HDCP unterstützen gibt es hier auch keine Probleme mehr. Und wenn ich ein zweites älteres Gerät verwenden möchte, das per CVBS angeschlossen wird, kann ich auch einfach umstecken oder ein ~1 Euro Cinch - T-Stück dazwischen setzen... 

Das Layout der Platine befindet sich gerade noch in der Prüfung, das Layout steht jedoch bereits fest. Hier ein Beispielfoto wie die Platine aussehen könnte.

Der Vorteil dieser neuen Platine ist, dass diese wieder nur auf zwei Layern abgebildet ist, was die Produktionskosten deutlich verringert und das sich die Anzahl der Bauteile auch deutlich reduziert hat. Weiterhin kann die Software der vorherigen Hardware direkt und ohne große Änderungen verwendet werden. Am FPGA - Design ändert sich auch nichts. Für Anfänger ist das Löten jedoch weiterhin nichts.

Ich hoffe, dass ich in den nächsten Wochen dazu kommen werde die Platine fertig zu stellen und dann in Auftrag geben zu können. Ich hoffe auch auf den einen oder anderen fleißigen Helfer die dann jeweils eine Platine aufbauen dürfen und testen dürfen

ob das ganze praktikabel ist.

Vortrag auf der #GPN14

Wer um den 20.6.2014, in Karlsruhe, Besucher der GPN14 gewesen ist konnte meinen kurzen Vortrag über mein AmbiController-Projekt live anhören. Für alle die weder per LiveStream oder vor Ort sein konnten gibt es hier einen Mitschnitt.

Projektlog auf HackADay.io

Ich habe in den letzten Tagen auf HackADay.io dieses Projekt online gestellt und bereits einige Informationen dazu gepostet. Hier geht es direkt zu der Projektseite... 

Autonomous Light Controller - Hardware Synthese

Und dann war da noch die Sache mit dem FPGA. Bevor ich mit diesem Projekt angefangen habe wusste ich nichts darüber, außer das die Dinger schnell sein müssen. Schneller als ein CPLD zumindest, damit hatte ich schon einmal Kontakt als es darum ging Linux mittels einem PassMe auf einem Nintendo DS booten zu können. Das gute beim ersten Kontakt mit dieser Art Baustein war, dass man es mit JTAG ansprechen konnte. Und wenn man in ein Entwicklungs-Board wie das DE0-Nano investiert sogar komfortabel per USB damit arbeiten kann. Allerdings ist so ein FPGA (wiedererwarten) alles andere als ein besserer Mikrocontroller- so meine erste Annahme. Ein FPGA ist für mein Empfinden mittlerweile eine Spielwiese der nur die eigene Rechenkapazität im Gehirn eine Grenze setzt (ja ich weiß sehr hochgestochen).

Die erste Sache die man sich als Software-Entwickler aus dem Kopf schlagen muss, wenn man mit einem FPGA arbeiten möchte, ist das man da ein Programm für schreibt das darauf läuft. Zumindest wenn man VHDL (Very High Speed Integrated Circuit Hardware Description Language) sieht das dann sogar noch wie ein Programm aus. Es verhält sich aber in sehr vielen Punkten einfach so wie man es erwartet. Das fängt an bei parallelen Prozessen, dass Variablen einen bösen Beigeschmack haben können und endet bei der Synchronisierung von Signalen in verschiedenen Clock-Domains. Beißt man sich jedoch durch das Thema durch hat man jedoch ein wirklich sehr komfortables und mächtiges Werkzeug in der Hand um verschiedenste Probleme lösen zu können.

Wie ich bereits in einem früheren Post geschrieben habe, verwende ich für den analogen Teil einen DSP, der in der Lage ist analoge Videosignale in ITU-R BT.656 kodierte Daten zu transformieren. Diese Daten werden in meinem Fall mit 27MHz bitparallel aus dem DSP mit einer Farbtiefe von 10Bit heraus getaktet.

Für den von mir verwendeten XMega deutlich zu schnell wenn man bedenkt das dieser mit 32MHz läuft und ca. 1-2 Takte benötigt um einen einzelnen Pin auszulesen.

Mit der richtigen Hardware-Synthese im richtigen FPGA sind diese Laufzeiten jedoch kein Problem. Was also muss die Hardware-Synthese tun damit das Ergebnis für Ausgabe auf LED-Streifen als Hintergrundbeleuchtung für einen Bildschirm verwendet werden kann. Es ist recht simpel. Der FPGA muss die Pixeldaten taktgesteuert annehmen, puffern, herunter skalieren (von beispielsweise einer PAL-Auflösung) auf eine vom XMega verarbeitbare Pixel-Größe, und ausgeben des Ergebnisses an den XMega. Und all das so, dass mindestens 25 Bilder pro Sekunde verarbeitet werden können um unschönes Geflacker zu vermeiden.

Meine Logik auf dem FPGA realisiert genau das. Zur Laufzeit werden alle Pixeldaten (eines Halbbildes) eingelesen und in einen kleinen OnChip-RAM gepuffert. Gleichzeitig wird über einen Hardware-Algorithmus die Auflösung des Eingangs-Bildes auf 20x20 Pixel skaliert. Warum nur ein Halbbild verwendet wird liegt daran, dass es unnötig ist die volle Auflösung beim Eingangs-Bild zu verwenden wenn man es Bild danach auf ein gerade noch verwendbares Minimum zu skalieren.

Die Übertragung zum Mikrocontroller erfolgt darauf hin direkt aus dem OnChip-RAM heraus. Der Mikrocontroller lädt die Pixel einzeln und komponentenweise, mittels einer Taktleitung und bitparallel über einen 12Bit-Bus aus dem FPGA. Wurden alle Daten übertragen beginnt dieser damit aus den Pixeldaten die Farben für die LEDs heraus zu rechnen. Parallel dazu verarbeitet der FPGA das nächste Halbbild. Der beschriebene Ablauf verarbeitet damit alle 25 empfangenen Halbbilder des Eingangssignals. Die Ausgabe der LED-Farben erfolgt ebenfalls mit 25 "Bildern" pro Sekunde.

Aufgrund der Performance des Gesamtsystems war es sogar notwendig einen Puffer in die Software einzufügen, damit die ausgegebenen Farben mit dem angezeigten Bild synchronisiert werden kann. Der AmbiController ist deutlich schneller in der Bildverarbeitung als mein TV-Gerät.

Autonomous Light Controller - Standalone-Hardware funktionstüchtig

Wie immer habe ich auf Twitter (@KaiLauterbach) seit ein paar Tagen oder Wochen immer mal wieder die eine oder andere Sache über den Fortschritt der Inbetriebnahme meiner Platine veröffentlicht. Den aktuellen Stand möchte ich hier aber auch nochmals festhalten.

Wie im letzten Post hier bereits beschreiben ist die Platine vollständig aufgebaut. Seit dem letzten Post habe ich also daran gearbeitet diese zum laufen zu bringen. Das ganze gestaltete sich jedoch nicht ganz so einfach wie es hätte sein können, da sich das eine oder andere wichtige Bauteil grundlegend verändert hatte - im Vergleich zum vorherigen Prototypen.

So wurde beispielsweise der FPGA aus dem ersten Prototyp (Turm-Version) durch eine deutlich kleinere Variante ausgetauscht. Kleiner im Sinne der Anzahl von Pins, dem verfügbaren Speicher und den verfügbaren Logik-Zellen etc.. Um diesen FPGA nun dazu zu bewegen weiter im System mitzuarbeiten musste die, für eine andere Hardware implementierte Hardware-Synthese entsprechend angepasst und getestet werden. Alleine der Aufwand hierfür nahm einige Wochen in Anspruch.

Auch in der Firmware mussten einige Änderungen vorgenommen werden. Zum einen bestehen diese Änderungen angefangen bei der Anpassung an die neuen Hardwarevoraussetzungen der Platine, bis hin zur Implementierung einer neuen Kommunikationsschnittstelle - welche per Bluetooth angesprochen werden kann.

Der Teil zur Verarbeitung analoger Videosignale ist damit vollständig lauffähig. 

Das Video zeigt die neue Platine in Aktion.

Autonomous Light Controller - Platine fertig aufgebaut

Wer mit auf Twitter (@KaiLauterbach) folgt, wird schon des öfteren von Neuigkeiten zu dem Projekt gelesen haben. Das Bild unten zeigt die vollständig aufgebaute Platine. Diese soll den Prototyp (oben) später vollständig ersetzen.

Die neue Platine Funktioniert bereits zu großen Teilen. Bis die Hardware jedoch komplett läuft, wird jedoch noch ein wenig Zeit vergehen. 

Autonomous Light Controller - Platine

Heute ausnahmsweise kurz und knapp - die Platine ist bestellt. Die folgenden Bilder zeigen Screenshots des Layouts aus SketchUp heraus und das Video am Ende soll nur einen kurzen Überblick über die einzelnen Bereiche darstellen. In 8-10 Tagen werden die drei bestellten Platinen eintreffen, es bleibt also spannend. Ich werde bei Gelegenheit weiter darüber berichten.

Autonomous Light Controller - Dizzying Signal Processing

Wie ich in meinem letzten Post geschrieben habe gibt es neben dem Mikrocontroller noch einen weiteren Prozessor, es handelt sich dabei um einen TVP5146M2, von Texas Instruments. Dieser ist ein Videoprozessor, der in der Lage ist analoge Videosignale zu digialisieren und über eine bitparallele Schnittstelle (10- oder 20Bit breit) taktsynchron weiterzuleiten. Er unterstützt alle gängigen analogen Videosignale, wie beispielsweise alle PAL- und NTSC-Varianten. Als Übertragungsmedium wird CVBS, Component RGB und Component YPbPr unterstützt. VGA oder ähnliches nicht.

Die von diesem Prozessor ausgegebenen Videodaten werden nach dem Videostandard ITU-R BT.656 kodiert. Hierbei werden volle Bilder in Halbbildern nacheinander übertragen. Dabei wird - eine im DSP einzustellende - Unterabtastung verwendet. Bei der Übertragung wird durch die Unterabtastung deutlich an Bandbreite eingespart, ohne das es zu erheblichen Qualitätseinbußen kommt.

Der Takt zur Datenübertragung beträgt bei PAL/NTSC, einem 10Bit breiten Datenbus (entspricht 10Bit Farbtiefe) 27MHz, was einem Datenstrom von 27MBit/s ergibt. Leider ist der ATXMega hierbei schon komplett überfordert, da die Datenworte, am Bu,s nur ca. 18,5ns (Nanosekunden) anliegen, und dies drastisch kürzer ist als der Mikrocontroller (selbst bei Übertaktung auf 54MHz, 32MHz ist die empfohlene Obergrenze) erkennen kann.

Die Idee das System mit einem AVR XMega und diesem DSP aufzubauen scheiterte also recht früh in der Entwicklung, da auch der DSP nicht weiter um konfiguriert werden kann um die Übertragungsgeschwindigkeit bzw. die Bildauflösung zu reduzieren.

Jetzt könnte man sagen, dass man einfach einen anderen Mikrocontroller verwendet oder einen anderen DSP. Aber nein - das wäre zu einfach.

Der Flaschenhals bei dem Thema ist der Mikrocontroller. Setzt man nun einen deutlich schnelleren ein, mit dem die ITU-R BT.656-Signale nun verarbeitet werden können, steht man kurz darauf vor dem nächsten Problem sobald man moderne (digitale und hochauflösende) Videosignale verarbeiten möchte. Bei der Bildübertragung eines FULL-HD-Signales mit knapp 1280x1080 Pixeln, selbst mit 10Bit Farbtiefe sind deutlich höhere Taktraten als 27MHz notwendig um die Bilddaten in akzeptabler Zeit zwischen den Prozessoren zu übertragen. Ein Datenblatt eines anderen Signalprozessors (auf den ich in einem Späteren Post eingehen werde) gibt hier Taktraten von etwa 250MHz an. Es wird schnell klar, dass ein bezahlbarer Mikrocontroller hierbei einfach nicht hinterher kommt, so einfach die Lösung auch sein mag. Daher hab ich mich dazu entschieden einen anderen Ansatz zu verfolgen und den einfachen Weg zu verlassen.

Allerdings ist dieser Ansatz bei weitem komplexer und aufwendiger als einfach mehr Rechenleistung zu kaufen. Es geht dabei darum eigene eigene Hardware zu entwerfen, welche die vom DSP übertragenen Daten in Realtime empfangen kann, in der Lage ist diese zeitnah zu verarbeiten, und dem Mikrocontroller vor verarbeitet und in kleinen Portionen zur Verfügung zu stellen. Dazu gibt es aber mehr in einem der nächsten Posts...

Wie jedes mal habe ich in das Git-Repository die dazugehörigen Schaltpäne übertragen.

Autonomous Light Controller - The FPGA Ambilight clone?

Wie angekündigt möchte ich hier nach und nach mehr Details über mein Projekt verraten. Dem aufmerksamen Leser ist sicher bereits schon aufgefallen, dass die Verlinkungen (Tags) zu den Posts in Kategorien fallen, in denen sich bereits kleine andere Projekte befinden.

Beispielsweise verwende ich als Mikrocontroller-Basis mein XMega-Evaluation-Board.

Genauer gesagt wurde dieses genau für diesen Zweck erstellt...

Letztendlich handelt es sich um eine Grundschaltung für den XMega und diversen Schnittstellen um das Board mit der anderen Peripherie anzubinden. Der Schaltplan ist im Bild rechts zu sehen. Ein Layout gibt es hierfür nicht, da das ganze auf Lochraster aufgebaut ist (Bilder unten).

Den Schaltplan (Eagle) zu dem Board ist auf GitHub Verfügbar...

Die Aufgaben dieses Boards sind die folgenden:

1. Steuerung aller weiteren Komponenten wie dem FPGA-Board und dem Signalprozessor.
2. Kommunikation und Steuerung der Beleuchtungsanlage (Fnordlichter oder LED-Stripes).
3. Kommunikation per USB/Bluetooth mit externen Komponenten oder dem Anwender (TTY)
4. Power- und Videosignal-Management.
5. Empfang und Aufbereitung der bereits durch den FPGA vorbereiteten Bilddaten.
6. Übertragung der vom FPGA empfangenen Bilddaten per USB oder Bluetooth.

Die Software auf dem Chip besteht aus einer in C geschriebenen Firmware welche alle Aufgaben aus der Liste oben. Der größte Teil der Implementierung entspricht einer TTY-Emulation für die Interaktion mit dem System.

Per TTY können verschiedene Konfigurationseinstellungen vorgenommen und Systemtests durchgeführt werden.

Das folgende Video zeigt den Zugriff auf das System bzw. auf verschiedene Register des Signalprozessors per I²C. Das Terminal enthält eine ausführliche Online-Hilfe und erlaubt, neben dem vollem Systemzugriff, zudem die Steuerung der Beleuchtung. Der Controller kann damit auch anderweitig verwendet werden.

Eine wesentlich maschinenlesbare Variante der Kommunikation ist in Arbeit.

Das Video soll schlicht demonstrieren, dass so eine Schnittstelle existiert und verwendet werden kann. Als einfacher Anwender kommt man damit nicht in Berührung. Damit wäre die Usability sonst komplett unmöglich...

Wie in der Auflistung oben bereits erwähnt (Punkt 6) ist das System zudem in der Lage die Bild-Rohdaten, welche vom FPGA erzeugt werden, per USB oder Bluetooth auszugeben. Hierzu ist das Tool "FrameView" entstanden. FrameView verwendet unter anderem SDL, ist plattformunabhängig und als Linux-Binary gerade mal 14kb groß.
Das folgende Video zeigt die Applikation in Aktion. Das Bild des Desktops wird dabei per VGA->CVBS-Adapter in den AmbiController geleitet, automatisch ausgewertet, und das Ergebnis per USB an die FrameView-Anwendung weitergeleitet, welche das aktuell ermittelte Bild in dem kleinen Fenster links darfstellt. Das Größere Fenster ist Video mit einem ein einfachen Farbtest. Das Ganze stammt aus den Anfängen der Entwicklung. Daher ist das Ergebnis noch sehr sehr pixelig.
Das Protokoll an dieser Stelle ist recht proprietär und nur zu Debug-Zwecken gedacht, da diese Ausgabe zudem die Framerate drückt. Um Bandbreite bei der Datenübertragung zu sparen werden hier immer nur Änderungen übertragen. 

Damit erstmal genug für heute und viel Spaß beim Video schauen...

Erstes Update - Autonomous Light Controller

In den letzten Wochen habe ich einige Emails bekommen, darunter Spam, einige mit sehr verdächtiger und dubioser Formulierung und andere wirklich sehr nette. Das Projekt scheint also, ich mir auch steigenden die Besucherzahlen auf diesem Blog ansehe und Eure Suchbegriffe bei dem großen Suchmaschinenanbieter ansehe, ein gewisses Interesse geweckt zu haben. Das freut mich natürlich!

Leider muss ich alle Interessenten enttäuschen, da dieses Gerät momentan nur als Prototyp vorhanden ist. Von einer Verbreitung ist zudem abzusehen. Daher habe ich mich dazu entschlossen in der kommenden Zeit die Schaltpläne, Software, Hardware-Synthese etc. als OpenSource/-Hardware zu veröffentlichen. Und wenn die Zeit dafür gekommen und mir verfügbar ist, eine kurze Dokumentation dazu schreiben wie das System arbeitet und aufgebaut ist.

Das Bild oben zeigt den aktuellen Prototyp. Ein weiterer Prototyp, welcher nicht mehr aus 7 (in Worten sieben) vernetzten Lochrasterplatinen und mehreren hundert Metern Kupferlackdraht besteht, ist in Arbeit. Dieser wird nur noch aus einer kleinen 4-Layer Platine, mit an die 180 "0403" SMD-Bauteilen (als Hinweis an diejenigen die nun auf einen Bausatz oder ähnliches hoffen), bestehen.

Sobald der neue Prototyp (Bild vom unvollständigen Layout links) bestellt, geliefert und aufgebaut wurde, fängt die eigentliche Arbeit mit diesem erst wirklich an. Die Firmware muss angepasst werden, neue Hardwarekomponenten in Betrieb genommen, Messungen durchgeführt müssen werden, (hoffentlich

keine) Korrekturen vorgenommen werden und sehr viel Zeit damit verbracht werden, das neue System (mindestens) auf den Stand.

Es ist viel zutun!

 

Hier noch ein paar Fragen und Antworten aus den Emails:

• Verkaufen Sie das Gerät/Bausätze/etc.? NEIN 
• Wird das Gerät auch HDMI und HDCP verarbeiten können? Über einen HDMI zu Composite-Wandler und einem zusätzlichen HDMI-Splitter (wird beides beispielsweise von der Firma Ligawo angeboten) ist es möglich auch digitale Medien mit dem Gerät zu verarbeiten. Da es jedoch am Markt HDMI-Chips gibt wäre dies im neuen Prototyp theoretisch möglich, HDCP steht auf einem anderen Blatt.
• Funktioniert das Gerät auch mit anderen TV-Größen als 32 Zoll? Ja das ist definitiv möglich und bereits vorbereitet.
• Wie steht es mit der Benutzerfreundlichkeit? Das System wird mit dem Video-Signal und mit einer Stromquelle verbunden. FERTIG. Es schaltet sich selbstständig ein und aus, und kann per Bluetooth oder USB bzw. mittels einer Android-App konfiguriert werden (wenn überhaupt nötig).
• Wieso sind die Ecken auf dem Video schlechter ausgeleuchtet und wird das noch verbessert? Das liegt zum einen an der Art wie die LED-Streifen angebracht wurden. Und zum anderen reichen diese in meinem Fall nicht bis in die Ecken. Verwendet man entsprechend längere Streifen kann die Beleuchtung lückenlos aufgebaut werden.
• In einem der letzten Videos scheint die Beleuchtung nicht synchron zu dem dargestellten Bild zu sein, wird das noch behoben? Richtig, die Beleuchtung ist nicht synchron. Meine Hardware berechnet die anzuzeigenden Farben schneller und zeigt diese auch früher an als der TV das dazugehörige Bild darstellt. Daher kann die Verarbeitungsgeschwindigkeit, Software-seitig und zur Laufzeit vom Anwender, individuell angepasst werden.
• Wie schnell ist das System denn wirklich? Es verarbeitet alle empfangenen Bilder des Eingangssignals zur Laufzeit, ohne Verluste.
• Wieso werden die Farben in den vorherigen Videos falsch dargestellt? Da ich all meine finanziellen Mittel in das Projekt stecke, besitze ich leider ausreichend gute Videokamera und verwende mein Smartphone für die Aufnahmen. Daher ist die Qualität auch dementsprechend "hochwertig".
• Kann ich dann mein HDMI-Kabel durch das Gerät durchschleifen? Nein, siehe oben.
• Was kostet das System? Die Materialkosten belaufen sich (inklusive aller Prototypen) auf einen gerade noch 3-stelligen Betrag. Die Arbeitszeit innerhalb der fast 3 Jahre die ich an dem System arbeite nicht mitgerechnet. 
• Wieso mache ich mir den Aufwand und kaufe mir nicht einfach ein Gerät das das schon kann? Weil ich es kann, Spaß daran habe die Probleme zu lösen, meine Hardware ist besser, in dieser Form hat das noch keiner geschafft (verschiedene haben es versucht)... es gibt viele Gründe, aber warum hat man ein Hobby?

Autonomous Light Controller

Lange ist es her seitdem ich hier über etwas geschrieben habe. Die Zeit zum bloggen war leider einfach nicht verfügbar. Dafür aber für ein sehr spezielles Projekt. Sehr sehr viele Arbeitsstunden, neue Ideen, Technologien und auch finanzielle Mittel sind in dieses eingeflossen, Und es ging einen riesige Schritte nach vorne damit.

Vor langer langer Zeit habe ich bereits über ein Vorgänger-Projekt gebloggt bei dem Fnordlichter über den VLC-Player als dynamische Hintergrundbeleuchtung eines Bildschirms verwendet werden können.

Dieses Projekt hat mir seitdem keine Ruhe mehr gelassen. Ich musste dieses einfach, trotz aller Kosten und Mühen, weiter perfektionieren.

Bei der ersten  Version und auch an den vielen "Ambilight"-Clones, die in verschiedensten Internet-Shops zu erwerben sind, stört mich vorallem eines: Es wird immer ein PC benötigt der die Rechenarbeit durchführt. Es gibt auch Ausnahmen, aber diese Projekt sind dann entweder seit vielen Jahren stillgelegt, seit langer Zeit unvollständig oder entsprechen einfach nicht meiner eigenen Vorstellung eines solchen Systems.

Nach der Devise, was es nicht gibt baue ich mir selbst, kann ich nun endlich die ersten (meiner Meinung nach) wirklich gelungenen Videos meines "Autonomous Light Controllers" in Aktion vorstellen. 

Technische Daten:

• 12 Volt Spannungsversorgung
• max. 20 Watt Leistungsaufnahme
• 120 RGB-LEDs (keine Lücken auf dem Bildschirmhintergrund, bei einem 32" TV)
• Bildschirmgröße und Anzahl der LEDs sind frei zu konfigurieren
• Eingänge: Composite (Cinch), S-Video, RGB, YPbPr und SCART
• HDMI-Fähig mit entsprechendem HDMI-Splitter und Signal-Wandler
• USB2.0 und Bluetooth 2.0, zur Anpassung der Konfigurationseinstellungen per PC oder Android App
• 80 Farbkanäle (die Anzahl der möglichen Farben die um den Bildschirm-Rand herum dargestellt werden können)
• Videoanalyse in Realtime (jedes empfangene Bild wird analysiert bei voller Framerate und ohne zeitlichen Versatz wiedergegeben)