Ein Datenlogger mit AVR - Nutzung von Sensoren

Page content

Am AVR können zahlreiche (um nicht zu sagen: zahllose) Sensoren angeschlossen werden. Bei stromsparender Bauweise und Verwendung eines nichtflüchtigen Speichers (großes EEPROM, SD-Karte) können diese Werte über einen langen Zeitraum vom AVR autark gesammelt werden (“Data Logger”). Ein bisschen habe ich da auch herumexperimentiert.

Luftdruck und Temperatursensor HopeRF HP03S

Dieser Sensor erfasst Luftdruck und Temperatur als 16-Bit Werte. Er kann mit dem I2C Protokoll (auch “TWI”, Two Wire Interface genannt) angesprochen werden. Zum Sensor gibt es ein Datenblatt, dass auch die Programmierung darstellt. Allerdings ist das bei HopeRF abgedruckte Programm für 8051-CPUs.

Der Sensor (9,5x9x4,6mm) aus der Nähe. Das Innere ist mit einer gelartigen Masse gefüllt.

Um den Sensor nutzen zu können, muss man ihn elektrisch mit dem AVR verbinden. Ich habe ein Kabel angelötet. Evtl. kann man den Sensor auch direkt auf eine Platine auflöten.

An die sechs Kontakte kann man noch per Hand und ohne Lupe ein Kabel anlöten

Der Sensor wird mit maximal 3,6V betrieben. Man muss also evtl. aus einer 5V-Spannung noch eine geeignete Spannung (also z.B. 3,0 oder 3,3V) ableiten. Er hat einen XCLR-Eingang, der nur während der Messung High sein soll. Außerdem noch einen Masterclock-Eingang MCLK, an den eine Frequenz um 32768Hz anzulegen ist (auch nur während der Messung). Schließlich noch SDA (Daten) und SCL (Clock) des I2C-Interfaces um das EEPROM auszulesen.

Die sechs Anschlüsse des Sensors

Ich habe zum Experimentieren 3,0 Volt aus 5 in Serie geschalteten Dioden und einem Vorwiderstand gewonnen, die an +5V anliegen. MCLK, XCLR und SCL sind Leitungen, die nur der AVR beschreibt, daher kann man da die Pegelanpassung mittels zweier Widerstände machen. Der I2C-Bus erfordert, dass die beiden Leitungen mit einem Pullup-Widerstand gegen VCC gelegt sind.

Die SDA-Leitung wird in beide Richtungen genutzt, hier langt ein einfacher Spannungsteiler nicht aus. Man kann sich aber aus zwei Transistoren und drei Widerständen einen schönen Pegelwandler bauen (Erläuterungen dazu hier). Insgesamt ergibt sich das folgende Schaltbild.

Verkabelung zum AVR. Nicht eingezeichnet die beiden Pullup-Widerstände zu 4K7 gegen 3V an den Leitungen SDA und SCL.

Die vier Pins werden an den AVR angeschlossen, ich habe zum Experimentieren folgende Belegung gewählt:

AVR Sensor
PD7 MCLK
PD2 XCLR
PD3 SDA
PD6 SCL

Den Masterclock für den Sensor erzeugt der AVR mit einem Timer, der als PWM-Generator geschaltet ist. Mit einem 16Mhz- bzw. 8Mhz-Quarz bekomme ich nicht genau die Soll-Frequenz, sondern 31372 Hz. Erlaubt laut Datenblatt sind 30..35Khz, also ist meine Frequenz im erlaubten Rahmen.

Es dauerte einige Zeit, bis meine Hardware soweit war, die Calibration Werte auszulesen (hatte erst SDA auch nur mit einfachem Spannungsteiler versucht, was zu Lesefehlern führte). Bei mir kamen im Erfolgsfall folgenden Werte (mehrfache Auslesung):

Environmental Data Logger $Revision: 363 $ C1=17837, C2=3189, C3=358, C4=1474, C5=30695, C6=6333, C7=2500. A=7, B=29, C=6, D=11  
Environmental Data Logger $Revision: 363 $  
C1=17837, C2=3189, C3=358, C4=1474, C5=30695, C6=6333, C7=2500. A=7, B=29, C=6, D=11  
Environmental Data Logger $Revision: 363 $ C1=17837, C2=3189, C3=358, C4=1474, C5=30695, C6=6333, C7=2500. A=7, B=29, C=6, D=11  
Environmental Data Logger $Revision: 363 $   
C1=17837, C2=3189, C3=358, C4=1474, C5=30695, C6=6333, C7=2500. A=7, B=29, C=6, D=11 

Aus den Calibration Werten und den eigentlichen Messwerten, die als “raw” 16-Bit-Werte vorliegen, muss nach einer (ohne Float-Arithmetik) nicht ganz simplem Formel die echten Werte für Temperatur und Luftdruck berechnet werden. Die Formeln sind im Datenblatt angegeben. (Da der normale Luftdruck auf Meereshöhe eine Art Konstante ist und der Luftdruck mit der Höhe linear abnimmt, kann aus dem Luftdruck und einer passenden Tabelle/Formel übrigens auch die Höhe des Messorts berechnet werden.)

Bei mir ergaben sich an einem schwülen Tag mit angekündigtem Gewitter (D1 und D2 sind die Raw-Werte, die anderen Werte Zwischenschritte der Umrechnung):

dUT=165  
OFF=12774  
SENS=17894  
D1=41101, D2=30860  
Temp=26.5 °Celsius, Pressure=1008.90 hPa (Height ~ 3.0m).
  
dUT=163  
OFF=12773  
SENS=17893  
D1=41101, D2=30858  
Temp=26.5 °Celsius, Pressure=1008.87 hPa (Height ~ 3.0m).

Die Höhe stimmt irgendwie nicht, zugegeben, es müssten um die 120 Meter sein :-)

Zwei weitere digitale Thermometer, die ich direkt neben den Sensor stelle weichen nur minimal (0.1-0.3 Grad) von dem Messwert des Sensors ab. Die Temperatur stimmt also so in etwa. Genauer kann ich es nicht testen.

Weiterführende Infos

Luftfeuchtigkeitssensor HopeRF HH10D

Von Hope gibt es auch einen Luftfeuchtigkeitssensor, den HH10D. Dieser ist ein kleines Modul bestehend aus einem EEPROM sowie einem Sensor zuzüglich Beschaltung. Die Beschaltung macht aus einem Feuchtigkeitswert einen Frequenzwert. Im EEPROM stehen zwei Kalibrierwerte vom Hersteller.

Ansicht des Sensors HH10D von oben

Der EEPROM-Teil kann via I2C ausgelesen werden, für den Sensor-Teil muss man die entstehende Frequenz messen und mit den Kalibrierwerten in einen echten Messwert umrechnen. Eigentlich wäre es schöner, wenn der Sensor via I2C den Messwert bereitstellen würde, so wie das der HP03s macht. Ist aber nicht so. Die zu messende Frequenz liegt um 7Khz (5-10Khz).

Ansicht des Sensors HH10D von unten. Erkennbar sind das EEPROM und der Spannungs-Frequenz-Konverter. Die Unterseite des Moduls ist vergossen. Die Schnittkante der Platine (oben, unten) ist erstaunlich schlampig ausgeführt (es sieht wie mit der Hand an der Tischkante abgebrochen aus :-)

Die Nutzung dieses Sensors besteht also darin dass man

  • Zunächst die Kalibrierkonstanten ausliest und dann
  • die Frequenz am Pin FOUT misst.

Mittels eines “Pin Changed”-Interrupts können Signalflankenwechsel an den Eingängen des AVRs erkannt und gezählt werden. Mit einem Timer-Interrupt, der z.B. alle Sekunde eintritt, kann nun der erreichte Zählwert als Frequenzwert des Sensors hergenommen werden.

Bei Experimenten mit einem 8Mhz-getakteten ATmega644, der nebenbei noch diverse Berechnungen machte und via RS232 kommunizierte (aber keine weiteren zeitkritische Interrupts ausführte), konnte ich Frequenzen bis etwa 70Khz sauber vom einem Eingangspin des AVRs lesen. Dies liegt weit über den geforderten maximalen 10Khz des Sensors.

Der HH10D wurde nach erfolgreichem Anschluss in das Logging des Datenloggers integriert. Es muss nur ein zusätzliches Byte mit abgespeichert werden.

Weiterführende Infos

Datenlogger

Nach dem prinzipiellen Anschluss des Sensors HP03s sollte ein Datenlogger entstehen. Designziele waren:

  • Loggen von Temperatur und Luftdruck, später kam noch Luftfeuchte hinzu
  • Speicherplatz für geloggte Daten (“Samples”) für einen Zeitraum von mindestens 60 Tagen
  • Stromversorgung durch Akku o.ä. (nicht durch ein Netzteil!) autark für mindestens 60 Tage
  • Auslesen der Daten via RS232 oder USB
  • Nutzung einer Realtime-Clock für das Loggen der Uhrzeit
  • Die Möglichkeit, evtl. weitere Samples zu nehmen, insbesondere Nutzung der ADC-Eingänge des AVRs (Port A)

Aus den Designzielen habe ich abgeleitet:

  • Möglichst geringer Stromverbrauch des Datenloggers
  • Abspeicherung der Samples (Uhrzeit+Temperatur+Luftdruck+…) in einem EEPROM ausreichender Größe

Ein erster Grobentwurf des Dataloggers ist im Bild unten zu sehen. Ein AVR in einem möglichst stromsparenden Betrieb steuert Sensor, RTC (Real Time Clock) und EEPROM an.

Grobschaltbild des Datenloggers mit Sensor, Echtzeituhr und EEPROM (1. Enwurf, später durch ein Design mit 2 I2C-Bussen ersetzt. Das für die Realisierung gewählte EEPROM ist ein 24FC1025 und nicht wie hier im Bild noch beschrieben, ein 24LC1024).

Basierend auf den Designzielen wurde folgendes festgelegt:

  • Ablage der Daten in einem großen EEPROM. Das EEPROM ist ein 128KByte-Typ 24FC1025. Größere EEPROMs, die am I2C-Bus arbeiten, sind mir nicht bekannt.
  • Nutzung eines Realtime Chips (RTC). Die Wahl fiel auf den PCF8583. Vorab wurde bereits die Nutzung des PCF8583 und des EEPROMs am AVR ausprobiert.

Die Anzahl der pro Tag erzeugten Samples ist variabel.

Da ein “Environmental” Datalogger entworfen wird, sind Temperatur und Luftdruck den natürlichen Gegebenheiten unterworfen. Ein Datalogger für einen Hochofen oder eine Druckkammer hätte mit anderen Wertebereichen zu arbeiten.

Datenplatzbedarf

Annahme: Der Datenlogger nimmt alle 30 Minuten ein Sample vom Sensor. D.h. es werden 48 Samples pro Tag erzeugt.

Abzubildender Temperaturbereich:

Die höchste jemals gemessene natürlich entstandene Temperatur ist +70,7 Grad Celsius (im Iran, 2007), der höchste europäische Wert ist höchstens +50,0 Grad ( in Sevilla, Spanien, 1881). Die niedrigste jemals gemessene natürlich entstandene Temperatur ist höchstens -91,5 Grad Celsius (Antaktis, Wostok-Station, 1997). in Europa höchstens -59,0 Grad Celsius (in Schweden unbestätigt gemessen). Zu den erwähnten Extremtemperaturen siehe hier. Mit einem Wertebereich -100…+100 Grad Celsius sind wir also auf der sicheren Seite.

Abzubildender Luftdruckbereich:

Der höchste jemals gemessene Luftdruck beträgt 1085,7hPa (Mongolei, 2001), der niedrigste jemals publizierte Wert beträgt 856hPa (Taifun bei Okinawa, Japan, 1958). Zu diesen Werten siehe hier und hier . Mit einem Wertebereich 750..1250 käme man also ziemlich gut hin.

Pro Sample müssen folgende Informationen gespeichert werden:

  • Temperatur: Bereich -100 .. +100 Grad Celsius, zwei Nachkommastellen: Ganzzahlanteil 1 Byte, Nachkommaanteil 00..99: 1 Byte, also in Summe 2 Bytes.
  • Luftdruck: Bereich etwa 750..1250, zwei Nachkommastellen. Wenn man vom echten Luftdruckwert vor dem Speichern konstant 750 abzieht, kann man mit 9 Bit einen Ganzzahlanteil mit 512 Werten abbilden, also den Bereich 750 .. 1262. Für den Maximalwert 512 benötigt man 2 Bytes, eventuell kann man das 9.te Bit irgendwo anders unterbringen, dann nur 1 Byte. Nachkommaanteil 00..99: 1 Byte, also in Summe 3 Bytes. Evtl. oberstes Bit des 9-Bit Werts des Ganzzahlanteils in oberstem Bit des Nachkommateils mitcodieren, dann wären es in Summe nur 2 Bytes.
  • Zeitstempel: Hier wird z.B. alle 24 Stunden (immer um 0 Uhr) das Datum gespeichert: Jahr, Monat, Tag. Dann werden für die 47 weiteren Samples nur noch gespeichert: Samplenummer ab 1 gezählt. Für das Jahr braucht man (beim PCF8583) 2 Bit (0..3), Monat 4 Bit (1..12) und Tag 5 Bit (1..31). In Summe 11 Bit. Dies kann in 2 Bytes abgelegt werden. Für die Folgesamples wird jeweils 1 Byte benötigt, wenn man maximal 256 Samples pro Tag erlaubt oder halt 2 Bytes, dann kann man bis zu 65536 Samples / Tag abbilden.

Damit ergibt sich pro Tag folgender Bedarf (48 Samples / Tag):

  1. Annahme: Luftdruck Wert braucht 2 Bytes: (2 Bytes Zeitstempel + 2 Bytes Temperatur + 2 Bytes Luftdruck) + 47 * (1 Byte Samplenummer + 2 Bytes Temperatur + 2 Bytes Luftdruck) = 6+47*5=241 Bytes

  2. Annahme: Luftdruck Wert braucht 3 Bytes: (2 Bytes Zeitstempel + 2 Bytes Temperatur + 3 Bytes Luftdruck) + 47 * (1 Byte Samplenummer + 2 Bytes Temperatur + 3 Bytes Luftdruck) = 7+47*6=289 Bytes

Bei 128KByte EEPROM ergibt das in Tagen: 131.072 Bytes/241 = 543 Tage bzw. 453 Tage. Beide Werte sind mehr als ausreichend (Designziel waren 60 Tage).

Abzubildender Feuchte-Bereich

Dies ist mal einfach, es handelt sich um einen Prozentwert 0..100. Evtl. will man noch zwei Nachkommastellen haben, dann kommt ein weiterer Wert 00..99 hinzu. Also ein oder zwei Bytes Speicherbedarf.

Spannungsversorgung

Alle Bausteine hängen am I2C Bus.

Der Sensor wird mit 3,3V betrieben. Das EEPROM und die RTC kann ebenfalls mit 3,3V betrieben werden, ebenso der gewählte AVR ATMega644 (aber nur bis -offiziell- 10MHz Taktfrequenz). Somit wurde entschieden, alles mit 3,3V Versorgungsspannung aufzubauen.

Das Controllerboard ist das bewährte DD Megaboard mit einem 3,3V Spannungsregler LT1117 (statt dem “üblichen” 7805; der LT1117 wurde gewählt, weil im Fundus vorhanden; der LT1117 ist jedoch eine schlechte Wahl, wenn es um geringen Stromverbrauch geht, siehe weiter unten). Die Schutzdiode vor dem Spannungsregler wurde diesmal durch eine Drahtbrücke ersetzt, um den Spannungsabfall an der Diode zu vermeiden.

Der MAX232CPE kann (inoffiziell) gerade so noch mit 3,3V betrieben werden, dies ist in diversen Foreneinträgen belegt.

Auch ISP funktioniert an 3,3V.

Die extern anliegende Versorgungspannung besteht im Zielbild aus 3-4 Batterien zu je 1,5V, also 4,5V -6,0V.

Stromverbrauch der gewählten Plattform

Nachmessen ergab, dass das DD Megaboard “ohne alles” (also nur die Stromversorgung mit dem LT1117 3.3 alleine) schon 5,3mA braucht. Bei Betrieb mit Netzteil ist das lächerlich wenig, aber bei Batteriebetrieb schon zu viel. Ohne das Sensorboard, ohne eingestecktes MAX232 und ohne eingesteckten RS232-Stecker und ohne eingestecktes ISP-Kabel werden 10,7mA verbraucht, d.h. der ATMega 644 verbraucht etwa 5mA bei 8Mhz. Ein eingesteckter ISP-Stecker erhöht den Stromverbrauch um 0,4mA. Der MAX232CPE erhöht den Verbrauch um weitere satte 5,6mA. Alles zusammen verbraucht 16,7mA (ohne Sensorboard). Eine weitere Reduktion kann nur durch Programmierung des ATMega (Sleep-Modes, Aufwachen nur alle z.B. 10 Sekunden oder auch paar Minuten) erreicht werden.

Der Regler LT1117 3.3 ist nach Datenblatt für eine Anwendung bei minimalem Stromverbrauch definitiv nicht geeignet mit bis zu 5mA Eigenverbrauch. Laut Internet gibt es sparsamere Regler, z.B. den LP2950 in 3,3V Version, mit 75µA Eigenverbrauch, siehe hier. Ein LP2985 IM5 3,3 (SMD) ist ideal mit unglaublich niedrigen 1µA Ruhestrom.

Wenn der AVR mit set_sleep_mode(SLEEP_MODE_IDLE) und sleep_mode() schlafen geschickt wird, reduzieren sich die oben erwähnten 10,7mA auf 7,4mA. Mein Board braucht selbst wie erwähnt 5,3mA, so dass der AVR also in diesem Zustand nur 2,1mA bei 8Mhz braucht. Laut Quelle (http://www.mikrocontroller.net/articles/Sleep_Mode) soll der AVR bei nur 1Mhz sogar nur 0,3mA brauchen.

Mit einer optimierten Stromversorgung wie dem LP2950 denke ich, dass ohne Änderung der Hardware bei 8Mhz Gesamtverbrauchswerte um 3mA möglich sind. Bei einer Stromquelle, die nutzbare 1000mA liefert können so 333 Stunden überbrückt werden. Dies sind leider nur 333/24 ~ 13 Tage mit dem SLEEP_MODE_IDLE. Das langt aber nicht aus, um die Designziele zu erreichen (60 Tage Betrieb ohne Unterbrechung)

Momentan vorstellbarer Bestfall, wenn die Hardware verändert wird:

  • Die Stromversorgung benötigt 1µA (LP2985)
  • Statt des MAX232CP muß ein Typ verwendet werden, denn man in einen Sleep Zustand versetzten kann. Annahme: Auch dieser Chip verbraucht im Sleepmode nur 1µA
  • Der AVR ist während einer Stunde pro Minute nur 2 Sekunden aktiv, also nur 120 Sekunden in den 3600 Sekunden. Dabei verbraucht er die oben gemessenen 5mA. Pro Stunde sind dies 5000µA*120/3600=167µAh

Im Ergebnis sind dies 169µAh Gesamtverbrauch bei optimalen Annahmen.

Mit 2000mAh NiMh-Zellen, bei denen 1000mAh nutzbar sind (Annahme), kommt man so auf theoretisch 246 Tage (5917 Stunden). Bei solch großen Werten spielt schließlich die Selbstentladung der Akkus eine wesentliche Rolle. Die 60 Tage des Designziels sind aber unter diesen Annahmen sicher erreichbar.

Da mir momentan die entsprechenden Bauteile fehlen (kein passender Spannungsreger, kein abschaltbarer MAX232) mache ich erst mal mit dem weiter was ich habe. Ich kann den Datenlogger auch an eine vorhandene Solarzelle anschließen, die eine weit höhere Leistung liefert als der Datalogger braucht.

Interferenzen des Sensors HP03s mit anderen I2C Geräten

Ich habe ein EEPROM, eine RTC (Realtimeclock, PCF8583) sowie den genannten Sensor an einem I2C Bus betrieben. Dabei traten öfter Störungen auf. Das Auslesen der RTC war, wenn der Sensor gleichzeitig am Bus angeschlossen war, nicht zuverlässig. Variation der Bus-Pullup-Widerstände (an 3,3V Bus von 2K2 auf 1K gesenkt) brachte keine Verbesserung. Analysen mit dem Oszilloskop zeigen, dass das Acknowledge der RTC einen zu geringen Hi-Pegel hat, wenn der Sensor angeschlossen ist. Konkret waren es ohne Sensor ~2,4V, mit Sensor nur noch 1,78V. Dies langt zur Erkennung als HI nicht aus (Daumenregel: LO=weniger als 0,3VCC, HI=mehr als 0,7VCC). Herumsuchen in Foren brachte keine weiteren Erkenntnisse. Selbst wenn der Sensor softwaremäßig nicht angesprochen wird, funktioniert das Auslesen der RTC nicht immer (!). Nach drei Tagen Herumprobieren entschied ich mich dazu, das Design des Sensorboards zu ändern: Es gibt nun zwei getrennte I2C-Busse:

  • Einen für den/die Sensoren (Software Implementierung)
  • Einen für RTC und das EEPROM (Hardware-Implementierung)

Nach Änderung der Hardware können nun die drei Geräte (RTC, Sensor HP03S, EEPROM) sauber verwendet werden. Das Hardware-Design ist bereits vorbereitet, um den Luftfeuchtesensor HH10D aufzunehmen.

Schaltbild Sensorboard. Der Wannenstecker oben links dient der Verbindung mit dem AVR, die beiden Wannenstecker in der Mitte dem Anschluss der Sensoren HP03s und HH10D.

Verbindung AVR<->Sensorboard

AVR Pin AVR Pin Bedeutung Sensorboard Wannenstecker Pin Sensorboard Pin Bedeutung
PB3 OC0A PWM Generator Output 4 MCLK von HP03s
PC0 1 SCL (Hardware I2C)
PC1 2 SDA (Hardware I2C)
PC2 3 XCLR von HP03s
PC4 5 SCL2 (Software I2C)
PC5 6 SDA2 (Software I2C)
PC6 7 FOUT von HH10D
- - 9 GND
- - 10 VCC (3,3V)

 

Bild: DD Megaboard rechts, in der Mitte das Sensorboard und ganz links der Sensor HP03s.

 

Das Sensorboard aus der Nähe. Auf dem Sensorboard ist die RTC und das EEPROM sowie die Sicherungsbatterie zu sehen.

I2C Adressen

Die I2C Adressen der einzelnen Bausteine müssen eindeutig sein.

Baustein I2C Adresse Bus Kommentar
Hope HP03s 0xA0 SW Adresse nicht änderbar
Hope HH10 0xA2 SW Adresse nicht änderbar
EEPROM 24FC1025 0xAx11x HW Alternativen möglich (A0,A1,A2)
PCF8583 0xA2 HW Alternativen möglich (A0)

Hier kollidieren die Adressen von RTC und dem Luftdrucksensor. Da beide Bausteine an verschiedenen Bussen liegen, macht dies aber nichts. Über meist vorhandene Adressleitungen A0,A1,A2,… kann die Basisadresse eines I2C Bausteins variiert werden. Dies ist bei den beiden Sensoren nicht möglich, deren Adressen sind fix.

RTC PCF8583 geht viel zu schnell (läuft viel zu schnell)

Bei den ersten Tests zeigte es sich, dass die RTC PCF8583 viel zu schnell lief. Und zwar etwa eine Stunde in 4 Stunden, also satte ~20% zu schnell.

Nachforschen im Datenblatt und in Foren brachte die Erkenntnis, dass direkt an den Pins VCC und GND ein Kondensator zum Abblocken der hochfrequenten Störsignale aus der Versorgungsspannung benötigt wird. Ich hatte im Design einen 100n-Kondensator vorgesehen, diesen aber leider nicht direkt am PCF8583 platziert. Ich habe dann zur Nachbesserung einen 10uF-Kondenstator direkt an die Pins des Chips gelötet (Platinenunterseite). Danach war die Uhr sehr genau (in einem Tag ca. 12 Sekunden Abweichung). Ein weiteres Feintuning muss mit einem 20pF-Trimmer erfolgen (im Datenblatt beschrieben). Diesen Trimmer habe ich zur Zeit noch nicht an der Uhr. Die Datenlogger-Software erlaubt es aber, die Zeit direkt neu einzugeben, somit kann ich mit dem momentanen Zustand und einer leichten Gangabweichung nach einigen Wochen vorübergehend leben.

Weiter

  • Einbau in Gehäuse

Betriebssoftware

Für den Datenlogger wurde eine kleine Software geschrieben. Diese ist mittels doxygen in den Sourcen dokumentiert. Die mit doxygen generierte Dokumentation ist unter folgendem Link als Kopie vorhanden:

Dokumentation, erzeugt mit doxygen (Englisch)

Format der Datenausgabe

Im folgenden ein Auszug eines Datendumps:

<dump> 
<header>
 Environmental Data Logger $Revision: 625 $
 number of samples per day: 144
 oldest sample with complete timestamp: 12.01. 16:10
 newest sample with complete timestamp: 11.02. 12:40
 samples in total: 4180
 eeprom start byte: 0x000006
 eeprom end byte: 0x00b3a1
 total bytes in eeprom: 45980
 <date>11.02.</date>
 <time>12:44:15</time>
</header> 
<logdata>
 <log type="long">12.1. 16:10 18.5 1006.40 56.0</log>
 <log type="long">12.1. 16:20 19.2 1006.37 56.9</log>
 <log type="long">12.1. 16:30 19.7 1006.40 56.3</log>
 <log type="long">12.1. 16:40 12.4 1006.9 59.1</log>
 <log type="long">12.1. 16:50 9.1 1005.62 63.6</log>
 <log type="long">12.1. 17:00 7.8 1005.56 65.5</log>
 <log type="long">12.1. 17:10 7.4 1005.56 65.8</log>
 <log type="long">12.1. 17:20 7.1 1005.43 65.7</log>
 <log type="long">12.1. 17:30 7.0 1005.46 65.5</log>
 <log type="long">12.1. 17:40 7.0 1005.43 65.2</log>
 ...
 <log type="long">10.2. 22:50 -9.5 1018.21 34.8</log>
 <log type="long">10.2. 23:00 -9.5 1018.18 34.7</log>
 <log type="long">11.2. 12:40 21.6 1018.9 48.8</log>
<statistics> 
 <temp-min>-14.0</temp-min>
 <temp-max>21.6</temp-max>
 <pressure-min>987.53</pressure-min>
 <pressure-max>1020.87</pressure-max>
 <moisture-min>19.4</moisture-min>
 <moisture-max>78.0</moisture-max>
</statistics>
</logdata>
</dump>

I2C Debugging

Da der I2C Bus nur aus zwei Leitungen besteht, kann man die Aktivitäten auf dem Bus noch gut mit einem Speicher-Oszilloskop mit zwei Eingängen ansehen.

Viele Oszilloskope haben einen externen Triggereingang, den man irgendwo in der Schaltung anklemmt, wo ein Signal zur Verfügung steht, dass als Start-Trigger geeignet ist. Die beiden Eingänge werden dann an SDL und SDA gelegt. Wenn das Oszilloskop eine große Speichertiefe hat, kann man nun das Oszilloskop auf " Single" Trigger eingestellt und das Trigger-Event herbeigeführt. Danach steht die Geschichte um das Trigger-Event herum im Oszilloskop-Speicher. Man kann nun hineinzoomen, bis man die einzelnen Bits auf den beiden Leitungen sieht. Durch sorgfältiges Abzählen kommt man so auf die Bits und die Bytes.

Ein Datenbit wird in I2C immer bei einer steigenden SCL-Flanke übernommen.