Steuerung LED-Strip für ein Projekt

Die Annahme "Rds(on) Faktor 2,25 bei Tj = 175°C" ist ein Extremwert und hätte ich mir genauer gewünscht. Allerdings wüßte ich auch nicht, welche Figur da hilft.

Wieso genauer? :o

Der Wert ist im Datenblatt zu finden (Fig 4) und MUSS bei der Berechnung mit einbezogen werden.
Wenn man den Maximalstrom wissen will, und das war bei der Berechnung mein Ziel, muss man von der Grenztemperatur ausgehen.
Ich sehe da keinen Raum für "Genauer"

Irgendwo habe ich Wärmeleitpaste herumliegen, die könnte den Wärmeübergang verbessern.

Die Verwendung ist ein Pflicht Standard.
Die Angaben in den Datenblättern gehen immer von einer Verwendung einer Wärmeleitpaste aus.
Sonst steht es explizit dabei.
Zumindest kenne ich es nicht anders.

Das Datenblatt sagt:
0,5 K/W , zwischen Transe und Kühlkörper, bei Verwendung von Wärmeleitpaste, und ich sage:
Nur mit Federklammer, nicht mit Verschraubung zu erreichen
Mein Lehrer sagte damals: Nimm 2 K/W für trocken verschraubt an.

Ich habe zusätzlich folgende Dinge gelernt:

Danke für die Rückmeldung!
Und ja, dann hat es sich ja gelohnt.

Nimm 2 K/W für trocken verschraubt an.

Faustregeln sind immer gut.
Man sollte aber auch eine Idee der (Rand-)Bedingungen haben. Ist das für TO220 auf "ausreichend" großem Kühlkörper gemeint, oder passt der Wert für jede M3- Schraube?

Ist das für TO220 auf "ausreichend" großem Kühlkörper gemeint, oder passt der Wert für jede M3- Schraube?

Ich störe mich an dem Wort "ausreichend"

"ausreichend" bedeutet für mich hier, dass der Kühlkörper die Kühlfläche des Transistors vollständig abdeckt. Vollflächiger Kontakt. Ob der Kühlkörper, an sich, "ausreichend dimensioniert" ist, lässt sich an seinem Wärmewiderstand und den anderen Schaltungsparametern fest machen.

Die Schraube ist da recht belanglos.
Mal abgesehen davon, dass ein zu festes anziehen kontraproduktiv ist, da es den Wärmewiderstand deutlich erhöht.

Viel hilft viel
Ist da eher nicht angesagt.
Ebenso bei der Paste.

Setze Deinen Code bitte in Codetags (</>-Button oben links im Forumseditor oder [code] davor und [/code] dahinter ohne *).
Das kannst Du auch noch nachträglich ändern.

Gruß Tommy

Ah mist sorry. Also nochmal:
Okay, vielen Dank schonmal an euch!

Ich bin jetzt von de 24V Streifen umgestiegen auf einen NeoPixelRing 24 LEDs, da ich das Ganze in einer Box verbauen möchte und das per Batterie speisen will. (Habe jetzt eine 9V Batterie, die ich direkt an den Arduino anschließen würde).
Die Idee ist immernoch die gleiche, ich habe jetzt einen Code hierfür geschrieben, jedoch zeigt er mir immer
'strip' was not declared in this scope an bzgl der Zeile high = strip.setPixelColor ...

Könnt ihr mir sagen woran das liegt und ob ich den Code einigermaßen passend geschrieben habe?

#include <Adafruit_NeoPixel.h>
#define NUM_LIGHTS  24
const int buttonPin = 8;
const int LEDPin = 1;
bool s = HIGH;
int t;
uint32_t low = strip.setPixelColor(0, 0, 0);
uint32_t high = strip.setPixelColor(225, 225, 225);


Adafruit_NeoPixel strip = Adafruit_NeoPixel(NUM_LIGHTS, LEDPin, NEO_GRB + NEO_KHZ800);

void setup() {
  strip.begin();
  strip.show(); // Initialize all pixels to 'off'
  pinMode(buttonPin, INPUT_PULLUP);
}

void loop() {

  s = digitalRead(buttonPin);
  if (s = HIGH) {

    t = random (60000, 180001);

    delay (t);



    for ( int i = 0; i < NUM_LIGHTS; i++) {
      strip.setPixelColor(i, high);
      strip.show();
    }
    delay(1000);

    for ( int i = 0; i < NUM_LIGHTS; i++) {
      strip.setPixelColor(i, low);
      strip.show();
    }

    delay(100);
  }

  else {
    digitalWrite (LEDPin, LOW);
  }
}

Du hättest Deinen Beitrag auch verändern können.

uint32_t low = strip.setPixelColor(0, 0, 0);
uint32_t high = strip.setPixelColor(225, 225, 225);

Adafruit_NeoPixel strip = Adafruit_NeoPixel(NUM_LIGHTS, LEDPin, NEO_GRB + NEO_KHZ800);

Falsche Reihenfolge. Du mußt erst ein Auto kaufen, dann kannst Du damit fahren.

Außerdem hat setPixelColor keinen Rückgabewert.

Das heißt zum einen müsste ich die Zeilen umdrehen und der Befehl für die Farben ist an sich falsch? Wurde mir in der adafruit library vorgeschlagen.. ich bin verwirrt..

Ah, hab den Fehler gefunden

Würdest Du die Nachwelt an Deinen Erkenntnissen teilhaben lassen?

Gruß Tommy

Hi

Ihmr wird wohl in den Tiefen des WWW ein Aufruf folgender Methode über den Weg gelaufen sein:

// Convert separate R,G,B into packed 32-bit RGB color.
// Packed format is always RGB, regardless of LED strand color order.
uint32_t Adafruit_NeoPixel::Color(uint8_t r, uint8_t g, uint8_t b) {
  return ((uint32_t)r << 16) | ((uint32_t)g <<  8) | b;
}

Adafruit_Neopixel.cpp, Zeile 2072ff - die Lib scheint keine interne Versionsnummer zu haben, bei mir ist die 1.1.6 installiert.
In Seinem Code dann wohl in der Art

...
Adafruit_NeoPixel strip = Adafruit_NeoPixel(NUM_LIGHTS, LEDPin, NEO_GRB + NEO_KHZ800);
...
uint32_t aus=strip.Color(0,0,0);
uint32_t an=strip.Color(255,255,255);
...

MfG

PS: Wurde sogar per PN auf die falsche Anrede aufmerksam gemacht - sorry dafür :slight_smile:

  • Ihr :wink:

also hier der aktuelle Code

#include <Adafruit_NeoPixel.h>
#define NUM_LIGHTS  24
const int buttonPin = 12;
const int LEDPin = 8;
//bool s = LOW;
int t;
//int high;
//int low;

Adafruit_NeoPixel strip = Adafruit_NeoPixel(NUM_LIGHTS, LEDPin, NEO_GRB + NEO_KHZ800);

void setup() {
  strip.begin();
  strip.show(); // Initialize all pixels to 'off'
  pinMode(buttonPin, INPUT_PULLUP);
  randomSeed(analogRead(0));
}

void loop() {

  // high = strip.setPixelColor(24, 225, 225, 225);
  //  low = strip.setPixelColor(24, 0, 0, 0);
  // s = digitalRead(buttonPin);
  if (digitalRead(buttonPin) == LOW) {

    t = random (10000, 30000);

    delay (t);

    for ( int i = 0; i < NUM_LIGHTS; i++) {
      strip.setPixelColor(i, 225, 225, 225);
      strip.show();
    }
    delay(1000);

    /* for ( int i = 0; i < NUM_LIGHTS; i++) {
       strip.setPixelColor(i, 0, 0, 0);
       strip.show();
      }*/
    while (digitalRead(buttonPin) == LOW) {
      for ( int i = 0; i < NUM_LIGHTS; i++) {
        strip.setPixelColor(i, 0, 0, 0);
        strip.show();
      }
    }

    if (digitalRead(buttonPin) == HIGH) {

      t = random (10000, 30000);

      delay (t);

      for ( int i = 0; i < NUM_LIGHTS; i++) {
        strip.setPixelColor(i, 225, 225, 225);
        strip.show();
      }
      delay(1000);

      /* for ( int i = 0; i < NUM_LIGHTS; i++) {
         strip.setPixelColor(i, 0, 0, 0);
         strip.show();
        }*/
      while (digitalRead(buttonPin) == HIGH) {
        for ( int i = 0; i < NUM_LIGHTS; i++) {
          strip.setPixelColor(i, 0, 0, 0);
          strip.show();
        }
      }
      delay(100);
    }

    else {
      digitalWrite (LEDPin, LOW);
    }
  }
}

das einzige Problem, was ich momentan habe:
Ich habe mehrere Tests durchgeführt und die delay-Zeit aufgeschrieben.
Eigentlich hätte ich gerne eine random delay-Zeit zwischen einer halben Minute und 3 Minuten
wenn ich jedoch den random betrag auf random (30000, 180000) ändere, dann reagiert mein Licht nichtmehr.
Das Maximum, was ich erreichen konnte war eine delay-Zeit von random (20000, 30000).
Ich bin mir gerade nicht sicher ob das einfach eine zu große Zeit von einer halben bis 3 Minuten sind, beziehungsweise wie ich das in den Griff bekomme.

Wenn mich nicht alles Täuscht, kann random Zahlen bis 2147483647 liefern Und Delay Zahlen bis 4294967295 korrekt verarbeiten.

evtl:
random (10000L, 30000L);

Ansonsten:
Verzichte doch lieber auf das delay() und arbeite lieber mit der "Nachtwächter Erklärung"

Hi Sie dort :wink:

Du benutzt t als zufällige Zeit - als INT deklariert.
Warum INT? Erwartest Du negative Wartezeiten?
Nein -> UNSIGNED (vorzeichenlos) hast Du direkt den doppelten Zahlenvorrat.
int 16bit, bei signed 15bit + Negativ-Bit, bei unsigned 16bit.
-32768...32767 zu 0...65535
Erklärt, warum Du nur auf ~30 Sekunden (32767ms, um genau zu sein) kommst.
Bei 'int unsigned' - ich schreibe uint16_t (u steht hier ebenfalls für unsigned, int16->16bit breit, t ist wohl ein Überbleibsel aus der Urzeit, in der Art laß ich darüber) wird das 15.te Bit nicht für das Vorzeichen benutzt, sondern ganz normal als Zahlen-Wert - da jedes weitere Bit den doppelten Wert hat -> doppelter Zahlenraum.
Meine Schreibweise hat den Vorteil, daß ICH immer sehe, wie breit meine Variablen wirklich sind.
Bei int/long/long kann Das je nach verwendetem µC variieren.

Wenn Du auf das delay() ganz verzichtest?
Ok, akut macht Dein Sketch dann eben die ganze Zeit Nichts - wie beim delay() auch - ABER in DEINER Schleife (loop) - bei delay eben in einer while-Schleife der delay()-Funktion (Zum Selber-Googeln yield() ).

Dein Delay-Konstrukt sieht ... äh ... 'interessant' aus - was willst Du damit bezwecken?
Schaue Dir Blink_without_delay in der IDE an und/oder die Nachtwächter-Erklärung hier im Forum.

Dann strickst Du Deine delay()-Warterei auf einzelne Schritte um und prüfst bei jedem (der tausenden) loop()-Durchläufe pro Sekunde, ob die Wartezeit bereits um ist, Du also den nächsten Schritt machen kannst.
Combie (Klick auf den Nachtwächter, dort ich Der nämlich verlinkt) hat auch Makros im Angebot, wo man sich eigene und von einander unabhängige Timer zusammen bauen kann.

MfG

Du benutzt t als zufällige Zeit - als INT deklariert.
Warum INT? Erwartest Du negative Wartezeiten?
Nein -> UNSIGNED (vorzeichenlos) hast Du direkt den doppelten Zahlenvorrat.
int 16bit, bei signed 15bit + Negativ-Bit, bei unsigned 16bit.
-32768...32767 zu 0...65535

Interessant, dass ich das übersehen konnte!
:o Ein Fall von Betriebsblindheit, vermute ich mal :o

Vermutlich weil ich mir angewöhnt habe, immer möglichst den gleichen Type zur Weiterverarbeitung zu nutzen, den mir die Funktionen liefern.

Dem Schema folgend:
Ja, da wäre sicherlich long, oder sofort unsigned long der richtige Type

Combie (Klick auf den Nachtwächter, dort ich Der nämlich verlinkt) hat auch Makros im Angebot, wo man sich eigene und von einander unabhängige Timer zusammen bauen kann.

Ja, die "niedrigen" Funktionen nutze ich kaum noch.
Mittlerweile haben die Taskmakros ein Update Richtung OOP erfahren.
Und auch switch/case sind jetzt in dem Zusammenhang möglich, da die "neuen" Makros auf dem heiß geliebten und zu allem bereiten goto basieren.

Hi

Oha - goto und noch kein blubbernder Teer?? :wink:
(da hat man sich gerade an Intervall heran getastet und schon wieder gibt's neues Zeug)

Ja stimmt, int macht keinen Sinn, das war wohl noch ein Überbleibsel von meinem Anfangscode, ist mir entgangen. Danke für den Hinweis!

Wenn Du auf das delay() ganz verzichtest?
Ok, akut macht Dein Sketch dann eben die ganze Zeit Nichts - wie beim delay() auch - ABER in DEINER Schleife (loop) - bei delay eben in einer while-Schleife der delay()-Funktion (Zum Selber-Googeln yield() ).

Ja, also theoretisch muss/ soll während der delay-Zeit erstmal nichts anderes ausgeführt werden (der Schalter soll auch währenddessen nicht reagieren) ich bin aber jetzt auch immer öfter auf den millis () Befehl gestoßen und werde versuchen das noch einmal zu überarbeiten. Die Blockade des Schalters kann ich ja dann trotzdem noch mit einbauen.
Und danke für die Nachtwärtererklärung!

Nachdem ich eine zeitliche Begrenzung für den ersten "Prototypen" meines Konstrukts habe, habe ich das Ganze erst einmal so programmiert, wie es für mich als Einsteiger verständlich ist, um das erste Konzept zu vermitteln.

Dein Delay-Konstrukt sieht ... äh ... 'interessant' aus - was willst Du damit bezwecken?

Meinst du für was ich diesen Code am Ende verwende oder "interessant" weil er umständlich geschrieben ist? ;D

Hi

Mouns:
...
Meinst du für was ich diesen Code am Ende verwende oder "interessant" weil er umständlich geschrieben ist? ;D

Beides :slight_smile:
Mir ist nicht klar, was Du Da bezweckst und ja, umständlich ist's auch.
Der Ersatz wird sich in millis() und dem Nachtwächter finden lassen.

MfG

postmaster-ino:
Hi

Oha - goto und noch kein blubbernder Teer?? :wink:
(da hat man sich gerade an Intervall heran getastet und schon wieder gibt's neues Zeug)

Teer schon...
Aber für die Federn reichts bisher nicht.
Vermutlich hat es noch kaum einer bemerkt.
Ist ja auch so gut versteckt, dass man die Nase schon recht tief reinstecken muss.

Hier ist die erste testbare Version zu finden.
Die Lib selber wird sich kaum noch ändern.
Aber noch ein paar Beispiele und eine Doku dazu kommen.

Das Prinzip an sich, hat sich ja mit den Taskmakros schon seit bald 3 Jahren bewährt.
(zumindest bei mir)

Tipp:
Schaue dir mal ein paar Flacherde Videos an, dann kommt dir das mit dem Goto gar nicht mehr so schlimm vor.

@combie: Bei Dir weiß ich, dass das goto in guten Händen ist.

Anfängern würde ich es trotzdem weiterhin ausreden, da es bei denen in 99,9% der Fälle nur schlechte Programmierung/Planung kaschieren soll.

Gruß Tommy