RTB2000 I2C Probleme mit Dekodierung

Ich würde gerne verstehen wo das Problem liegt, ist es das Signal, das RTB2000, oder?

Ich meine das liegt an dem von dir verwendeten Triggerzeitpunkt/art. Also dem Zeitpunkt ab dem dekodiert wird. Ich hatte das naemlich auch schonmal. Ich weiss aber die Loesung nicht mehr. Spiel mal ein bisschen mit den diversen Triggermoeglichkeiten rum.

Vanye

Wenn der Fenstergucker als RTB2k Experte es nicht weiß, sehr ich schwarz. Ist das 2.4 oder schon 3.0 Firmware?

Ist das 2.4 oder schon 3.0 Firmware?

Sollte man die hier eigentlich mal hochladen oder wird dann R&S boese? :)

Vanye

Danke für die Rückmeldungen. Ich habe so ziemlich alles ausprobiert was möglich ist, aber das Signal wird nicht richtig dekodiert. Nur wenn ich die Deskew-Einstellung ändere funktioniert es, abhängig von der Zeitbasis, und nur bei den analogen Kanälen.

Die Firmware ist v03.000, und ich habe sie auch im EEVblog zur Verfügung gestellt: https://www.eevblog.com/forum/testgear/new-killer-scope-a-true-game-changer-from-rs-rtb2002-rtb2004/msg5876902/#msg5876902

Peter

Dann geht's mit 2.4 auch nicht ? Ich vermute es ist eine Einstellung in den Bus Parametern. High/Low irgendwas mit der Triggerung. Muss ich heute Mal ausprobieren.

Ich meine mich gerade dunkel zu entsinnen das ich von StartID auf normal Flanke umgestiegen um das Problem zu beheben als ich es hatte. Vielleicht ist das auch wirklich noch ein Bug im Decoder den R&S gerne beheben wird falls man sie drauf hinweist....

Vanye

Mit Usb4all von sprut.de und einem PIC18F4550, kann ich das I2C-Protokoll von einer DS1307 RTC ohne Probleme dekodieren. Es liegt also wahrscheinlich an dem Signal vom Raspberry Pico. Vielleicht ist irgendein Parameter für das RTB2000 an der Grenze, und wird darum als Fehler angezeigt.

Peter

Ich habe mir ein I2C-Paket erstellt und in den Patterngenerator vom RTB2000 geladen. Wenn sich die SDA-Bits sehr nahe oder direkt an der fallenden Taktflanke ändern, dann werden die Daten nicht mehr richtig dekodiert bzw. in rot angezeigt. Darum hilft auch die Deskew-Einstellung von einem Kanal.

Peter

Ich habe mir ein I2C-Paket erstellt und in den Patterngenerator vom RTB2000 geladen.

Ah, ich hab mich schon immer gefragt wofuer ich den wohl brauchen koennte. :)

Wenn sich die SDA-Bits sehr nahe oder direkt an der fallenden Taktflanke ändern, dann werden die Daten nicht mehr richtig dekodiert bzw. in rot angezeigt.

Das ist natuerlich irgendwie unschoen. Wohlmoeglich sogar ein Bug. Schick denen das doch mal, vielleicht ist es dann in der 3.1 draussen. Man darf ja noch hoffen.

Vanye

Ich bin nicht auf dem laufenden, aber ist das nicht irgendwie verletzte Setup Time?

Das hab ich gerade auch schon ueberlegt, allerdings war ich zu faul jetzt genau die Datenblaetter zu studieren. :-D Aber denkbar ist es. Bei dem letztdem Controller den wo ich I2C implementiert habe, weiss garnicht mehr wo das war, da konnte man erstaunlich sensibel diese Timings fuer die Flanken einstellen und da haette man da was falsch machen koennen. Angesichts der Wetterlage ueberlassen wir also mal dem geneigten Leser dieses Threads das Studium der Datenblaetter. :)

Vanye

Nee das war doch Quatsch von mir, ist ja fallende Flanke, bin noch zu müde.

Eher Hold Time dann.

Im Handbuch hab ich nix gefunden über die Fehlerbedingungen beim Dekodieren, vielleicht fragt Peter mal im eevblog ob jemand sagen kann, welche Fehlerzustände es da gibt.

Im NXP I2C-bus specification and user manual steht unter 3.1.3 Data validity: "The data on the SDA line must be stable during the HIGH period of the clock. The HIGH or LOW state of the data line can only change when the clock signal on the SCL line is LOW (see Figure 4)."

https://www.nxp.com/docs/en/user-guide/UM10204.pdf

Wenn steigende oder fallende Flanken von SDA und SCL zusammenfallen ist diese Bedingung gerade nicht mehr erfüllt.

Bin zu spät, haber auch gerade nachgelesen. In der NXP I2C Spezifikation steht bei allen I2C Modes für "tHD;DAT data hold time [1]" Minimum 0 µs. Aber es gibt zwei Bemerkungen dazu :

[1] tHD;DAT is the data hold time that is measured from the falling edge of SCL, applies to data in transmission and the acknowledge.

[2] Ensure SCL drops below 0.3VDD on falling edge before SDA crosses into the indeterminate range of 0.3 VDD to 0.7 VDD.

Das RTB2000 macht es also wahrscheinlich richtig, könnte aber etwas laxer sein meiner Meinung nach.

Peter

Der Vollständigkeit halber noch der PureBasic-Code für das Erstellen des I2C-Pattern. Und das Skript für mein 'Messinstrumente-Skript'-Programm, um die Daten in das RTB2000 zu kopieren. Sowie die Datei mit den Daten.

Peter