für ein neues Projekt, Li-Ion Lade-, Entladestation mit 10 Steckplätzen,
suche ich nach einem geeigneten Temperatursensor.
Früher hat man es einfach mit einem NTC gemacht, doch da wird es doch sicherlich noch was "besseres" geben.
Ob Analog oder Digital soll mir erstmal egal sein.
Falls ich ein Kühlkörper für die 10x MOSFET nutzen sollte, dann wäre es schön, wenn man diesen da auch montieren könnte, sonst werde ich wohl nur die Umgebungsluft messen (bzw. zusätzlich).
Hab schon gesehen, dass es diese in verschiedenen Gehäusetypen gibt:
TO-92, TO-220, SOIC-8, DIP-8, SOT-23, ...usw.
Am besten wäre es wenn dieser recht linear arbeitet.
Die Auswahl ist echt erschlagend.
Bin für jeden Vorschlag dankbar, mit denen ihr evtl. bereits Erfahrung gesammelt habt.
Hab schon gesehen, dass es diese in verschiedenen Gehäusetypen gibt:
TO-92, TO-220, SOIC-8, DIP-8, SOT-23, ...usw.
Am besten wäre es wenn dieser recht linear arbeitet.
Die Auswahl ist echt erschlagend.
Sorry das versteh ich als Dummer mal wieder nicht. DU müsstest doch am besten wissen welche Bauform für DEIN PROJEKT am besten geeignet ist, DU musst ihn doch montieren.
Und DU müsstest doch am besten wissen welche Schnittstelle für dich am besten geeignet wäre. Hast du sowieso schon 1WIRE, I2C oder SPI im Einsatz? Kannst und willst du das Analog Gedöns für einen NTC machen?
Du musst doch sagen können was dein Controller kann und was praktisch ist, weil evt. sowieso schon benötigt.
Nicht mal einen Temperaturbereich gibst du an.
Wer für alles offen ist, und dem alles egal ist, der hat doch null Plan und noch gar nichts gemacht.
Sorry das versteh ich als Dummer mal wieder nicht. DU müsstest doch am
besten wissen welche Bauform für DEIN PROJEKT am besten geeignet ist, DU
musst ihn doch montieren.
Und DU müsstest doch am besten wissen welche Schnittstelle für dich am
besten geeignet wäre. Hast du sowieso schon 1WIRE, I2C oder SPI im
Einsatz? Kannst und willst du das Analog Gedöns für einen NTC machen?
Du musst doch sagen können was dein Controller kann und was praktisch
ist, weil evt. sowieso schon benötigt.
Nicht mal einen Temperaturbereich gibst du an.
Wer für alles offen ist, und dem alles egal ist, der hat doch null Plan
und noch gar nichts gemacht.
So ist das halt in der Planungsphase, da hat man halt noch nichts gemacht.
Deshalb sind die Schnittstellen noch alle frei.
Ich wollte hier Anregungen und Ideen sammeln, bevor ich mich für ein Konkreten Typ entscheide.
Das man bei einer allgemeinen Frage direkt auf Das technische Know-How schliessen muss, erschließt sich mir nicht. Aber sei es drum.
Falls jedem der 10 Steckplätze ein eigener Temperatursensor zugeordnet werden soll, könntest du die Sensoren z.B. nicht alle auf einen I2C-Bus legen, weil dir die Adressen ausgehen.
Falls du einen µC einsetzen willst, kann dir die Linearität eher egal sein. Wichtiger wären dann vielleicht die Toleranzen der Sensoren.
Früher hat man es einfach mit einem NTC gemacht, doch da wird es doch
sicherlich noch was "besseres" geben.
Ob Analog oder Digital soll mir erstmal egal sein.
Hängt halt von der Auswertung ab. Wenn man nur einen Lüfter ansteuern will, oder der uC einen Analogeingang hat, sind analoge Sensoren sicherlich passend. Irgendwie scheint es auch nicht um 1 GradC zu gehen. NTC sind nicht so gut darin, grosse Temperaturbereiche (-50-300) abzudecken, aber wenn man eigentlich nur an einer Temperatur interessiert ist (wann der Lüfter angehen soll, oder Fieberthermometer) völlig ok.
Es gibt auch noch Silizium PTC Sensoren wie KTY die linearer sind, auch ein paar GradC ungenau, und im Spannungsteiler ausgewertet werden können.
Platin Pt1000 oder Dioden (Vorwärtsspannung bei definiertem Strom -2mV/K) scheint für deinen Anwendungszweck nicht ideal.
Falls ich ein Kühlkörper für die 10x MOSFET nutzen sollte, dann wäre es
schön, wenn man diesen da auch montieren könnte
Kann man auch selber in so eine Öse stecken, ist nicht high tech.
sonst werde ich wohl
nur die Umgebungsluft messen (bzw. zusätzlich).
Hab schon gesehen, dass es diese in verschiedenen Gehäusetypen gibt:
TO-92, TO-220, SOIC-8, DIP-8, SOT-23, ...usw.
Am besten wäre es wenn dieser recht linear arbeitet.
Die Auswahl ist echt erschlagend.
Falls jedem der 10 Steckplätze ein eigener Temperatursensor zugeordnet
werden soll, könntest du die Sensoren z.B. nicht alle auf einen I2C-Bus
legen, weil dir die Adressen ausgehen.
Ne, ich denke mal je Kühlkörper (5 MOSFET) ein Sensor + ein dritter für die Umgebungsluft.
Muss nicht 100% genau sein, ich denke mal so 2-4% Genauigkeit.
Temperatur wird wohl so zwischen 20°C - 50°C liegen. Wobei ich die obere Temp. gar nicht so abschätzen kann.
Lüfter wollt ich dann mit PWM in abhängigkeit zur Temp. steuern.
Falls jedem der 10 Steckplätze ein eigener Temperatursensor zugeordnet
werden soll, könntest du die Sensoren z.B. nicht alle auf einen I2C-Bus
legen, weil dir die Adressen ausgehen.
So ist das halt in der Planungsphase, da hat man halt noch nichts
gemacht.
Deshalb sind die Schnittstellen noch alle frei.
D.h. du startest dein 10fach Ladegerät mit dem dir unbekanntesten und mithin unwichtigstem Bauteil? Es gibt noch kein Blockschaltbild, grobe Planung der Pinbelegungen, Busse?
Die 10 fach Spannung/Strom- Regelung und Messung, also das wirklich WICHTIGE und entscheidende bei diesem Projekt gibts auch noch nicht, geschweige denn die Steuerung über den Controller.
Aber nach einem Temp Sensor, da suchst du schon mal?
Steht der Controller wenigstens fest?
Macht keinen Sinn. Ich denke das wird so nichts. Deine Herangehensweise zeigt es bereits.
D.h. du startest dein 10fach Ladegerät mit dem dir unbekanntesten und
mithin unwichtigstem Bauteil? Es gibt noch kein Blockschaltbild, grobe
Planung der Pinbelegungen, Busse?
Die 10 fach Spannung/Strom- Regelung und Messung, also das wirklich
WICHTIGE und entscheidende bei diesem Projekt gibts auch noch nicht,
geschweige denn die Steuerung über den Controller.
Aber nach einem Temp Sensor, da suchst du schon mal?
Steht der Controller wenigstens fest?
Macht keinen Sinn. Ich denke das wird so nichts. Deine Herangehensweise
zeigt es bereits.
Eine 10 Fach Ladestation ist bereits in Betrieb, somit weiß ich genau was ich mache.
Diese soll halt besser werden.
Aber hat kein Wert auf deine Vermutungen einzugehen.
Eine 10 Fach Ladestation ist bereits in Betrieb, somit weiß ich genau
was ich mache.
Na wenn du das sagst wird es so sein. Es ist dann aber umso merkwürdiger dass noch kein Pin belegt ist und noch keine Schnittstellen eingeplant sind. Und auch keine präferiert wird. Man hat ja normalerweise Vorlieben. Wie gesagt, komplett offen für alles heißt meist nichts gutes.
Den verwendeten Controller rückst du auch nicht raus. Evt. engt der die Möglichkeiten auch ein.
Nächster Post dann: "Welcher Controller für 10 fach Ladegerät".
Diese soll halt besser werden.
Besser ist immer gut.
Aber hat kein Wert auf deine Vermutungen einzugehen.
Meistens liege ich mit meinen Vermutungen allerdings richtig. Auch wenn es manchen weh tut.
Ist mittlerweile tatsächlich zu einem Problem geworden. Wieso nimmt man sich die Zeit, so häufig und armselig Fremde im Internet zu beschimpfen und sich denen gegenüber zu profilieren?
Dann hast Du ja genug Eingangspins für den ADC.
Eine erweiterte Schaltung wie folgende, sollte passen: Beitrag "Temperatursensor KTY81 am ATmega328 (Arduino UNO), 1-6 Kanäle"
Im Grunde kannst Du jeden Sensor nehmen und die Stützpunkte der Kennlinie anpassen. Bevorzugen würde ich Typen mit Gewindestutzen zum Einschrauben in die Kühlkörper oder ein TO92 Gehäuse einkleben.
Was juckt den hier der µC, es geht um Temp.Sensor.
Weil nicht jeder Controller jede Schnittstelle gleich gut implementieren kann.
ich würde trotzdem schlicht zu I2C Sensoren raten. den LM75 oder der Nachfolger den auch Peda schon empfohlen hat,TMP1075, haben auch bei 6 Stück den wenigsten Verdrahtungsaufwand bei gleichzeitig trivialer Softwareansteuerung und eindeutige Adressierung.
Bei 1WIRE ist die Ansteuerung schwieriger wegen des Timings und die Adressierung immer so eine Sache für die man sich extra was ausdenken muss.
Ich habe sowas mit Gewindebolzen, aber leider keine Idee, woher die stammen. Eine Lüfterregelung habe ich mir erspart und nur zwei Schwellwerte ermittelt, Lüfter ein und wieder aus. Dazu einen dritten Wert für die Meldung Übertemperatur.
Aber ob NTC für 10 Meßstellen der richtige Ansatz ist?
ich würde trotzdem schlicht zu I2C Sensoren raten. den LM75
Zur Montage am Kühlkörper eine maximal unhandliche Bauform.
Bei 1WIRE ist die Ansteuerung schwieriger wegen des Timings und die
Adressierung immer so eine Sache
Das bekommen soagr "Arduinos" hin, kann also so schlimm nicht sein. Die DS18x20 kommen im TO-92, dafür müssten sich Montageklammern finden lassen oder man klebt sie ihn in ein Loch ein. Und es genügt ein Port für seine 10..12 Meßstellen.
Die DS18x20 gibt es als Chinaclone auch für kleines Geld im Edelstahlröhrchen vergossen. Entweder Loch in den KK bohren und einkleben, oder mit einer Schelle dranmontieren. Oder einen Aluklotz in der Art der Leistungswiderstände machen, wo der Sensor eingeklebt wird und der Klotz wird dann auf den KK montiert. Über Onewire kannst du über einen Controllerpin bis zu 64 Sensoren abfragen. Das sollte wohl reichen.
Das bekommen soagr "Arduinos" hin, kann also so schlimm nicht sein.
Das ist eine Fehleinschätzung. Nur weil es im Testprogramm mit einer fertigen Lib funktioniert. Die ganze 1WIRE Kommunikation muss in diesen libs atomar ablaufen, d.h. da gehts nichts parallel oder async. Ganz im Gegensatz zu I2C oder SPI übrigens. Weil es da fertige HW Peripherie in den Controllern gibt. 1WIRE ist aber 100% Software. Nicht optimal.
Dann lass die Ansteuerung selbst ok sein, aber wie adressierst du 6 Sensoren? Wie ordnest du die den jeweiligen Stellen zu? Jeder Baustein hat eine eindeutige ROM Adresse. Tippst du die manuell ab für jede Messstelle fest in den Code? Was passiert wenn du einen Sensor tauschen musst?
Bei I2C hast du schlicht eine feste Adresse pro "Slot". Auch im Tauschfall.
Nein, 1WIRE ist im Notfall ok, sonst unnötig umständlich.
Vielleicht könnte man sie auch einschrumpfen, Alu dehnt sich stärker als
Edelstahl.
Sehr wartungsfreundlich, wechsele den mal irgendwann.
Wenn es nur Q&D "irgendwie" halten soll, kann man den auch mit einem Kleber der eigenen Vorliebe irgendwie auf den KK pappen.
Ich habe noch kein Ladegerät gebaut, will mich daher auch nicht zu den internen Details äußern. Aber ein Frage hätte ich: Die Temperatur von WAS soll eigentlich gemessen werden? Das stand hie bisher nirgendwo.
Von der Ladeelektronik oder vom Akku?
Wenn Erstes - gibts keine "Ladecontroller", die sowas bereit intus haben?
Wenn Zweites - wie bringt man den Sensor zuverlässig in Kontakt mit dem Akku?
Wenn Erstes - gibts keine "Ladecontroller", die sowas bereit intus
haben?
Wenn Zweites - wie bringt man den Sensor zuverlässig in Kontakt mit dem
Akku?
Nein nicht von der Ladeelektronik.
Da kann ich den Akku direkt per I2C auslesen und nach seiner Temp. fragen.
Es geht hier um den Entladeteil.
Das Entladen wird per PWM, MOSFET, Lastwiderstand realisiert.
Ich bin mir jedoch noch nicht ganz sicher, wie warm das alles wirklich wird.
Die MOSFET sind an einem Kühlkörper fixiert, an dem dann auch der Sensor sitzt.
Grundsätzlich wird es eine Mischung aus diversen Temperaturen sein.
Die interene Akku Temp. die von den Kühlkörpern, die vom Netzteil.
Das ist eine Fehleinschätzung. Nur weil es im Testprogramm mit einer
fertigen Lib funktioniert. Die ganze 1WIRE Kommunikation muss in diesen
libs atomar ablaufen, d.h. da gehts nichts parallel oder async. Ganz im
Gegensatz zu I2C oder SPI übrigens. Weil es da fertige HW Peripherie in
den Controllern gibt. 1WIRE ist aber 100% Software. Nicht optimal.
Keiner verlangt, dass die Sensoren und die zugehörige Software optimal sind.
Für die Kontrolle bei einem einfachen Ladegerät reicht es, wenn alles zuverlässig funktioniert.
Die paar Byte von den Sensoren abzuholen, ist nun wirklich kein Hexenwerk, falls man seine Software halbwegs im Griff hat.
Je einfacher die Prozessorarchitektur, um so einfacher das saubere Timing der Software. Temperatur und Laden/Entladen eines Akkus sind so langsam, dass man alle Zeit der Welt für einen geordneten Ablauf hat.
Die paar Byte von den Sensoren abzuholen, ist nun wirklich kein
Hexenwerk
Hast du meine Ausführungen zur HW Peripherie nicht gelesen oder nicht verstanden?
Es ist immer besser diese zu nutzen als unnötigerweise etwas anderes in Software zu machen. Es gibt hier schlicht keinen Grund für 1Wire. Warum es dann nehmen?
Hast du meine Ausführungen zur Zuordnung nicht gelesen oder nicht verstanden?
Wenn man schon 6 Temp Sensoren verbaut hat, will man auch wissen welcher Sensor nun genau wo misst. Bitte erläutere deinen Ansatz wie man das bei 1Wire macht, der einfacher oder gleich einfach ist, wie bei I2C.
Wenn man schon 6 Temp Sensoren verbaut hat, will man auch wissen welcher
Sensor nun genau wo misst. Bitte erläutere deinen Ansatz wie man das bei
1Wire macht, der einfacher oder gleich einfach ist, wie bei I2C.
So wie ich es gelesen habe geht das beim DS18B20 über seine ID:
Each DS18B20 has a unique 64-bit serial code, which
allows multiple DS18B20s to function on the same 1-Wire
bus. Thus, it is simple to use one microprocessor to
control many DS18B20s distributed over a large area.
Match ROM & Skip ROM
Aber erstens passt mir das Gehäuse nicht und dann noch der Aufwand der Implementierung, neee Danke.
So wie ich es gelesen habe geht das beim DS18B20 über seine ID:
Ja die haben eine eindeutige ID. Jetzt kannst du alle Sensoren abfragen mit ihren jeweiligen IDs. Aber woher weißt du nun, welcher Sensor wo sitzt?
Jetzt kannst du die IDs (64 Bit) fest in den Code schreiben, mit Zuordnung (z.B. Sensorname).
Bei einem Sensortausch musst du nun aber den Code anpassen.
Natürlich gibt es alle möglichen Möglichkeiten. Die DS18X20 bieten einen EEPROM Bereich. Damit kannst du deine eigene Adressierung basteln. Damit kannst du auch dynamischen Sensortausch realisieren. Geht alles. Benötigt aber zusätzliche Implementierung und Hirnschmalz. Wohingegen du bei I2C oder SPI quasi gar nichts extra tun musst.
Es ist immer besser diese zu nutzen als unnötigerweise etwas anderes in
Software zu machen.
Unsinn - Millionen von 1wire-Sensoren laufen ohne Hardwareunterstützung. Und für einen Prozessorkern im Idle gibt es kein Geld zurück.
Wenn man Schwierigkeiten hat, seine Software so zu strukturieren, dass sie stabil läuft, ist es natürlich besser, auf weitgehend autarke HW Peripherie zu setzen.
Wenn man Schwierigkeiten hat, seine Software so zu strukturieren, dass
sie stabil läuft, ist es natürlich besser, auf weitgehend autarke HW
Peripherie zu setzen.
Du darfst 1Wire von Früh bis Spät einsetzen. ICH empfehle aber passende Dinge wenn jemand fragt.
Kommt dein Adressierungskonzept noch du Schwätzer?
Hab ich am Kühlkörper einer Eigenbau Fahrradlampe mit 60W, funktioniert bestens. Im Grunde interessiert doch nicht das letzte Grad, sondern eher die Grenzwerte. Auch in BEVs hat nicht jede Zelle einen Tempsensor.
Nimm einen guten externen ADC, eine brauchbare Referenzspannung, 0.1% Widerstände für den Spannungsteiler und dann sollte es auch gut sein. Passendes Layout und Befilterung vorausgesetzt.
Eben. Selbst wenn du die normalen LM75 nimmst, kannst du 8 Stück an einen I2C Bus hängen. Die gibts, wie gesagt, schon auf Platine mit Befestigungsloch. Aber selbst wenn man den SOIC auf ne Lochraster lötet ist das kein Problem.
Denn der Nachteil bei den fertigen Platinen: Auf jeder sind die I2C Pullups mit drauf. Will man bei mehreren Teilnehmern am Bus nicht. Aber die kann man auch runterlöten.
Allerdings muss man alle analogen Sensoren kalibrieren. Sonst ist es
wirklich nur ein sehr grobes Schätzeisen.
Der Hersteller liefert doch eine Tabelle, die in 1 °C Schritten ist.
Aber du baust den Analogteil um das Ding zu messen. Abgesehen von dynamischen Einflüssen wie Temperatur, hat der in jeden Fall einige konstante Fehler.
Meinst der interne ADC reicht nicht?
Der hat 10-bit.
Ja, ich kann nur den Kopf schütteln bei dem was hier empfohlen wird. Entweder alles Theoretiker die noch nie ein Gerät wirklich gebaut und programmiert haben, oder die haben das letzte mal 1915 was gebaut.
Meinst der interne ADC reicht nicht?
Der hat 10-bit.
Ja, ich kann nur den Kopf schütteln bei dem was hier empfohlen wird.
Sonst hab ich hier noch ADS1299 mit 24-bit rumliegen :-D
Ach quatsch.
Der NTC ist mit -55 bis +125 °C angegeben, das ist ein Range von 180 °C.
Im besten fall hätte man da bei 10-bit eine Auflösung von 0,175 °C.
Also ich bin auch mit +/- 1 °C zufrieden.
Das ist ein 10% NTC. Soweit unten muß man nicht mitspielen :-(
Der 10Bit ADC vom ATmega reicht völlig aus und Du mußt für Deine Anforderungen nichts abgleichen, wenn Du wie vorgeschlagen eine ratiometrische Messung machst.
Das ist ein 10% NTC. Soweit unten muß man nicht mitspielen :-(
Der hat 5% Toleranz!
Der 10Bit ADC vom ATmega reicht völlig aus und Du mußt für Deine
Anforderungen nichts abgleichen, wenn Du wie vorgeschlagen eine
ratiometrische Messung machst.
Sag ich ja, sehr grobes Schätzeisen. Wenn das reicht ok. Bei digitalen Sensoren bekomme ich halt 0,5-1 grad billigst und ohne jeglichen sonstigen Aufwand und mit weniger Bauteilen.
Auch, wenn hier die Wahl schon auf NTC gefallen ist, wollte ich noch anmerken zu den DS18_20.
Wenn man nur einen Sensor an den Bus hängt, dann kann man mit dem Befehl skipROM den Sensor auch ohne ID ansprechen. Bei 6 Sensoren und einem Mega256 wären die 6 IOs wohl gerade noch verkraftbar.
Ich mache es so, daß ich die ID vorher auslese und auf einem kleinen Aufkleber am Sensor befestige. Manche Hersteller liefern die Sensoren auch bereits mit einem solchen Aufkleber.
Übrigens benutze ich nur die niedrigsten 3 Bytes, weil das für 16 Mio. Kombinationen ausreicht. Mir sind noch keine Sensoren mit den gleichen Bytes untergekommen.
Wenn mehrere Sensoren an einem Bus hängen, könnte man z.B. beim Gerätestart die Sensor IDs abfragen und in einer Liste im RAM speichern. Dann kann man die Sensoren direkt ansprechen und "merkt" auch, wenn einer nicht mehr antwortet.
Bei den Original DS18B20 ist die absolute Genauigkeit +/- 0,5°C im Beriech von -10 bis 80°C -> das ist schon ganz ordentlich. (Allerdings für die Anwendung hier wäre vermutlich auch +/- 5°C ausreichend.)
Anstelle der NTC würde ich lieber PT1000 verwenden, wenn das Gerät sehr lange halten soll. Die NTCs entwickeln nach m.E. nach >10 Jahren doch eine merkliche Drift.
Wenn man für den Temp-Sensor extra einen Thread aufmacht, keine Angaben zu den geplanten Genauigkeitsanforderungen macht.... nein, dann würde ich sagen der reicht nicht ;).
Aber das kannst nur du allein definieren. So hab ich es gemacht, da ich noch paar ADS1115 rumliegen hatte und mehrere NTCs auswerten wollte. So lässt sich der Analogteil gut vom Digitalteil trennen. Ob man es braucht steht auf einem anderen Zettel, aber manchmal arten Hobby Projekte ja auch etwas aus ;). Dürfen sie ja auch.
Kommt dein Adressierungskonzept noch du Schwätzer?
Am einfachsten ist es, eine Messstellen-ID im Permanentspreicher des DS18B20 abzulegen und die beim Bus-Scan mit auszulesen. Dann kommt sich auch bei einem Sensorwechsel nichts in die Quere und die ID bleibt unabhängig von der ROM-ID.
Anstelle der NTC würde ich lieber PT1000 verwenden, wenn das Gerät sehr
lange halten soll. Die NTCs entwickeln nach m.E. nach >10 Jahren doch
eine merkliche Drift.
Also die 10 Jahre sollten kein Problem sein, dann tauscht man sie halt oder baut wieder was neues. Wer weiß ob es die Akkus in 10 Jahren überhaupt noch gibt.
Am einfachsten ist es, eine Messstellen-ID im Permanentspreicher des
DS18B20 abzulegen und die beim Bus-Scan mit auszulesen. Dann kommt sich
auch bei einem Sensorwechsel nichts in die Quere und die ID bleibt
unabhängig von der ROM-ID.
Und wie kommt die Messstellen-ID in den EEPROM des Sensors?
Nein, sagtest du nicht, und auch jetzt kommt nur Stuss von dir
sehr grobes Schätzeisen. Wenn das reicht ok. Bei digitalen
Sensoren bekomme ich halt 0,5-1 grad billigst und ohne jeglichen
sonstigen Aufwand und mit weniger Bauteilen.
ich würde trotzdem schlicht zu I2C Sensoren raten. den LM75
Zur Montage am Kühlkörper eine maximal unhandliche Bauform.
Kann man nicht so pauschal sagen. Man könnte ja einen beliebigen Temperatursensor in ein Metallgehäuse verpacken und mit Epox eingießen. Das Gehäuse mit einem Gewindebolzen ist auf einer Drehbank ja schnell hergestellt. Das schraubt man dan genau so ein wie Deine Beispiele (https://www.mikrocontroller.net/attachment/preview/663614.jpg). Eine passende Sechskantschraube mit einer Bohrung für den Fühler würde vermutlich den gleichen Zweck erfüllen.
Die Montage des Fühlers dürfte wohl das geringste Problem sein, es gibt da viele Möglichkeiten, man muß halt etwas kreativ sein.
Am einfachsten ist es, eine Messstellen-ID im Permanentspreicher des
DS18B20 abzulegen und die beim Bus-Scan mit auszulesen. Dann kommt sich
auch bei einem Sensorwechsel nichts in die Quere und die ID bleibt
unabhängig von der ROM-ID.
Das kann man machen, ich würde dort aber lieber Kalibrierdaten ablegen. Allerdings war es m.W. so, daß es bei einigen Nachbauten (aus CHN) Probleme mit dem EEPROM gab - nicht vorhanden bzw. nicht dauerhaft. Da muß man also aufpassen; mit den originalen DS sollte das aber kein Problem sein.
Zur Montage:
Man kann die Sensoren auch mit 2K-Epox-Wärmeleitkleber direkt auf dem Kühlkörper festkleben.
Wenn man schon 6 Temp Sensoren verbaut hat, will man auch wissen welcher
Sensor nun genau wo misst.
Ja und? Das ist kein Hexenwerk. Es kann ja wohl nicht so schwer sein sich die ID des Sensors zu notieren bevor man sie montiert.
Ich habe bei mir im Haus derzeit 16 Temperatursensoren DS18xx und diverse andere 1-Wire Bausteine verbaut, im Grundstück und Nebengebäude auch noch einmal die gleiche Anzahl, und ich kann genau sagen wo welcher Baustein ist und was er tut.
Ja man man muß schon etwas penibel sein und sich die ID's notieren und "die Datenbank" auch pflegen. Es überfordert aber einen auch nicht. Wenn wirklich mal ein Sensor verrecken sollte ( bei mir in 10 Jahren nur einmal vorgekommen, weil ich bei meinem Bodentemperatursensor mit 5 DS18xx die falsche Vergußmasse gewählt hatte und die Anschlüsse weggegammelt sind) ist die ID auch schnell geändert. Man kann ja die ganzen ID's in einer simplen Textdatei halten, die vom Programm eingelesen wird. Da man die Sensoren aber eher selten wechselt kann man es auch in den Code fest einkompilieren. Hierfür gibt es bei mir eine Headerdatei in der alle 1-Wire-ID's eingetragen sind und die ich in allen Projekten mit 1-Wire benutze. Und ja man muß das Programm neu kompilieren, wenn man einen Sensor ändert, aber da das nicht alle Tage der Fall ist kann ich gut damit leben. Viel häufiger als ein neuer Sensor sind neue Funktionen im Programm, weil man am Anfang was nicht bedacht hat, neu Ideen hat was man noch machen könnte etc. etc..
Ja und? Das ist kein Hexenwerk. Es kann ja wohl nicht so schwer sein
sich die ID des Sensors zu notieren bevor man sie montiert.
Notieren. Ok. Von wo? Die steht nicht drauf.
Und was bringt mir die ROM Adresse auf einem Zettel? Die SW im Gerät muss die ja wissen.
ist die ID auch schnell geändert. Man kann ja die
ganzen ID's in einer simplen Textdatei halten, die vom Programm
eingelesen wird.
Es geht um ein Ladegerät. Nicht um eine Datenbank in einem PC.
Da man die Sensoren aber eher selten wechselt kann man
es auch in den Code fest einkompilieren. Hierfür gibt es bei mir eine
Headerdatei in der alle 1-Wire-ID's eingetragen sind und die ich in
allen Projekten mit 1-Wire benutze. Und ja man muß das Programm neu
kompilieren, wenn man einen Sensor ändert
Unglaublich. Genau. Neu kompilieren wenn sich ein Sensor ändert.
Wenn mehrere Sensoren an einem Bus hängen, könnte man z.B. beim
Gerätestart die Sensor IDs abfragen und in einer Liste im RAM speichern.
Dann kann man die Sensoren direkt ansprechen und "merkt" auch, wenn
einer nicht mehr antwortet.
Ja und? Das ist kein Hexenwerk. Es kann ja wohl nicht so schwer sein
sich die ID des Sensors zu notieren bevor man sie montiert.
Notieren. Ok. Von wo? Die steht nicht drauf.
Du bist ja ein Schlauberger. Ja natürlich muß ich die irgenwie auslesen, z.B. mit einem RasPi dauert das keine 5 Minuten.
Ich habe meine 1-Wire Programme so geschrieben, das ich auch den Bus abscannen kann, damit ist es auch keine Hürde einen neuen Sensor am Bus festzustellen und die ID zu notieren.
Und was bringt mir die ROM Adresse auf einem Zettel? Die SW im Gerät
muss die ja wissen.
Ja wenn Du meinen Post bis zum Ende gelesen und nicht vorschnell in die Tasten gehauen hättest, dann müßtest Du diese Frage nicht stellen, denn ich hab's geschrieben wie man die ID in die SW bekommt - habe mich persönlich für die Variante mit dem fest einkompilieren entschieden. Das Warum habe ich hier auch ausreichend begründet.
ist die ID auch schnell geändert. Man kann ja die
ganzen ID's in einer simplen Textdatei halten, die vom Programm
eingelesen wird.
Es geht um ein Ladegerät. Nicht um eine Datenbank in einem PC.
Das ich die Datenbank in Anführungszeichengesetzt habe ist Dir schon aufgefallen? Bei dem Ladegerät wäre diese Datenbank für mich ein einfacher Aufkleber im Gerät, wo alles Nötige vermerkt. Man könnte so was natürlich auch in seinen Projektunterlagen vermerken.
Bei dem Ladegerät wird er die Temperaturfühler nicht jeden Tag wechseln nd vermutlich halten die solange das Ladegerät existiert, also muß man den "Aufwand" mit der ID nur einmal tätigen - wirklich schlimm.
Da man die Sensoren aber eher selten wechselt kann man
es auch in den Code fest einkompilieren. Hierfür gibt es bei mir eine
Headerdatei in der alle 1-Wire-ID's eingetragen sind und die ich in
allen Projekten mit 1-Wire benutze. Und ja man muß das Programm neu
kompilieren, wenn man einen Sensor ändert
Unglaublich. Genau. Neu kompilieren wenn sich ein Sensor ändert.
Völlig wirre und weltfremde Vorschläge.
Völlig daneben ist nur einer hier. Wenn sein Ladegerät fertig ist, wird er wohl nie wieder den Temperaturpart in der FW anfassen oder den Sensor ändern, die halten nämlich ausgesprochen lange - bei mir nun seit gut 10 Jahren.
Ist aber völlig wurscht, der TO hat sich eh schon gegen 1-W entschieden und das Dir dieses Konzept nicht behagt wissen jetzt auch alle.
Es gibt genug Anwender, die mit dem Ermitteln der ID und richtigen Zuordnung keine Probleme haben. Ganz offensichtlich sind die alle wirr im Kopf.
Es gibt genug Anwender, die mit dem Ermitteln der ID und richtigen
Zuordnung keine Probleme haben. Ganz offensichtlich sind die alle wirr
im Kopf.
Die meisten nutzen dann in ihrer Not einfach einen Sensor pro 1WIRE Pin, die Buseigenschaft ist damit zwar verloren aber man spart sich den Wahnsinn mit den Adressen.
Es gibt genug Anwender, die mit dem Ermitteln der ID und richtigen
Zuordnung keine Probleme haben. Ganz offensichtlich sind die alle wirr
im Kopf.
Die meisten nutzen dann in ihrer Not einfach einen Sensor pro 1WIRE Pin,
die Buseigenschaft ist damit zwar verloren aber man spart sich den
Wahnsinn mit den Adressen.
Ganz offensichtlich ist nur einer hier wirr im Kopf, oder sogar wahnsinnig.
Es gibt genug Anwender, die mit dem Ermitteln der ID und richtigen
Zuordnung keine Probleme haben. Ganz offensichtlich sind die alle wirr
im Kopf.
Die meisten nutzen dann in ihrer Not einfach einen Sensor pro 1WIRE Pin,
die Buseigenschaft ist damit zwar verloren aber man spart sich den
Wahnsinn mit den Adressen.
Das kann der Cyblord gern so machen. Die meisten werden es aus gutem Grund anders machen. Speziell die "Nichtskönner" die mit einem Pi anfangen machen das bestimmt so - oder doch nicht? Die werden wohl in der Lage sein sich solch eine ID zu notieren und diese dann auch in das Script, SW oder what ever zu übertragen. Da wird wohl keiner anfangen für jeden Sensor einen Pin zu definieren. Die nutzen lieber den Defaultpin und das zugehörige Kernelmodul oder OWFS - beides simpel zu handhaben, wenn man in der Lage ist mit den ID's umzugehen, was für die meisten wohl kein Problem darstellt - momentan gibt es nur einen der da Probleme hat.
Nun stell dich doch nicht blöder an, als du bist.
Beim Bus-Scan kann man sich die IDs automatisch ausgeben lassen und gut
is's.
Jaja ich habe alles dazu gesagt und auch genau dargelegt warum es in diesem Fall unnötig kompliziert ist und was die bessere Alternative ist. Und auch warum. Sachliche Einwände kamen bisher nicht und werden wohl auch nicht mehr kommen.
Macht ihr euren 1Wire Quatsch in eurem Altersstarrsinn.
Der TE ist zum Glück davon abgekommen.
Macht ihr euren 1Wire Quatsch in eurem Altersstarrsinn.
Der TE ist zum Glück davon abgekommen.
Glücklicherweise ist er auf deinen Digital-Humbug erst gar nicht reingefallen.
Er schraubt 10 MOSFETs auf 1 Kühlkörper braucht also nur 1 Temperatursensor um a) zu ermitteln wann der Lüfter helfen soll b) abzuschalten wenn zu heiss.
Selbst wenn er 10 Kühlkörper mit 10 Sensoren hätte, reicht es wenn er weiss ob EINER davon so warm wird dass der Lüfter laufen muss bzw. um abzuschalten weil zu heiss. Er muss gar nicht wissen welcher MOSFET das war. Insofern ist dein ganzes Geschwätz um die Sensorzuordnung völlig überflüssig, es reicht wenn man sie der Reihe nach auslesen kann.
Wer ein Ladegerät mit 10 Schächten baut, das offensichtlich auch noch eine Entladefunktion hat, der dürfte zumindest ein Text-LCD verbauen. Auf diesem könnte man die IDs beim Start anzeigen. Wenn dann noch eine Eingabetaste vorhanden ist, ggf. auch sortieren und ins EEPROM des Mega256 schreiben.
Wer ein Ladegerät mit 10 Schächten baut, das offensichtlich auch noch
eine Entladefunktion hat, der dürfte zumindest ein Text-LCD verbauen.
Auf diesem könnte man die IDs beim Start anzeigen. Wenn dann noch eine
Eingabetaste vorhanden ist, ggf. auch sortieren und ins EEPROM des
Mega256 schreiben.
Ja Du könntest das, die meisten alten Hasen hier im Forum könnten das und ich vermutlich auch, allerdings würde ich das bei diesem Projekt schon für etwas oversized halten - ich meine das mit den ID's. Das brauche ich genau einmal beim Zusammenbau des Ganzen und da ermittle ich die ID vorab mit einem Pi oder einem µC meiner Wahl und kompiliere sie danach fest ein. Wenn wirklich mal so ein Sensor den Weg alles irdischen gehen sollte, dann ist es doch eine Kleinigkeit, beim Wechseln von selbigen die FW neu zu kompilieren und zu flashen.
Andererseits wird der TO vorgesehene ATmega2560 genug Potenzial haben, um Deinen Vorschlag zu implementieren. Am Ende ist es wohl Ansichtskarte wie man es umsetzt. Für ein projekt wo man über kurz oder lang mit Änderungen/Anpassungen rechnen muß, dürfte Dein Vorschlag schon eine Überlegung wert sein.
Ja und? Das ist kein Hexenwerk. Es kann ja wohl nicht so schwer sein
sich die ID des Sensors zu notieren bevor man sie montiert.
Ich habe bei mir im Haus derzeit 16 Temperatursensoren DS18xx und
diverse andere 1-Wire Bausteine verbaut,
Mein Senf dazu:
Ich habe auf der Stirnseite des TO-92 Gehäuse eines DS18B20 mittels einer Reißnadel fortlaufend eine Zahl eingeritzt, sodass ich jeden Sensor einer Messstelle zuordnen kann.
Eine Messanordnung z.B. mit 8St. DS18B20 läuft nun schon seit 2015 störungsfrei in unserer Heizstation. Die Messwerte werden alle
8 Sekunden ausgelesen und auf einer SD-Karte abgespeichert.
Die meisten scheinen ganz offensichtlich in der Lage zu sein das mit ID's in irgend einer Form zu lösen. Viele Wege führen nach Rom, wenn man nur will - Manche wollen halt nicht.
