Show Posts
Pages: 1 2 [3] 4 5 ... 23
31  International / Deutsch / Re: Fernbedienung on: May 16, 2014, 10:54:51 am
Zuerst musst Du die Library ordnungsgemäß installieren.

http://arduino.cc/de/Guide/Libraries

Dann startest Du die Arduino IDE neu und probierst die mitgelieferten Demos aus (gehe zum Menüpunkt File->Examples->IR...)

Ich würde mit IRrecord anfangen.

Hochladen.

Tools->Serial Monitor aufmachen.

Taste auf Fernbedienung drücken.

Lesen, was im Serial Monitor Fenster steht.

P.S. Bin ab jetzt bis Montag offline. Viel Erfolg!
32  International / Deutsch / Re: Fernbedienung on: May 16, 2014, 10:12:16 am
Das ist doch ein Anfang.

Nächster Schritt:  der Fernbedienung zuhören, also Signale empfangen.

Schau Dir das mal an: http://www.righto.com/2009/08/multi-protocol-infrared-remote-library.html

Quote
The examples/IRrecvDemo sketch provides a simple example of how to receive codes:

Gruß

Helmuth
33  International / Deutsch / Re: Fernbedienung on: May 16, 2014, 09:50:14 am
Sehe ich genauso, dem ist nichts hinzuzufügen.

Außer vielleicht, dass man hier in der Regel binnen Minuten/Stunden eine Anwort auf eine konkrete Frage bekommt, welche möglichst präzise beschreibt, was Du schon getan hast und an welchem Punkt Du nicht weiterkommst.

Grüße

Helmuth
34  International / Deutsch / Re: Bauteil entwickeln und herstellen lassen? on: May 16, 2014, 07:41:30 am
Ich habe für den Anfang die Verwendung eines existierenden Treiber ICs vorgeschlagen - konkret einen LPD8803.

Der hat zwar auch nur 8 Bit und ein 2 Draht Interface, aber er ist ziemlich schnell (20 MHz) und hat eine PWM Frequenz >4 kHz, was die mangelhafte Farbtiefe relativiert, da man dann via Software interpolieren kann (Dithering).

Und das würde in einem 5050 Gehäuse mit 6 Pins auch theoretisch funktionieren: Data+Clock in/out, Vcc, GND  smiley

An Kickstarter habe ich bereits gedacht und im Gespräch auch erwähnt - schließlich kann ich denen ja viel erzählen, eine Vorbestellung im 6 oder 7stelligen Dollarbereich würde da eine andere Sprache sprechen... wobei das aus deren Sicht immer noch wenig ist.

Auf meine Frage, ob sie vielleicht was ähnliches auf ihrer eigenen Roadmap haben, haben sie sehr ausweichend geantwortet, jedenfalls nicht mit einem klaren "nein".

Bin gespannt, wie es nächste Woche weitergeht, wenn mein Anliegen dem zuständigen Don vorgetragen wurde.

@Addi: Ich fürchte, so eine Entwicklung sprengt ein Hochschulbudget... Ist aber ein Plan B, fragen kostet ja nix.
35  International / Deutsch / Re: Regelungsproblem on: May 16, 2014, 05:49:32 am
Ah, so meinst Du das. Es sind übrigens (leider nur) 3 * 8 = 24 Bit Farbwerte. Ja, pro Farbe 10 bis 15 vom Wert abzuziehen ist ein Bereich, der hinkommt.

Falls Interesse, hier der Code von dem Spiralvideo (mit Jurs tollem Timer): http://pastebin.com/pFdQSsFD

@jurs: Hier mal noch ein Video, was das Temporal Dithering bei niedrigen Helligkeiten macht:



36  International / Deutsch / Re: Bauteil entwickeln und herstellen lassen? on: May 16, 2014, 05:28:05 am
Der Erstkontakt war vielversprechend... ich berichte weiter.
37  International / Deutsch / Re: Regelungsproblem on: May 16, 2014, 05:16:50 am
Quote
bei z.B.10bit bis 15bit "weniger" Helligkeitswert

Den Satz verstehe ich nicht.

Ja, die eigene Dynamik, welche sich aus den Wechselwirkungen ergibt ist das eigentlich Spannende. Ich bin auch immer wieder überrascht und fasziniert, was alles passiert, wenn man 3 für sich genommen total simple Vorschriften kombiniert - das kann ich mir vorher nicht/nur schwer vorstellen/ausdenken - aber staunen, wenn ich es dann sehe.

Wenn ich o.g. Problem in den Griff bekommen würde, könnte ich z.B. auch ein paar Dutzend Emitter/Stream Funktion via Zufall kombinieren und würde ziemlich lange immer wieder was neues sehen...

Schön, dass Dir mein Zeug gefällt. Und wenn sie es nicht mag, muss sie ja nicht hinschauen... Muss Du ihr halt mal im richtigen Moment im passsenden Bewustseinszustand vorführen... smiley-wink

Ja, bis jetzt habe ich alles mit integer Rechnungen hinbekommen und das soll auch so bleiben.

Danke für den Link, da lese ich mich mal in Ruhe ein.

Sitze übrigens wie auf Kohlen, bis meine MSGEQ7 endlich kommen und ich Ereignisse synchron zum Sound auslösen kann... Das ist das nächste Level, aber ja...erstmal dieses hier in den Griff bekommen.

Beste Grüße

Helmuth
38  International / Deutsch / Re: Regelungsproblem on: May 16, 2014, 04:40:23 am
Hatte gerade noch die Idee, einen "Autoadjust" Modus zu bauen, wo bei einer Effekt Kombination bright über z.B. 1 Minute lang beobachtet wird und das das dann nacheinander mit 50 Korrekturfaktoren durchgespielt wird wird, um anzuschätzen zu lassen, welcher am besten passt.

Wäre aber nur ein Workarround und keine Echtzeitregelung...
39  International / Deutsch / Re: Regelungsproblem on: May 16, 2014, 04:27:57 am
Nochmal @jurs: Wenn Du selbst damit arbeitest, könnte Dich vielleicht interessieren, dass nach FastSPI_LED2 die FastLED Lib herauskam und wir momentan die Beta von FastLED v2.1 testen - bisher ohne Probleme.

[urlhttps://github.com/FastLED/FastLED/tree/FastLED2.1[/url]

Temporal Dithering bei niedrigen Helligkeiten, neue flotte Wellenfunktionen, Multikanaloutput auf ARM, u.v.m....

40  International / Deutsch / Re: Regelungsproblem on: May 16, 2014, 04:13:23 am
@jurs: Ich habe schon damit gespielt, vor der Addition zu prüfen, was passieren wird und es gegebenenfalls zu verhindern, aber dann geht viel Effekt verloren, weil die sich im weißen Bereich ergebende Form sehr spannend ist. Schau nochmal dieses Video ab 0:35 an: https://www.youtube.com/watch?v=0Ehj7sEwOy4

Wenn dieser Ansatz, dann müsste man noch einen Counter einfügen, welcher z.B. nur 2/3 von allen als weiße Pixel erlaubt und dann gegensteuert.

Eine RGB zu HSV Funktion gibt es nach meinem Wissen noch nicht, aber ich schau nochmal. Kann ich mir gerade schwer vorstellen, wie das gehen soll, da HSV auf einer Lookup Tabelle für H basiert und S und V  diesen Wert nur in Richtung weiß / schwarz verschiebt = ein Großteil des RGB Farbraums ist in HSV nicht beschreibbar (jedenfalls nicht mit 8 Bit für Hue)?!

@volovodani:
Quote
Regler beginnt bei einem Wert >230 zu arbeiten und gibt dir dann einen Korekkturwert aus

Das klingt vielversprechend. Bleibt die Kernfrage, wie man den Korrekturwert beschreiben könnte.

Quote
Du bekommst aus diesem Regler dann eine Abweichung im Sinne eines Korrektuwertes diesen Wert dann in deinen Faben Logarithmus eingebaut

Was meinst Du mit Farben Logarithmus? Und ja, genau um die Ermittlung dieses Korrekturwertes geht es mir.

Die Idee mit verschiedenen Reglern /Korrekturen für R, G und B gefällt mir gut, weil das "dunke" (dreckige) weiß tatsächlich auch ein (kleines) Problem ist.

Aber nochmal: Irgendeine Idee, WIE ich den Korrekturwert errechnen könnte?
41  International / Deutsch / Re: Design Ideen für LED Deckenbeleuchtung mit LED Stripes gesucht. on: May 16, 2014, 03:47:17 am
Das im Video zu sehende modellierte Partikelsystem ist nicht von mir sondern von Gilad Dayagi.

Alles wichtige findest Du hier: https://github.com/giladaya/arduino-particle-sys

Das ist alles für einen Colorduino gemacht - Du musst also mindestens die drawMatrix() umschreiben und eine LED Lib Deiner Wahl einbinden, aber der Aufwand ist überschaubar...

Zu 1-dimensonalen simulierten Flammen auf einem  Strip sei noch Mark Kriegsmanns Fire2012 erwähnt: http://pastebin.com/xYEpxqgq

Na dann ein schönes Wochenende....

Gruß Helmuth
42  International / Deutsch / Re: Regelungsproblem on: May 15, 2014, 07:01:54 pm
Hallo pylon,

offensichtlich habe ich mich immer noch unklar ausgedrückt. Deine Anmerkungen sind alle zutreffend, helfen jedoch noch nicht weiter.

Alle Effekte, die ich bisher geschrieben habe, funktionieren in einem Array: CRGB leds[NUM_LEDS]

Alle Effekte basieren auf der Addition von Farben verschiedener Pixel, z.B.

Code:
leds[i] += leds[i + 1];

Was passiert bei der Addition? Das Ergebnis wird heller. Dabei entstehen schöne Mischfarben - aber nur, wenn das Ergebnis "im Rahmen bleibt". Addiert man z.B. sattes gelb zu sattem cyan (weil die nebeneinanderliegenden Pixel gerade zufällig so aussehen) ist das Ergebnis weiß. Soweit kein Problem für diesen einen Pixel, aber:

Diese Additionen laufen in mehreren Iterationen - also werden immer mehr Pixel weiß. Weiß + x = weiß. Bis zu einem gewissen Punkt ist das ok - so lange noch Stuktur/Form im entstehenden Muster erkennbar ist - aber anschließend werden immer mehr und schließlich alle Pixel weiß.

Das gilt es zu verhindern.

Momentan mache ich das, indem ich vor/nach der Addition die betreffenden Pixel ein wenig runterdimme. Und genau das ist ein schmaler Grat. Dimme ich zu viel, "geht Farbe verloren" und das Ergebnis wird zu dunkel. Dimme ich zu wenig, driftet das Ergebnis immer mehr in Richtung weiß.

Wenn diese Balance von Hand eingestellt ist, ist alles schön - füge ich aber z.B. einen weiteren Emitter hinzu, muss ich das Ausmaß der Dimmung erneut anpassen, da plötzlich "mehr Farbe" auf dem Screen ist.

Hinter "durchschnittliche Helligkeit" (bright) feststellen steckt die Idee, dass sich viele weiße Pixel in einem relativ hohen bright Wert wiederspiegeln. Und mein Ansatz ist, in Abhängigkeit von bright (vor/nach dem addieren) mehr oder weniger stark runterzuskalieren, um in Abhängigkeit vom momentanen Bildinhalt und dem zu erwartenden Ergebnis nach der nächsten Addition dynamisch gegenzusteuern - so, dass das Ergebnis nicht zu dunkel (schwache Farben) und nicht zu hell (weiß) wird.

Und dieses Problem erinnerte mich an die Lagestabilisierung des Quadrocopters - wo es auch darum geht, verschiedene unvorhersehbare und wechselwirkende Einflüsse auszugleichen und einen relativ stabilen Gesamtzustand des Systems herbeizuführen.

Jetzt nachvollziehbar?

Gruß Helmuth

P.S. Ich bin mir jedoch nicht sicher, ob die Kenntnis des bright Werts allein hinreichend für die Lösung des Problems ist.

edit: Wenn bright 255 ist, ist auf jeden Fall etwas schiefgelaufen. Wenn bright mal kurz 0 wird, macht das nichts, weil die (pulsierenden) Emitter in Kürze "neue Farben säen".

Quote
Soll das heissen, Du möchtest mit der Funktion sicherstellen, dass der ermittelte Wert "bright" nach der Ausführung einen konstanten Wert hat?

Nein, ich möchte einerseits sicherstellen, dass er nicht oder nur kurz 255 erreicht und andererseits nur kurzfristig (z.B.) < 50 wird. Die Untergrenze muss man wohl je nach Effekt festlegen. Wahrscheinlich muss man bright zusätzlich im Zeitverlauf beobachten und je nach Anstiegs-/Abfallgeschwindigkeit gröber oder feiner gegensteuern.

Aber wenn ich mir ansehe, was die Leute hier für Probleme haben, die passenden Parameter für eine PID Regelung zu ermitteln, befürchte ich, dass das das Problem der Handarbeit auch nur verschiebt. Wobei mich grundsätzlich ein leicht schwingendes System nicht wirkich stören würde.
43  International / Deutsch / Re: Bauteil entwickeln und herstellen lassen? on: May 15, 2014, 06:07:08 pm
@Doc: Danke für Deine PN. Und ich habs doch nicht erfunden, ich träume nur von der Kombination einer existierenden Bauform mit anderen existierenden Bauteilen/Spezifikationen. 

@Serenifly: Zweifellos gehört das in die Hände eines Profis, der das Know-how für Entwicklung und Fertigung (und Marketing) hat.

Ich versuche morgen mal jemanden bei Woldsemi zu erreichen, der mich hoffentlich nicht sofort auslacht. smiley-wink
44  International / Deutsch / Re: Bauteil entwickeln und herstellen lassen? on: May 15, 2014, 05:44:19 pm
Noch mal ganz klar meine Absicht: Ich sehe ein Massenprodukt, worauf viele warten. Es geht mir nicht um die Entwicklung eines Prototypen für mich allein.
45  International / Deutsch / Re: Bauteil entwickeln und herstellen lassen? on: May 15, 2014, 05:34:34 pm
Ok, man müsste also eine Chip- und einen LED Hersteller kontaktieren.

Hat jemand persönliche Kontakte zu einem von beiden?

Irgendjemand (Worldsemi?) hatte ja schließlich auch mal die gute Idee, die WS2812Bs herzustellen - und damit quasi einen neuen Standard gesetzt.

Ich vergleiche das nicht mit irgendetwas, dafür hab ich zu wenig Ahnung von der Materie. Ich habe nur einen Traum und frage mich, ob und wie man den materialisieren könnte.
Pages: 1 2 [3] 4 5 ... 23