Hallo, hat evtl. jemand mal etwas mit dem Omron D6T-44L (MEMS) Thermal Sensor gemacht? Ich versuche den Sensor per I2C auszulesen und komme trotz einigen Versuchen mit unterschiedlichen Clock Frequenzen und Wartezeiten zwischen den Samples nie unter Fehlerraten unter 30%. Eher mehr. Im Fehlerfall bricht die Kommunikation ab oder der Wert für Pixel ist unplausible (mehr als 55°C). Ich lese mit einer erweiterten TWI Library per Arduino 35 Bytes (2bytes PTAT + 16*2 Bytes Pixel + 1 Byte PEC) ohne Stop Condition durch (wenn es klappt). Vom Raspberry aus klappte praktisch kein einziger Abruf. Ich vermute das mich hier das fehlende Clock Stretching behindert hat. Gruß Peter
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 |
Es scheint kein generelles Problem zu sein. Vielleicht hilft dieser Bericht samt Samplecode ... https://forum.arduino.cc/index.php?topic=323245.0
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.
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.