Lüftersteuerung, Open Source Projekt

Interessant -> Abo

Baue ich mir dann vielleicht mal nach, wenn ihr alles in den Griff bekommen habt.
Wünsche viel Erfolg! ;)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ist ja ganz schön ruhig geowrden um das Projekt.
Gibt es vielleicht irgendwelche Neuigkeiten?
 
Da alle beteiligten das ganze nebenbei machen, halte ich es für normal das mal etwas zeit ohne fortschritt vergeht.
Glaube nicht das soviel gute Arbeit einfach versandet...

Da hilft nur abwarten und auf Updates freuen oder mithelfen wo es eben geht :)
 
Sorry das ich mich zwischendurch nicht gemeldet habe.

Hier geht's noch weiter Layout 2 ist fertig und wird denke ich in der nächsten Woche geätzt und umgesetzt.

Layout2.png


Wie man im Vergleich zum 1. Layout sieht wurde die Verteilung komplett verändert. Der ganze PWM-Leistungsteil sitzt jetzt auf der oberen Platine und der Analogteil hat jetzt ein eigenes Masse Polygon, welches nicht mehr in Berührung mit den PWM-Störungen kommen sollte. Auch wurden die Enstörmaßnahmen deutlich erhöht, was zwar ein paar mehr SMD-Kondensatoren mit sich bringt, aber das sollte kein Problem sein.


Wenns fertig ist wird die Hardware noch einmal ausgiebig getestet und wenn das klappt gibt es nicht mehr viele Hürden zu überwinden.


Mfg Bimbo385
 
Zuletzt bearbeitet:
Hallo,

mal einige Fragen, wieso so viele bedrahteten Bauteile obwohl schon einiges an SMD vorhanden ist, SMD hat einige EMV technische Vorteile.

Dann ist die Masseführung nicht sinnvoll, Trennung AGND und DGND ist soweit erstmal richtig, die DGND sollte man an punktuell zusammenführen und nicht flächig, das gibt Störungen.
Die VDC ist nicht kompensiert, das könnte massive Rückwirkung auf Spannung geben (Rauschen, Oberwellen) welche durch den 3,3V Stabi nicht vermindert werden, im Gegenteil.

Aber der Anfang sieht schonmal ganz nett aus.
 
Du scheinst dich ja auszukennen, Die Bedrahteten Bauteile kommen daher, dass geplant ist Platinen herauszugeben die SMD-Seitig bestückt sind und quasi als Bausatz fertig zu bauen sind (dann ohne SMD Lötungen).

VDC kompensieren meinst du ein LC-Filter in der 5V Zuleitung zum 3,3V Stabi?

Zum Thema punktuelle Masseführung, möchtest du da selber mal Hand dran anlegen. Sind EAGLE 5 Dateien, schick dir die gerne per Mail.

Mfg Bimbo385
 
@Bimbo: (ich muss leider zugeben nicht den ganzen Thread gelesen zu haben):

Kann man Brushless-Lüfter mit 3-Pin-Anschluss nun doch PWM-stellen? Ich habe immer gelesen dass das nicht geht weil die eigene ElKos eingebaut haben und dann einfach in der On-Time mehr Strom ziehen...

Und zum Thema Platinen: Meiner Erfahrung nach sind SMD1206-Teile besser als alle bedrahteten weil sich diese Größe noch problemlos von Hand löten lässt, aber keine Löcher benötigt.
Man kann sie sogar "stapeln" um sie parallel zu schalten.
 
Also einzelne Lüfter machen da keine Probleme und PC Lüfter sind doch schon seit langem Brushless und kommerzielle Steuerung arbeiten größten Teils auch mit PWM.

Nur wenn man viele Lüfter parallel betriebt beeinflussen die sich evtl. gegenseitig.

Mfg Bimbo385
 
bimbo385 schrieb:
Also einzelne Lüfter machen da keine Probleme und PC Lüfter sind doch schon seit langem Brushless und kommerzielle Steuerung arbeiten größten Teils auch mit PWM.

Nur wenn man viele Lüfter parallel betriebt beeinflussen die sich evtl. gegenseitig.

Mfg Bimbo385
Zum Vergrößern anklicken....

Ich habe eben immer gelesen dass die Brushless-Lüfter dann die Energie für eine Periode vollgas in der Ontime ziehen und das so lange bis das nicht mehr geht, dann bleiben sie stehen.

Oder hängst du einen Tiefpass zwischen PWM und Lüfter?
Dann wäre es ja eine normale Spannungsstellung
 
Nein mach ich nicht, da aber die Frequenz dieser PWM bei ca. 32kHz liegt scheint es da keine Probleme zu geben.

Ich hab ja Lüfter mit der Endstufe schon am Laufen und die lassen sich wunderbar regeln.

Mfg Bimbo385
 
OK, ich finde PWM-Lüfter am angenehmsten weil die kaum mehr kosten und man die direkt mit nem PWM-Pin vom µC aus steuern kann.
Aber gut zu wissen dass es mit HF-PWM auch so schön läuft.
 
So nachdem der Postbote es geschafft hat mir heute schon neue doppelseitige Platinen zu bringen ist das neue Layout geätzt. Ist auch ganz gut geworden.

Mal schauen wann ich zum Bohren und bestücken komme, Wochenende ist ziemlich ausgebucht.

Mfg Bimbo385
 
Bimbo358, besorg dir mal ein Flattr Konto und einen Blog wo Du dein Zeug promotest.
Solltest doch einiges was bekommen aus der Geek Ecke.
 
Auf meiner Website gibts jetzt einen Artikel zur Lüftersteuerung, mit Flattr-Button.

Wenn hier jemand den ausprobiert, könnte er sich mal melden ob der funktioniert. Hab ihn erst eingebaut.

Hab die Bauteile von der alten Platine zerstörungsfrei runter bekommen. Nur hab ich bei dem Wetter irgendwie keine lust im Keller vorm Lötkolben zu sitzen ;-)

Da sitzt ich lieber auf der Terasse vorm Notebook und mach ein bisschen Doku.

Mfg Bimbo385


Edit:

So heute Prototyp Rev. 2 zusammengebaut und Hardware tut. Auch die Temperatursensoren zeigen jetzt stabile (und realistische) Werte. In meinem Keller sind 21,5-22°C. Glaub ich ihm mal ;-)

Jetzt wird weiter an der Software gefeilt. DMA für die Kommunikation mit dem PC währ toll. Mal schauen ob ich das hin bekomme.
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
 
Zuletzt bearbeitet:
Genau das gleiche Problem hatte ich auch!

Das Signal auf meinem Oszi war genau das gleiche wie bei euch. Also mit dieser "runden" Störung.

Ich hab mit dem RC-Filter auch etwas rumprobieren müssen. Ich hab jetzt 22 kOhm und 100nF. Ich mach auf meiner Website nachher mal ein Update der Quelldateien. Da ist dann auch die Excel Datei dabei, da sieht man schön den Frequenzverlauf.

Und wenn man zu viel mit einem RC-Glied rausfiltert kommt bei hohen Frequenzen nix mehr an was man auswerten kann.
Zum Vergrößern anklicken....

Das klappt gerade noch so,auch wenn ich bei den 7000 RPM von dem kleinen Lüftern ein Sägezahn habe und kein Rechteck mehr. Aber da ich die Flankenerkennung des Xmegas (im Zusammenspiel mit dem Event-System und einem Timer) verwende klappt es trotzdem super. Dem Xmega ist völlig egal wie das Signal aussieht, solange er die Flanke vom definierten High- in den Lowbereich bekommt.

Höhere Drehzahlen halte ich jetzt mal für Quatsch. Die meisten Nutzer kommen eh nicht über 2000 RPM hinaus.

Da du schon mal hier vorbeischaust hätte ich noch 2 kleine Fragen:

Wie viele Impulse pro Umdrehung nehmt ihr denn an, oder kann man das beim AE einstellen (hab keins)? Für die Phobya Nano-G 12 hab ich jetzt 2 Impulse pro Umdrehung. Vielleicht sind es für den kleinen auch 4, dann macht er keine 7000 RPM (was ich auch nicht für realistisch halte) sondern 3500 RPM.

Kannst du mir evtl. einen Wink zu den Kennlinien der "Standard 10K NTC Sensoren" geben, die es ja z.B. bei AT gibt? Ich hab jetzt eine aus eurem Inline Sensor rekonstruiert. Aber irgendwo muss es die doch mal richtig geben, mit google hab ich nichts gefunden.

Danke!
Bimbo385
 
Ein Lüfter hat immer 2 Imp/Umdrehung.
Die Messung am AE5 wird dynamisch mit der Drehzahl angepasst, je höher die RPM, desto mehr flanken werden gemessen. Anschließend wird das noch mal gefiltert um unsinnige werte loszuwerden. Dann hat man auch keine Probleme mit dem Jitter.
Mit dem ae5 gehts es recht gut von 250 rpm .. 10K.
Die Sensoren kannst du einfach mit der NTC Formel berechnen: Heißleiter das passt recht gut.
 
Immer 2 Imp/Umd. das ist gut zu wissen. Dann überlege ich mir noch mal ob ich das einstellbar lasse oder einfach auf 2 festlege. Danke!

Da haben wir wohl zwei völlig verschiedene Konzepte um die Drehzahl zu messen :-)

Bei mir funktioniert das prinzipiell wie folgt:

Ich lasse einen 16-Bit Counter im Hintergrund ununterbrochen zählen (immer von 0 - 65535) und überlaufen. Der zählt mit 125 kHz, das heißt er braucht ca. 524 ms, bis er einmal rum ist.
Jetzt hab ich ich jedes Tachosignal auf einen Capture Kanal geschaltet. Bei jeder fallenden Flanke des Tachosignals wird jetzt der Aktuelle Zählstand des Timers zwischengespeichert und ein Interrupt ausgeführt.
In diesem Interrupt bilde ich jetzt die Differenz zwischen dem aktuellem Zählstand und dem bei der letzten fallenden Flanke. Diese Differenz ist proportional zur Periodendauer und somit kann ich aus der einfach die Frequenz und die Geschwindigkeit berechnen.

Wenn der Timer in der Zwischenzeit übergelaufen sein sollte (merke ich ja wenn meine Differenz negativ wird), schmeiße ich einfach die Differenz weg und speicher nur den aktuellen Wert für die nächste Differenz. Da eh sehr viel öfter gemessen, als die Anzeige aktualisiert wird, merkt man das nicht.

Das funktioniert theoretisch so lange das Tachosignal schneller als 2 Hz ist (was nebenbei bemerkt 60 RPM entsprechen würde). Umso schneller mein Lüfter ist, desto ungenauer wird meine Messung, da ja weniger Zählschritte pro Periode gezählt werden. Bei 2000 RPM sind es noch 1875 Zählschritte also noch völlig ausreichend. Bei 10000 RPM währen es nur noch 6 Zählschritte, also ziemlich grob. Aber wer braucht schon so eine Turbine...


Die allg. Formel für nen Heißleiter kenn ich schon ;-)

Nur nützt mir das nichts, wenn ich den B-Wert der Sensoren nicht kenne...


Mfg Bimbo385

PS: Aktuelle Quelldateien sind online:
http://www.open-electronics.de/Quelldateien.htm
 
Umso schneller mein Lüfter ist, desto ungenauer wird meine Messung
Zum Vergrößern anklicken....
Dann definiere einfach eine minimale messzeit, und schon kannst du sagen du misst mindestends 100ms, wenn du nun in der zeit 100 flanken + zeit x hast, sollte das als basis genau genug sein.
Je nach drehzahlbereich muss man die verschiedenen messprinzipien miteinander kombinieren.
 
Man verwirft keine Messung. Wenn der A-Wert kleiner als der B-Wert ist, addiert man auf den A-Wert die Timebase und subtrahiert erst dann den B-Wert.

ich programmiere auf der Arbeit zur Zeit auch ein Messgeraet und muss auf eine PWM dynamisch reagieren; also auch mit dynamischer Periodenkalibrierung, da es sonst einfach ungenau wird.
 
Das die Steuerung die Anforderungen an ein Frequenz Messgerät nicht erfüllen kann ist klar denke ich. Dafür ist der Takt des Timers auch nicht genau genug.

Mir ist schon klar, dass man auch den Messwert mit dem Überlauf auswerten kann. Aber man beachte, dass das alles Rechenzeit kostet. Und da ja 4 Tachosignale die Interrupts auslösen können und der Kontroller auch noch was Anderes zu tun hat, hab ich darauf verzichtet.

MfG Bimbo385
 
Zuletzt bearbeitet:
Der Beitrag vorhin sollte jetzt nicht als tätlicher Angriff, sondern als sachdienlicher Hinweis gegolten haben.

Mein "Frequenzmessgerät" ist auch nichts anderes als eine Mikrocontrollerschaltung; eine etwas schnellere MCU, aber sonst vom Prinzip das Selbe.

Ich messe übrigens zyklisch, für diese Firmware, ohne Interrupts vier (zeitversetzte) Signale (f=1..2kHz) asynchron gleichzeitig je Signal drei Flanken. Man braucht für so etwas nämlich nicht zwingend Interrupts zu nutzen, da eine Messkette ohne Messwerte sowieso nicht anfangen kann. Außerdem spare ich mir dadurch den Jitter für den ISR-Jump (Register push/pop etc). Nach tmax=2ms (worst case Zeitversatz) sind alle vier Signale eingelesen und entsprechend, für die folgenden Rechnungen, vorkalibriert.

Na gut, trotzdem noch viel Erfolg :) .
 
Ich weis ja nicht wie genau deine Messignale sind, aber die Lüfterelektronik hat schon schon ca. 5% schwankung in der erzeugung des Drehzahlsignals. Das äussert sich in einer minimal springenden Drehzahl. Und das Signal wird qualitativ schlechter wenn man unter 5V kommt, da gibt es dann auch Impulse die nicht zum Messignal gehören. All das muss man kompensieren/filtern um eine stabile messung zu bekommen. Der Jitter kommt nicht aus dem ISR, der ist im Messignal der Lüfter.
Man könnte die Drehzahl der Lüfter auch auf 2 stellen nach dem komma messen, aber das Drehzahlsignal an sich ist einfach zu schlecht.
 
Danke!

Meine Meinung. Die Steuerung spuckt ein Realistischen Drehzahlwert aus, der Stabil ist und hinreichend genau. Das mit möglichst wenig Hardware- und Softwareaufwand.

Habt ihr irgendwelche Vorstellungen oder Ideen zum automatischen Farbenwechsel der RGB LED Ausgänge?

Mfg Bimbo385
 
@ AquaSebastian
Genau sind meine Signale auch nicht... je zwei Signale sind komplementär zueinander z.B. sollte ein Paar f=1 kHz haben, das eine Signal rennt aber mit 998µs das andere mit 968µs... und mit Temperatur wird's noch ärger, da geht's z.B. auf 980µs zu 1020µs. Effektiv wird mein Signal qualitativ mit Temperatur schlechter, was ich mit der dyn. Anpassung kompensiere; um die restliche Filterung auf HW-Ebene hat sich mein Kollege ausreichend gekümmert. Und mit Fließkomma rechnet man nicht, wenn man keine HW-FPU hat. Das ist doch viel zu langsam...

Aber egal, ich führ's nicht weiter aus und sag auch nichts mehr dazu; schon bedauerlich zu sehen wie angegriffen sich manche fühlen, wenn man (fachlich) etwas anmerkt, anstatt nur "oh wie cool" (o.ä.) schreibt...
 
Und mit Fließkomma rechnet man nicht, wenn man keine HW-FPU hat. Das ist doch viel zu langsam...
Zum Vergrößern anklicken....
ich habe damit nicht viel zu tun, .. im ae5 läuft das ganze sehr ressourcenschonend. Und für berechnungen wo man n-stellen hinter dem komma benötigt gibt es fixed point operationen wo ich mit int rechen kann.
das eine Signal rennt aber mit 998µs das andere mit 968µs
Zum Vergrößern anklicken....
das ist doch recht konstant, aber das lüftersignal ändert sich mit jeder periode um +/-5%.

Den idealen Weg muss jeder selbst finden. Hier gehts ja nur um ein Bastelprojekt, da verlangt niemand ernsthaft das es auch mit den Lüftern aus der letzten ecke chinas läuft.
 
Schön das wir das Ganze jetzt erschöpfend diskutiert haben ;-)

Die Auswertung des Tachosignals funktioniert bei den zur Verfügung stehenden Lüftern auf jeden Fall problemlos und mit der für eine Lüftersteuerung zu erwartenden Genauigkeit.


Jetzt hätte ich gerne Vorschläge zur RGB LED Farbwechslung. Und zum Inhalt des Displays.


Danke, Bimbo385
 
kurzes Update:

Ich hab mir jetzt mein ganzes WE mit der Steuerung um die Ohren geschlagen.

Die digitalen Temperatursensoren sind implementiert und das GUI ist ziemlich fertig.

Nur noch ein paar einzelne Sachen und der Optionsreiter fehlen noch.

Aller drei Lüfterkanäle lassen sich einstellen und funktionieren auch problemlos. Hauptsache funktioniert :coffee:

Die LED Ansteuerung ist auch komplett. 3 Farbwechselmodi gibt es zum Anfang und fest einstellen geht sowieso.

Heute hab ich mich an der Programmierung für das Display zu schaffen gemacht. Es war wirklich nicht einfach, aber jetzt hab ich folgende Screens:

1x Alle drei Lüfterkanäle (jeweils RPM und % pro Zeile),
Dann Pumpe und DFM (also Spannung und Durchfluss),
Dann einmal was AIDA ausspukt (CPU, GPU und RAM Auslastung sowie CPU Takt). Das zeigt noch nichts an, weil AIDA noch nicht im GUI implementiert ist.
Das war einfach und jetzt kommen alle Temperaturen...

und zwar kann man für jede einzeln im GUI auswählen, ob man sie auf dem Display haben will oder nicht. Die Steuerung stellt dann je nach dem wie viele Temperaturen man ausgewählt hat, entsprechend viele Screens a 3 Temperaturen zusammen. Jeweils mit frei wählbaren Namen (4 ASCII Zeichen) und der aktuellen Temperatur versteht sich.

Alarme sind auch schon in der FW. Der Peeper geht bei Übertemperatur los und wenn ein Lüfter sich nicht dreht, obwohl er es sollte (ausgeschaltete Lüfter werden selbstverständlich vom Alarm ignoriert).

Im Großem und ganzen bin ich am überlegen, ob ich die steuerung nicht schon in meinen großen PC einbaue. Sie funktioniert schon so schön :coolblue:

Da ich nächste Woche Projektwoche habe (aber kein Projekt), denke ich mal dass ich bis zum WE die Steuerung soweit habe, dass man über eine Verbreitung nachdenken kann!

Mfg Bimbo385
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh