Hallo, ich beziehe mich auf diesen Artikel - https://www.heise.de/newsticker/meldung/Fahnder-beschlagnahmen-ueber-eine-Million-gefaelschte-Elektro-Teile-3761227.html?wt_mc=nl.ho.2017-07-04 ... und Beobachtungen mit LM92 ICs aus China, die ich zur Temp-Messung via I2C Bus einsetze. Laut Datenblatt sollen diese ja digital hochgenau sein. Ich habe mehre 10 Stück aus China bezogen, die 4 ersten am I2C Bus verbaut. Die ICs arbeiten IT-technisch gesehen genau wie im Datenblatt angegeben, lassen sich also ohne Schwierigkeiten adressieren, auslesen etc. - alles wie angegeben - direkt im ersten Versuchsaufbau. Klasse Teile! Einziges Manko, der digital übermittelte und daraus laut Bit-Formel im Datenblatt errechnete Temp-Wert liegt um ca. 3 Grad zu hoch!!! Mit Sicherheit kein Rechenfehler - wie sollten sich durch BitShifting ziemlich genau 3° (bei allen 4 ICs) kompensieren lassen? Ist kein fundamentales Problem für mich - ich kalibriere jedes IC mit einem hochgenauen Tempfühler und lese in 0,1° Schritten Korrekturwerte ein. Die Abweichung bleibt nämlich absolut gesehen immer gleich (~+3° zuviel) - egal bei welcher Temperatur - der Aufwand der Kalibrierung ist also minimal. Kalibrierung ist aber laut Datenblatt nicht vorgesehen. Nun frage ich mich, hat jemand ähnliche Erfahrungen mit LM92 aus China gemacht - fehlt vielleicht die IC-interne Kalibrierung (bei einem geclonten Billig-Teil)? Wie sind Eure Erfahrungen / Meinungen? Noch ein kleiner Zusatz - beziehe (fast) alle Technikteile (meist Elektronik) aus China - pro Woche mindestens 1 Päckchen, kann aber schon 'mal ein Päckchen pro Tag sein ....! In den letzten 5 Jahren hat die Qualität immer gestimmt. Sehe bei diesen Erfahrungen nicht ein, warum ich Zwischenhändlern x100% Marge spendieren soll, wenn sie selbst auch in China beziehen. Werde also auch weiter in China beziehen - selbst wenn diese LM92 eine Fälschung sein sollten - das Problem ist ja praktikabel mit wenig Aufwand korrigierbar. Bin kein Wiederverkäufer- bin lediglich Hobbyist - alles private Verwendungen - also ein Mini-Problem. Gruesse
Hier nur einige kurze Anregungen: - EMI - LSB/MSB Handling korrekt? - I2C Pull-Ups vorhanden? - "Original" LM92 funtkioniert?
Mick schrieb: Hallo Mick, Danke für Deine qualifizierte Antwort! > Hier nur einige kurze Anregungen: > - EMI > - LSB/MSB Handling korrekt? Ich denke, ja: 1. - Habe die Formel gewissenhaft umgesetzt! 2. - 3° - wie soll ein socher Fehler bei Bit Shifting passieren? > - I2C Pull-Ups vorhanden? Ja - - auch schon varieiert zwischen 500 Ohm und 5 kOhm - alles gar kein Problem - es hängen insgesamt 10 Slaves am Bus - ich bin sehr I2C erfahren- arbeite mit Level Shifting, Bus Expandern (Taktung auf 20kHz) und und - alles klappt. Problem bleibt auch bei nur einem LM92 am Bus exakt gleich. Es gibt keine anderen Probleme am Bus - es ist definitiv ein Kalibrierproblem. > - "Original" LM92 funtkioniert? Sehr gute Frage - lange her, aber ich meine, die ersten LM92 waren von Farnell (oder einem ähnlichen Disti - weiß nicht mehr genau). Ich meine mich erinnern zu können, diese hatten exakt weniger als 0,3 ° Abweichung bei der Kalibrierung. Habe jetzt leider nur noch chinesische Teile im Vorrat ....! :-( Gruesse
Mampf unterwegs schrieb: > Wie oft liest du die aus, bzw mit welcher Frequenz? ich habe den Bus auf 20kHz runtergetaktet. Alle 500 mS lese ich 4 LM92 nacheinander aus. Also ich habe nach 500 mS 4 neue Temp-Werte ...! Gruesse
:
Bearbeitet durch User
Das Problem hatte ich auch schon. Erhöhe die Ausleserate mal auf 5 Sekunden.
Ich auch. Ob es der LM92 war weiss ich nicht mehr. Aber das häufige kommunizieren führte zur Eigenerwärmung.
Bei den DS18B20 und DHT22 aus meinem Shop ist das selbige zu beobachten. Zuviele Abfragen führen zur Eigenerwärmung. Trump würde sagen, das stimmt nicht, das sind Fake-News ;-) Frag mal nur alle 5 Sekunden ab. dann kannst du die Eigenerwärmung ausschliessen.
Hendrik L. schrieb: > Temp-Wert liegt um ca. 3 Grad zu hoch!!! Das ist laut Datenblatt selbst bei Dauermessung zu viel: die Stromaufnahme von 0,6mA zusammen mit der Versorgung 5V und einem Rth von 200K/W ergibt bei Dauermessung eine Temperaturabweichung von max +0,6K. Miss doch mal die Stromaufnahme deiner Bauteile...
Da ist auch noch bisschen was... Aber 3° kommen trotzdem nicht zusammen.
> 2. - 3° - wie soll ein socher Fehler bei Bit Shifting passieren?
um 5 Bit falsch geschoben und damit 32x 0,1° Versatz?
Hendrik L. schrieb: > Mit Sicherheit kein Rechenfehler - wie sollten sich durch BitShifting > ziemlich genau 3° (bei allen 4 ICs) kompensieren lassen? Quantelung 0,0625° 3°/0,0625°=48=0b110000 Hm - sieht schon ein bisschen verdächtig aus.
H.Joachim S. schrieb: > Hendrik L. schrieb: >> Mit Sicherheit kein Rechenfehler - wie sollten sich durch BitShifting >> ziemlich genau 3° (bei allen 4 ICs) kompensieren lassen? > > Quantelung 0,0625° > 3°/0,0625°=48=0b110000 > > Hm - sieht schon ein bisschen verdächtig aus. Ja - guter Tip! Werde ich noch einmal checken! Aber - wenn meine Erinnerung richtig ist, dass mit Nicht China LM92 die Genauigkeit hinreichend war - den Code "Bitshifting" habe ich seitdem definitiv nicht geändert. Frage bleibt also, ob ich sicher bin, dass mit "Nicht-China Bauteilen" schon einmal die Genauigkeit hinreichend war! Ich werde auf jeden Fall auch den Tip umsetzten, die Abfragefrequenz auf 5 Sekunden zu setzen - das geht am leichtesten. Werde asap berichten! Evtl. bestelle ich mir auch noch einmal LM92 aus Nicht China Quellen. Danke bisher für die guten Tips! Gruesse
Aber erstmal alles auf die bösen Chinesen schieben, :) Bin gespannt, was nun rauskommt... StromTuner
Fred R. schrieb: > Bei den DS18B20 und DHT22 aus meinem Shop ist das selbige zu beobachten. > Zuviele Abfragen führen zur Eigenerwärmung. > > Trump würde sagen, das stimmt nicht, das sind Fake-News ;-) > > Frag mal nur alle 5 Sekunden ab. > dann kannst du die Eigenerwärmung ausschliessen. So, mal eben geändert und gemessen. Mit viel Einbildung liegt die durch Eigenwärme beeinflusste Temperatur um 0,1° niedriger, wenn ich mit 5000mS Zyklen messe. Aberrrr ... ich messe Pooltemperaturen, da gibt es Temp-Schichtungen im Pool, kommt darauf an, welche Temp-Schicht nach Verwirbelungen gerade geskimmt worden ist ... die Aussage ist mit großer Vorsicht getätigt. In erster Näherung würde ich sagen - keine Veränderung durch den Übergang von 500 mS auf 5000 mS. Definitiv liegen die Sensoren im direkt Kontakt zu den Leitungsrohren - ein guter Wärmeabfluss durch die masssive Hydraulikführung (massgeblich also Wämeleitung, keine Konvektion und keine nennenswerte Strahlungswärme) sind gegeben. 0,1° ist bei meinen Messungen schon blanker Unsinn ...! Poolwasser schwankt wegen Strömungsdynamik schnell um 0,5° - ist ganz normal ...! Da gilt: Wer misst, misst häufig Mist! Aber 3° ist natürlich schon eine Hausnummer ...! Gruesse
Hmmm... wenn der Messfehler plötzlich 3° statt 0,3° bei selber Hard und Software ist, muss man annehmen, dass der LM92 nicht richtig kalibriert ist. Glaube nicht, dass irgendwer das Teil fälscht,das wäre zu aufwendig, eher dass ein Mitarbeiter einer Produktionsstätte die Ausschussteile "mitnimmt" und dann wird in einer Hinterhofklitsche irgendwas draufgelabelt. Hab so was ähnliches mit einem DM9000 (Ethernet-Controller) erlebt, bestimmte Chargen haben ein thermisches Problem gehabt und zeitweise Pakete verloren. Bei Nachforschungen stellte sich heraus, dass es die aufgedruckte Chargennummer gar nicht gibt. Der chinesische Distri hat mir wenigstens die 250 Teile gutgeschrieben, aber über 100Stk. mussten manuell ab und anschließend wieder mit Original-Teil aufgelötet werden. Um solchen A...löchern das Leben etwas schwerer zu machen, sollte man den chinesischen Distri verständigen, dass mit den gekauften Teilen etwas nicht stimmt. Der sollte dann seinen Lieferanten auf eine schwarze Liste setzen. Grüsse
Hendrik L. schrieb: > Die Abweichung bleibt nämlich absolut gesehen immer gleich (~+3° > zuviel) - egal bei welcher Temperatur Wenn das so ist dann ziehe von deinem Ergebnis immer 3° ab und alles ist gut.
Hendrik L. schrieb: > In erster Näherung würde ich sagen - keine Veränderung durch den > Übergang von 500 mS auf 5000 mS. Bitte, bitte, bitte benutze die korrekten Einheiten. Du meinst "500 ms" auf "5000 ms", keine Leitwerte.
S. R. schrieb: > Hendrik L. schrieb: >> In erster Näherung würde ich sagen - keine Veränderung durch den >> Übergang von 500 mS auf 5000 mS. > > Bitte, bitte, bitte benutze die korrekten Einheiten. Du meinst "500 ms" > auf "5000 ms", keine Leitwerte. Auweia - Danke für den Hinweis! Dann aber auch richtig: 5000 [ms]. (RWTH Aachen) Gruesse
Ich hatte mal Eigenerwärmungsprobleme mit einigen DS18B20, andere liefen problemlos. Sogar bei einen Meßzyklus von 4 Sekunden sind die innerhalb kurzer zeit um ca. 0,5 °C rauf. Beitrag "Re: Quick&dirty - schnelle Problemlösungen selbst gebaut" Vielleicht kannst Du auch provisorisch einen Kühlkörper montieren? Oder ist mehr oder weniger direkter Kontakt zum Wasser gegeben?
Klaus I. schrieb: > Ich hatte mal Eigenerwärmungsprobleme mit einigen DS18B20, andere liefen > problemlos. Sogar bei einen Meßzyklus von 4 Sekunden sind die innerhalb > kurzer zeit um ca. 0,5 °C rauf. > Beitrag "Re: Quick&dirty - schnelle Problemlösungen selbst gebaut" > > Vielleicht kannst Du auch provisorisch einen Kühlkörper montieren? Oder > ist mehr oder weniger direkter Kontakt zum Wasser gegeben? So - habe noch einmal das BitShifting beispielhaft gecheckt, vom I2C Bus übermittelt: HB=16, LB=194 ... von mir errechnetes Resultat ((4096 + 194) / 8) * 0,0625 33,5...°C Gegenmessung mit Greisinger GTH 175/PT -199.9 bis +199.9 °C Fühler-Typ Pt1000 ... 30,4°C ! Tja - ist zum Hohnepiepeln ...! Der Unterschied ist einfach zu groß - es kann keine Eigenerwärmung sein! Ausserdem sind die Sensoren auf der Hydraulik Anlage aufgeklebt - Körperkontakt, Wärmeleitung! Bei 13m**3 Wasser-Durchfluss pro Stunde (50er Verrohrung) ist die Rohr-Aussentemperatur definitiv gleich der Innentemperatur=Wassertemperatur ... Gruesse
Ich hatte auch ein Problem mit dem Messwert, er war ca. 3°C zu hoch. Ich habe dann den empfohlenen 100nF Kondensator an die Versorgung gehängt und die Messwerte waren deutlich realistischer. Leider habe ich keine hochgenauen Messgeräte um es Gegenzuprüfen. Beim DHT11 scheint übrigens das gleiche Problem zu bestehen. Gruß Stefan
Hendrik L. schrieb: > So - habe noch einmal das BitShifting beispielhaft gecheckt, > > vom I2C Bus übermittelt: HB=16, LB=194 > > > ... von mir errechnetes Resultat > > ((4096 + 194) / 8) * 0,0625 > > 33,5...°C Irgendwie kann ich Deiner Berechnung nicht so ganz folgen. Mag vielleicht daran gelegen haben, dass ich seit Mitternacht wieder wach bin und kaum geschlafen habe, aber ich verstehe nicht woher dass /8 kommt. Laut Datenblatt würde ich folgendes rechnen: (16*256 + 194) * 0,0625 = 268,125 °C Alleine das HB=16 kann doch nicht sein. Bin jetzt echt verwirrt und versuche doch noch ein kleines Nickerchen zu halten. Stefan schrieb: > Beim DHT11 scheint übrigens das gleiche Problem zu bestehen. Ja, aber ich glaub die sind eher chronisch unzuverlässig, gerade die Temperatur. Ist aber denke ich auch so im Datenblatt vermerkt.
Klaus I. schrieb: > Hendrik L. schrieb: >> So - habe noch einmal das BitShifting beispielhaft gecheckt, >> >> vom I2C Bus übermittelt: HB=16, LB=194 >> >> >> ... von mir errechnetes Resultat >> >> ((4096 + 194) / 8) * 0,0625 >> >> 33,5...°C > > Irgendwie kann ich Deiner Berechnung nicht so ganz folgen. Mag > vielleicht daran gelegen haben, dass ich seit Mitternacht wieder wach > bin und kaum geschlafen habe, aber ich verstehe nicht woher dass /8 > kommt. > > Laut Datenblatt würde ich folgendes rechnen: > (16*256 + 194) * 0,0625 = 268,125 °C > > Alleine das HB=16 kann doch nicht sein. > > Bin jetzt echt verwirrt und versuche doch noch ein kleines Nickerchen zu > halten. > > > Stefan schrieb: >> Beim DHT11 scheint übrigens das gleiche Problem zu bestehen. > > Ja, aber ich glaub die sind eher chronisch unzuverlässig, gerade die > Temperatur. Ist aber denke ich auch so im Datenblatt vermerkt. Ich hoffe, Du hast zuwischeneitlich gut geschlafen ...! "/8" ....! Gruesse
(16*256 + 194) * 0,00625 = 26,8125 °C --------------------^ Würde doch passen?
Beitrag #5103269 wurde vom Autor gelöscht.
Alex W. schrieb: > (16*256 + 194) * 0,00625 = 26,8125 °C .00625 = 1/160. Wozu sollte das gut sein? Beim LM92 hat man 16 Bits, in denen die Temperatur als 13 Bits in 16 Bits linksbündig sitzt. Daher die /8, die aber als Rechts-Shift um 3 verständlicher rüber kommt. Also int16_t t1 = (HB << 8 | LB) >> 3; float t2 = t1 / 16; Oder int16_t t1 = (HB << 8 | LB) & ~7; float t2 = t1 / (8 * 16); // entspricht t1/8 * 0.0625 Wenn man die 3 unteren Bits mit in die Rechnung nimmt, dann kriegt man diese Statusbits mit ins Ergebnis. Was zwar praktisch nichts ausmacht, aber trotzdem Unsinn ist.
:
Bearbeitet durch User
A. K. schrieb: > Beim LM92 hat man 16 Bits, in denen die Temperatur als 13 Bits in 16 > Bits linksbündig sitzt. Daher die /8, die aber als Rechts-Shift um 3 > verständlicher rüber kommt. OK jetzt ist es klar, wird so im uC.net verlinktem DB in Table 3 erklärt. Merci
A. K. schrieb: > Also int16_t t1 = (HB << 8 | LB) >> 3; Besser: int t1 = (int16_t)(HB << 8 | LB) >> 3; Funktioniert so auf 32-Bittern auch im Winter.
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.