Hallo, Ich habe bis dato noch keine Ahnung von Controllern, hoffe dies aber ändern zu können. Mit der Suchfunktion habe ich nichts passendes gefunden. Ich bin Jongleur und möchte mir steuerbare LED-Geräte bauen. Nach ein wenig Recherche meine ich ein ATMEGA32-16PU sollte für meine Zwecke reichen. Ich würde gerne aber doch nochmal eure Meinung hören. Die Anforderungen an das Konstrukt sind: -5 Dreiergruppen RGB-LEDs müßen von einem Controller angesteuert werden können. Für eine spätere Version sollte eine Controller als Upgrade verfügbar sein, der 15 Sechsergruppen RGB_LEDs steuern kann. -Mehrere Controller (in unterschiedlichen Geräten) müßen bei gleichzeitigem Start nach 30 Minuten immer noch ohne merkbare Abweichung synchron sein. -Laufsicherheit trotz mechanischer Belastung (Erschütterungen...) -Die Controller sollten in einem Rohr mit 20mm Innendurchmesser verbaut werden können. -Der Stromverbrauch bei Akkubetrieb sollte 2h Dauerbetrieb zulassen. Vielen Dank für jede Hilfe, gé
Salut. Ich kann mir das ganze nicht so bildlich vorstellen, du möchtest aber vermutlich LEDs in so rumzuwirbelnde Stäbe einbauen? Solange du passende Akkus hast, die das Ding nicht aus der Balance bringen, sollte die MCU kein Problem darstellen.. aber: warum die DIP-Version, eine kleine Platine zur Stabilisierung der LEDs brauchst du eh, da kann man dann auch die smd-version auflöten. Synchroner start... innerhalb eines Gerätes kein Problem, kann man ja koppeln. Über mehrere Geräte: Funk, IR, Ultraschall, Reset-Taster.. Viele Wege führen zum Ziel.. Gruss, Tim
Hi, bezüglich des synchronen Laufs...
> ohne merkbare Abweichung synchron
Damit meinst Du vermutlich, vom Menschen bemerkbar, oder? Also ein paar
Millisekunden sind wohl erlaubt; die sieht man sicherlich nicht.
Wenn's die Mechanik mitmacht: Vielleicht geht's ja mit so Art
Klinkenbuchsen an einem Stabende. Die gibt's mit Schaltkontakt. Damit
könntest Du mit eingestecktem Stecker die Akkus laden und wenn Du den
Stecker ziehst, geht der Schaltkontakt zu und versorgt die Schaltung.
Beim Auftritt musst Du dann nur alle gleichzeitig aus der
Ladevorrichtung entnehmen... Das halte ich für leicht möglich.
Zur Schaltung selbst: Auf jeden Fall einen Quarz mit hoher Frequenz
verwenden und dann kräftig runterteilen; das sollte für diese kurze
Zeitspanne spielend ausreichen.
Hast Du noch ein paar Infos? Genaueres drunter vorstellen kann ich mir
nämlich auch noch nicht...
Viele Grüße,
Michi
Hallo, der Interne Oszillator kann es sehr wahrscheinlich nicht ausreichend Synchronhalten. Mit einen Quarz sollte es aber Problemlos sein. Du könntest dir aber überlegen alle per Infrarot zu Synchronisieren. Gruß Peter
Hi, Danke für die schnelle Antworten! Das mit den Stäben geht in die richtige Richtung. Zur bildlichen Vorstellung von dem was ich mit meinen derzeiteigen Geräten mache: http://light-motion.net/galerien/schwarzlicht/ Bloss bin ich von der Leuchtstärke und der Vielseitigkeit von dem was ich jetzt habe nicht überzeugt. Langfristig will ich dann auch eine Steuerung über Funk bzw. IR (Würde das überhaupt bei sich schnell bewegenden Objekten funktionieren?) oder Effekte mit Fliehkraft-Sensoren einbauen. Aber ich will erstmal die Basics verstehen. smd hat mich schonmal überzeugt. Den synchronen Start würde ich manuell mittels Taster machen. Wenn nach einer halben Stunde ein Gerät mit ein paar ms versetzt läuft ist das voll in Ordnung. Wie groß wäre denn so ein Quarz? Für einen Kippschalter um vom Ladebetrieb in Spielbetrieb zu wechseln, wäre genügend Platz. Grüße, gé
Gerald Richter schrieb: > Den synchronen Start würde ich manuell mittels Taster machen. Wenn nach > einer halben Stunde ein Gerät mit ein paar ms versetzt läuft ist das > voll in Ordnung. Wie groß wäre denn so ein Quarz? In SMD ist der Quarz so groß wie eine Linse (schlagt mich jetzt nicht). Das ist das letzte, was Dir Sorgen machen wird. Zum gleichzeitigen Starten sehe ich eher ein IR-Protokoll als praktikabel an. Ein starker Sender, der alle Empfänger auf eine Zeitbasis einstimmt, damit es gleichzeitig starten kann...
Tolles Spielzeug :) Ich bin kein Jongleur, habe bisher nur einmal Kugeln mit LEDs gesehen - teuer, Batterie nicht wechselbar, weil komplett in Epoxy eingegossen. Für die Synchronisierung (oder Bootloader zwecks Firmware Updates) wäre das iDropper-Verfahren schlau. http://www.merl.com/publications/TR2003-035/ Für extra Effekte könnten Beschleunigungssensoren recht spektakulär sein. Zum Aufladen gibts das hier : http://en.wikipedia.org/wiki/Resonant_energy_transfer Das Vergiessen scheint mir schon sinnvoll, sonst ist der Kram schnell kaputt. Insgesamt ein sehr spannendes Projekt, da lernt man so einiges. Was Quarze angeht, ein billiges SMD-Quarz vom Reichelt misst 13 x 4,7 mm - nicht besonders klein, aber extrem genau : Frequenztoleranz ± 50 ppm (ppm heisst "parts per million") Temperaturkoeffizient ± 30 ppm ... für 24 Cent einzelpreis.
Zum Synchronisieren ich war vor kurzem mal beinem TV-Interview an ner Autobahn dabei, waren 3 Kameras, die werden alle über BNC Kabel zusammengestöpselt und laufen dann ununterbrochen durch, so kann man später cutten ohne sich darum kümmern zu müssen das Ton und Bild unsynchron werden. Beim Film wird das mithilfe der "Klappe" gemacht, den Peak der beim zuschlagen ensteht kann man nacher bei allen Spuren übereinanderschieben und schon ist alles Synchron. Sowas würde ich auch in deinem Fall machen, einfach in jeden Stab zwei Klinkenbuchsen oder sowas, das ganze auf per Optokoppler von allen Schaltungen getrennt auf irgendnen Pin der bei wenn man ihn auf High zieht die Show startet. IR wär natürlich auch gut, da könnt man dann zeitweise ausmachen, oder ne andere Show fahren usw.
Die Fragestellung klingt super interessant. Sind es Kugeln, die du jonglierst.. sowas wie Tennisbälle ? Kugeln mit LED ... ja? .. dann IR-led überall dazwischen. diese machen dann den Takt... und ggf. noch das "Master / Slave" system. wird wohl sehr toll aussehen. Klaus
ok leute, ihr meints bestimmt gut mit mir, aber ich würde gern nochmal daran erinnern, daß ich vorher noch nix mit Elektronik gemacht habe. Für mich ist es schon Science-Fiction, wenn ich einen schnuckligen, überschaubaren Schaltplan verwirklicht habe, und nachher ein paar LEDs so blinken wie sie sollen. IR-Synch schiebe ich erstmal in die nächste Projektphase, da werde ich euh bestimmt noch mit Fragen löchern ;) Da keiner von euch sich explizit gegen den ATMEGA32-16PU ausgesprochen hat, scheint er wohl (mit Quarz) den Anforderungen von meinem Projekt zu entsprechen. Gibt es diesen Controller auch als smd und wenn ja, wo kann ich das bestellen? Kurz noch was ich mache: Ich bin Spinning-Jongleur mit Poi und Stäben, d.h. ich habe Kugeln oder ähnliche Objekte an Schnüren oder Ketten bzw. Stäbe die geschwungen werden. @ohforf: Wie rechne ich 50ppm Ungenauigkeit bei 10MHz auf 30 Minuten hoch? Liege ich da mit 90ms richtig? @david: sorry, daß mit den Klinkenbuchsen und Oktokoppler check ich nicht.
Hallo Gerald, darf ich daran erinnern, dass die meisten hir noch nie jongliert haben. Meinst du nicht, dass es für all die elektronischen Geister hier hilfreich wäre, zu verstehen um was es genau geht. Ich selbst bin bei "Ich bin Spinning-Jongleur mit Poi und Stäben" eigentlich schon überfragt. (kann man das essen ?) Wir kennen POTIS und STABile Spannungen. Hast du nicht einen Link auf ein Youtube Video , was deine Frage verdeutlichen könnte ? Gruss Klaus
Klaus De lisson schrieb: > @ohforf: Wie rechne ich 50ppm Ungenauigkeit bei 10MHz auf 30 Minuten > hoch? Liege ich da mit 90ms richtig? Ja, nach meiner Rechnung sind 90ms richtig. Mit vernünftigem Aufwand gehts nicht genauer. Die Temperatur wird eh für alle Quarze gleich sein, wenns unbedingt sein muss kann man die alle auf gleiche Frequenz abgleichen - dann wirds fast perfekt genau.
Freut mich, daß euch das interessiert. Ich dachte für den Elektroniker reicht zu wissen, daß das fertige Produkt durchaus auch mal gegen den Fußboden oder Hart- und Weichteile des menschlichen Körpers geschmettert werden kann. Spinning-Jonglage ist eine Jonglage-Form, bei der die Objekte nicht geworfen werden, sondern gedreht, bzw. geschwungen. Ein Poi ist eine Kugel o.ä. an einer in etwa armlangen Schnur oder Kette. Im Normalfall wird mit jeder Hand ein Poi geschwungen. Stäbe werden meist um ihren Mittelpunkt gedreht. Beim Zuschauer wird durch die Trägheit des Auges der Bewegungsweg des Objektes teilweise als Band sichtbar. Video-mässig habe gerade nur was mit Feuer, aber da sieht man in etwa um welche Bewegungen es geht: http://www.youtube.com/watch?v=E1XGc9mtqsY&feature=player_embedded Die Bilder in meiner Foto-Galerie sind meist Langzeitbelichtungen von 1-2 Sekunden. Die Lichtlinie auf den Bildern zeigt den Weg, den das Leuchtteil in der jeweiligen Zeit zurückgelegt hat: http://light-motion.net/galerien/schwarzlicht/
Das stimmt nicht: --------------------------------------------------- Klaus De lisson schrieb: > @ohforf: Wie rechne ich 50ppm Ungenauigkeit bei 10MHz auf 30 Minuten > hoch? Liege ich da mit 90ms richtig? ---------------------------------------------------------- ---- hab ich nicht geschrieben aber Gerald: das sieht toll aus, mit dem Feuerpoi. ... und deine Fotogalerie ist wirklich der Knüller Wenn ich allerdings die Feuerpoi sache anschaue, komme ich an dem Gedanken nicht vorbei, dass du evt. einen Masterclock benötigst. Selbst wenn alle quartze sehr genau sind, ist alles ausserhalb des Taktes, da du es ja einschalten musst. vielleicht geht ja eine kleine Senderschaltung am Halsband, die den Masterclock liefert. Diese Biester nennen sich OOC transmitter und receiver. Bekommt man im Zweifel bei Conrad und anderen Konsorten. Die Akkus kannst du in die Stäbe einbauen. (Hobbydrachen -> kohlefaserstäbe) Beim Betrachten des Video dachte ich allerdings sofort an ein EXTRA. Eine kleine Xenon-Blitzlampe , die losgeht, wenn du den Knopf drückst. Das wird dein Publikum erfreuen. (Schreck und Adrenaline)
Ohforf Sake schrieb: > Klaus De lisson schrieb: >> @ohforf: Wie rechne ich 50ppm Ungenauigkeit bei 10MHz auf 30 Minuten >> hoch? Liege ich da mit 90ms richtig? > > Ja, nach meiner Rechnung sind 90ms richtig. > Mit vernünftigem Aufwand gehts nicht genauer. > Die Temperatur wird eh für alle Quarze gleich sein, wenns unbedingt sein > muss kann man die alle auf gleiche Frequenz abgleichen - dann wirds fast > perfekt genau. Ist aber kein wirkliches Problem. Ähnlich wie bei dem bekannten Artikel über die 'genau Sekunde' kann man hinten nach den Quarz ausmessen und dann mit dem CTC alle µC auf noch viel weniger Abweichung in den Blinkfrequenzen bringen. Das seh ich eigentlich nicht als das große Problem. Schwieriger stell ich mir den synchronen Anfang des jeweiligen Programms vor. Da würd ich von Anfang an auf Infrarot setzen. Alle µC warten nach dem Einschalten auf einen IR-Puls, der von einer zentralen Stelle aus gegeben wird. Das sollte so nicht weiter schwer zu realisieren sein. Ob es genügend störsicher ist, ist eine andere Frage. IR hätte noch einen anderen Vorteil: Man könnte es, ähnlich wie beim Asuro, zur Übertragung des Leuchtprogramms benutzen. Problematisch hingegen ist, dass du noch keinerlei Erfahrung mit Elektronik bzw. µC hast. Die Schaltung an sich ist nicht das große Problem. Ein Mega32 ist weit überdimensioniert für deine Zwecke, ist aber egal, die Mehrkosten sind sicherlich nicht das Problem. Die Anforderungen an deinen µC würde ich in etwa so kategorisieren: Irgendwas um die 4 bis 8k Flash und soviel EEPROM wie du kriegen kannst. Pins brauchst du nicht allzuviele, die LED könnte man als Matrix oder über Schieberegister ansteuern. UART wär gut (wegen einspielen des neuen Lichtprogramms) Auf den µC kommt ein Universalprogramm, welches ein 'Lichtprogram', das in Datenform vorliegt, aus dem EEPROM auf ein Startsignal hin abspielt. Das Universalprogramm selbst ist nicht das große Problem. Schwieriger wird hingegen schon die Erstellung des 'Lichtprogramms'. Wenn du nicht nur einfache Dauerblinksequenzen machen willst, wird man ev. ein paar Hilfsmittel auf dem PC machen. Zur Not geht auch ws mit einem einfachen Texteditor.
moinmoin, @ Klaus: Nette Idee, so ein Licht-Schock! Und die Zuschauer kriegen vom Rest der Aufführung nix mehr mit weil sie nur noch Sternchen sehen... 8D Das Einschalten mit einem Taster werde ich von Hand synchron genug hinkriegen. Ich habe ja nur 2 Teile, und dementsprechend 2 Hände. Langfristig wird da auch noch ein Master-Synch gebastelt, aber ist IR da das richtige? Wenn ich mir vorstelle, die Fernbedienung eines Fernsehers wild durch die Gegend zu schleudern, erwarte ich nicht, daß alle Signale ankommen... Karl heinz Buchegger schrieb: > Problematisch hingegen ist, dass du noch keinerlei Erfahrung mit > Elektronik bzw. µC hast. Ich sehe das nicht als Problem, sondern als Herausforderung. Ich bin zwar nicht besonders clever, aber als Jongleur immerhin frustrationserprobt... Da mir smd vorgeschlagen wurde, liebäugel ich nun mit einem ATMega 8535L-8P. der hat 512B eeprom, das sollte erstmal reichen. Welche Platine nehme ich am besten, wenn ich diesen nachher in einem Polycarbonat-Rohr mit 20mm Innendurchmesser einbauen will? Von der Steuerung hatte ich gedacht ein Programm mit verschiedenen blink- Strob- und Farbverlaufs-Funktionen in den Flashspeicher zu laden. Im eeprom wird dann eine Sequenz geladen, die angibt welche Funktion mit welchen Parametern wielange gespielt wird. Eine Matrix zu multiplexen ist vom Namen allein schon ansprechend. Habe ich den Aufbau richtig verstanden? Meine Matrix hätte 3 Spalten (für die Rot-, Grün- und Blauphase) und 5 Zeilen. Für jede Spalte geht von einem I/O-pin ein Signal über einen Transistor und Vorwiederstand zum Schieberegister wo das Signal dann abwechselnd zu einer der 5 LED(-Gruppen) geleitet wird. Beste Grüße, gé
@Gerald: Magst Du vielleicht mal aufzeichen, wie Du die Dinger "geographisch" anordnen willst? Beim Multiplexen sehe ich nämlich schon ein gewisses Risiko, dass Du plötzlich "dunkle" Stellen in der Bahn haben wirst. Wenn die LEDs still stehen, klappt das prima, aber sobald die sich schnell bewegen, fällt das schon auf, wenn die mal für ein paar Millisekunden dunkel sind (weil dann gerade andere LEDs an sind). Nicht dass dann nachher nur der halbe Kreis zu sehen ist :-( Vielleicht geht's ja auch ohne Multiplex... Dann lieber ein paar Bauteile / Pins mehr nehmen...
Hallo! Handelt es sich bei den 50ppm Ungenauigkeit um +/-50ppm, dann müsste man die 90ms im schlimmsten Fall auf 180ms verdoppeln, was eigentlich schon ziemlich viel ist. Sollte jedoch die Genauigkeit der Quarze ausreichen, sodass während des Jonglierens keine Synchronisierung erforderlich ist, könntest du ja auch deine Stäbe in eine art selbstbebaute (Lade-)Station stellen, die die Akkus auflädt und einen einzelnen Taster für die Synchronisierung aufweist. Drückst du den Taster der Ladestation, dann synchronisieren sich alle Stäbe, die in dieser eingehängt sind, danach nimmst du sie aus der Halterung und kannst damit deine Kunststücke machen. Der Vorteil dabei ist, dass du nich irgendwelche Übertragungsprotokolle über Infrarot realisieren musst und die Synchronisierung nur über einen einfachen Taster geht, der sich in der Ladestation befindet und über Kontakte mit den eingehängten Stäben verbunden ist. Würde mich aber sehr interessieren, wie dein Projekt weiter geht und für welche Technologien du dich entscheidest, Taster, Funk, Infrarot. Schöne Grüße Sebastian
Michael B. schrieb: > Wenn die LEDs still stehen, klappt das prima, aber sobald die sich > schnell bewegen, fällt das schon auf, wenn die mal für ein paar > Millisekunden dunkel sind (weil dann gerade andere LEDs an sind). Nicht > dass dann nachher nur der halbe Kreis zu sehen ist :-( Hmm. An dieser Argumentation ist was drann. Das sollte man durchrechnen. Wichtig wäre zu wissen, mit welchen Bahn-Geschwindigkeiten zu rechnen ist. Denn: Da du ja auch dimmen willst (für Farbübergänge) ist PWM zunächst der erste Ansatz, sofern das nicht so ausartet, dass du keine dunkelrote LED rumwirbelst, sondern eine LED die sichtbar blinkt
Ihr solltet auch noch bedenken das Quarze relativ erschuetterungsempfindlich sind. Das sind die Teile die bei FBs und USB Sticks gerne kaputt gehen wenn sie runterfallen. Ich wuerde also darauf achten einen Quarz oder Taktgenerator zu verwenden der Erschuetterungen aushaelt. Olaf
Die Teile werden maximal in einem Kreis mit 3m durchmesser in 500ms geschwungen. Das macht eine Geschwindigkeit von 18m/s. Wenn ich das Datenblatt verstenden habe, hat der ATMega8535L-8P 32 I/O-Pins von denen ich 16 für PWM nutzen kann. Dann bräuchte ich keine Matrix, aber für jede LED-Gruppe einen eigenen Transistor. Ich bastel gerade mal einen Schaltplan... @ Olaf: Danke, das ist ein wichtige Info für mich. Gibt es da irgendein Qualitätsmerkmal auf den Datenblättern, oder erkenne ich das am Preis?
@Gerald: Schau Dir mal die "CSTCE 8,00" (z.B. bei Reichelt) an. Die Dinger sind sehr klein (ca. 4,5x2mm) und haben eine hohe Schockfestigkeit. Da Du eh SMD machen willst, wären das vielleicht brauchbare Teile. Sind etwas blöder zu löten, aber ist trotzdem machbar. Und bei FB etc. brechen ja meist die großen Schwinger ab, weil die eine entsprechende Masse und damit Trägheit haben.
bitte nicht lachen, das mit den Schaltplänen hab ich noch nicht so drauf...
Gerald Richter schrieb: > bitte nicht lachen, das mit den Schaltplänen hab ich noch nicht so > drauf... Versuchs mal mit Eagle - dann wirds besser lesbar.
> bitte nicht lachen... Wieso sollten wir? Ist doch o.k.; jetzt kann ich mir zumindest mal was drunter vorstellen. Unter >5 Dreiergruppen RGB-LEDs und > 15 Sechsergruppen RGB_LEDs konnte ich mir nichts vorstellen Also benötigst Du (aktuell) 15 Pins für die LEDs.... Das ist noch eine Anzahl, die locker machbar ist. Bei dem Upgrade (mit dann wohl 15x6 = 90 Pins) wird's eng :-) Vorallem, wenn Du auf 20mm beschränkt bist... Die UART willst Du wegen...?!? Programmupdate? Vielleicht kann man die irgendwie mit der Ladebuchse kombinieren (z.B. Stereo 3,5 Klinke). Dürfte mechanisch einfach sein, eine Buchse einzubauen, als Platz für zwei zu finden... Wegen der Platine.... Da hattest Du gefragt, welche man da am Besten nehmen kann... Ich vermute, da wird's keine fertige geben, also selber machen (oder machen lassen). Was bevozugst Du da?
Also, ich verstehe die Wahl des Controllers nicht so ganz. Gibt es einen besonderen Grund für den 8535? Bei 15-16 Kanälen wird man die PWM so oder so von Hand machen müssen und ich habe das Bauchgefühl, dass man mit 512 Bytes EEPROM sehr schnell am Ende des "Leuchtprogramms" ist. Angenommen man will (nur) 16 Abstufungen pro Kanal haben, dann landet man bei 8 Byte für einen einzelnen Zustand der LEDs. Das heißt, man kann 64 verschiedene Zustände im EEPROM speichern und hat damit noch keinerlei Timing-Informationen. Man kann also bei einer 30-Minuten Performance (?) alle halbe Minute mal einen Lichtwechsel machen. Mal einen kontinuierlichen Farbwechsel mittendrin? Kann man vergessen. Ich würde sogar soweit gehen, dass man über ein externes Flash nachdenken sollte. Und wie wäre es dann mit USB zum Laden und mit Daten bespielen? :-) --> at90usb162 oder atmega32u2, bei mehr IO-Bedarf ggf. auch atmega32u4. Das mit dem Akku ist auch noch eine spannende Frage: Wie baut man eine sinnvolle Lade- und Spannungsregelung für einen Lipo-Akku? Viele Grüße, Simon
Hallo, 18m/s ist ziemlich viel in meinen Augen. Da wird PWM nicht das allereinfachste da sie sehr schnell sein muss. (bei 50kHz hast du schon löcher von 0,36mm ich denke das fällt grad so nicht auf). Wenn du jetzt für jede Farbe 3 Bit haben willst dann bräuchstest du eine PWM-Auflösung von 400kHz wenn du nicht auf eine Hardware PWM zurückgreifen kannst wird das bei 15Kanälen schon etwas Knifflig. Mal ganz abgesehn davon wenn du gleichzeit noch Multiplexing machen willst. Denn bei 400kHz hast nur etwa 40 Taktzyklen dazwischen. Es gibt allerdings ICs mit intigrieten einstellbaren Konstantstromquellen. Das wird wohl für dich das einfachste sein. Ich habe leider grad kein Typ im Kopf. Aber da kann sicherlich jemand weiterhelfen. Gruß Peter
Man könnte natürlich auch überlegen, direkt ein fertiges LED-Modul zu nehmen, was die PWM alleine macht und nur z.B. seriell mit den Farbdaten bespielt wird. Ich selber besitze ein paar von den Shiftbrite-Modulen, die sogar noch in die 20mm-spec passen: http://docs.macetech.com/doku.php/shiftbrite Die kann man dann auch völlig problemlos auf beliebige Anzahlen ausdehnen, ohne etwas fundamental an der Hardware zu ändern. Vermutlich will man die LEDs ja nicht auf der gleichen Platine wie den Prozessor haben, damit man die ggf. tauschen und über die Länge des Sticks verteilen möchte. Muss man nur mal gucken, ob einem das Abstrahlverhalten der Shiftbrites passt. Es ist natürlich nur nach einer Seite und die Farbmischung ist auch nicht so dolle. Viele Grüße, Simon
Hallo, hier sind die gemeinten Chips. http://focus.ti.com/docs/prod/folders/print/tlc5922.html Gruß Peter
Hi, Bei Quarzen wäre ich vorsichtig, wie schon erwähnt, können die ziemlich empfindlich auf Stöße sein. Wäre ärgerlich, wenn ein Lichtmodul während der Vorstellung ausfällt (dazu noch der Reparaturaufwand). Praktikabler wäre da meiner Meinung den µC mit RC-Oszillator laufen zu lassen und fortwährend eine Synchronisation laufen lassen. Dazu einen kleinen IR-Sender (RF hat in den meisten Fällen auch Quarze) am Körper tragen, der wie ein Leuchtfeuer Zahlenfolgen sendet. Wird eine Zahl nicht empfangen, kann der Empfänger ja autonom weiterzählen. Dadurch dass man im Empfänger auch die Abstände der Leuchtfeuer messen kann, wäre auch eine durchgehende Anpassung möglich. Zusätzlich könnte man dadurch blitzschnell zwischen verschiedenen Programmen wechseln ohne groß an den Jonglierobjekten herumzufummeln. Für den Empfang dürfte sich sich IRMP anbieten. Was denke ich noch ein Punkt ist: du wirst die LEDs vermutlich nicht direkt am AVR anschließen können, da ihr Strombedarf weit über dem liegen dürfte, was die Ausgänge treiben können. Du brauchst Treiberstufen! ULN2803 als Stichwort. Ansonsten: PWM ist denke ich ein schlechter Tipp, wenn unterschiedliche Helligkeiten bei schneller Bewegung, dann über Strombegrenzung. Bezüglich den LED-Abläufen: Ich denke, dass deine Vorstellungen durchaus im längeren Minutenbereich mit mehreren Variationen sind und somit einiges an Programmen zusammenkommt. Da wird der EEProm schnell mal knapp. Für den Anfang würde ich die Abläufe einfach fest ins Programm nehmen, später wäre überlegenswert, das eigentliche Programm in den Bootloaderbereich zu schreiben und die Abläufe in den Flashbereich zu packen. Das aber erst, wenn du in Sachen µC-Programmierung auf festen Beinen stehst ;)
@Michael: Das Problem ist, daß das Licht 360° in alle Richtungen abstrahlen muß. Deswegen habe ich gedacht an jeder Stelle wo LEDs sein sollen, eine paralell geschaltete Traube von 3 Stück zu plazieren, die gemeinsam angesteuert werden. Das käme dann auf 60mA, was wohl für den I/O zu viel ist, deswegen die Überlegung mit Transistoren zu boosten. Das momentane Projekt mit 5*3LEDs soll ein recht kleines Jongliergerät von insgesamt max. 25cm ergeben. Das Upgrade wäre ein Stab von ca. 110cm. Dabei wäre der Akku und die Elektronik in der Mitte des Stabes unter dem Griff. Zu jeder Seite wären dann 15 LED-Träubchen á 3 LEDs. Jeweils 2 Träubchen könnte man symetrisch zusammenschalten, daher 6er-Gruppen. Ich dachte über UART kann ich am bequemsten neue Sequenzen für andere Shows aufspielen. Platinen selber zu ätzen wäre mir erstmal zu krass. Aber es gibt dich bestimmt so Lochplatten, wo man sich die LEiterbahnen als Kabel zieht. Ich hab leider keine gefunden die 18mm breit ist... @Simon: Der Controller war einfach der erstbeste, der so aussah als könnte er dienlich sein. Wenn sich herausstellt, daß ich mehr Speicher brauch, steige ich gerne um. Allerdings stelle ich mir eher vor mit Funktionen zu arbeiten, bei denen die Information sich auf "Wechsel für soundsolang von der Farbe zu der Farbe und zurück, dann blinke solange in dieser Frequenz..." beschränken. USB klingt natürlich verlockend, leider finde ich keinen Shop, wo der ATMega32U4 nirgendswo angeboten wird =(
Gerald Richter schrieb: > Allerdings stelle ich mir eher vor mit > Funktionen zu arbeiten, bei denen die Information sich auf "Wechsel für > soundsolang von der Farbe zu der Farbe und zurück, dann blinke solange > in dieser Frequenz..." beschränken. Ok, rechnen wir nochmal: zweimal Farbinformationen (15 Kanäle a - meinetwegen 3 bit) = 90 bit plus Zeitdauer plus "Programmmodus" - sagen wir mal optimistisch 96 bit = 12 Byte. Man kriegt also ca. 42 versch. Programme unter. Das klingt etwas besser, ist aber auch nicht so richtig großzügig... Vielleicht wirds noch besser, wenn man eine "Farbpalette" definiert und da dann reinreferenziert. > USB klingt natürlich verlockend, leider finde ich keinen Shop, wo der > ATMega32U4 angeboten wird =( Den gibt es z.B. bei Farnell, wobei er da aber im Moment leider nicht lieferbar ist. Den at90usb162/atmega32u2 findet man aber. Da muss man nur u.U. etwas mit den IO-Pins haushalten und wenn man tatsächlich ein i2c/spi-EEprom anschließen möchte, könnte es etwas lästig werden, was die Zuordnung der Pins angeht. Viele Grüße, Simon
Schade, da hatte ich mich schon in den ATMega32u4 verguckt, weil mich die 14 PWM-Kanäle beindruckt haben, aber leider ist der vorerst nirgendwo lieferbar. Der ATMega32U2-AU hat immerhin 5 PWM-Kanäle. Was macht jetzt mehr Sinn? Die PWM bei den übrigen 10 Kanälen per Software zu errechnen, oder über eine Matrix 3 LEDs pro PWM-Kanal anzusteuern? Das Problem ist, daß auch bei einer Geschwindigkeit von 18m/s keine Lücken von mehr als 5mm (0,027ms) auftretten sollten. Vielen Dank für die vielen guten Ratschläge!!! Ich möchte erstmal keinen externen Speicher einbinden, wenn ich dann mal an die Grenzen komme, kann ich ja immer noch nachrüsten, hoffe ich. Schöne Grüße, gé
Also prinzipiell denke ich, dass 5 PWM auch reichen könnten. Der "Verkabelungsaufwand" würde halt steigen und, was noch schlimmer wäre, die Anzahl der µC-Pins würde sich mehr als verdoppeln. Zumindest wenn sich keine bessere Lösung finden würde. (Sicherlich schlechte, aber gerade einzige) Idee: Du könntest je einen PWM-Ausgang auf einen Eingang eines AND-Gatters legen (pro LED ein Gatter) und am anderen Eingang einen freien PIN vom µC. Am Ausgang dann die LED(Transistoren). Somit könntest Du mit dem "EnablePWM-Pin" des µC festlegen, welche LED gerade dimmbar sein sollte. Da die LEDs aber sicherlich ja auch "mal" dauerhaft leuchten sollen und die PWMs dann andere LEDs steuern sollten, müsste zusätzlich pro LED noch ein µC-"DauerAnPin" benutzt werden. Also 2 Pins pro LED; das ist echt schlecht, aber damit könntest Du gleichzeitig bis zu 5 beliebige LEDs dimmen und den Rest leuchten lassen. Vielleicht stehe ich auch nur gerade auf der Leitung und jemanden fällt eine bessere Schaltung ein...
Gerald Richter schrieb: > Was macht jetzt mehr Sinn? > Die PWM bei den übrigen 10 Kanälen per Software zu errechnen, oder über > eine Matrix 3 LEDs pro PWM-Kanal anzusteuern? > > Das Problem ist, daß auch bei einer Geschwindigkeit von 18m/s keine > Lücken von mehr als 5mm (0,027ms) auftretten sollten. Ich glaube, eine PWM zu multiplexen macht mehr Kopfweh als sonst was, das sollte ja phasengenau passieren, damit man keine Blitzeffekte o.Ä. bekommt (wobei ich nicht weiß, wie groß das Problem tatsächlich ist) aber trotzdem. Man muss neue Werte in die PWM-Register reinschreiben, die Matrix weiterschalten etc. pp. Dann doch lieber eine selbst programmierte PWM, bei der man die Wellenform ggf. selbst beeinflussen kann. Der µC muss dann nicht viel anderes machen als die output-ports mit neuen Werten zu beschreiben, wenn man das clever organisiert kriegt man das gut hin. Lass nochmal nachrechnen: 5mm / (18000mm/s) = 0.28ms, das sind bei 16MHz 16000000 / 18000 * 5 = 4444 Takte. --> wenn das nicht reicht... In einem Timer-Interrupt brauchst Du eine handvoll Takte um die nächsten Werte bereitzustellen und 2 Takte um die IO-Ports zu beschreiben. Da hat man außerhalb des Interrupts alle Zeit der Welt um die Playlist abzuarbeiten. Viele Grüße, Simon
3 davon: http://docs.macetech.com/doku.php/octobrite im Dreieck zusammenpappen? aber k.a. ob das synchron genug ist mit den drei LEDs auf gleicher höhre müsste man mal ausprobieren. Aber da ist auch nen Codebeispiel für den 24 Kanal TI Chip wenns Dir hilft :-)
Vielen Dank mal wieder ;) So langsam schöpfe ich Hoffnung. Hat euch eigentlich schonmal jemand gesagt, daß das unverschämt kompliziert ist womit ihr euch da rumschlagt? Nun denn, Schritt für Schritt, hier ein neuer Schaltplan (mit nur 2 der 5 LED-Gruppen), diesmal wie von Ohforf vorgeschlagen mit Eagle. Die Schaltung für Taster, Stromversorgung und LEDs habe ich dem Tutorial hier entnommen. Für die LEDs habe ich die Vorwiderstände berechnet bekommen, wäre aber dankbar, wenn jemand das kontrolliert. Mit den Widerständen der Transistorn bin ich noch nicht wietergekommen. Ändert sich da eigentlich dann noch was wegen der PWM? Sebastians Idee mit der Synchronisation über eine Ladestation hat mich dazugebracht ein Kabel zu nehmen, bei dem von jedem Tool je ein I/O-Pin verbunden ist. Wird bei einem der Taster gedrückt, triggert der die anderen. Ich würde gerne die Akkus über ein externes Ladegerät aufladen. Muß ich dann während des Ladevorgangs die Verbindung zum Rest unterbrechen, damit da nichts vom Ladestrom durchgebruzelt wird? Im Tutorial wird der 7805 mit 5V bespeist, ich würde allerdings lieber 12V verbraten. Kann ich dann die gleichen Kondenstoren nehmen? Ist das mit dem USB wirklich so einfach, oder muß da doch noch Vogelfutter dazwischen? grüße, gé
Gerald Richter schrieb: > Vielen Dank mal wieder ;) > > So langsam schöpfe ich Hoffnung. Hat euch eigentlich schonmal jemand > gesagt, daß das unverschämt kompliziert ist womit ihr euch da > rumschlagt? So kompliziert auch wieder nicht. Heutzutage ist das, ganz im Gegenteil, sogar ziemlich einfach geworden. > Die > Schaltung für Taster, den 10K Widerstand schmeisst du gleich wieder raus. Braucht keiner > Stromversorgung und LEDs habe ich dem Tutorial > hier entnommen. Für die LEDs habe ich die Vorwiderstände berechnet > bekommen, wäre aber dankbar, wenn jemand das kontrolliert. Die wirst du im Nachhinein sowieso wieder ändern. Größenordnungsmässig könnten sie stimmen. Nach oben (also zu größeren Widerstandswerten) hast du immer Spielraum. Die LED wird dann einfach dunkler. Abhängig von deinen konkreten LED wirst du die Widerstände aber sowieso anpassen, damit die LED in der gewünschten Helligkeit leuchten und vor allen Dingen einigermassen gleichmässig (ich meine jetzt die verschiedenen Farben) leuchten. Nimm die 20mA nicht als muss, sondern als kann maximal. Bei vielen LED ist es, dass du, wenn du auf kann maximal dimensionierst, du eine Sonnenbrille brauchst :-) > Mit den > Widerständen der Transistorn bin ich noch nicht wietergekommen. Das sind bei dir Schalttransistoren. Mit 1K als Basiswiderstand wirst du dabei sein. Alles halb so wild, der Transistor ist nur Schalter und muss nicht im linearen Arbeitsbereich betrieben werden. > Ändert > sich da eigentlich dann noch was wegen der PWM? Die Vorwiderstände der LED :-) > Im Tutorial wird der 7805 mit 5V bespeist, ich würde allerdings lieber > 12V verbraten. Kann ich dann die gleichen Kondenstoren nehmen? Hmm. Bist du sicher, dass du 12V haben willst? Du verbrutzelst mehr Energie in Form von Wärme, als du als elektrische Energie nutzt! > Ist das mit dem USB wirklich so einfach, oder muß da doch noch > Vogelfutter dazwischen? Was sagt das Datenblatt zum Prozessor?
Mir fehlt aber noch die Reset-Beschaltung und wie du den µC Programmieren willst (ISP SChnittstelle) ist mir auch noch nicht klar :-) (Hmm. Wusste gar nicht, dass es den Mega32 auch mit USB Anschluss gibt. Hast du die üblichen Bezugsquellen [Conrad, Reichelt, CSD, Farnell] kontrolliert, ob du den überhaupt irgendwo kaufen kannst?)
wärend der show IR zur Synchronisation zu benutzen, halte ich nicht für so geschickt. wenn jemand Fotos macht, hat der dann das Licht mit drauf.
>> Ist das mit dem USB wirklich so einfach, oder muß da doch noch >> Vogelfutter dazwischen? > > Was sagt das Datenblatt zum Prozessor? Das sagt, dass da noch je ein 22 Ohm-Serien-Widerstand in die Datenleitungen reinmuss (Seite 186/187 (Anfang von Kap. 20) hat ein paar Skizzen für die versch. Stromversorgungsszenarien). Übrigens sind die atmega32u2/at90usb162 mit einem Bootloader vorprogrammiert, so dass man die über USB mit Firmware versorgen kann. Erst wenn man den Bootloader austauschen möchte, muss man auf ISP zurückgreifen. Und ein Tip: vermeide schräge Leiterbahnen im Schaltplan. Kreuzungen zu vermeiden hilft auch bei der Lesbarkeit, evtl. lohnt es sich, einen Bus für die IO-Pins einzuführen. GND muss nicht alles miteinander verbunden sein, lieber packe ein paar GND-Symbole über den Schaltplan verteilt. Ich würde übrigens die Transistoren an PortB und PortD hängen, falls Du die Pins nicht dringend für was anderes brauchst. Dann kannst Du nämlich in zwei Taktzyklen die LEDs neu konfigurieren, indem Du einfach die Konfiguration auf PORTD und PORTB rausschreibst. Du vermeidest so lästige Bit-Schiebereien. Viele Grüße, Simon
Danke, ihr Leuts! den ATMega32U2 gibt es bei Farnell. <träum>Ich hatte gehofft, ihr sagt mir jetzt, daß ich den ganz unkompliziert über USB programmieren kann.</träum weiter> Mein Gedankengang war, daß ich mit 12V auf der sicheren Seite bin. Wäre ich das den auch mit 9V oder gar 6V? Im Datenblatt steht, der USB controller braucht von extern 48MHz -+0,25% für volle Geschwindigkeit. 'Wie groß ist denn da der Unterschied. @Karl Heinz: meinst du, ich soll beide Widerstände an den Transistoren mit 1k bestücken? @Simon: Super, dann weis ich was heute abend noch ansteht...
Gerald Richter schrieb: > Mein Gedankengang war, daß ich mit 12V auf der sicheren Seite bin. Wäre > ich das den auch mit 9V oder gar 6V? 9V. Der 7805 braucht mindestens 3V mehr als er liefern kann, also 5 + 3 = 8 Alles was über diesem Minimum liegt, wird letzten Endes in Wärme verheizt. > @Karl Heinz: meinst du, ich soll beide Widerstände an den Transistoren > mit 1k bestücken? Man kann natürlich auch genauer rechnen, aber mit 1K solltes du in etwa hinkommen.
Gerald Richter schrieb: > <träum>Ich hatte gehofft, ihr sagt mir jetzt, daß ich den ganz > unkompliziert über USB programmieren kann.</träum weiter> Mhm, ich dachte ich hätte das geschrieben? :-) Das FLIP-Utility von Atmel kann das, falls Du Linux verwendest, geht das mit dem "dfu-programmer". Der Default-Bootloader kann auch nach dem ersten Flashen der Firmware wieder angesprungen werden, dafür muss der HWB-Pin (PD7) beim Verlassen des Reset auf GND gezogen sein. Ggf. sollte man daher den Taster daran hängen. Es ist auch auf jeden Fall sinnvoll, in den Firmwares einen Weg vorzusehen, den Bootloader aus dem laufenden Betrieb heraus anzuspringen. Code dafür habe ich, das ist auch schonmal hier im Forum diskutiert worden. > Im Datenblatt steht, der USB controller braucht von extern 48MHz -+0,25% > für volle Geschwindigkeit. 'Wie groß ist denn da der Unterschied. Wo liest Du das? Ich lese hier in der Featureliste: "48 MHz PLL for Full-speed Bus Operation: data transfer rates at 12 Mbit/s". Meine Erfahrung mit dem at90usb162 ist (der dem atmega32u2 sehr ähnlich ist), dass zumindest low-speed USB funktioniert, mehr brauchst Du auch nicht. Wichtig ist nur, dass Du einen 8 oder 16MHz-Quarz verwendest, damit die interne PLL damit arbeiten kann, siehe Abschnitt8.10 im Datenblatt.
ok, das mit dem lesen übe ich dann wann anders... The USB controller requires a 48 MHz ±0.25% reference clock for USB Full-Speed compliance. This clock is generated by an internal PLL. The reference clock to the PLL must be provided from an external crystal or an external clock input. Only these two clock options will be able to provide a reference clock within the accuracy and jitter requirements of the USB specification. also ich bräuchte eine "reference clock" für full speed, aber brauch ich sowieso nicht, weil für so ne trödeltante wie mich low-speed voll langt. Linux habe ich derzeit keins, wenn es unbedingt sein muß würde ich mir auf dem laptop dafür ne partition freihauen. aber etwas für win7 oder XP wäre besser. ich muß ehrlich gestehen, daß ich mich über alles software-technische noch garnicht informiert habe. step by step. wenn der grobe Aufbau soweit gut ausschaut, kann man denn was rauskürzen? könnte ich LEDs, die gemeinsam an einer Transistor-Treiberstufe hängen über einen gemeinsamen Vorwiderstand regeln? Oder jede LED sein R?
@poidokan Etwas Off-Topic. Ich muss mal ein großes Lob aussprechen. Du machst Dich hier als Nichtelektroniker verdamt gut. Der Schaltplan ist für den Anfang garnicht mal so schlecht. Du hast Mut, erarbeitest Dir eine Menge selber und stellt keine "blöden" Fragen. Davon sollte sich mal so manch ein Neuling hier eine Scheibe abschneiden. Mach weiter sol. Es macht Spaß, diesen Faden durchzuarbeiten. PS: Den atmega32u2 werde ich mir wohl mal genauer ansehen. USB kann man immer gebrauchen.
@ Christian: Das freut mich sehr! Dadurch daß ich, dank eurer Hilfe, so schnell vorankomme macht es auch richtig Spaß. Im Anhang ist der überarbeitete Plan mit USB-Anschluß und mehr Bussen und weniger Kriselgekreutze. Dann hab ich nochmal eine Vorversion konzpipiert, wo an jeden I/O-Pin nur eine LED kommt. Dadurch spar ich mir die Treiberstufen und kann erstmal experimentieren. Schaltplan hängt auch an. Ich fang dann mal an die Materialien zu besorgen und das mit dem Löten zu üben. Sollte ich es wirklich schaffen was funktionables zusammenzufriemeln, werde ich ja kaum drumrumkommen, das mit der Software anzugehen. Ich hab vor 20 Jahren mal ein bisschen Basic gelernt (Hey, das waren die C64-Zeiten! Ich war jung und brauchte den Spaß...) Taugt das noch? Oder soll ich lieber gleich C oder gar Assembler lernen? Hat vielleicht noch jemand einen Tip mit welcher Software (bitte free oder share!) ich den Controller bespielen kann? Derzeit hätte ich Win7 und XP zugänglich und hätte nur geringe Hemmungen mir mal wieder Ubuntu zu instalieren. schöne Grüße, gé
Also, da Du einen Atmel-Prozessor verwendest, würde ich einfach zum AVRStudio von Atmel tendieren; ist kostenlos (man muss sich nur registrieren). Als Sprache würde ich C vorschlagen; sollte es irgendwo mal zeitlich problematisch werden, kann man sich das Assemblerergebnis immernoch anschauen und modifizieren. Wenn Du bei Basic bleiben magst, gibt es BASCOM; das ist - soweit ich weiß - bis zu einer Größe von 4kByte auch kostenlos; wenn die Programme dann größer werden, muss man sich die SW kaufen. Zu der Schaltung: Da musst Du später beim Programmieren aufpassen; prinzipiell kann zwar vermutlich jeder einzelne Pin "seine" LED betreiben, aber wenn Du "aus Versehen" oder absichtlich mehrere LEDs gleichzeitig an hast, dann muss der Gesamtstrom ja auch über die µC-Masse zurück zur Batterie und die GND-Pins werden dann sicherlich überlastet; Ergebnis: µC putt :-( Betreibe die LEDs doch lieber mit dan ganzen Transistoren; die sind billiger als ein neuer ATMega :-) Noch eine Anmerkung zum Akku: Da steht jetzt was von einem 9V-Akku... Haben die Dinger inzwischen genügend Kapazität? Mein Akku-Kenntnis-Stand (der schon viele Jahre alt und entprechend verstaubt) ist, dass die Dinger so um 100-150mAh haben... Wenn Du also alle 15 LED gleichzeitig mit 10mA betreibst, ist der Akku nach max. einer Stunde leer; da es aber zwei Stunden halten soll, würde ich vielleicht (wenn's gewichtsmäßig klappt) 6-8 Mignon-Akkus nehmen; die gibt's locker mit bis zu 20facher Kapazität.
Huhu Gerald, also als Software für Windows gibt es AVR Studio von Atmel selbst umsonst - wenn man direkt daraus flashen will brauch man einen Programmer von Atmel glaube ich oder einen Kompatiblen. Unter Linux wäre Texteditor + avrdude(Open source) das Mittel der Wahl. Wie schon erwähnt, würde ich von Infrarot abstand nehmen, da auf jeglichen Videos und Fotos von deinem Auftritt dann ein heller Punkt an der Stelle des IR-Senders zu sehen sein wird (Probier es aus, schnapp dir eine Fernbedienung und eine Digicam, halte den Sender der Fernbedienung vor die Linse der Kamera während du eine Taste drückst - fröhliches Blinken auf dem Display). Gruß Moritz und viel Erfolg :-)
schönen morgen! Guter Einwand! IR kann ich mir sowieso nicht so richtig vorstellen, ich möchte bei den Signalen ja nicht immer warten, bis zufällig der letzte Empfänger Sichtkontakt mit dem Sender bekommen hat. Wenn es eine Datenübertragung gibt, wäre es schön, die komplette Information zu senden. D.h. ich träume davon, daß auf dem Laptop das Leuchtprogramm berechnet wird (mit komplexen Mustern oder sogar live mit Musikdaten verrechnet) und die Tools die empfangenen Signale direkt an die LEDs schicken. Also zusammengefasst müßte das Übertragungsverfahren folgendes können: -Signale für 45 PWModulierte LEDs übertragen, ohne daß irgendwo ein Loch von mehr 0,28ms auftritt -ständigen Kontakt auch bei schnellen Bewegungen des Empfägers garantieren -klein genug sein -keine Nebeneffekte haben, die den Showablauf stören könnten Was gibt es denn da alles? Bluetooth, Funk, WLAN, Rauchzeichen, telepathisch kommunizierende KIs...
..warum waren wir noch gleich vom LED Treiber abgekommen? Ich erinnere mich dunkel, dass ich wegen der PWM Problematik mit den dunklen Stellen einfach die Dot-correction eines TLC5940 genutzt habe. Ist zwar technisch nicht so sauber, aber 6 bit haben bei mir völlig gereicht, da ich ja kein Display bauen wollte. Ganz zu schweigen davon, dass so ein Treiber den Platinen- und Bauteilaufwand ENORM reduziert.
@ Otto: nettes Teil, danke für den Tip. Was ist daran technisch unsauber?
Wenn ich das richtig sehe, stellt man mit der Dot-Correction den Strom über einen "Vorwiderstand" ein. D.h. das man zum einen die Energie sinnlos verbrät zum anderen drehen sich da "echte" Elektroniker im Grabe um, weil man LEDs wegen der Unlinearität nicht über den Widerstand dimmt. Das ist ungefähr so böse, wie eine LED nur über ihren eigenen, nicht linearen Widerstand und den Innenwiderstand der Batterie zu betreiben, ohne einen Stromquelle oder wenigstens einen Vorwiderstand zu nutzen. Trotzdem wirds natürlich Millionenfach so gemacht, und eigentlich funktioniert es super... Aber das ist halt der Unterschied zwischen der Theorie von Leuten die es gelernt haben und Praxis der Leute die eigentlich keine Ahnung haben ( ich zum Beispiel bin Maschinenbauer): theoretisch ist es wirklich schlecht, praktisch gehts halt trotzdem (zumindest unter gewissen Umständen) ;-)
Ich weiss nicht ob das Thema hier schon auftauchte, aber meines Wissens sind Quarze stoßempfindlich und gehen dann auch mal kaputt. Da würde ich eher den internen Oszillator nehmen und wenn der (nach Kalibrierung) zu ungenau ist synchronisieren (per USB, weil Funk braucht auch nen Quarz).
für die Infrarot sachereicht ja one-way kommunikation, da kann der Sender also durchaus vom Publikum weg auf die Bälle zeigen.
Oneway stimmt, das wird die Fotografen freuen, aber trotzdem ist IR zu sehr auf Sichtkontakt angewiesen, imho. Der Quarz ist einem Keramik-Resonator gewichen. Dieser ist laut Hersteller stossunempfindlich... Ich geh jetzt shopen!^^
Gerald Richter schrieb: > Oneway stimmt, das wird die Fotografen freuen, aber trotzdem ist IR zu > sehr auf Sichtkontakt angewiesen, imho. Meinst du das ist so tragisch? Es reicht doch, wenn zum Beispiel spätestens alle 15 Minuten synchronisiert wird. Der Zeitunterschied dazwischen fällt doch fast nicht auf. > Der Quarz ist einem Keramik-Resonator gewichen. Dieser ist laut > Hersteller stossunempfindlich... Hey, Gute Idee!
Über die Störung von Fotografen brauchst du dir denke ich keinen Kopf machen. Eigentlich alle Kameras haben einen IR-Sperrfilter (CMOS und CCDs sind von sich aus sehr IR-Empfindlich, was die Bilder verfälschen würde). IR-LEDs mit halbwegs humaner Helligkeit sollten vom Rest (restliche LEDs, Feuer,...) deutlich überstrahlt werden. Ein Problem hat man nur, wenn einer seine Kamera mit Nightshot (IR-Filter weggeklappt) auspackt. Das sollte aber nicht dein Problem sein. Bedenke: Die meisten Keramik-Resonator sind ungenauer als Quarze. Noch zum Thema Stromversorgung: die LM78xx sollten IMO nur im Prototyp die Schaltung versorgen. Spätestens im produktiven Einsatz würde ich auf jeden Fall Schaltregler (der Betriebsdauer wegen) empfehlen. Problematisch ist da wahrscheinlich nur die Stoßempfindlichkeit der meisten Induktivitäten.
Chris R. schrieb: > Über die Störung von Fotografen brauchst du dir denke ich keinen Kopf > machen. > Eigentlich alle Kameras haben einen IR-Sperrfilter (CMOS und CCDs sind > von sich aus sehr IR-Empfindlich, was die Bilder verfälschen würde). Halte mal deine Fernseh-Fernbedienung vor deine Kamera...
Simon K. schrieb: > Halte mal deine Fernseh-Fernbedienung vor deine Kamera... Halte mal deine Hand in einen Fleischwolf ;) Im Ernst: Du siehst die Fernbedienung in der Regel nur, wenn du sie direkt vor die Kamera hältst (Entfernung und Blickwinkel). Selbst starke LEDs kann ich mit den Kameras hier (dSLR, einjährige und 3 jährige Kompakte) selbst direkt vor der Linse und bei absoluter Dunkelheit etwas sehen. Durchgehenden erfolg habe ich nur mit meiner Handyknipse, bei der wohl am IR-Filter gespart wurde. Und wenn schon: die meisten werden sich über ein paar Lichtpunkte nicht wundern, wenn sie überhaupt den Blitz ausbekommen. Alle anderen wundern sich vielleicht ein bisschen, wissen aber, wie man die Punkte entfernt.
Chris R. schrieb: > Durchgehenden erfolg habe ich nur mit meiner Handyknipse, bei der wohl > am IR-Filter gespart wurde. Ja, könnte ich mir bei billigen Digiknipsen auch schon vorstellen... Ansonsten muss ich wirklich sagen, dass ich die IR LED Methode für am besten halte. Schön unkompliziert.
Also ich würde mich mal freuen, wenn Du mir das mit der IR-Synch genauer erklären würdest. Weil ehrlich gesagt, ich halte das speziell hierfür für absolut unbrauchbar. Er hat in den Dinger doch ohnehin eher wenig Platz und somit wird er kaum ringsum, oben und unten, lauter IR-Empfänger einpauen können. Das müsste aber sein, damit man 100%ig sicher sein kann, dass die Synch-Impulse auch empfangen werden. Die Dinger drehen sich doch relativ schnell; vermutlich auch machnmal vor und manchmal hinter dem Rücken. Ich halte es da für nahzu 100%ig sicher, dass mal der eine Stick gesyncht wird, der andere aber nicht. D.h., wenn die beiden - vor dem Synch - evtl. noch einigermaßen gleich liefen und kein Unterschied sichtbar war, kann es nach einem Synch evtl. passieren, dass der eine auf der neuen Zeitbasis läuft, der andere aber noch nicht (weil er es eben nicht empfangen hat). Noch schlimmer wäre es dann sogar, wenn damit auch die Programme umgeschaltet werden sollen. D.h. dass dann genau durch eine "Synchronisation" ein versetzter Lauf erzeugt werden könnte. Bei max. 0,28ms Unterschied halte ich das für sehr wahrscheinlich.
@planlessmichi: hab ich eigentlich weiter oben schon geschrieben... Mit jedem Sync wird eine fortlaufende Zahl gesendet. Wird eine mal nicht empfangen wird auf der Basis der letzten weitergemacht. Dadurch dass man im Idealfall mehrere Syncworte nacheinander empfängt, kann sich der Empfänger auch danach kalibrieren, also die interne Abweichung von sich aus ausmerzen. Der IR-Empfänger muss halt so angebracht werden, dass er möglichst viel mitbekommt. Wichtig ist hier denke ich neben der eigentlichen fortlaufenden Zahl auch eine Prüfsumme mitzusenden, nicht dass sich die Leuchtkeulen durch Bitfehler falsch synchronisieren. Wobei man hier wahrscheinlich auch einiges über Plausibilität machen kann: nach einem Abstand von zwei Syncs ist es z. B. unwahrscheinlich, dass auf 5 die 2 folgt (Bit der Wertigkeit 4 gekippt).
Was haltet ihr von einer Synchronisation in der Ladestation: Der Akku wird zum laden gut und gerne 2h brauchen. In dieser Zeit hätte man ausreichend Möglichkeit die beiden Quarze zu synchromisieren und einen Korrekturfaktor zu berechnen. Dass hier dauerhaft große Stöße auftreten ist ein Irrtum, diese Stäbe berühren NIE den Boden, ausser beim Üben oder im worst Case Fehlerfall. Der Quarz wird hierdurch ausser Tritt kommt ist möglich, aber eigentlich nicht tragisch, da er ja neu synchromisiert werden kann. Willst du die 2h wirklich kontinuerlich mit den dingern herumwirbeln oder abgesetzt 3min Show 10min Feuer und so weiter? in der Feuerpause könnte wiederum synchronisiert werden, die Stäbe nebeneinander legen und über eine simple IR Verbindung sysnchronisieren. Eine maximale Abweichung von 0,28ms halte ich für ein wenig übertriben, ich habe gerade zwei Leds aufgebaut und bis zu 50ms kannst nicht erkennen ob diese sysnchron blinken oder nicht. Als maximale PWM Dunkelphase haben diese natürlich ihre Berechtigung, um Löcher im Lichtschweif zu vermeiden. Eine dauerhafte IR Synchromisation mit dem von dir beschriebenen Fehler kann vorkommen, allerdings kannst du ja einen Zeitraum schätzen oder ermitteln in dem jeder deiner Stäbe mindestens einen Synchronimpols erhält (z.B. eine Minute). Danach kannst du entscheiden, ob die in dieser Zeit auftretende Abweichung tolerierbar ist oder nicht. Dass beide ZUGLEICH den Triggerimpuls erhaltn halte ich für unwahrscheinlich. tolles Projekt, wenn du Platinen brauchst schreib einfach, so ein 20mm fällt sicher irgendwo als "Rest" ab sg zoggl
Mal etwas zu den Batterien. Sie werden sicherlich das schwerste an der ganzen Elektronik sein. Soll sie Mittig sein, reicht eine aus. Ansonsten müssen es schon zwei Stück sein. Für die Syncronisation ist die Ladestation wohl am besten geeignet. Ansonsten kommt ein "Halter" in Form einer Dose in Frage. Hier werden die Stöckchen in den Pause hineingelegt. Dort ist dann auch die IR-Sendestation verbaut. Einen Programmwechsel könnte man auch in dieser Dose durchführen. Hierzu hat die Dose entsprechende Bedienknöpfe. Jedoch ist ein Programmwechsel wärend der Vorführung oder gar eine Musiksteuerung/-syncronisation bei dieser Variante nicht möglich. IR wäre ja noch möglich, wenn man dazu mehrere IR-Sendestationen verwendet. Ansonsten bleibt nur noch Funk.
Hallo, mein aktueller Stand: Lochplatinen jagen mir nach ersten Lötversuchen keine Angst mehr ein. Überraschenderweise hat jeder Versuchskreislauf bis jetzt auf Anhieb funktioniert. Die Controller sind bestellt und kommen hoffentlich morgen per Post. Als nächstes nehme ich mir AVR-Studio vor. die 0,28ms waren als Richtwert für die PWM. Also Jede LED sollte auch bei gedrosselter Helligkeit keine Pause von länger als 28ms machen müßen. Die Synchronisation darf ruhig auch mal 100ms daneben sein, das sieht keiner. Was für eine Übertragungsgeschwindigkeit hätte IR eigentlich? Mit der Funktionabilität/Konektibilität werde ich baldmal ein paar Experimente machen. Von der Auswuchtung wäre es günstig die Batterien am äusseren Ende zu plazieren. D.h. bei der kleinen Version (sogenannte "Poi" mit jeweils 5*3 LEDs) an einem Ende und bei der Großen (Stab von 110cm mit 15*6 LEDs) an beiden Enden. Auf einem Festival könnte es schon mal vorkommen, daß ich die Teile 2h ununterbroch spiele, aber da wäre es kein Unding zwischendrin kurz die Teile per Kabel zu synchen. Shows Dauern ca. 20-30 Minuten. Es wäre schön wenn ich in dieser Zeit nicht synchen müßte. @ hownottobeseen: Hättest du ein Beispiel, wie man einen Schaltregler einbaut?
hownottobeseen (unangemeldet) schrieb: > Mit jedem Sync wird eine fortlaufende Zahl gesendet. > Wird eine mal nicht empfangen wird auf der Basis der letzten > weitergemacht. So kompliziert würde ich das gar nicht machen. Jeder Prozessor hat eine eigenständige Zeitbasis. Wenn wir davon ausgehen, dass sich die Prozessoren alle, sagen wir 5 Sekunden, neu synchronisieren, reicht es doch, wenn sie bei 4.5 Sekunden den Eingang scharf schalten und bei 5.5 Sekunden wieder aus. Kommt in dieser Zeit ein Puls an, so wird der als Kalibierpuls gewertet, der die Uhr auf genau 5.0 setzt. Kommt keiner, na dann kommt eben keiner und die interne Uhr läuft weiter wie bisher. Voraussetzung: Die µC werden vor der Vorführung synchronisiert. Das kann man abseits vom Geschehen machen, indem sie nach dem Power-Up auf den Kalbirierpuls vom Master warten.
Gerald Richter schrieb: > Was für eine Übertragungsgeschwindigkeit hätte IR eigentlich? Mit der > Funktionabilität/Konektibilität werde ich baldmal ein paar Experimente > machen. Der Träger liegt üblicherweise bei 36kHz, die Übertragungsrate ist vom Protokoll abhängig. Genaue Datenraten weiß ich jetzt nicht aus dem Kopf. In deinem Fall sollte eine niedrige Datenrate reichen. Evtl. kannst du den IR-Decoder (TSOP 1736 oder kleiner der SFH 5110) direkt an den RX vom UART hängen. > @ hownottobeseen: Hättest du ein Beispiel, wie man einen Schaltregler > einbaut? Ein konkretes Beispiel nicht, aber es gibt die üblichen verdächtigen: Fürs erste Design würde ich dir allerdings einen der "handzahmen" Regler empfehlen, also LM2575 oder LM2576. Die sind zwar nicht so effektiv wie manch andere, Linearregler dürften sie allerdings schlagen. Karl heinz Buchegger schrieb: > Voraussetzung: Die µC werden vor der Vorführung synchronisiert. Das kann > man abseits vom Geschehen machen, indem sie nach dem Power-Up auf den > Kalbirierpuls vom Master warten. Warum mehrfach den Aufwand der Synchronisation betreiben? Ein stabiles Verfahren reicht doch ;)
Hallo, Cooles Projekt. Die Dinger die es schon gibt sehen bei ner Keulennummer oder so fantastisch aus. Warum machst du nicht an jede Keule einen Stecker (von mir aus auch in Ladebuchse integriert), so dass an der Basisstation alle miteinander verbunden sind. Dann würde über ein Taster (entweder an einer Keule, oder an Basisstation) einfach ein High-Bit über den Stecker geschickt, der alle Keulen ja gleichzeitig erreicht, ab da sollen sie losgehen mit dem Programm. Machst du anstelle eines einfachen Start-Bits eine I2C-Verbindung oder UART oder ähnliches, kannst du in das Startsignal auch noch das gewünschte Programm koppeln. Die Programme werden am PC designed? Dann würde ich sie ja per extra-Stecker als ISP-Stecker direkt in den Controller flashen (z.B. ins EEPROM, oder auch nur direkt ins Programm). Andererseits gibt auch kleine Funkmodule, die sich für die Übertragung von einem Start-Bit allemal eignen... Dann könntest du per Knopf hinter der Bühne z.B. von Assistenten Bedient, alle Keulen direkt zusammen starten lassen, wenn die schon bei den Jongleuren sind! Übrigens, ich würde mich sehr wundern, wenn nach 30 Minuten auch nur ne Millisekunde Abweichung vorliegt, die Controller mit Quarz gehen doch ultragenau! Viele Grüße ps: life is a struggle if you can't juggle
Schönen Morgen, Da ich zur Zeit noch auf die Controller warte, bin ich doch mal das Thema IR angegangen. Für mich käme das nur in Frage, wenn ich damit auch die Programme für die Leucht-Modi übertragen könnte. Das hängt sich für mich gerade an folgenden Fragen auf: -Kann ich mit IR (und wenn ja mit welchem Format) 212bits Information pro Sekunde übertragen? Die Übertragung soll über 2-3 Sendestationen funktionieren, die bis zu 5m Abstand zum Empfänger haben. -Würde es Sinn machen mehrere TSOP1736 in ein Gerät einzubauen, um aus möglichst vielen Richtungen die Daten empfangen zu können? Was passiert wenn mitten in der Signal-Sequenz ein Empfänger den Kontakt verliert, der andere aber Kontakt bekommt? -Welche IR-Diode eignet sich hierfür als Sender? Hier habe ich ausklamüsert, welche Parameter ich für die Choreographien brauche, und wie sie verarbeitet werden. Die Idee ist vordefinierte Leucht-Funktionen (Modi) und Farben im Flashspeicher zu haben, die dann mit den über IR-gesendeten Parametern abgerufen werden. Die Parameter: Timer(1-2097152 = 21bits) #fängt bei 1ms an und zählt aufwärts ProgrammNummer (1-511 = 9bits) #jedes Programm bekommt eine Nummer, sobald ein Programm abgearbeitet ist, wird es gelöscht ProgrammStart (1-2097152 = 21bits) #Zeitpunkt des Timers bei dem dieses Progrmm starten soll ProgrammDauer (1-262143= 18bits) #Dauer dieses Programmes in ms Modus (0-31 = 5bits) #einer von 32 Modi nach denen die LEDs gesteuert werden Farbe1 (0-31 = 5bits) #eine von 32 vordefinierten Farben Farbe2 (0-31 = 5bits) #eine von 32 vordefinierten Farben Farbe3 (0-31 = 5bits) #eine von 32 vordefinierten Farben Farbe4 (0-31 = 5bits) #eine von 32 vordefinierten Farben Farbe5 (0-31 = 5bits) #eine von 32 vordefinierten Farben Farbe6 (0-31 = 5bits) #eine von 32 vordefinierten Farben Zeit1 (0-262143 = 18bits) #Zeitparameter in ms Zeit2 (0-262143 = 18bits) #Zeitparameter in ms Zeit3 (0-262143 = 18bits) #Zeitparameter in ms Zeit4 (0-262143 = 18bits) #Zeitparameter in ms Zeit5 (0-262143 = 18bits) #Zeitparameter in ms Zeit6 (0-262143 = 18bits) #Zeitparameter in ms Im IR-Signal müßten 17 also Parameter aus ingesamt 212bits kodiert sein. Dazu kämen Adress-, Stop- & Kontroll-Bits. Der IR-Sender sollte die Sequenz in einem regelmässig Abstand schicken. Da manche Programme nur kurz laufen (z.B. einmalig bei einer Betonung in der Musik), und das Folgeprogramm direkt verfügbar sein soll, darf der Abstand, bis die nächste Sequenz gesendet wird nicht länger als 1000ms sein. Die Modi könnten z.B. so aussehen: Modus1 = setzt von <ProgrammStart> bis <ProgrammStart>+<ProgrammDauer> die Farbwerte aus <Farbe1> auf LED-Gruppe1 aus <Farbe2> auf LED-Gruppe2 usw... und dann für <Zeit2> auf 0 Modus2 = startet bei <ProgrammStart> mit <Farbe1> auf allen LEDs und errechnet für <Programmdauer> einen fliessenden Farbwechsel zu <Farbe2> Modus3 = startet bei <ProgrammStart> mit einem Blinken auf allen LEDs in <Farbe1> mit Pulsen von <Zeit1> und Pausen mit <Farbe2> von <Zeit2> Modus4 = fadet bei <ProgrammStart> <Farbe1> auf allen LEDs in <Zeit1> ein und in <Zeit2> wieder aus, dann <Farbe2> in <Zeit3> und <Zeit4> und dann dann <Farbe3> in <Zeit5> und <Zeit6> Modus5 = startet bei <ProgrammStart> mit <Farbe1> auf LED-Gruppe 1 & 5 und <Farbe2> auf LED-Gruppe 3 und einer Mischfarbe aus <Farbe1> und <Farbe2> auf LED-Gruppe 2 & 4 bis <ProgrammStart>+<ProgrammDauer> morphen die LED-Gruppen jeweils versetzt zwischen den beiden Farben im Rhytmus von <Zeit1> ... Modus23 = Stroboskopisches Blinken das hoch- und runterfadet und die Farben wechselt ... Modus32 = alles LEDs sind aus jeder Modus ist dabei eine Funktion, die jede ms aufgerufen wird. Modus2 würde so aussehen: wenn Timer >= ProgrammStart + ProgrammDauer dann rufe nächstes Programm auf Setze Helligkeit der roten Fraktion der LED-Gruppen 1-5 auf (Rotwert von Farbe1 + (Differenz aus den Rotwerten von Farbe1 und Farbe2 * ProgrammDauer / (Timer - ProgrammStart))) dasgleiche für Grün und dasgleiche für Blau Modus3 wäre: wenn Timer >= ProgrammStart + ProgrammDauer dann rufe nächstes Programm auf x++ Wenn x < Zeit1 dann setze Helligkeiten der Farbfraktionen der LED-Gruppen 1-5 auf Farbwerte von Farbe1 sonst auf Farbwerte von Farbe2 Wenn x > Zeit1+Zeit2 dann x=0 Farbpalette: Vordefinierte Farbe1 = 0x000000 Vordefinierte Farbe2 = 0xFFFFFF Vordefinierte Farbe3 = 0xFF0000 Vordefinierte Farbe4 = 0x00FF00 Vordefinierte Farbe5 = 0x0000FF Vordefinierte Farbe6 = 0xFFFF00 Vordefinierte Farbe7 = 0xFF00FF Vordefinierte Farbe8 = 0x00FFFF Vordefinierte Farbe9 = 0x888888 Vordefinierte Farbe10 = 0x880000 Vordefinierte Farbe11 = 0x008800 Vordefinierte Farbe12 = 0x000088 Vordefinierte Farbe13 = 0x888800 Vordefinierte Farbe14 = 0x880088 Vordefinierte Farbe15 = 0x008888 Vordefinierte Farbe16 = 0xFF8888 Vordefinierte Farbe17 = 0x88FF88 Vordefinierte Farbe18 = 0x8888FF Vordefinierte Farbe19 = 0x88FFFF Vordefinierte Farbe20 = 0xFF88FF Vordefinierte Farbe21 = 0xFFFF88 Vordefinierte Farbe22 = 0xFF8800 Vordefinierte Farbe23 = 0xFF0088 Vordefinierte Farbe24 = 0x00FF88 Vordefinierte Farbe25 = 0x88FF00 Vordefinierte Farbe26 = 0x8800FF Vordefinierte Farbe27 = 0x0088FF ... Vordefinierte Farbe32 = Farbwerte so übernehmen wie sie bei Programmstart sind Eine Choreographie bei der ein Violett über 2 Sekunden eingefadet wird, es dann über 10 Sekunden cyan blinkt und dann über 4 Sekunden blau ausfadet würde aus drei verschiedenen Signal-Sequenzen bestehen: Sequenz1 = 1(Timer),1(Programmnummer),2000(Programmstart),2000(ProgrammDauer),2(Mod us),1(Farbe1),6(Farbe2),0,0,0,0(Zeit1),0,0,0,0 Sequenz1 wird 2 Sekunden gesendet, wobei der Timer sich ständig verändert, danach startet Programm 1 und Sequenz2 wird gesendet: Sequenz2 = 2000(Timer),2(Programmnummer),4000(Programmstart),10000(ProgrammDauer),3 (Modus),8(Farbe1),1(Farbe2),0,0,0,100(Zeit1),50(Zeit2),0,0,0 Sequenz2 wird 10 Sekunden gesendet, danach startet Programm 2 und Sequenz3 wird gesendet: Sequenz3 = 4000(Timer),3(Programmnummer),14000(Programmstart),4000(ProgrammDauer),2 (Modus),5(Farbe1),1(Farbe2),0,0,0,0(Zeit1),0,0,0,0 Nachdem Programm3 beendet ist bleibt alles aus, da keine neue Sequenz mehr empfangen wurde.
Ich hab da mal eine Frage an die keulenschwingende Zunft (vor der ich großen Respekt habe): Inwieweit ist das Timing eurer Nummmern fix? Wie reproduzierbar ist das Ganze (jetzt zeitlich gesehen). Was ich mir nämlich gerade vorstelle, sind diese Lichtprogramme. Was natürlich ultrageil aussehen würde (denk ich mal): Wenn die Keulen im oberen Totpunkt zb einen Lichtblitz aussenden. Könnte mit vorstellen, dass so etwas fantastisch aussieht. Nur: Dazu muss das Timing exakt stimmen. Nichts ist schlimmer als wenn vorgefertigte Sequenzen ausser Tritt kommen. In diesem Fall die Figuren und die Lichtshow. Ist ja mit Musik auch nichts anderes. Sieht einfach sch... aus, wenn die Musik den Trommelwirbel intoniert, nachdem die 7 Keulen alle schon wieder herunten sind :-)
Mit Keulen und Stäben ist das gar kein Problem. Allerdings plane ich das ganze gerade für Poi, sprich die LED-Tools hängen an einer Schnur, sind also etwas schwieriger zu kontrollieren. Ist aber trotzdem machbar. Im Hinterkopf schwirrt ja auch noch die Idee mit den Brschleunigungsensoren =D
Wollte mich erstmal schlau machen, bevor ich hier poste und bin auf dieses Produkt gestossen: http://www.glowball.de/poi/ziriuz/pair.html Schwebt Dir soetwas vor? Gruß Axelr.
jain. geht die richtung. bloss will ich es heller und voll programmierbar haben. so richtig begeistert mich leider nichts, was es auf dem markt gibt. am ehesten die produkte von aerotech, aber denen ihre poi sind mir zu klobig...
technisch ist das alles kein Problem, aber warum sollen den die Teile noch kleiner werden, als hier vorgestellt? ( Gut, wenn sie Dir zu groß sind, mach sie halt kleiner) http://www.homeofpoi.com/shop/listItems/LED-Glow-Poi Kann ich mir nur so erklären, das die Leuchtkraft nicht die beste ist oder die Akkulaufzeit nur 15min. beträgt. Bau den Akku (18650er Zelle) in den Griff und die LEDs und die Platine oben in den Ball. Nimm einen Beschleunigungssensor, so wie du es schon vor hattest. Somit ist das alles schön synchron. Platz ist genug im Controller. Da kannst Du die ganze Darbietung drinn ablegen. Man kann auch die LEDs an der Schnur auffädeln und ganze Bilder darstellen, wenn man will. Ich dachte, die Leucht-LED-POI sind teuerer. So lass ich es - für 40 Euro bekomm ich das nicht hin, schade. Viel Erfolg Axelr.
ich will jetzt nicht auf die nachteile der einzelnen fabrikate eingehen. allgemein gesagt: kaum ein produkt ist von der leuchtkraft ausreichend um bei normaler bühnenbeleuchtung die zuschauer auch in den hinteren reihen zu flashen. die wenigen ausnahmen haben dann andere nachteile. fakt ist, daß ich schon viel geld für led-jonglage-geräte ausgegeben habe, die teile aber meist im schrank bleiben. im zweifelsfall, wenn ich mir mit der lichtsituation nicht sicher sein kann, biete ich meinen kunden lieber eine feuershow an. mit smd kriege ich den aufbau auch in der größe hin, die ich gerne hätte. ideal wäre 150mm*25mm und ein gewicht von 180g, wobei der Schwerpunkt möglichst am äußeren ende sein sollte. LEDs auf der schnur auffädeln möchte ich lieber nicht, da ich beim poi-swinging viel mit "wickeltechniken" arbeite. der optische effekt, daß man eine scheibe bekommt, geht mit stäben genauso.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.