Computer und Linux

---

Bastelecke

---

Zur Startseite

---

Kontakt
Impressum

Ein Datenlogger mit AVR - Nutzung von Sensoren

Hinweis: Diese Aktivität ist nicht abgeschlossen. Das Dokument beschreibt also den momentanen Stand.

Am AVR können zahlreiche (um nicht zu sagen: zahllose) Sensoren angeschloßen 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 bischen 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.

Um den Sensor nutzen zu können, muß 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.

Der Sensor wird mit maximal 3,6V betrieben. Man muß 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. Ausserdem 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.

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.

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


Aus den Calibration Werten und den eigentlichen Messwerten, die als "raw" 16-Bit-Werte vorliegen, muß 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 Meßorts 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):


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

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

Weiterführende Infos

• Link zu Hope Microelectronics
  

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.

Der EEPROM-Teil kann via I2C ausgelesen werden, für den Sensor-Teil muß man die enstehende 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).

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 Anschluß in das Logging des Datenloggers integriert. Es muß nur ein zusätzliches Byte mitabgespeichert werden.

Weiterführende Infos

• Link zu Hope Microelectronics 
• Link zur Seite für den Sensor bei HopeRF
  

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.

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 maxinmal 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 Spoeicherbedarf.

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 anliegendeVersorgungspannung 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: LINK. 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 gemessenenen 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 erstmal mit dem weiter was ich habe. Ich kann den Datenlogger auch an eine vorhandene Solarzelle anschliessen, 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,3*VCC, HI=mehr als 0,7*VCC). Herumsuchen in Foren brachte keine weiteren Erkenntnisse. Selbst wenn der Sensor softwaremässig 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.

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)

 

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 verschiedeen Bussen liegen, mact dies aber nichts. Über meist vorhandene Adressleitungen A0,A1,A2,... kann die Basisadresse eines I2C Bausteins variiert werden. Dies ist bei den beiden Sonsoren 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 plaziert. 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 muß 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 kommet man so auf die Bits und die Bytes.

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