Omron D6T Thermal Sensor

ich krame das hier nochmal hervor weil ich jetzt ebenfalls einen D6T 
Sensor habe der nicht richtig ausgelesen wird. Mal kommen gültige Werte, 
mal nicht. Die Doku zu dem Teil ist schwer zu finden und dürftig. Hat 
hier jemand mehr Erfolg gehabt beim Auslesen dieses Sesnors?

Angeschlossen habe ich einen D6T8L06 an ein STM43F407VET6 Board, 2k2 
PullUps an +5V, 20 cm Flachbandkabel, Versorgung ist auch 5V.
IO Pins sind an PB_10 und PB_11 (5V tolerant), SW ist mbed-os.
Getestet habe ich zwei Sensoren, die verhalten sich beide gleich, ebenso 
wie die vom TO am Arduino.
So sehen die Werte z.B aus (die Anzahl der Fehler ist immer anders):

1

err: 0      25.6     23.7     23.1     22.8     23.1     23.5     23.9     23.9     24.7 

2

err: 1       0.0      0.0   6110.1    204.8   1822.9      2.0    506.7    204.9      0.0 

3

err: 1       0.0      0.0   6110.1    204.8   4318.9      3.5    506.7    204.9      0.0 

4

err: 1       0.0      0.0   6110.1    204.8    256.6      5.1    506.7    204.9      0.0 

5

err: 0      25.3     23.4     22.8     22.6     22.8     23.3     23.6     23.6     24.5 

6

err: 1       0.0      0.0   6110.1    204.8   5449.9      8.1    506.7    204.9      0.0 

7

err: 0      25.3     23.4     22.8     22.6     22.8     23.3     23.6     23.6     24.4 

8

err: 0      25.3     23.3     22.8     22.6     22.9     23.3     23.6     23.6     24.4 

9

err: 1       0.0      0.0   6110.1    204.8    272.8     12.8    506.7    204.9      0.0 

10

err: 0      25.3     23.5     22.9     22.7     23.0     23.5     23.7     23.7     24.5

Danke, die Pause zwischen Kommando schreiben und Daten lesen hatte ich 
inzwischen auch eingebaut, damit sinkt die Fehlerrate auf etwa 5%.
Im Fehlerfall brechen die Pegel beim Daten lesen ein, das sieht beim 
Fehler immer gleich aus. Ein zusätzlicher 100n C hat nix gebracht, ich 
packe mal noch einen etwas grösseren C auf die Sensorplatine.

1

void readD6T8L06()

2

{

3

    const int i2cAddrD6T8L06 = 0x14;

4

    const char cmdReadData = 0x4c;

5

6

    char rawBuffer[64];

7

    float temperatures[9];

8

9

    irMeasureActive = 1;

10

    i2c.write(i2cAddrD6T8L06, &cmdReadData, true);

11

    wait_ms(2);

12

    int err = i2c.read(i2cAddrD6T8L06+1, rawBuffer, 19);

13

    irMeasureActive = 0;

14

15

    com1.printf("err: %i  ", err);

16

17

    for (int i=0; i<9; i++) {

18

        temperatures[i] = (rawBuffer[i*2] + (rawBuffer[1+i*2] << 8)) * 0.1f;

19

        com1.printf("%8.1f ", temperatures[i]);

20

    }

21

    com1.printf("\n");

22

}

Hallo,

leider erkenne ich auf dem Oszi-Print nicht die relevanten 
Pegel(übergänge).
Mach doch bitte mal genau das gleiche Foto nur mit SDA/SCL.
Wie schnell ist denn überhaupt der Clock?

Im PDF steht ja was von MAX 100kHz!!
So wie das bei Dir aussieht, bist Du da wohl weit drüber??

Auf jeden Fall scheint in der dargestellten Übertragung ein NACK zu 
kommen. Also liegt das Problem einen Schritt vorher.

Gruß
TK

TK schrieb:
> Wie schnell ist denn überhaupt der Clock?

ich hatte verschiedene Werte von 10...400 kHz probiert. Bei 400 bekomme 
ich weniger Fehler als bei 100 kHz, noch etwas weniger Fehler bei 10 
kHz. Soviel zu den Angaben im Datenblatt...

Die PullUp habe ich jetzt von 2k2 auf 4k7 vergrössert, zeigt auch keine 
signifikante Änderung.

Bei anderen Sensoren und Displays hat I2C immer auf Anhieb funktioniert, 
hatte da allerdings auch meist NXP Hardware verwendet. Ich teste das 
gleich auch nochmal mit einem LPC824.
Im Internet habe ich diverse Arduino Codes gefunden. Die verwenden die 
Wire Lib und senden nach Adresse und Kommando noch ein Stop. Laut 
whitepaper soll da ein repeated start kommen, aber da ist der Sensor 
scheinbar tolerant. Ich habe beide Varianten probiert (das 3. Argument 
im write steuert das bei mbed), keine Änderung.

Das NACK scheint aber das Problem zu sein. Mit diesem NACK wird eine 
Fehlerbehandlung per Interrupt ausgelöst und die initialisiert die I2C 
Schnittstelle neu, daher kommen wohl die kaputten Pegel nach dem 
fehlerhaften Byte. Aber es sieht so aus als ob sich der Sensor bei den 
Clocks verzählt, nach dem NACK kommt immer ein low Pegel der das 
richtige ACK sein könnte.
Der clock sieht nicht so schön aus, was ist der min Pegel für high? 
Bilder liefere ich gleich.

Johannes S. schrieb:
> noch etwas weniger Fehler bei 10
> kHz.

Ja - lt. Datenblatt

Clock Frequency
max 100kHz

Das Teil scheint halt nicht besonders schnell zu sein :-)

Jetzt wo ich die Bilder gemacht habe sehe ich das ein NACK schon beim 
Schreiben der Adresse kommt und dann wird auch alles weitere negativ 
quittiert. Abfragezyklus ist 500 ms, aber auch bei 1s gab es die Fehler.
Die Taktfrequenz scheint mir nicht das Problem zu sein, eher das der 
Sensor manchmal nicht ready ist.

auf dem LPC824 läuft das jetzt fehlerfrei. Das Timing sieht fast gleich 
aus, nur die Datenbits werden nach der fallenden Taktflanke etwas länger 
gehalten. Mehr als 100 kHz macht der Sensor hier nicht mit, und zwischen 
Kommando schreiben und Lesen möchte er eine Pause haben, 100 µs sind 
gut. Auslesen im 50 ms Zyklus macht der Sensor auch mit.
Vielleicht läuft das auf dem STM mit Pegelwandler besser, was nimmt man 
da für I2C?

Edit:
irgendwie mögen der FF und die Forensoftware die .png vom Rigol nicht, 
das iPhone zeigt sie an. Habe das Bild nochmal als gif angehängt.

Das Problem nervt mich immer noch...
Habe den Sensor auch an ein Nucleo mit STM32L031 angeschlossen, auch da 
liefert er zu 100% gültige Messwerte. Nur an dem STM32F407 gibt es 
ständig Fehler. Also schon das erste Byte (Adresse + Write) das er auf 
den Bus legt wird negativ quittiert.
Ich habe mir nochmal die SDA Haltenzeit nach der fallenden Flanke von 
SCL angesehen, beim L031 ist die ca. 250 ns und beim F407 mit ca. 400 ns 
eher länger. Nur der Hi Pegel bricht beim F07 kurz auf ca. 3 V ein.

Hallo,

also die "runde Flanke" bekommst Du mit einem kleineren Pull-Up weg.
Bei 5V sollte der Pull-Up jedoch nicht kleiner als 1k8 werden.
Jetzt spekuliere ich mal:
Der Sensor liest die SDA-Pegel bei einer fallenden SCL Flanke ein. Das 
würde erklären, wieso ein weiter oben gezeigtes Bild (mit einem SDA 
Wechsel in der SCL-L / 2 Phase) scheinbar gut funktioniert, die anderen 
Versuche jedoch sporadische Aussetzer haben.
Frage hierzu: Wo misst Du genau die IIC-Signale (am Sensor oder am 
Controller und wie lange sind die Leitungen noch mal zwischen uC und 
Sensor)?
Wenn es geht, probiere doch mal die IIC Engine so einzustellen, dass die 
SDA Wechsel nicht sofort mit SCL-H-L kommen, sondern z.B. 1us später 
(ich kann Dir jedoch nicht sagen, wie/ob das bei den Controllern geht)

Gruß
TK

TK schrieb:
> Jetzt spekuliere ich mal:
> Der Sensor liest die SDA-Pegel bei einer fallenden SCL Flanke ein.

das vermute ich auch, deshalb hatte ich diese Zeiten genauer angesehen. 
Nur der L031 hält die Daten nur 250 ns, der F407 400 ns und 
funtktioniert trotzdem schlechter.
Der F407 hat keine Einstellmöglichkeiten für das Timing, andere 
(neuere?) cores lassen sich genau hier mit SCLDEL / SDADEL in setup und 
hold time beeinflussen.
Aufbau siehe Bild, Tastköpfe sind auf 10x eingestellt, Fehler gibt es 
auch ohne. Mit dem gleichen Breadboardaufbau am STM32L031 oder LPC 
funktioniert der Sensor.
Ich habe jetzt noch PCA9306D Levelshifter bestellt, so schlecht sieht 
mir das Timing nicht aus, da bleiben ja nur noch die Pegel.

Hallo,

2 Dinge, die Du mal durchführen müsstest.

1) Schliess mal den GND vom Tastkopf an (direkt auf Sensor GND oder auf 
uC GND). Damit könnten die gezeigten Spikes schon mal wegfallen.
2) Wie hoch ist die Versorgungsspannung des uC? Läuft der STM überhaupt 
mit 5V oder sind die IIC-Pins 5V tolerant??? Hier ist meines Erachtens 
ein Levelshifter notwendig. Sowas kannst Du evtl. auch schnell selbst 
aufbauen.
Unter
http://www.ibkirchen.de/zipliste/wissen/iic.html
habe ich eine kleine IIC-Infoseite erstellt - vielleicht hilft das ja 
etwas weiter.

Gruß
TK

1) ja, ist nicht ideal. Mit Masse am Tastkopf sieht es aber nicht viel 
anders aus.
2) der STM32F407 läuft mit 3,3 V, die Eingänge PB10 und PB11 sind 5 V 
tolerant. Eigentlich ist der Levelshifter unnötig, aber erstmal der 
letzte Strohhalm. Mit 3,3 V am Sensor misst der nur Fahrkarten und mehr 
Fehler.
Oder SoftI2C, aber an dem anderen STM läuft der Sensor ja auch.
An der Schnittstelle PB10/11 ist auch nichts anderes angeschlossen, habe 
ich auch kontrolliert.
Die 5 V Quelle für den Sensor habe ich auch variiert, bringt auch keine 
Änderung.

PS:
schöne Zusammenfassung deine Seite. 100 R Serienwiderstände habe ich 
gerade auch mal eingebaut, die machen die negativen Spitzen etwas weg, 
Übertragungsfehler bleiben.

Ha, ich denke ich habe es endlich.
Die 100 R in den SCL/SDA haben doch etwas gebracht, da waren die Fehler 
beim write() weg.
Der letzte Fehler war dann noch Software, in dem write() hatte ich mit 
dem true/false für das unterdrücken des Stop gespielt und das auf 'Stop 
senden' stehen gelassen. Da ist der Sensor aber doch nicht so tolerant, 
erst ohne Stop vor dem Daten lesen geht es fehlerfrei, reproduzierbar. 
Auch der Fehler mit den 100 R ist reproduzierbar, also könnte der 
levelshifter auch was bringen.

Eine Sache fällt mir gerade noch ein. Mit Deinem Hinweis:
>Mit 3,3 V am Sensor misst der nur Fahrkarten und mehr Fehler.
habe ich mir das DB nochmal genau angesehen. Der Sensor benötigt 
5V+-10%.
Das sind nach unten 4.5V. Wenn ich jetzt mal die Oszi-Bilder ansehe, 
dann
liegst Du ziemlich nahe an der unteren Grenze (ich glaube 4.6V 
interpretiert zu haben). Ist das auch die Sensor VCC? Wenn dem so ist, 
versuch doch mal die VCC nach oben zu korrigieren. Vielleicht bringt das 
noch eine Erkenntnis.

Gruß
TK

Ja, die Sensorspannung kommt von dem STM Board und beträgt 4,6 V. An dem 
Nucleo kam 4,4 V raus und es lief besser (digital jedenfalls, analoge 
Messung ist dann vlt. schon ungenauer). Dann habe ich ein LaborNT mit 
5,0 V angeschlossen und es wurde auch nicht besser. Mehr möchte ich dem 
STM auch nicht zumuten, da ist mir der LS auch als Schutz für den uC 
recht.