Guten Morgen... Ich habe diesen Text auch in dem etwas älteren Thread bereits angehangen, habe aber den Eindruck, das das dort schlecht gefunden wird ganz am Ende. Sorry deswegen schonmal für das Crossposting. Meine Problemstellung. Ich erwarte keine fertige Lösung, sondern hoffe, das ich hier die Frage beantwortet bekomme, ob meine Aufgabe mit einem Microcontroller zuverlässig lösbar ist. Den Gedanken, einen Raspberry Pi zu nehmen und dort mit Python diese Funktion zu bauen, habe ich verworfen. Ich meine das die Software dort zu komplex (OS) wäre und das ganze dann zu anfällig werden würde bei Spannungsausfall o.ä. Mein LED Leuchtmittel arbeitet mit 24 V/DC, wird allerdings nicht durchgehend betrieben, sondern erzeugt durch einen internen oder extern hinzugeführten Taktgeber ein recht kurzes Blitzlicht von z.T. wenigen Millisekunden. Was mir vorschwebt. Ein Microcontroller, der auf einem Eingang einen statischen Kontakt erhält, wenn die LED mit dem Blitzen beginnen soll. (Dämmerung) Ein Helligkeitssensor, der dieses Blitzen erfasst und sich auch von einem statischen Fremdlich nicht stören lässt. Es muss also blitzen oder blinken. Bei ausbleiben des Blitzlichts, entweder durch kompletten Ausfall oder durch eine Störung in der Steuerung mit daraus resultierendem Dauerlicht, soll ein Ausgang aktiv werden. Ein Messzyklus darf gerne eine Minute oder auch etwas länger dauern. Sowas machbar.? Natürlich sollte der Controller auf evtl. andere Taktzeiten und Pausenzeiten anpassbar sein... Danke für evtl. Anregungen. -- Rüdiger
Gast
#5196015
Rüdiger S. schrieb: > Ein Helligkeitssensor, der dieses Blitzen erfasst und sich auch von > einem statischen Fremdlich nicht stören lässt. Es muss also blitzen oder > blinken. Das funktioniert nur, wenn er Informationen bekommt, wann genau es Blitzen soll, also den eigendlichen Impuls der den Blitz auslöst. Sonst kann er Fremdlicht/Blitze nicht von den gewollten unterscheiden.
Gast
#5196029
Ein Helligkeitssensor? Vielleicht besser mit 2 Sensoren. Der eine erfasst das Umgebungslicht, Fremdlicht/Blitze und die LED. Der andere Umgebungslicht, Fremdlicht/Blitze und die unvermeidbaren Reflexionen des LED-Lichtes. Wenn die Auflösung der ADCs des Mikrocontrollers nicht ausreichen, zuerst mit einer analogen Schaltung in Umgebungslicht/Fremdlicht/Blitze und LED aufteilen. Impulslängen messen, Regelmässigkeiten erkennen, Ausreisser herausrechnen... alles Sachen, die sich auf jedem Mikrocontroller berechnen lassen.
Rüdiger S. schrieb: > Ich habe diesen Text auch in dem etwas älteren Thread bereits angehangen Du meintest den Beitrag "Brainstorming – Funktionsüberwachung einer LED-Beleuchtung" Du kannst alte Threads verlinken (einfach aus der Browserzeile die Adresse in die eingabebox kopieren) wenn sie tatsächlich etwas zur Sache beitragen.
So war der Gedanke, das der Controller das Blitzen als Normalfall ansieht, wobei die Pulszeit nicht wichtig ist, und alles was statisch ist, als Fehler interpretiert. Deswegen der externe Steuereingang, der den Beginn des Blitzens und damit der Überwachung signalisiert. Welche Hardware würde sich anbieten.?
Ein Attiny44 würde sich anbieten. Willst du das selber bauen? Kannst du das? Butter bei die Fische... Klaus.
Rüdiger S. schrieb: > Sowas machbar.? Ja. Hat man die Info, wann es blitzt (elektrische Verbindung, genaues Timing) kann man mit einem Synchrongleichrichter das Signal rausfiltern, hat man es nicht wird man mit einem Hochpass schnelle Helligkeitsänderungen stark verstärkt von langsam wechselndem Dauerlicht das gar nicht verstärkt wird unterscheiden und muss dann auswerten, ob die Abstände passen, wobei man Störungen teilweise tolerieren sollte. Schlecht wird es, wenn mehrere LEDs asynchron durcheinanderblitzen.
Michael B. schrieb: > Schlecht wird es, wenn mehrere LEDs asynchron durcheinanderblitzen. Sie können auch synchron durcheinanderblitzen und es bliebe schlecht zu erkennen. Aus Sicht des Hochpassfilters entstünde soetwas wie Schwebungen. Aber ich würde jedem, der Hochpassfilter programmieren kann, auch die Signalerkennung zutrauen. Es gibt ja noch die Intensität und etwas PLL/ FFT, so man die Impulsdauer/ Frequenz grob abschätzen kann.
Klaus R. schrieb: > Ein Attiny44 würde sich anbieten. Willst du das selber bauen? Kannst du > das? Butter bei die Fische... Das Zusammenbauen auf einem Board ist kein Problem. Was die Software angeht. Das wird sicher nicht einfach. Ich mache viel mit Linux, und hab schon mit nem Pi und Python solche Sachen gestrickt. Aber gerade das halte ich für die falsche Plattform... Was das Programm angeht, wäre das für mich sicher hilfreich, wenn es Tutorials mit ähnlichen Aufgaben geben würde. Also Eingäne abfragen, Relais damit steuern. So SPS like... Ich hab mal für einen Bekannten eine Platine bestückt und mit einer Software, die Ponyprog heisst unter XP prgrammiert. War ne Weihnachtsbaum Lichterkette. Die Software war da aber bereits für da. Irgendein hex oder bin File...
Boris O. schrieb: > Michael B. schrieb: >> Schlecht wird es, wenn mehrere LEDs asynchron durcheinanderblitzen. > > Sie können auch synchron durcheinanderblitzen und es bliebe schlecht zu > erkennen. Aus Sicht des Hochpassfilters entstünde soetwas wie > Schwebungen. > > Aber ich würde jedem, der Hochpassfilter programmieren kann, auch die > Signalerkennung zutrauen. Es gibt ja noch die Intensität und etwas PLL/ > FFT, so man die Impulsdauer/ Frequenz grob abschätzen kann. Da blitzt nix durcheinander. Das ist mehr so eine Kennung wie bei Telegraphie. Aber jedes Leuchtmittel hat andere Blitzintervalle. Die stehen aber nicht nebeneinander. Der Controller sollte also tolerant sein und nur auf statische Signale wie Dauer an oder Dauer aus länger als z.B. 5 Minuten mit einem Fehler reagieren.
Gast
#5196255
Jedes Tutorial zeigt, wie man Eingänge abfragt und LEDs ansteuert. Und fast jedes zeigt, wie man statt einer LED ein Relais ansteuert. Vielleicht möchtest du mit meinem anfangen: http://stefanfrings.de/mikrocontroller_buch/index.html In dem Buch gibt es ein Experiment mit einen Phototransistor, der auf Helligkeits-Änderungen reagiert. Die Artikelsammung von Mikrocontroller.net ist sicher auch hilfreich.
Stefan U. schrieb: > Jedes Tutorial zeigt, wie man Eingänge abfragt und LEDs ansteuert. Und > fast jedes zeigt, wie man statt einer LED ein Relais ansteuert. > > Vielleicht möchtest du mit meinem anfangen: > http://stefanfrings.de/mikrocontroller_buch/index.html > > In dem Buch gibt es ein Experiment mit einen Phototransistor, der auf > Helligkeits-Änderungen reagiert. > > Die Artikelsammung von Mikrocontroller.net ist sicher auch hilfreich. Danke. Ich sehe mir das mal an und werde mal ein Controller (Attiny44..?) ordern und was noch erforderlich ist um den zu programmieren...
Gast
#5196292
In dem Buch wird ein ATtiny13 verwendet, der wird für deine Anwendung auch genügen. Prinzipiell kannst du alle Anleitungen aus dem Buch auch mit dem ATtiny44 nachvollziehen. Die Pinbelegung ist dann halt anders.
Schönes Buch, Stefan - Kompliment! Klaus.
Gast
#5196316
Ich finde, es fängt noch mit zu viel Theorie an.
Hab mir nur Band 3 durchgelesen, den finde ich als Einstieg super...die DCF Uhr baue ich als 24h Version auch mal, endlich ein guter Anwendungsfall für die gesammelten Drehspulanzeigen ;) Klaus.
Gast
#5196378
Wenn du mit Band 3 Anfängst, hast du ungefähr soviel gelernt, wie mit Franzis Bausätzen - nämlich nichts. In band 1 und 2 wird erklärt, wie es funktioniert. Band 3 sind nur konkrete Anwendungsbeispiele.
...ich wollte in dem Sinne nichts lernen, nur mal durchlesen. Ein bißchen was weiß ich ja schon ;) Klaus.
Gast
#5196390
Na dann. Was nettes zusammen zu klöppeln macht den meisten Menschen natürlich mehr Spaß, als Grundlagen zu lernen.
Stefan, es ist nicht ganz einfach mit dir. Ich kenne den Großteil dieser Grundlagen. Mir ging es nur um die nette Idee. Und dass ich dein Buch an Neueinsteiger weiterempfehlen könnte. Klaus.
Gast
#5196427
Ach so, da habe ich dich völlig falsch eingestuft. Dann ist das Buch auch nix für Dich. Finger weg :-)
Stefan U. schrieb: > Ich finde, es fängt noch mit zu viel Theorie an. Gut, hab jetzt die Elektronik Grundlagen auch übersprungen. Wie ist es mit der IDE.? In den Buch ist ja eine 4er Version gezeigt. Ist die noch genauso nutzbar.? Oder sollte man besser eine neuere Version nutzen. Linux würde ich ja bevorzugen. Aber wenn das bedeutet, alles zu Fuß zu schreiben, dann doch lieber was von Win... Zumindest am Anfang.
Gast
#5196534
> Wie ist es mit der IDE.? Wird im ersten Band verwendet. Im dritten band zeige ich die Alternativen ohne IDE auf (mit und ohne Makefile). > In den Buch ist ja eine 4er Version gezeigt. Ist die noch > genauso nutzbar.? Ja, nur USB Programmieradapter sind im Windows 10 problematisch. Aber dafür verweise ich auf avrdude und GUI dazu. > Oder sollte man besser eine neuere Version nutzen Kann man machen, dann muss man aber selbst herausfinden, wie die bedient wird. Ich habe keine Lust, das Buch alle par Jahre neu zu schreiben. Bedenke, dass die Versionen 4.19, 5.x, 6.x und jetzt 7 alle ziemlich rasch nacheinander veröffentlicht wurden. Wobei die Versionen 5 und 6 richtig mies waren. 7 ist ok, aber auch gewaltig groß. Läuft auf Papas altem Laptop nicht gut. > Linux würde ich ja > bevorzugen. Aber wenn das bedeutet, alles zu Fuß zu schreiben Linux hat zwei zig Jahren bereits grafische Oberflächen und es gibt auch jede menge AVR kompatible IDE's. Zum Beispiel Netbeans und Eclipse. Das alte AVR Studio 4.19 läuft auch (bis auf die USB Schwierigkeiten) problemlos unter Wine und in einer VM.
Gast
#5196704
Klaus R. schrieb: > Ein Attiny44 würde sich anbieten. Warum? Warum kein R8C? Warum nicht ein ...? Hier greift einer zu seinem Standard-Tool (sein einziges?) ohne die Aufgabenstellung verstanden zu haben.
Gast
#5196807
Horst schrieb: > Das funktioniert nur, wenn er Informationen bekommt, wann genau es > Blitzen soll, also den eigendlichen Impuls der den Blitz auslöst. Sonst > kann er Fremdlicht/Blitze nicht von den gewollten unterscheiden. So hochkomplex ist es doch nun nicht, die Blitze von statischem Fremdlicht zu unterscheiden, auch wenn man den Zeitpunkt nicht kennt. Früher (tm) hätte man einfach einen Kondensator zum differenzieren des Signals verwendet. Heutzutage wird man wohl eher ausreichend schnell samplen (bei einer Blitzdauer von 1ms also etwas mehr als 1kSa/s) und die Differenzen aufeinanderfolgender Samples berechnen. Größer Null bedeutet dann: "Blitz angegangen" ... ;-)
Gast
#5196894
Rüdiger S. schrieb: > Das Zusammenbauen auf einem Board ist kein Problem. Was die Software > angeht. Das wird sicher nicht einfach. Ich mache viel mit Linux, und hab > schon mit nem Pi und Python solche Sachen gestrickt. Du hast also ein Grundverständnis von Software, nutze es. > Aber gerade das halte ich für die falsche Plattform... Ich auch. Ich will jetzt verhauen werden: Befasse Dich mit Arduino! Einen Blitz mit ein paar Millisekunden kann der A* klaglos steuern. Da er weiß, wann es blitzt, sollte auch die Abfrage eines Fototransistors möglich sein. Mein Denkansatz wäre, den Fototransistor ständig abzufragen und beim Blitz zu gucken, wie weit sich dessen Wert verändert.
> Rüdiger S. schrieb: >> Das Zusammenbauen auf einem Board ist kein Problem. Was die Software >> angeht. Das wird sicher nicht einfach. Ich mache viel mit Linux, und hab >> schon mit nem Pi und Python solche Sachen gestrickt. Manfred schrieb: > Du hast also ein Grundverständnis von Software, nutze es. > >> Aber gerade das halte ich für die falsche Plattform... > > Ich auch. Ich will jetzt verhauen werden: Befasse Dich mit Arduino! Was wäre da der Nachteil? Wenn das ganze funktioniert, könnte es sein, das ich da dann eine grosse Menge von produzieren lassen muss. Ist da dann Arduino das richtige.? > Einen Blitz mit ein paar Millisekunden kann der A* klaglos steuern. Da > er weiß, wann es blitzt, sollte auch die Abfrage eines Fototransistors > möglich sein. Es wird nur der Status bekannt sein, das jetzt geblitzt wird. Nicht jeder Blitz.! > Mein Denkansatz wäre, den Fototransistor ständig abzufragen und beim > Blitz zu gucken, wie weit sich dessen Wert verändert.
Gast
#5197323
> grosse Menge von produzieren lassen muss. > Ist da dann Arduino das richtige? Jedenfalls ist es kein Hindernis.
Gast
#5197363
Wieder so ein Thema für notorische Controlfreaks. Man bastelt einen Murks zusammen und guckt dann mit nem riesen Überwachungsbrimborium, wie lange es hält. Während jeder vernünftige Mensch einfach richtig rechnet und schon geht die Schaltung nicht kaputt. :)
batman schrieb: > Wieder so ein Thema für notorische Controlfreaks. Man bastelt einen > Murks zusammen und guckt dann mit nem riesen Überwachungsbrimborium, wie > lange es hält. Während jeder vernünftige Mensch einfach richtig rechnet > und schon geht die Schaltung nicht kaputt. :) Dem muss ich jetzt widersprechen. Die LED Leuchten sind alles aber sicher kein Murks. In diesem konkreten Fall geht es nur darum, dessen Funktion möglichst zu 100% sicherzustellen.! So wie ( als Beispiel ) eine Signalleuchte an einer Kreuzung, dessen Ausfall auf jeden Fall erfasst werden muss. Da ist auch keine Bastellösung am Werk, aber jedes Bauteil geht mal kaputt.! Und das soll eben erkannt werden. Zu Zeiten, als alles mit stromintensiven Glühlampen oder Gasentladungslampen oder Bogenlampen beleuchtet wurde, war der Indikator eben der Strom in bekannter Höhe.! Aber LED oder dessen Treiber ziehen auch dann mal noch Strom wenn die LED nur noch IR emittiert.!
Gast
#5197517
Diese Vergleiche passen hier nicht, da in einer LED kein Glühdraht verbaut ist, der immer dünner wird und irgendwann durchbrennt. Der nicht-existente Verschleiß von LED wird immer wieder gern als Entschuldigung für Ausfälle genommen, die in Wahrheit zu 99% auf Designfehlern beruhen.
batman schrieb: > Diese Vergleiche passen hier nicht, da in einer LED kein Glühdraht > verbaut ist, der immer dünner wird und irgendwann durchbrennt. > Der nicht-existente Verschleiß von LED wird immer wieder gern als > Entschuldigung für Ausfälle genommen, die in Wahrheit zu 99% auf > Designfehlern beruhen. Ist doch völlig unerheblich, warum die LED(s) nicht mehr leuchten. Der Punkt ist, das ich die Funktion überwachen will. Im Grunde auch losgelöst von der Art des Leuchtmittels. Bei Glühlampen war es eben einfacher und es kam praktisch nicht vor, das eine Glüchlampe den Nennstrom hat fliessen lassen und trotzdem nicht leuchtet.!
Gast
#5197579
Na das ist bei ner LED auch nicht viel anders, wenn sie durchbrennt.
Gast
#5197583
Falsch. Es kommt vor dass eine LED noch Strom aufnimmt aber trotzdem nicht leuchtet.
Gast
#5197607
Wolf-Rüdiger S. schrieb: > Wenn das ganze funktioniert, könnte es sein, das ich da dann eine grosse > Menge von produzieren lassen muss. Ist da dann Arduino das richtige.? Das kommt drauf an, was "eine große Menge" bedeutet. Redest du von 1000, 10000 oder mehr? Oder passt ein Arduino aus irgendwelchen konkreten Gründen nicht in dein Konzept? Eine Eigenentwicklung kostet Arbeitszeit und du hast weitere Grundkosten. Dafür bekommst du eine maßgeschneiderte Lösung. Aber ich bezweifle, dass du bei einer Vollkostenrechnung preislich damit in die Region von chinesischen Aduino Klones oder Derivaten kommst - einfach schon, weil du schon beim Einkauf nicht auf deren Preise kommst.
Gast
#5197615
batman schrieb: > Der nicht-existente Verschleiß von LED wird immer wieder gern als > Entschuldigung für Ausfälle genommen, die in Wahrheit zu 99% auf > Designfehlern beruhen. Natürlich verschleißen LEDs. Guck dir irgendwelche 7-Segment LED-Anzeigen an, die über 20 Jahre 24/7 geleuchtet haben. Durch verstärkte Diffusion ändern sich die Halbleiterstrukturen, so dass der Wirkungsgrad langsam abnimmt. Die Halbwertsdauer für die Helligkeit von LED liegt typischerweise in der Größenordnung von einigen zehntausend Stunden. Falls du Zugang zur IEEE Library hast: http://ieeexplore.ieee.org/document/7360693/
Gast
#5197631
Das ist hier sicher nicht das Thema.
Wolfgang schrieb: > Wolf-Rüdiger S. schrieb: >> Wenn das ganze funktioniert, könnte es sein, das ich da dann eine grosse >> Menge von produzieren lassen muss. Ist da dann Arduino das richtige.? > > Das kommt drauf an, was "eine große Menge" bedeutet. Redest du von 1000, > 10000 oder mehr? Oder passt ein Arduino aus irgendwelchen konkreten > Gründen nicht in dein Konzept? Das wird im Endausbau da etwa die Mitte sein. > Eine Eigenentwicklung kostet Arbeitszeit und du hast weitere > Grundkosten. Dafür bekommst du eine maßgeschneiderte Lösung. Aber ich > bezweifle, dass du bei einer Vollkostenrechnung preislich damit in die > Region von chinesischen Aduino Klones oder Derivaten kommst - einfach > schon, weil du schon beim Einkauf nicht auf deren Preise kommst. Das fertige Endprodukt sollte in ein Hutschienenmodul passen. Eine Automatenbreite. Und es sollte unempfindlich gegenüber sporadischen Netzunterbrechungen sein. Also kein komplexes OS, was dann nur noch Müll auf der SD findet.
Dieser Programmer wird im Buch empfohlen. https://www.amazon.de/Diamex-7200-USB-ISP-Stick-AVR-Programmieradapter/dp/B0068K0D4O In den Rezessionen wird auch Linux als verwendbar bezeichnet.. Gehe ich Recht in der Annahme, das ich in einem aktuellen Atmel Studio 7 was entwickeln kann (VM) und das .hex dann unter Linux auf das Device schreiben.? Falls Windows aus der VM die USB Schnittstelle nicht ansprechen kann... Was für mich Zeit sparen würde, wenn es bereits fertige Platinen mit einem Controller und drumherum etwas Peripherie geben würde, die auch noch Platz bieten, eigene Anschaltungen zu plazieren. Also für Eingangshalbleiter oder kleine Printrelais... Gibts da was.? Klar geht ne Lochraster, aber sowas mit teilweise schon etwas Layout drauf..? Wäre schick
Gast
#5197735
> Gehe ich Recht in der Annahme, das ich in einem aktuellen Atmel Studio 7 > was entwickeln kann (VM) und das .hex dann unter Linux auf das Device > schreiben.? Falls Windows aus der VM die USB Schnittstelle nicht > ansprechen kann... Jawohl.
Hi Stefan U. schrieb: > Falls Windows aus der VM die USB Schnittstelle nicht > ansprechen kann... Sowohl ein ISP-Programmer wie auch diverse Arduino-Clones tauchen in der VirtualBox auf. Das erzeugte HEX-File sollte aber vom Betriessystem unabhängig identisch aussehen - oder zumindest gleiche Funktionalität auf dem Target hervorrufen. MfG
Gast
#5197767
> Sowohl ein ISP-Programmer wie auch diverse Arduino-Clones tauchen > in der VirtualBox auf. Das heißt noch nicht, dass sie funktionieren. Oft klappt es, manchmal nicht. Ich wollte nur drauf hinweisen, dass (wenn es nicht klappt) dies kein großes Hindernis wäre.
Gast
#5197807
Wolf-Rüdiger S. schrieb: >> Ich auch. Ich will jetzt verhauen werden: Befasse Dich mit Arduino! > > Was wäre da der Nachteil? Wenn das ganze funktioniert, könnte es sein, > das ich da dann eine grosse Menge von produzieren lassen muss. Ist da > dann Arduino das richtige.? Mit einem Arduino den Testaufbau machen um die Machbarkeit zu klären und zu testen. Für meine Bastelaktionen baue ich den ein, billiger als Chinesen-Arduinos komme ich nicht an den Controller. Für eine Serie wäre eher das blanke Controller-IC einzusetzen, weil noch weitere Peripherie mit auf die Leiterplatte muss. Da werden dann auch Kosten zu rechnen sein, ob es ein kleinerer µC tut.
Hab nun schon ein 5er Set der 13A-PU mit Sockel und diesen USB Programmer. Dann noch ein paar Lochraster. Gibt da so kleine 4x6 cm... Und ein Set Schraubklemmen zum einlöten. Achja, diese Jumper Reihe.. Found by Amazon... Den ganzen Kleinkram wie R's und C's hab ich da... Ich komme bestimmt nochmal bzgl. Programmiertips vorbei.;) Super Forum übrigens. Extrem schnelle Reaktionen...! Danke Falls ich was wichtiges vergessen habe, ich order dann morgen...
Beitrag #5198227 wurde von einem Moderator gelöscht.
Schön, dass du einfach loslegst - die ersten Erfolge werden dich beflügeln und bald hast du mehr uC Ideen als Zeit ;) Ein Breadbord für den Testaufbau ist WICHTIG! Klaus.
Klaus R. schrieb: > Schön, dass du einfach loslegst - die ersten Erfolge werden dich > beflügeln und bald hast du mehr uC Ideen als Zeit ;) Ein Breadbord für > den Testaufbau ist WICHTIG! > > Klaus. Ach Mist. Zu spät. Ich hab jetzt so kleine Lochraster, und für den µC noch Sockel. Ich denke die Peripherie für die I/O mach ich dann in Freiluft zum Test.
Schlecht ;) Kauf dir sowas! Klaus.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.