VM-Bordelektrik mit Arduino

Grundsätzlich würde ich nicht den Weg wählen, direkt den Soll-Zustand eines Lämpchens (z.B. Blinker) zu senden. Ich würde eher die Betriebsarten senden (z.B. "Blinken links", oder "Warnblinker").
Synchronisation hat ja @Nobbi schon angesprochen.
Interessant wird das Verschicken von Zustandsangaben wie "links blinken" und "links nicht blinken" v.a. dann, wenn die Satelliten selber entscheiden sollen, ob sie z.B. ein Positionslicht beim Blinken abdunkeln. Wenn ein Blinker in der Nähe des Positionslichtes ist, ist das nützlich, sonst nicht. Dann braucht man als Verbraucher nur z.B. linke Blinker, rechte Blinker und Positionslichter zu unterscheiden und die Satelliten machen den Rest selber. Sonst reicht's auch, für bestimmte Verbraucher(-klassen, wie z.B. "linke Blinker") die ab jetzt geltenden Helligkeiten herumzuschicken, aber man muss zwischen drei verschiedenen Arten von Positionslichtern unterscheiden (neben linken Blinkern, neben rechten Blinkern, isoliert).

Was evtl. für die Bordnetzbelastung interessant sein könnte, sich aber nur auf den Nanos selbst umsetzen lässt: Software-PWM und zeitversetztes Ein- und Ausschalten.
Bei einfachem Hardware-PWM sind die an einem Timer hängenden PWM-Ausgänge miteinander synchronisiert, was bedeutet, dass die Ein- oder Ausschaltphasen entweder alle zum gleichen Zeitpunkt beginnen oder um diesen Zeitpunkt herum zentriert sind. Das gibt hohe Spitzenströme. Wenn man die Pins per Interruptroutine schaltet, kann man das auch anders machen (z.B. einen Verbraucher dann einschalten, wenn ein anderer gerade aus ist), und man kann PWM auf Pins erzeugen, auf denen die Hardware das nicht kann.
Für sowas muss man allerdings etwas tiefer in die Timer- und Interruptsteuerung der Atmels einsteigen. Das läuft auf eine sortierte Liste hinaus, in der Timerwerte und jeweils zugehörige Schaltaktionen stehen, und wenn der Hintergrundtask die Liste ändern will, um Ein- und Ausschaltdauern anzupassen, ist das nicht leicht zu synchronisieren. Aber hier kann man auf die Synchronisation auch verzichten, denn es stört ja nicht allzu sehr, wenn eine LED mal für 3ms auf 0% oder 100% hängt.
 
@Fanfan : Immer schön die Pflicht und dann die Kür!;)
An so NobelHobel Sachen wie Blinker mit Tagfahrlicht zu verbinden denke ich noch nicht.
Sollten aber wenn die Satelliten selbstständig regeln...

Software-PWM würde ich tendenziell nicht machen, schon gar nicht bei der Frontlampe.

Mein Streben geht danach möglichst viele 12V-Geräte aus dem Mopped-Bedarf zu verwenden.

Ich denke auch nicht das hier am Ende EIN fertiges Produkt rauskommt sondern vieleMöglichkeiten und wir hier Ideen/Schaltungen/Programme und Hilfen stehen die Andere nutzen können um Ihre eigene Elektrik zusammen zu schalten.

Dazu war zB der Beitrag von @Heiko sehr hiflreich, das die Arduinos nicht am PC hängen dürfen...
 
wenn die Satelliten selber entscheiden sollen, ob sie z.B. ein Positionslicht beim Blinken abdunkeln

braucht's dass denn (das 'Selbstentscheiden')?

Wir haben im VM nur ne Handvoll Lämpchen und das primäre Ziel war die Zahl der Leitungen klein zu halten. Sekundäres Ziel ist das ganze möglichst einfach zu halten (sonst wird es nie fertig und wenn doch kann bzw. will das niemand weiterwarten).
Auf dem zu erwartenden Mini-(oder besser Mikro-) bordnetz läßt sich der gesammte Zustand (welche Lampe gerade mit welchem PWM-Wert angesteuert werden soll) so schnell an alle Sekundären Kontroller (ich sehe da maximal 3) übertragen, dass es sich nicht lohnt über mehr Eigenintelligenz nachzudenken als dass jeder Kontroller die vom zentrallen Controller übermittelten Zustände einfach an die angeschlossenen Verbraucher als PWM oder An/Aus-signal weitergibt. Daher auch mein Vorschlag als Sekundärkontroller fertige Chips wie sie in Lichterketten mit RGB-chips verwendet werden zu nehmen. Die können nämlich genau das was hier gebraucht wird und man muss auf Sekundärkontrollerseite nämlich genau gar nix programmieren (sondern nur die jeweils passenden KSQs dahinter hängen). Fertige Libraries für die Arduino-seite zum geziehlten Ansteuern des jeweiligen Chips gibts auch. Und ein einziger Ardunio langt (wie @Gear7Lover ja schon gezeigt hat) locker um den nötigen Gesammtzustand zentral zu verwalten.

Aber ich will niemanden davon abhalten das Rad neu zu erfinden :). Hab ich in anderem Kontext auch schon öfter gemacht. Ist ja nicht so, dass man genau daran auch ja jede Menge Spaß haben kann :D

Zum Rumspielen mit der genannten Technik und um die Beleuchtung des VMs mit simpelsten Mitteln zu simulieren muss man sich ja nur nen Meter RGB-Lichterkette vom Chinamann bestellen. Ardino-Tutorials zu dem Thema spuckt Google reichlich aus :)
 
Software-PWM würde ich tendenziell nicht machen, schon gar nicht bei der Frontlampe.
Zur Ansteuerung von Lichtern würde ich am liebsten gar kein PWM machen, jedenfalls nicht, um Lichter im PWM-Takt schnell ein- und auszuschalten. Aber mit einem zweipoligen Tiefpassfilter kann man PWM-Signale so weit glätten, dass man mit dem resultierenden Analogpegel an den Steuereingang einer Konstantstromquelle gehen kann. Wenn es nicht um die Blinker geht, die ja schnell an- und ausgehen sollen, kann man so ein Filter auch so langsam machen, dass es ganz ohne Rampenfunktion im Controller weiche Helligkeitsübergänge erzeugt.

braucht's dass denn (das 'Selbstentscheiden')?
Von mir aus nicht. Es wäre aber nur konsequent, wenn man die Strategie fährt, auf den Steuerleitungen Fahrzeugzustände zu verschicken, also etwa "links blinken, Abblendlicht Stufe 2, Fernlicht Stufe 3, Umgebungshelligkeit x". Dann ist es konsequenterweise Job des Satelliten, die Helligkeit der Blinker und des Abblendlichtes an die Umgebungshelligkeit anzupassen oder mit dem "Wissen", dass der Blinker neben einem Positionslicht ist, das Positionslicht für die Dauer des Blinkens zu dimmen. Man könnte auch noch die Fahrgeschwindigkeit mitschicken und bei niedrigem Tempo vom Abblendlicht auf die Positionslichter verlagern, wenn die hell genug sind, seitlich den Weg etwas auszuleuchten.
Der Gegensatz dazu ist, die gesamte Intelligenz konsequent in den Hauptcontroller zu legen und im 100ms-Takt die Helligkeiten herumzuschicken ("Blinker 70%, Fernlicht 0%, Abblendlicht 50%" o.ä.). Dann haben die Satelliten nicht viel zu rechnen und setzen nur stumpf die Helligkeitswerte in PWM-Tastverhältnisse oder Analogpegel um.
Für ungünstig halte ich es, da irgendwelche Mittelwege zu wählen. Das wird m.E. unübersichtlich.
 
Zuletzt bearbeitet:
Zur Ansteuerung von Lichtern würde ich am liebsten gar kein PWM machen
hm, genau so hatte ich das aber bei meiner letzten Bordelektronik gemacht der PWM des Arduino direkt auf den DIM Eingang der KSQ, sowohl für Blinker als auch Frontlicht. Warum hätte ich ein Tiefpass verwenden sollen?
Flackern? Die PWM Frequenz liegt bei 30 - 60 kHz wenn ich nicht irre.
Geschwindigkeitsabhängiges Positionslicht durch die Blinker gefällt mir, das hätte mir schon Schrammen rechts und links erspart.
 
Warum hätte ich ein Tiefpass verwenden sollen?
die PWM-frequenzen zum Dimmen sind typischer viel niedrieger. Ergibt bei bewegten Lichtern einen netten Stroboskopeffekt. Was im >20kHz Bereich angesiedelt ist ist die Frequenz des eigentlichen Schaltreglers. Ob ein Tiefpass zum Dimmen einer geschalteten KSQ überhaupt sinnvoll ist hängt aber stark von der verwendeten KSQ ab. Wenn eine KSQ einen analogen Dimm-eingang hat, dann heißt das nämlich nicht automatisch, dass der den hochfrequent geschalteten Anteil nicht auch über eine niederfrequente PWM-ansteuerung moduliert. Kann man auch ohne Oszi einfach herausfinden. Eine LED-lampe mit der KSQ betreiben und den Dimmeingang über einen Poti steuern und dann bei Regen ein bischen im Dunkeln rumleuchten. Das Tastverhältnis einer niederfrequenten PWM ist dann sehr schön am Verhältniss der beleuchteten Falllänge der Regentropfen zu dunkel zu sehen.
 
Gute KSQ können mit PWM-Frequenzen um 2-3 kHz angesteuert werden und glätten ohnehin, ausgangsseitig. Das ist selbst für Videoanwendungen mit 90 FPS problemlos geeignet. Der Mensch erkennt bei 200 Hz reeller PWM-Beschaltung kein Flackern mehr, so sehr er es auch im Dunkeln herumschwenken mag.. Weder im Regen noch unter Bewegung im Nebel o.Ä.

Moderne "Gaming"-Monitore mit 120/144/165 Hz schalten in dunklen Szenen die LED-Backlight bei jedem Bildwechsel beispielsweise kurz aus. Da sieht einer auch bei eifrigstem Kopfnicken unter Stroboskopbeleuchtung keinerlei Flackern oder dunklen Bildschirm.

Viele Grüße
Wolf
 
Man sieht ja auch nicht das Flackern direkt. Unter geeigneten Bedingungen sieht man den Stroboskopeffekt. Regen fällt mit etwa 6-10m/sek. Damit werden die Pulse einer 200Hz PWM mit etwa 3cm Abstand der beleuchteten Fallstreckenabschnitte sichtbar. Aufgefallen ist mir das an der Frontlampe meines AWs beim Fahren in Schneeregen. Da war die innerhalb eines Pulses gefallene Strecke noch viel größer (so im 10cm Bereich - nasser Schneeregen fällt wohl schneller).
Alternativ kann man auch ein sich drehendes Speichenrad anleuchten. Da sieht man das viel besser. Wenn man die richtige Drehgeschwindigkeit trifft, scheint es sich rückwärts zu drehen.
Ist ja nix was stört. Normal beleuchtete Flächen oder Monitore flackern ja flächig mit der PWM-frequenz, da merkt man das definitiv nicht. Und wenn die PWM-frequenz im kH Bereich liegt kann man es an fallenden Regentropfen auch nicht mehr sehen (am Speichenrad bei der richtigen Drehgeschwindigkeit natürlich schon).
 
Hm, konnte ich bei meinen und anderen besseren Lampen nicht feststellen. Meine werden beispielsweise mit 2 kHz reell beschaltet und sind leicht geglättet, da wird es wohl sehr schwierig, den Effekt im Regen zu erkennen.

Schneeregen fehlt, sonst würde ich es testen.

Viele (auch bessere) Taschenlampenansteuerungen aus Asien lassen den Stroboeffekt sehr einfach erkennen, das kann ich bestätigen. Selbst die "besseren" Flashlight-Lösungen mit µC-Ansteuerung wie die Nanjg AK-47 oder KD7135V2 erzeugen recht gut sichtbare Stroboeffekte.

Viele Grüße
Wolf
 
ist subjektiv. Die Sakkadensuppression auch. Die "Sehenden" machen nur 5% der Bevölkerung aus.
Der Arduino Mega schafft 490Hz PWM Frequenz. Das ist besser als ein Passat und so mancher Mercedes aber sicher nicht perfekt. Aber das Beste was wir kriegen können, oder? Analogdimmen geht mit vielen KSQs, aber wie präzise ist das. Ausserdem scheue ich das Kondenswasser was das zarte Pflänzchen Analogsignal zwischen 0.4 und 2.4V gerne mal achtlos zertritt. Das einzige Analogsignal das ich bislang akzeptiert hab ist die Helligkeit. (Gäbe es auch als I2C, aber dann ist es immer gleich ein Platinchen und passt sicher nicht mehr oben in eine meiner Lichtkanonen.)
 
Die "Sehenden" machen nur 5% der Bevölkerung aus.
Es sind der Sichtbarkeit dennoch physikalische Grenzen durch den Aufbau von Auge und Nervensträngen / Signalverarbeitung im Hirn gesetzt, über welchen es auch den "Sehenden" oder sogar denjenigen, welchen durch 50-300 Hz "Flackern" schlecht wird (oder durch Farbräder/DLP-Beamer oder durch Active 3D Brillen oder, oder..) nicht mehr auffällt und sie nicht mehr beeinflusst (auch nicht unterbewusst, ergo keine Übelkeit/Orientierungslosigkeit beispielsweise).

490 Hz sind für visuelle Effekte recht viel, solange diese nicht im Videobereich (oder gar in Hochgeschwindigkeitkameraaufnahmen) eingesetzt werden.

Für eine einfachere Auslagerung (und somit freie CPU-Time) könnte eine Auslagerung auf dedicated ICs sorgen. Diese können auch auf der Seite des Megas verbleiben, solange die Signalleitung zur KSQ nicht gestört wird (wofür zugegebenermaßen schon einige Dezimeter freie, ungeschirmte Litze sowie ebenfalls PWM-basierte Signalerzeugung in der Nähe ausreicht..).

Für eine wirklich effektive Wirkung auf den "Zuschauer" / Beeinflussten finden im militärischen Bereich beispielsweise Frequenzen unterhalb von 30 Hz Verwendung:

https://en.wikipedia.org/wiki/LED_Incapacitator
http://www.hrpub.org/download/20160229/UJEEE3-14905726.pdf

Viele Grüße
Wolf
 
Zuletzt bearbeitet:
hm, genau so hatte ich das aber bei meiner letzten Bordelektronik gemacht der PWM des Arduino direkt auf den DIM Eingang der KSQ, sowohl für Blinker als auch Frontlicht. Warum hätte ich ein Tiefpass verwenden sollen?
Kommt auf die KSQ an. Wenn die nur "an" und "aus" versteht, natürlich gar nicht. Es gibt aber einige (z.B. hier: klick, klick) bei denen man den Steuereingang sowohl mit PWM ansteuern kann als auch mit einer analogen Spannung.

Flackern? Die PWM Frequenz liegt bei 30 - 60 kHz wenn ich nicht irre.
Nach dem, was ich >hier< finde, könnte man die so hoch einstellen, aber das ist viel mehr als die üblichen dimmbaren KSQs verkraften, deren Grenzen liegen eher um 1 kHz herum.

PWM-Frequenzen >1 kHz sollten auch reichen, um das Wahrnehmungsproblem zu vermeiden. Das besteht nicht im Flackern an sich, sondern darin, dass getaktete LEDs kein kontinuierliches Bild erzeugen. Wenn sich die LED schnell genug am Auge vorbeibewegt (oder andersherum Du den Blick schnell genug an ihr vorbeischwenkst), bildet eine analog gedimmte LED einen schwach leuchtenden Streifen ab, eine PWM-gedimmte einzelne helle Punkte oder kurze Striche. Das fällt v.a. dann auf, wenn das Tastverhältnis niedrig ist, und stört v.a. im peripheren Blickfeld, und die Wahrnehmung ist wohl individuell verschieden.

Bei den Scheinwerfern kann übrigens die stromabhängige Farbtemperatur ein Grund sein, trotzdem mit PWM zu dimmen. Analoges Dimmen würde hier nicht nur die Helligkeit ändern, sondern das Licht auch etwas gelblicher oder bläulicher machen.
 
Zuletzt bearbeitet:
@TitanWolf
Du verstehst es nicht, wie die meisten der 95%. Gewöhnlich helfen da auch keine Erklärungen. Der Mensch ist so ausgelegt dass er nur glaubt was er sieht. Es geht nicht um Flackern oder Flimmern. Ich find den Artikel nicht mehr. Google mal PWM und Sakkadensuppresion, oder glaub es einfach, dass das für manche Leute ein Problem ist. Die
Signalverarbeitung
beinhaltet einen Filter, der bei Augenbewegungen das Bild ignoriert damit es durch den schnellen Schwenk nicht verschmiert. Lieber ein Standbild als ein unbrauchbares sagt der Filter. Wenn sich jetzt die hellen Blitze einer stark PWM gedimmten LED während der Augenbewegung durch den Filter brennen dann hast Du ein Fahrzeug das schlagartig durch die Luft in den Acker fliegt wahrgenommen. Weil die echte Position der Rückleuchten nicht zum Standbild vom Beginn der Augenbewegung passt.

Als besagte Passatbaureihe rauskam hab ich das erste mal einen Ausweichhaken gefahren. Man kann es zwar trainieren, dass man es ignoriert. Aber Spass ist es immer noch keiner hinter so einem Auto zu fahren. Da es aber so viele davon gibt hilft auch Überholen oder zurückfallen lassen nichts. Mercedes, Peugeot, ... Die meisten Hersteller haben so ein Foltergerät im Programm.
 
Zuletzt bearbeitet:
Du verstehst es nicht, ..
Ich kann Deine Schilderung problemlos nachvollziehen (und wenn ich nur glauben würde, was ich -sehe-, wäre ich längst nonexistent), doch sind KFZ-Beleuchtungen keinesfalls mit hohen Frequenzen PWM-angesteuert. Da reicht eine normale Videoaufzeichnung mit 30-60 FPS und Du hast eine deutlich sichtbare PWM-Frequenz..

Wenn eine ausreichend hohe PWM-Schaltfrequenz + evtl. Glättung genutzt wird, sollten sich keine "Lichtblitze durch den Filter brennen", da keine "Lichtblitze" für das menschliche Auge mehr vorhanden sind, sondern ein geglättetes Niveau (Medianhelligkeit über Wahrnehmungszeit): Die Frequenz liegt deutlich über der Wahrnehmungsschwelle. Der Filter sitzt jedoch hinter der physikalischen Wahrnehmungsschwelle.

Sicher kann es dann vorkommen, dass Du bei einer von X-hundert Begegnungen mit hochfrequenter LED-PWM-Ansteuerung das Pech hast, den Effekt zu erfahren.. im Vergleich zu "jedes Mal" wohl eine deutliche Besserung. KFZ-Beleuchtungen sind leider nur mit ~150 - 600 Hz beschaltet (je nach Anbauposition und Technik).

Schau mal hier hinein, dort sind unterschiedliche Methoden, die Lichtimpulshelligkeit über Zeit und den Perlschnureffekt zu reduzieren oder zu vermeiden, untersucht worden (wenn auch nicht in Bezug auf Dein Sakkadensuppressionsproblem): https://www.vda.de/dam/vda/publications/2015/fat-schriftenreihe-270/FAT-Schriftenreihe_270.pdf

So gibt es neben der (deutlich) höheren Frequenz auch die Möglichkeit, durch die Art des KSQ-Ausgangssignals einen hellen Lichtimpuls zu glätten, was bei hochwertiger Technik auch schon angekommen ist. Anstelle "Ein-Aus" wird dann "Ein-Weniger ein" oder ein geglätteter KSQ-Ausgang verwendet, wodurch die LED selbst (so schnell sie auch umschaltet) keine hellen Lichtblitze in Ein-Aus-Beschaltung mehr erzeugt, somit sollte Dein Problem mit Helligkeitsunterschieden nicht auftreten.

Viele Grüße
Wolf
 
Zuletzt bearbeitet:
Wieso diskutiert ihr hier OT über solche "Nebensächlichkeiten"? Es geht hier bitte nur um die Programmierung mittels Arduino ...
 
OK, verstehe. Man sollte also programmatisch, durch Beschaltung und Wahl der KSQ sicherstellen, dass es nicht zu den beschriebenen Effekten kommt. Meine bestehende Alleweder Schaltung werde ich dahingehen auch noch mal überprüfen auch wenn ich rein visuell dort keine solche Effekte bemerkt hätte und gegebenenfalls nachrüsten.
 
Also was sicher hilft ist die KSQ nach dem Maximalstrom zu bemessen und nicht zu gross und dann runterdimmen. So ist die maximale Helligkeit der Leuchte im Betrieb 100% PWM Taktverhältnis. Die Lösung des obigen Problems ist die einzelnen Chips der Leuchte phasenversetzt zu takten, so ist die Leuchte als ganzes nie ganz dunkel, aber wie Reinhard sagt führt das für VM-Leuchten zu weit. Wir machen das Beste daraus, was uns der Arduino bietet. Milliardenbudget haben wir ja leider nicht.

noch mal überprüfen
Du kannst die Perlschnur mit dem Fotoapparat aufnehmen indem Du das Bild absichtlich stark verwackelst. Musst ein paar mal probieren bis eine schöne Perlschnur drauf ist. Anzahl Punkte zählen und durch Belichtungszeit teilen gibt PWM-Frequenz. >1000Hz wären wünschenswert, (für Fahrzeugleuchten), von den meisten KSQs noch verdaubar, aber selten.
 
Hi René,
wenn Du den Nano noch nicht programmiert hast, dann mach das bitte auch noch nicht. Der läßt sich anschließend nicht mehr programmieren, weil die serielle von dem Programm immer gelesen wird und damit nach dem Anstöpseln an USB die Schnittstelle blockiert. Irgendwie logisch :D Einfache Lösung: Zu Beginn des Programms eine Pause einbauen, dann sollte es gehen.
Getestet habe ich es noch nicht. Ich muss meinen Nano nun erst einmal zurücksetzen. Das geht wohl nur über neues Flashen des Bootloaders.

Grüße
Heiko
 
Der läßt sich anschließend nicht mehr programmieren
Blödsinn, es ist völlig egal was das Programm macht - unmittelbar nach dem Reset kommt immer(!) erst der Bootloader und wartet ne kleien Weile ob der Arduino programmiert werden soll. Erst dann wird das eigentliche Programm gestartet.
Und wenn man den Bootloader kaputt macht, dann kann man das Teil jederzeit über den ISP neu aufspielen.
 
Zurück
Oben Unten