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.
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.
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);
}
}
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..
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
#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.
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.
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.
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
Oha - goto und noch kein blubbernder Teer??
(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.