LM92 aus China- eine Produktfälschung?

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

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.

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

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:
> 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

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

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.

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.