Forum: Analoge Elektronik und Schaltungstechnik Rigol MSO5000: Fragen zur Protokollanalyse


von Hans K. (korn13)


Lesenswert?

Ein paar Fragen stellen sich mir bei der Protokolldekodierung mit einem 
Rigol MSO5074.

Ich lausche (u.a.) auf einem I2C mit knapp 1MHz Clock.
In der Einstellung 50MSa/s(25MPts) wird das nicht sinnvoll dekodiert;
in der Einstellung 100MSa/s(20MPts) klappts knapp;
erst in der Einstellung 200MSa/s(20MPts) wirds zuverlässig.

Handelt es sich, wie ich vermute, um 200-faches Oversampling, oder ist 
da noch ein Denkfehler dabei?
Warum ist ein so hohes Oversampling erforderlich - gibts sinnvollere 
Einstellungsmöglichkeiten des Geräts?
Wie sieht das bei MSOs anderer Hersteller aus?

Ein Saleae(-Klon) (mit PulseView) analysiert genau den selben I2C mit 
10MHz-Rate sehr zuverlässig.
(Klar: die quasi zeitsynchrone Anzeige von allem Möglichen parallel zum 
I2C ist auch sehr wertvoll)

Bitte um sachdienliche Hinweise / Erläuterungen!

Dank & Gruß
Hans

von Olaf (Gast)


Lesenswert?

Hat dein neues schickes Luxusoszi keine Moeglichkeit ein Bild
abzuspeichern? Ich meine auf die Idee koennte man ja mal kommen
wenn man ein Problem hat.

Reichen sollte eigentlich etwa 5fache OVersampling um halbwegs
zuverlaessig zu dekodieren. Mit 10x bist du garantiert auf
der sicheren Seite.
Wenn es dann nicht geht machst du entweder etwas falsch
oder dein Oszi hat einen Bug.

Olaf

von Leuchtobst (Gast)


Lesenswert?

> schickes Luxusoszi
Eher Ghettoblasterdesign.
Wie man vom TO liest auch mit Maengeln im Inhalt.

Es geht doch nichts ueber einen richtigen LA aber nicht
so ein Maeusekino,

von Hans K. (korn13)


Angehängte Dateien:

Lesenswert?

Bildergalerie:

r1-200 200MSa/s I2C wird gut erkannt;
r1-100 100MSa/s I2C wird teils Fehlern erkannt;
r1-050  50MSa/s I2C wird nur sporadisch erkannt, und wenn dann mit 
Fehlern

von Patrick L. (Firma: S-C-I DATA GbR) (pali64)


Lesenswert?

Hans K. schrieb:
> r1-200 200MSa/s I2C wird gut erkannt;
> r1-100 100MSa/s I2C wird teils Fehlern erkannt;
> r1-050  50MSa/s I2C wird nur sporadisch erkannt, und wenn dann mit
> Fehlern

Bei Meinem Rigol,und/Oder Voltkraft, kann ich die "Empfindlichkeit" bzw 
"Erkennungsschwelle" einstellen.

Aber tatsächlich, für Analyse und Kontrolle über Sauberkeit des Signals, 
messe ich I²C-Signale mit möglichst viel Oversampling, um das Timing 
genau zu bestimmen und etwaige "Glitches" zu sehen.

Ansonsten verwende ich da auch tatsächlich lieber den von Saleae oder 
den Dolch LAM(64 Chanels) oder mein Antiquiertes 256 Kanal Logicanalyzer 
von Gould....Und wenn es auch nur ist dass sie nicht einrosten :-)

Aber die MSO's sind wirklich, meiner Meinung nach nur als
Logicanalyzernotlösung zu gebrauchen, da ziehe ich den Saleae vor :-D

MfG

: Bearbeitet durch User
von Olaf (Gast)


Lesenswert?

> messe ich I²C-Signale mit möglichst viel Oversampling, um das Timing
> genau zu bestimmen und etwaige "Glitches" zu sehen.

Natuerlich. Als erstes schaut man sich immer mal die Analogsignal
an damit man weiss das die Physik auf dem Board stimmt.
Vermisse ich irgendwie in den Bildern der TOs.

> Aber die MSO's sind wirklich, meiner Meinung nach nur als
> Logicanalyzernotlösung zu gebrauchen,

Nicht von Rigol verallgmeinern. :)

Ich hab das mit Hameg/R&S immer gerne genutzt und war damit zufrieden.
Einfach auf die Adresse seines Problembausteins triggern
und dann schauen was abgeht...

Olaf

von Bernd (Gast)


Lesenswert?

Hans K. schrieb:
> Bildergalerie
Ich kenne das Rigol nicht, aber bei anderen Herstellern, lässt sich die 
Samplerate für die Digital- und die Analogkanäle separat einstellen.
Ist das hier vielleicht auch so?

von Hans K. (korn13)


Lesenswert?

nicht wirklich:

Handbuch, Abschnitt "LA Sample Rate":
"LA sample rate is displayed under the LA SampleRate menu. To indirectly
modify the LA sample rate, rotate the Horizontal SCALE knob to adjust
the horizontal time base or modify the memory depth"

und Abschnitt "LA Memory Depth":
"The LA memory depth will change with the memory depth of the analog 
channel, and cannot be set separately. The maximum LA memory depth is
25 Mpts"

Es kann also im Prinzip nur die analoge (== gemeinsame) horizontal time 
base (== samples / sek ) eingestellt werden.

Die Verkleinerung der Memory Depth bringt in der Wirkung meiner 
bisherigen Erfahrung nach nur einen schnelleren Refresh des Bildschirms 
(und natürlich weniger Samples zum analysieren…).

von Ernest (Gast)


Lesenswert?

Nun hab ich mir gerade auch so ein MSO gekauft und bin dabei, mich durch 
die endlos lange Anleitung zu fressen. Was das Ding wirklich taugt - 
weiß ich noch nicht. Zu dem hier angesprochenen Messfall fallen mir aber 
4 Punkte ein:

1. Die Signale auf der Signalleitung sind schon sehr kurz im Verhältnis 
zu den Signalen auf der Taktleitung. Das spricht schon dafür, dass man 
da mit hoher Frequenz abtasten muß.

2. Laut Anleitung kann man I2C Busanalyse auch mit den Analogeingängen 
machen. Dann kann man oberen und unteren Logikschwellwert seperat 
einstellen (und sich auch anschauen, wie der Signalverlauf aussieht, ob 
da z.B. Kapazitäten in der Schaltung die Flankensteilheit 
beeinträchtigen).

3. Wenn man die Digitaleingänge zur Busanalyse nimmt, kann man auch dort 
einen Schwellwert auswählen - der I2C Bus wird ja mit verschiedenen 
Betriebsspannungen eingesetzt. Angenommen der gewählte Schwellwert passt 
für TTL und der Bus läuft mit einer Spannung von nur 1,xx Volt - das 
passt dann nicht.

4. Laut Anleitung kann man auch für die Digitaleingänge eine 
Selbstkalibrierung durchführen.

Wäre interessant zu wissen, ob einer der obigen Punkte das Problem 
abschwächt oder behebt.

von Patrick L. (Firma: S-C-I DATA GbR) (pali64)


Lesenswert?

Ernest schrieb:
> 2. Laut Anleitung kann man I2C Busanalyse auch mit den Analogeingängen
> machen.

Was ich sowieso empfehle, denn bei meinem [Voltcraft DSO1254F] habe ich 
nur 4 Analogeingänge, und grad bei I²C-BUS ist es Wichtig die 
Flankensteilheit zu sehen was bei den Digitalen nicht geht.

Wie gesagt (mal abgesehen vom berechtigten Einwand von:
Olaf schrieb:
> Nicht von Rigol verallgmeinern. :)

Sind bei den günstigeren die Logicanalyzer Teile, meiner Meinung nach,
nur ein Behelf und eben kein vollwertiger Logicanalyzer.

Soll nicht heißen das die schlecht sind, aber bei den Meisten fehlt 
halt eine echte Activprobe wie bei z.B. meinem DOLCH DLI bei welchem 
ich den Digital-Flankenpegel von 0.5V ~ 24V Gruppenweise festlegen kann.

Auch verfälschen die Passivproben, das Signal, da die Leitungen oft 
etwas Lang ausfallen und damit Induktive und Kapazitive Lasten 
darstellen.

Deshalb die Bezeichnung Behelf. Anders ist es bei den MSO mit 
intelligenten aktiven Proben wie HP und Tektronix oder gar LeCroy & Co.

Nur bei meinem Rigol z.B. vermisse ich die Activprobe und sehe oft bei 
Schnellen oder halt bei Leistungsschwachen Digitalsignalen, wie eben 
grad bspw I²C-Bus ist, oft Messfehler durch Signalbeeinträchtigungen, 
was zum beispiel, der Saleae durch seine kurzen Signalleitungen, kaum 
macht.
;-)

: Bearbeitet durch User
von Olaf (Gast)


Lesenswert?

> halt eine echte Activprobe wie bei z.B. meinem DOLCH DLI bei welchem
> ich den Digital-Flankenpegel von 0.5V ~ 24V Gruppenweise festlegen kann.

Ich glaube das war fruher mal ein Argument, aber heute laeuft doch
99% in 3V3, und selbst wenn nicht, bei mir kann ich dann auch eine 
zweite
Probe anschliessen und da vermutlich, hab es noch nie gebraucht, eine
zweite Schwelle einstellen.

> Auch verfälschen die Passivproben, das Signal, da die Leitungen oft
> etwas Lang ausfallen und damit Induktive und Kapazitive Lasten
> darstellen.

Sowas gibt es doch gar nicht. Du hast doch immer den Comparator mit 
seinen Logicschwellen in der Probe der dann die Leitungen zum Oszi 
treibt.

> Nur bei meinem Rigol z.B. vermisse ich die Activprobe und sehe oft bei
> Schnellen oder halt bei Leistungsschwachen Digitalsignalen, wie eben

Wenn Rigol wirklich nur ein Kabel hat und sonst nix dann koennte man das 
wirklich im Klo runter spuelen. Das kann ich kaum glauben.

> grad bspw I²C-Bus ist, oft Messfehler durch Signalbeeinträchtigungen,
> was zum beispiel,

Und zwar aus genau diesem Grund.

> der Saleae durch seine kurzen Signalleitungen, kaum
> macht.

Bei Hameg/RS haben die Probes 100k Ri, dann 10cm Leitung und dann kommt 
die Signalaufbereitung in der Probe, bevor es weiter zum Oszi geht.
Das wird doch bei Rigol nicht anders sein weil man sonst niemals die
Daten ueber die Leitung bekommt, erst recht nicht wenn man halbwegs
hochohmig an den Bus gehen will und das will man auf jedenfall.

Olaf

von Ernest (Gast)


Lesenswert?

Soweit ich das verstehe, gibt es bei den Logikkanälen des Rigol nur 
einen Schwellenwert - dadrunter ist 0, drüber ist 1. Ermittelt wird das 
offenbar mit einem Komparator je Kanal. Das ist natürlich anfällig für 
Glitsches, Prellen, Einstreuungen ... Einstellen kann man den 
Schwellenwert wohl schon in Abhängigkeit von der Logikfamilie (und damit 
dem Vcc) die verwendet wird.

Per Definition für Logikfamilien gibt es einen unteren Schwellwert, 
unterhalb dessen der Zustand 0 ist und einen oberen Schwellert, oberhalb 
von dem der Zustand 1 ist. Dazwischen ist per Definition unbestimmt. 
Häufig sind dann Eingänge als Schmidt-Trigger gestaltet, die die 
unbestimmten Zustände wegfiltern. Das ist nach dem, was ich jetzt weiß, 
bei den Rigol Logikkanälen nicht implementiert, damit sind die 
störanfälliger als bei einer korrekten Implementierung der Definition 
für Logikfamilen.

Ob das bei anderen Geräten besser ist - wahrscheinlich schon je nach 
dem, was für ein Gerät man sich kauft und wieviel Geld man auf den Tisch 
legt.

Workaround drüfte beim Rigol tatsächlich die Verwendung der Analogkanäle 
mit den dort einstellbaren unterem und oberem Schwellwert sein.

Soweit mein Verständnis bisher - ich lerne ja noch.

von Hans K. (korn13)


Lesenswert?

Ernest schrieb:
> Soweit ich das verstehe, gibt es bei den Logikkanälen des Rigol nur
> einen Schwellenwert - dadrunter ist 0, drüber ist 1.
So ist es.

> Einstellen kann man den
> Schwellenwert wohl schon in Abhängigkeit von der Logikfamilie (und damit
> dem Vcc) die verwendet wird.
So ist es.
Separat einstellbar für je 8 Pins.
(semi-active-probe?)
Änderungen in den Einstellungen funktionieren, befriedigen aber meine 
Erwartungshaltung nicht vollständig.

> Workaround drüfte beim Rigol tatsächlich die Verwendung der Analogkanäle
> mit den dort einstellbaren unterem und oberem Schwellwert sein.
Jaaaaaaa…
Ich will aber parallel noch auf mehr Kommunikationskanälen mitlesen - 
und da reichen die Analogkanäle nimmer.
Hab mir die Kommunikationskanäle zuerst analog betrachtet, war mit 
Flanken, Überschwingen, Jitter usw. soweit zufrieden, und sie dann auf 
das digitale Probe umgepinnt (ich weiss, da gelten dann andere 
Kapazitäten, Eingangswiderstände usw.; habs auch mit angeschlossenem 
Digitalprobe parallel nochmal analog angeschaut).

Mein bisheriger Workaround(1) ist mit deutlich mehr Samples/s zu 
arbeiten (mit dem Nachteil deutlich geringerer Speichertiefe).
Ein anderer Workaround(2) ist mit Saleae(-Klon) und PulseView 
einzusetzen (mit dem Nachteil dass ich keine Zeitzusammenhänge mehr 
sehe).

Meine Verwunderung ist eben, dass Saleae den <1MHz I²C mit 10MHz 
Samplerate gut decoded, Rigol aber >100MHz dafür braucht.

Mein ursprüngliches Anliegen war eben festzustellen obs noch andere 
Lösungen mit dem Rigol alleine gibt.

Hilfreich ist beim Rigol ein spezifischeres Triggern (auf Inhalte der 
Datenpakete), damit ich das Mem nicht mit Trivialem verstopfe, bin da 
noch am evaluieren.

Für weitere Hinweise offen!
Hans

von Ernest (Gast)


Lesenswert?

Einige 1/10 Volt Hysterese an den Eingängen sollten die Anfälligkeit für 
Jitter / Störungen reduzieren. Dafür müsste wohl etwas vorgeschaltet 
werden. Ob Dein Problem, dass Du aktuell nur mit hoher Abtastrate lösen 
kannst, allerdings durch Jitter verursacht wird oder ob sich da in den 
Tiefen des Gerätes noch andere Besonderheiten finden, die beitragen ... 
Viel Erfolg auf jeden Fall. Wenn Du eine Lösung hast bitte berichten - 
ich hab mir ja jetzt auch so ein Teil zugelegt und mich interessiert 
natürlich schon, was damit geht und wo es in der Praxis klemmt.

von No Y. (noy)


Lesenswert?

Sofern er die original Rigol Probes hat ist da ordentlich was verbaut 
inkl. einstellbarer ref pegel :

https://www.eevblog.com/forum/testgear/rpl1116-active-logic-probe-pod-for-1000z-series-teardown/

Wenn er da direkt Kabel ansteckt oder diese DIY billig Lösung gekauft 
hat bei eBay oder aus dem Forum sieht es entsprechend anders aus..

: Bearbeitet durch User
von Patrick L. (Firma: S-C-I DATA GbR) (pali64)


Lesenswert?

No Y. schrieb:
> Sofern er die original Rigol Probes hat ist da ordentlich was verbaut
> inkl. einstellbarer ref pegel :

Tja original Ja,
Bloß die Digital Probe RPL2316 hat außer Widerstände nicht viel 
Verbaut....

Von Activ kann da nicht die Rede sein.
https://www.eevblog.com/forum/testgear/looking-for-rigol-mso-2072a-digital-probe-rpl2316/msg902878/#msg902878

Deshalb schrieb ich ja auch:

Patrick L. schrieb:
> Sind bei den günstigeren die Logicanalyzer Teile, meiner Meinung nach,
> nur ein Behelf und eben kein vollwertiger Logicanalyzer.
>
> Soll nicht heißen das die schlecht sind, aber bei den Meisten fehlt
> halt eine echte Activprobe wie bei z.B. meinem DOLCH DLI bei welchem
> ich den Digital-Flankenpegel von 0.5V ~ 24V Gruppenweise festlegen kann.
>
> Auch verfälschen die Passivproben, das Signal, da die Leitungen oft
> etwas Lang ausfallen und damit Induktive und Kapazitive Lasten
> darstellen.

73

von Carsten S. (dg3ycs)


Lesenswert?

Hi,

Patrick L. schrieb:
> No Y. schrieb:
>> Sofern er die original Rigol Probes hat ist da ordentlich was verbaut
>> inkl. einstellbarer ref pegel :
>
> Tja original Ja,
> Bloß die Digital Probe RPL2316 hat außer Widerstände nicht viel
> Verbaut....

Das es bei der RPL2316 (Für irgendwelche "relativ" alten 2000er 
Rigol...) so ist kann sein. Nur hier geht es überhaupt nicht um diese 
Geräte.

Der Kopf für die MSO5000 um die es hier geht heisst PLA2216 und der ist 
sehr wohl "Aktiv" wie schon aus dem EEVBlog-Forumslink zu ersehen.
Die Elektronik ist in dem DUT-Seitigen Ende des Flachbandkabels 
untergebracht. Das wird auch gut warm bei längerem Betrieb.
Da drinn sitzen einige recht schnelle (und auch nicht so ganz billige) 
TI Komparatoren die für die Entkopplung,Verstärkung und Umwandlang in 
ein Differentielles Signal bei jedem der 16 Digitaleingänge zuständig 
sind.
(Reine Bauteilkosten für den Nachbau der Probe-Elektronik sind schon 
fast 100Euro!) Ohne Grabberspitzen etc.
Das Setup sieht also so aus:
Messpunkt am DUT -> 20cm Litze (Einzelader) mit Federhaken oder direkt 
gesteckt -> Aktiveprobe -> als Diff-Signal übers Flachbandkabel
-> und weiter ins Skope

Auch der Tastkopf für die schon älteren MSO aus der DS1000z Serie 
(Geschwister des bekannten DS1054z mit MSO Eingang halt) sind wohl 
bereits aktiv...

Olaf schrieb:
> Bei Hameg/RS haben die Probes 100k Ri, dann 10cm Leitung und dann kommt
> die Signalaufbereitung in der Probe, bevor es weiter zum Oszi geht.
> Das wird doch bei Rigol nicht anders sein weil man sonst niemals die
> Daten ueber die Leitung bekommt, erst recht nicht wenn man halbwegs
> hochohmig an den Bus gehen will und das will man auf jedenfall.

Genau so ist es!
Auch die Daten sind ähnlich, bis halt auf 20cm statt 10cm für die dünne 
Einzelleitung vom DUT ins Probe.
Eingangswert für den Aktivtastkopf ist 100KOhm/8pF!

Gleich kommen noch ein paar Tests & Screenshots die ich Versuchsweise 
gemacht habe...

Gruß
Carsten

: Bearbeitet durch User
von Olaf (Gast)


Lesenswert?

> Auch die Daten sind ähnlich, bis halt auf 20cm statt 10cm für die dünne
> Einzelleitung vom DUT ins Probe.

Hameg/RS hat uebrigens in den kleinen kaebelchen die man in deren Probes
steckt einen Spannungsteiler drin. (82k/22k, wenn ich es jetzt richtig 
im Kopf habe) Wenn man das beachtet dann kann man sich
eigene Adapter bauen die anstatt der Kabel an die Probes steckt um so
einen direkten und einfachen Zugriff auf seinen Lieblingsbus zu haben. 
Man muss den Spannungsteiler im uebrigen mit 1-2pF kompensieren wenn er 
linear/brauchbar sein soll.
Das zeigt vielleicht wie empfindlich solche Probes sind.

Sollte dann ja bei Rigol aehnlich funktionieren.

Olaf

von Patrick L. (Firma: S-C-I DATA GbR) (pali64)


Lesenswert?

Nicht des do trotz, denke ich weis jetzt wo das Problem her kommt.
Bei den LA's die ich einsetze, kann ich das Signal,
zwischen Latch und Sample umstellen,

Wen ich auf LATCH schalte, brauche ich auch höhere Sampleraten dass ich 
bei einem schlechten I²C-Bus-Signal, eine saubere Darstellung der Daten 
bekomme.

Beim RIGOL, habe ich aber auf die schnelle, keine Funktion gefunden, wo 
ich dies umstellen könnte.

Deine 3 Bilder zeigen ja klar dass da wohl ein Glitch gelatcht wurde 
und so das Ergebnis logischerweise falsch ist.

von Ernest (Gast)


Lesenswert?

Bin ja auch interessiert an dem Thema und schaue deshalb noch nach 
passender Info. Auf diese zwei Punkte bin ich noch gestossen (beide bei 
eevblog):
-In dem Trööt über das PLA2216 werden für die Hysterese Werte von z.B. 
15mV oder 25 mV je nach Komparator IC erwähnt. Das ist gegenüber 
definiertem oberem / unterem Logiklevel wahrlich nicht viel, wenn es um 
das Unterdrücken von Störungen / Glitches geht.
-In einem anderen Trööt ist die Rede von einem High-Res Modus, der 
vermutlich durch Auswertung von 16 Samples erreicht wird. Ob der - wenn 
der aktiviert ist - auch den LogikAnalyzer Teil zum Auswerten von 16 
Samples zwingt, dazu hab ich da nichts gesehen. So eine Auswertung von 
16 Samples um einen Wert zu bekommen wäre aber schon mal ein Grund 
(nicht alleiniger), warum hohe Taktfrequenzen helfen. Wenn solch ein 
Modus denn aktiviert sein sollte.

von Ernest (Gast)


Lesenswert?

Nachtrag noch von Wikipedia für den I2C: Der High-Pegel soll mindestens 
0,7 × VDD betragen, und der Low-Pegel soll bei höchstens 0,3 × VDD 
liegen. Das ist auch bei niedrigen VDD um mehr als eine Größenordnung 
mehr, als eine Hysterese von 15 oder 20 mV.

von Carsten S. (dg3ycs)


Angehängte Dateien:

Lesenswert?

Da ich selber ebenfalls ein Rigol MSO5000 habe und zudem seit ein paar 
Tagen auch im Besitz des dazugehörigen Digital-Probe in so gut wie 
neuwertigen Zustand bin (gekauft hier im Forum vom Nutzer Rolf D. - 
Beitrag "Re: Rigol MSO5000" ) habe ich jetzt 
auch mal versucht die Ergebnisse des TO Nachzuvollziehen.

Vorab:
Grundsätzlich funktioniert die Auswertung bei mir gut und das was man 
typischerweise so mit einem MSO macht lässt sich auch gut damit 
erledigen.
(Ein MSO hat ja dann doch einen etwas anderen Einsatzzweck als ein 
Stand-alone Logikanalyzer – ist wie der Unterschied zwischen einem 
Druckluft-Schlagschrauber und einem Drehmomentschlüssel in der KFZ 
Werkstatt. Im Prinzip lässt sich sehr sehr vieles mit beiden Werkzeugen 
irgendwie erledigen weil sich die Möglichkeiten weit überlappen. Aber 
beides hat eigentlich seinen ganz speziellen Einsatzzweck)

Die Beobachtung das erst bei relativ hohen Samplefrequenzen eine 
fehlerfreie Dekodierung erfolgt kann ich aber bestätigen.
Wobei einiges dabei auch nicht ganz schlüssig ist.

So wechselt die angezeigte Samplefrequenz für die Digitalkanäle deutlich 
wenn ich analogen Kanäle ein- bzw. ausschalte. Merkwürdigerweise ändert 
sich aber die Qualität der Dekodierung überhaupt nicht  in dem Moment! 
Die wird weder schlechter noch besser
(Siehe Bilder: ANALOG_AN  vs. ANALOG_AUS
Ausser der (de)aktivierung der zwei Analogkanäle wurde hier nichts aktiv 
verändert!)

Vielleicht liegt da auch einfach nur ein BUG in der Anzeige der 
Samplefrequenz vor (Die sowieso tief in einem Menü versteckt ist und da 
nicht direkt einstellbar für die Arbeit nicht wirklich relevant)

Wie der TO habe ich je nach Samplefrequenz drei Zustände:
1. Dekodierung erfolgt fehlerhaft bzw. gar nicht oder nur im Glücksfall.
(Samplerate < 10* fCLK)

2. Dekodierung von Adresse, Datenrichtung und Payload wird zuverlässig 
ausgewertet. Das ACK/NAK wird aber teilweise nicht korrekt erkannt (aber 
auch rot auf dem Schirm markiert!)
( 10* fCLK <Samplerate < 50* fCLK)

3. Alles Passt
(50* fCLK <= Samplerate)


Kurz noch zu den Möglichkeiten des Skopes:

Samplerate:
Die Samplerate beim Skope ist, wie schon vorher hier im Thread 
geschrieben wurde, nicht direkt einstellbar. Sie ergibt sich immer aus 
der eingestellten Zeitablenkung in Verbindung mit der eingestellten 
Speichertiefe. (Die Samplefrequenz ist so, das immer ein voller 
UNGEZOOMTER Bildschirminhalt die eingestellte Speichertiefe 
vollschreibt)

Schwellwerte H/L:
Im Analogmodus lässt sich für jeden Kanal (SDA & SCL etc.) jeweils 
einzeln EIN Schwellwert im Decoder-Menü  einstellen.  Oberhalb des 
Schwellwertes wird HIGH gewertet, unterhalb LOW. Unterschiedliche 
Schwellwerte H/L gibt es nicht (Also keine Definition eines „verbotenen 
Bereiches“)

Im Digitalmodus gibt es zwei Blöcke a 8 Kanäle.
Pro Block lässt sich ein Schwellwert einstellen. Hier erfolgt die 
Einstellung des Schwellwerts allerdings im LA Menü. Es lassen sich Werte 
von 0 bis 15V als Schaltschwelle einstellen.
(Maximale Eingansspannung Digital-Tastkopf sind 40V)

Etwas „Strange“ ist das für die Analogkanäle die Schwellwerte im 
Dekodermenü festgelegt werden, für die Digitalkanäle aber im LA-Menü. 
Wenn man sich die Technik dahinter ansieht ist dann aber logisch, da die 
digitalen Schaltschwellen erzeugt werden in dem vom Skope die 
entsprechende Vergleichsspannung für die Komparatoren im Aktivtastkopf 
bereitgestellt wird. Zum Skope kommt dann nur noch das aufbereitete 
High-LOW Signal das so verwendet werden muss wie es kommt.

Für die analogen Kanäle aber steht der Analogwert voll zur Verfügung und 
der Zustand wird alleine in der SW bestimmt. Auch kann ein Kanal sowohl 
in Dekoder 1 und Dekoder2 gleichzeitig verwendet werden und dabei in den 
Dekodern abweichend eingestellte Schaltschwellen nutzen.
Daher macht hier die Einstellung im Dekoder selbst sinn.

Dekoder:
Das Gerät verfügt über VIER Protokolldekoder die individuell 
parametriert werden(Protokoll, Darstellung etc.) und einzeln oder 
gleichzeitig aktiv sein können. Pro Dekoder können die Signale der 
Analog- und Digitalkanäle beliebig gemischt werden.
Ein Kanal  kann auch mehrfach bei verschiedenen Dekodern verwendet 
werden.

Neben der Darstellung als Extrazeile unter den Signalen lässt sich auch 
eine Tabelle mit den dekodierten Telegrammen einblenden.


Zu den Bildern/Test
Etwas schwierig gestaltete sich dabei der 1MHz I2C Bus, da der ja nicht 
so ganz typisch ist. Glücklicherweise habe ich noch eine alte Bastellei 
mit einem PIC18F14k22 Und 24LC02 drauf gefunden, die ich mit einem I2C 
Minimalprogramm etwas zweckentfremden konnte.

Ganz 1MHz habe ich mit dem Setup nicht geschafft, aber 800kHz läuft 
stabil.
Als Pull-UP an SDA und SCL sind 1,8k Widerstände verbaut, die für dieses 
Setup @800kHz vielleicht schon eher groß sind. Ich habe für die Tests 
jeweils einen Digital- und einen Analogkanal parallel an die beiden 
Leitungen angeschlossen, so das man das erfasste LA-Signal und den 
tatsächlichen Spannungsverlauf auch gleichzeitig sehen kann.
(Bild: All_Channel)

Wie man am Oszillogramm der Analogsignale auf SDA und SCL sieht ist 
diese Frequenz schon nicht mehr ganz so optimal da die Flankenwechsel 
auf den beiden Leitungen schon oft eng beieinander liegen und sich 
manchmal schon zeitlich etwas überlagern.
Das könnte zumindest eine Fehlauswertung deutlich begünstigen!
(Siehe Bilder: I2C_roh1 & I2C_roh2)

Zu den Messergebnissen bei verschiedenen Einstellungen im Anschluss
(wegen Bilderzahl/Übersichtlichkeit)

von Carsten S. (dg3ycs)


Angehängte Dateien:

Lesenswert?

Hier jetzt noch die konkreten Testergebnisse bei verschiedenen 
Sampleraten sowohl mit wie auch ohne gleichzeitig aktivierten 
Analogkanälen

BILDER aus vorherigem Beitrag:
Analog_AUS:
angezeigte Digital-Samplerate 12,5 MSa/s, keine Analogkanäle
→ Dekodierung Adresse & Payload Korrekt – teilweise ACK Erkennung 
fehlerhaft

Analog_AN:
angezeigte Digital-Samplerate 50 MSa/s, Analogkanäle aktiviert, sonst 
identisch zu Analog_AUS
→ Dekodierung Adresse & Payload Korrekt – teilweise ACK Erkennung 
fehlerhaft, Fehlerrate vergleichbar Analog an trotz scheinbar deutlich 
höherer Digital-Samplerate

BILDER aus diesem Beitrag :
Analog_AUS25:
angezeigte Digital-Samplerate 25 MSa/s, keine Analogkanäle
→ Dekodierung vollständig korrekt!

Analog_AN50:
angezeigte Digital-Samplerate 50 MSa/s, Analogkanäle aktiviert
→ Dekodierung vollständig korrekt!

Ansicht1:
Informativ-Darstellung des Kurvenverlaufs &
Datentelegramms in normaler Bildschirmeinstellung
(Ohne Analogkanäle)

Ansicht2:
Informativ-Darstellung des Kurvenverlaufs &
Datentelegramms im Zoom-Modus
(Ohne Analogkanäle)

All_Channel:
Informativ-Darstellung des Kurvenverlaufs &
Datentelegramms im Zoom-Modus mit Analogkanälen


Was ich aus diesen Bildern (und noch ein paar Tests mehr) entnehme ist, 
dass die Ergebnisse/Zuverlässigkeit der Dekodierung für I2C Signale mit 
diesen An-und Abfallzeiten durchaus zu den angezeigten Sampleraten passt 
SO LANGE DIE ANALOGKANÄLE DEAKTIVIERT SIND.

Werden die Analogkanäle aktiviert, dann sind die Ergebnisse aber FÜR DIE 
IM MENÜ ANGEZEIGTEN Sampleraten unerklärbar schlecht.
Das sich die Anzeige der Sampleraten überhaupt (Deutlich) nur durch ein 
und ausschalten der Analogkanäle ändert, dies aber weder die Qualität 
der Darstellung noch die zuverlässigkeit der Dekodierung beeinflusst ist 
dabei auffällig. Das passt weiterhin zu dem Wert der ohne Analogkanäle 
angezeigt werden würde.
Rein vom Bauchgefühl würde ich daher darauf tippen das hier vielleicht 
einfach ein BUG bei der Anzeige der Samplefrequenz vorliegt?

Evtl. kann es zusätzlich gut sein das bei der Dekodierung 
Programmiertechnisch noch nicht das Optimum herausgeholt ist. Für die 
allermeisten Anwendungen funktioniert es mit dem zwischenzeitlich 
erreichten Stand vollkommen hinreichend. Aber es könnte vielleicht noch 
ein wenig mehr herausgeholt werden...

Generell muss man aber nochmals betonen das die Frage, ob hier mit 10x 
oder 20x oder 50x der CLK Frequenz gesampelt werden muss damit die 
Anzeige korrekt ist, für die meisten Anwendungen eher rein akademisch 
ist.

Die Samplefrequenz kann nicht eingestellt werden, die rein Informative 
Anzeige sitzt in einer unteren Menüebene (die man beim Arbeiten nicht 
offen haben will weil das Platz weg nimmt) Man stellt sich die Ablenkung 
so ein wie man es für die Übersicht braucht und dann ergeben sich daraus 
die Werte.

Relevant ist das wirklich nur in dem Fall wo man sehr lange 
Aufzeichnungen der Daten mit dem Gerät machen möchte. Aktuell bekomme 
ich, bei diesem nicht optimalen Eingangssignal mit sich überschneidenden 
Flanken, für das ~1MHz I2C Signal eine Aufzeichnungslänge von 1s mit 
korrektem Telegramminhalt hin wenn ich ACK Fehler in Kauf nehme oder 
0,5s wo wirklich alles perfekt ausgewertet ist.
Das ist für diese Anwendung schon eine verdammt lange Zeit. Insbesondere 
für die Darstellung auf einem MSO Bildschirm. Zumal die Tabellarische 
Ansicht nur 10 Zeilen hat…

Heute sind wir durch die direkt an den PC übertragenen LA wie Saleae 
hinsichtlich der Aufzeichnungslänge alle etwas verwöhnt. Das ist aber 
die Ausnahme. Normal war für lange Zeit und ist es auch heute noch das 
man mit dem LA nur halbwegs kurze Aufzeichnungen machen konnte (aber 
länger als mit einem Skope), aber über viele Sekunden oder gar Minuten… 
das hat man mit anderen Geräten gemacht die dann wirklich nur noch die 
Inhalte Dekodiert und mit Zeitstempel gespeichert haben.

Und LA die auch schnellere Signale als ~10MHz CLK deutlich länger 
aufzeichnen können als dieses Skope kosten immer noch mehr als das ganze 
Skope!
Generell ist ein MSO eine super Ergänzung zu einem LA, manches geht auch 
nur mit einem MSO, aber sehr viele Dinge gehen mit einem Dedizierten LA 
einfach besser und Bequemer. Da darf man sich nichts vormachen. Wenn ich 
lange Aufzeichnungen machen will – die ich ja auch noch auswerten muss- 
dann ist eine genau darauf ausgelegte PC Umgebung einfach das Mittel der 
Wahl.

In den meisten Fällen, vermutlich >>95%  (egal ob beruflich oder Privat) 
wo ich ein Skope als MSO mit Protokollanalyse eingesetzt habe (sowohl 
echte MSO wie auch Vierkanaler mit Dekoderoption) haben mich da gerade 
mal 1-5 Telegramme nach dem Triggerereignis interessiert.

Für Fehler auf der Softwareebene, wo man dann auch mal die langen 
Aufzeichnungen braucht weil man nicht auf ein bestimmtes Ereignis 
triggern kann, da nimmt man den LA.

Das verbietet aber natürlich trotzdem nicht sich über gewisse 
Eigenschaften zu wundern oder auch mal darüber zu 
diskutieren/spekulieren warum ein Gerät tatsächlich oder auch nur 
scheinbar hinter seinen technischen Möglichkeiten zurückbleibt ;-)

Das sollte nur die Bedeutung dieses Verhaltens für die tägliche Arbeit 
etwas ins richtige Licht rücken!

Gruß
Carsten

von Olaf (Gast)


Lesenswert?

> Rein vom Bauchgefühl würde ich daher darauf tippen das hier vielleicht
> einfach ein BUG bei der Anzeige der Samplefrequenz vorliegt?

Ich wuerde ja eher denken das der Kiste einfach die Rechenzeit ausgeht.
Mach das ganze doch  mal bei 100khz I2C und ebenfalls veringerter 
Samplefrequenz am Oszi. Wenn der Status der Analogkanaele dann immer 
noch eingeht wohl ein Bug, wenn dann nicht dann kann die Hardware 
einfach nicht mehr.

> Heute sind wir durch die direkt an den PC übertragenen LA wie Saleae
> hinsichtlich der Aufzeichnungslänge alle etwas verwöhnt. Das ist aber
> die Ausnahme.

Naja, sowohl bei meinem alten Hameg wie auch beim neuen RTB bin ich 
eigentlich der Meinung das die Aufzeichnungslaenge mehr als ausreichend 
ist. Die Probleme sehe ich eher in der Auswertung grosser Datenmengen. 
Da kann dann eine PC-Software von Vorteil sein. Allerdings sehe ich auch 
wie der RTB gegen meinen altem HMO da Vorteile durch grosses LCD und 
Touch-LCD gewinnt.

Aber wie du schon sagst, man braucht natuerlich immer beides. :)

Olaf

von Patrick L. (Firma: S-C-I DATA GbR) (pali64)


Lesenswert?

Olaf schrieb:
> Aber wie du schon sagst, man braucht natuerlich immer beides. :)

Jup, ganz eurer Meinung Der Schmid hat auch mehr als ein Hammer ;-)

Wenn die Dinger nicht Praktisch wären hätte ich nicht so viele MSO's in 
der Werkstadt ;-)

Fakt ist einfach wie schon erwähnt und richtig Erkannt, das Richtige 
Werkzeug für die richtige Arbeit, und dann passt das.

Leider bin ich noch Unterwegs und kann deshalb keine Tests diesbezüglich 
machen.

Aber das mit dem Sample/Latch habe ich nirgends im Handbuch enteckt.
Auch das Mit der:
Olaf schrieb:
> Ich wuerde ja eher denken das der Kiste einfach die Rechenzeit ausgeht.
> Mach das ganze doch  mal bei 100khz I2C und ebenfalls veringerter
> Samplefrequenz am Oszi. Wenn der Status der Analogkanaele dann immer
> noch eingeht wohl ein Bug, wenn dann nicht dann kann die Hardware
> einfach nicht mehr.

Scheint teilweise plausibel, nur auch das digitale Diagramm(Signal) 
zeigt den Fehler, also Auswertung(Decodierung) richtig Sampling falsch.

Dies wäre dann aber Fatal , wen das aus dem Grund, Bug oder 
Rechenleistung passieren würde! Ich denke immer noch, das das ev. mit 
dem Latch/Sample zusammenhängt, den selbst mein DLI(der ein Kleinwagen 
kostete) zeigt bei Latch natürlich auch ein Glitch an und würde dann 
die Auswertung fehlerhaft(Ja eigentlich richtig) machen.

Ich habe aber auch keine Hinweise gefunden, ob das Rigol die 
Logicsignale im Latch- oder Sample-Betrieb aufzeichnet.

von Carsten S. (dg3ycs)


Angehängte Dateien:

Lesenswert?

Hi,

Olaf schrieb:
>> Rein vom Bauchgefühl würde ich daher darauf tippen das hier vielleicht
>> einfach ein BUG bei der Anzeige der Samplefrequenz vorliegt?
>
> Ich wuerde ja eher denken das der Kiste einfach die Rechenzeit ausgeht.
> Mach das ganze doch  mal bei 100khz I2C und ebenfalls veringerter
> Samplefrequenz am Oszi. Wenn der Status der Analogkanaele dann immer
> noch eingeht wohl ein Bug, wenn dann nicht dann kann die Hardware
> einfach nicht mehr

Es ist ja so, dass der Status der Analogkanäle bereits jetzt überhaupt 
keine Änderung verursacht. Mit Ausnahme der angezeigten MSa/s Zahl im 
Infofeld des Untermenüs...
Bei einem Problem mit der Rechenleistung wäre ja das genau gegenteilige 
Verhalten zu erwarten. Also das sich die Auswertungsqualität dann beim 
zu-/wegschalten verändert.

Habe das ganze jetzt aber auch noch mal mit ~200kHz I2C Clk. getestet.
Genau dasselbe Verhalten wie bei der höheren Clockfrequenz.

Ergänzend habe ich jetzt auch mal die Kurven der Parallelgeschalteten 
Digital- und Analogkanäle skaliert genau übereinander gelegt. Da sieht 
man gut wie die Schaltpunkte liegen.

Screenshots:
Analog_200AUS:
200kHz-I2C, angezeigte Digital-Samplerate 6,25 MSa/s, keine Analogkanäle
→ Dekodierung Adresse & Payload Korrekt – teilweise ACK Erkennung
fehlerhaft

Analog_200AN:
200kHz-I2C, angezeigte Digital-Samplerate 25 MSa/s, Analogkanäle 
aktiviert, sonst identisch zu Analog_200AUS
→ Dekodierung Adresse & Payload Korrekt – teilweise ACK Erkennung
fehlerhaft, Fehlerrate vergleichbar Analog_200AUS trotz scheinbar 
deutlich
höherer Digital-Samplerate

Comb800kHz:
Übereinandergelegte Kurvenverläufe für die Digital- & Analogkanäle
800kHz I2C

Comb200kHz:
Übereinandergelegte Kurvenverläufe für die Digital- & Analogkanäle
200kHz I2C

Chan_Uebersicht:
Informativ- Darstellung des Kurvenverlaufs &
Datentelegramms für die Digital- & Analogkanäle
800kHz I2C



Olaf schrieb:
> Naja, sowohl bei meinem alten Hameg wie auch beim neuen RTB bin ich
> eigentlich der Meinung das die Aufzeichnungslaenge mehr als ausreichend
> ist. Die Probleme sehe ich eher in der Auswertung grosser Datenmengen.
> Da kann dann eine PC-Software von Vorteil sein. Allerdings sehe ich auch
> wie der RTB gegen meinen altem HMO da Vorteile durch grosses LCD und
> Touch-LCD gewinnt.

Genau so meinte ich es eigentlich...
Für das wo ich üblicherweise ein MSO einsetze reicht die 
Aufzeichnungslänge mehr als aus. Eine Aufzeichnungslänge von ~1s ist 
schon einiges.
Viel mehr macht zumindest mit diesem Gerät (und so gut wie allen MSO mit 
denen ich BIS JETZT als MSO gearbeitet habe) auch nicht viel Sinn. Eben 
wegen der von dir angesprochenen Auswertung/Übersichtlichkeit.

Wie ist das denn beim RTB?
(habe nur mal ein paar Grundmessungen mit einem Gerät gemacht weil das 
bei einer besuchten Fa. gerade auf dem Tisch stand, nichts spezielles 
und schon gar nichts mit Protokollanalyse)
Haben die auch weitergehende Funktionen wie verünftige Suche in den 
Telegrammen, komplette tabellarische Übersicht aller Telegramme in der 
Aufzeichnung und spezielle Exportfunktion?
Da ist das MSO5k ja noch etwas sparsam.

Und wie lang könnte man denn damit tatsächlich 1MHz I2C bei korrekter 
und halbwegs korrekter Auswertung aufzeichnen?

Olaf schrieb:
> Aber wie du schon sagst, man braucht natuerlich immer beides. :)
Da sind wir uns ja, wie auch bei eigentlich allem wesentlichen hier im 
Thread, einig ;-)

Generell ist es natürlich sicher so das es auch eine Reihe aktueller 
Geräte am Markt gibt die mehr können, hier mal eine Funktion besser 
implementiert haben etc. Aber die haben dann auch wieder an anderer 
Stelle Nachteile. Und sei es nur die Zahl auf dem Preisschild ;-)

Deshalb finde ich es ja auch völlig in Ordnung über vor- und Nachteile 
diverser Geräte sachlich zu diskutieren. Die offen zu benennen und zu 
Vergleichen. Das gilt genau so auch für tatsächliche BUGs die man auch 
bei diesem Gerät immer noch an verschiedenen Stellen finden kann.
Alleine schon damit verifiziert werden kann das es wirklich ein Bug ist 
und  falls ja damit andere feststellen können ob dieser einem selbst 
betrifft und schließlich auch in der Hoffnung das der Bug dann, nach 
Meldung an Rigol, irgendwann behoben wird.

Ich finde es dabei nur immer wichtig das auch in echter Relation zum 
sonstigen Markt und den Anforderungen bei der täglichen Arbeit zu setzen 
bzw. das nicht aus den Augen zu lassen.
Aber dieser Thread ist in der Hinsicht ja bis auf eine Trollmeldung ja 
recht sachlich ;-)

Aber um auch das deutlich zu sagen:
Hier mit diesem Skope ist es dieselbe Entwicklung wie mit den anderen in 
Bastlerkreisen bekannten Rigol Skopes in der Vergangenheit. Insbesondere 
z.b. dem DS1000z (Bei Siglent etc. hat man aber auch schon ähnliches 
gesehen)

Die Hardware ist für die Preisklasse der jeweiligen Einstiegsmodelle 
bereits von Anfang an sehr brauchbar. Die ersten Firmwareversionen sind 
aber total verbuggt, selbst bei kritischen Funktionen.
Das macht aus dem GErät Anfangs einen schlechten Deal.

Nach 1...3 Jahre der Reifung mit zahlreichen Updates hat man dann aber 
eine gut brauchbare Firmware. Noch nicht absolut Bugfrei, aber das sind 
die GEräte der Premiumhersteller zu Premiumpreisen auch nicht. GEmeinsam 
ist beiden dabei das die Bugs die noch da sind i.d.R. eher 
"Schönheitsfehler" sind die die Arbeit mit dem Gerät nicht mehr wirklich 
beeinträchtigen. Und es wird noch weiter gefixt.
(An diesem Punkt ist man beim MSO5K jetzt so langsam angekommen)

Da gleichzeitig die Preise schon gefallen sind und auch mehr Optionen 
bereits enthalten sind sind die Basismodelle dann ein guter Deal. Erst 
recht wenn man "hacken" kann-aber auch ohne Hack meist schon.
(Der Preis für die originale -ohne Hack- Topversion der Modellreihe 
passt aber weiterhin eigentlich nicht ganz zur Leistung weil das ja 
schon ein Vielfaches des Basispreises ist. Da ist man schon im 
Preisbereich der AKTUELLEN Geräte der "Premiumhersteller" die dann oft 
doch den "kleinen Touch" mehr bieten...)

Gruß
Carsten

von Carsten S. (dg3ycs)


Lesenswert?

Patrick L. schrieb:
> Dies wäre dann aber Fatal , wen das aus dem Grund, Bug oder
> Rechenleistung passieren würde! Ich denke immer noch, das das ev. mit
> dem Latch/Sample zusammenhängt, den selbst mein DLI(der ein Kleinwagen
> kostete) zeigt bei Latch natürlich auch ein Glitch an und würde dann
> die Auswertung fehlerhaft(Ja eigentlich richtig) machen.

HHMmm,
Die Firma DOLCH DLI hat als solche im Jahr 1988 aufgehört zu existieren.
Das ist jetzt 34 Jahre her... Der genannte LA muss also MINDESTENS 
34JAhre alt sein. eher Älter.
Ich glaube nicht das ein solch altes Gerät noch als Vergleichsobjekt für 
die heutige Technik taugt (weder von den Daten, Bedienung noch 
Funktionsprinzip)
Ausser das irgendetwas abgetastet und dargestellt wird gibt es da keine 
nennenswerte Gemeinsamkeit mehr.

BTW:
Ein Glitch (Hazard) ist etwas völlig anderes als eine fehlerhafte 
Abtastung. Egal ob durch Pegel oder Jitter.
Das steht in der Elektronik exklusiv für durch Laufzeitunterschiede 
(Race Codition) in logischen Schaltungen ausgelöste kurzzeitige 
Fehlerzustände.

> Ich habe aber auch keine Hinweise gefunden, ob das Rigol die
> Logicsignale im Latch- oder Sample-Betrieb aufzeichnet.

Was soll denn Latch- und Samplebetrieb sein?
ISt das eine damals von Dolch verwendete Bezeichnung für die Umschaltung 
zwischen den Betriebsarten State- und Timinganalyse?

Wobei auch diese Umschaltmöglichkeit bis auf Nischenanwendungen 
eigentlich schon am Aussterben ist. Immer mehr LA lassen sich überhaupt 
nicht mehr Umschalten und bieten nur noch die Timinganalyse.
(Das Samplen rein in einem festen, immer exakt gleichen, Zeitintervall)
Durch immer schnellere Digitaltechnik und immer leistungsfähigere 
Speicherbausteine zum günstigen Kurs auch kein echtes Problem mehr.
Auch wenn die Betriebsart Stateanalyse durchaus auch echte Vorteile 
bietet da die erfassung zum Datentakt Synchron erfolgt, also 
normalerweise so wie die Signalsenke tatsächlich erfasst!

Das MSO5K erfasst rein asynchron mit einer festen Samplerate
(Also Timing-Betrieb). Das kann nicht umgestellt werden.

Gruß
Carsten

von Carsten S. (dg3ycs)


Lesenswert?

Ernest schrieb:
> oweit ich das verstehe, gibt es bei den Logikkanälen des Rigol nur
> einen Schwellenwert - dadrunter ist 0, drüber ist 1. Ermittelt wird das
> offenbar mit einem Komparator je Kanal.
Das ist soweit korrekt!

> Das ist natürlich anfällig für
> Glitsches, Prellen, Einstreuungen ...
Jain...
Für einen Glitch hat das keine Relevanz. Ein Glitch ist ein tatsächlich 
anliegender Pegel der aber zu der Zeit nicht anliegen darf.

Prellen bzw. Schwingen/Zittern des Ausgangssignal wenn das 
Eingangssignal im Bereich des Umschaltpunktes kommt könnten vorkommen.
Entweder wenn das Signal selbst etwas rauscht/zittert (z.B. durch Ripple 
in der Stromversorgung) oder durch Einstreuung ein paar mV zusätzlich 
auf die Leitung einkoppeln.
Eine Hysterese vorzusehen ist dagegen das Mittel der Wahl. Diese braucht 
gar nicht groß zu sein. Schon gar nicht mehrere Volt. (Ausser in 
extremst gestörten Umgebungen), Ein paar mV reichen da oft.

Neben diesem Zittern des Ausgangssignals kann es durch 
Einstreuungen/Rauschen etc. auch zu einem leichten Jittern der erkannten 
Signale kommen. Dagegen hilft eine Hystere aber nicht. Im Normalfall 
macht das keine Probleme. Bei einem ganz engen Timing sollte man aber 
immer im Kopf haben das auch dies eine Rolle spielen kann.

> Einstellen kann man den
> Schwellenwert wohl schon in Abhängigkeit von der Logikfamilie (und damit
> dem Vcc) die verwendet wird.
Ja, der ist wählbar. Von 0 bis 15V

> Per Definition für Logikfamilien gibt es einen unteren Schwellwert,
> unterhalb dessen der Zustand 0 ist und einen oberen Schwellert, oberhalb
> von dem der Zustand 1 ist. Dazwischen ist per Definition unbestimmt.
Das ist so NICHT Korrekt.

Es ist ein unterer Schwellwert definiert unter dem jedes ordnungsgemäß 
funktionierende Bauteil SICHER eine 0 erkennen muss.

Es ist ein oberer Schwellwert definiert über dem jedes ordnungsgemäß 
funktionierende Bauteil SICHER eine 1 erkennen muss.

Der Bereich zwischen dem unteren und dem oberen Schwellwert nennt sich 
sich "verbotener Bereich". Dieser Bereich ist nicht unbestimmt sondern 
es ist unbestimmt was ein Bauteil aus einer Spannung in diesem Bereich 
macht.

Als Beispiel:
Für CMOS-Eingänge ist der untere Schwellwert mit 0,33*Ub und der obere 
Schwellwert mit 0,66*Ub definiert.
Bei einer Ub von 3.3V also 1.1V und 2.2V

Ein CMOS-Baustein an 3,3V würde deshalb bei 1V SICHER eine 0 und bei 2,3 
V
SICHER eine 1 erkennen. Was dieser Baustein aber bei 1,5V macht, das ist 
völlig offen. Er wird definitiv ENTWEDER eine 0 ODER eine 1 erkennen. 
Nur was von beiden, DAS ist das was unbestimmt ist.
Es kann durchaus auch sein das alle Bausteine des Herstellers A bei 1,5V 
eine 1 erkennen und die des HErstellers B eine 0. Oder das die Bausteine 
die im Jahr 2018 gefertigt wurden eine 0 ausgeben, die aus 2019 aber 
eine 1. ODer die aus der rechten FErtigungsstrasse 1 und die aus der 
linken eine 0... Aber alle Bausteine haben nur EINE EINZIGE 
Spannungsgrenze (pro richtung des Flankenwechsels) wo der Zustand von 0 
auf 1 umspringt.
Diese Spannungsgrenze liegt garantiert irgendwo zwischen dem oberen und 
dem unteren Schwellwert.

ISt der Schaltpunkt bei einem Spannungsanstieg/ansteigende Flanke 
derselbe wie bei abfallender Flanke, dann gibt es keine Hystere. Das 
kann bei unsauberen Signalen oder zu langsamen Spannungswechseln 
probleme machen.

Hat der Schaltpunkt bei ansteigender Flanke eine etwas höhere Spannung 
als bei abfallender Flanke, dann ist das die Hystere. Eine definierte 
Hysterese wird durch einen Smith-Trigger realisiert.

> Häufig sind dann Eingänge als Schmidt-Trigger gestaltet, die die
> unbestimmten Zustände wegfiltern.
Nein, das ist nicht die Funktion eines Smith-Triggers. Ein Smith-Trigger 
verhindert nur ein Zittern des Ausgangssignals im Umschaltmoment bei zu 
langsamen Spannungswechseln bwz. stärkeren rauschen/einstreuungen auf 
der Leitung. Auch mit einem Smith-Trigger gibt es nur einen Wechsel 
zwischen 0 und 1 IRGENDWO im verbotenen Bereich.

Das Bauteil bzw. die Schaltung die du meinst und die die von dir 
gewünschte Funktion erfüllen würde nennt sich "Fensterkomparator". Damit 
ginge tatsächlich eine Unterscheidung zwischen 0, 1, sowie "dazwischen".
Dafür braucht man aber DREI parallele Komparatoren mit etwas Zusatzlogik 
und so sind absolut keine normalen Logikeingänge aufgebaut. (Eine solche 
Unterscheidung wird manchmal bei sicherheitskritischen Steuersignalen 
tatsächlich gemacht... Hat aber nichts mit Standard-Logik zu tun.)

> Das ist nach dem, was ich jetzt weiß,
> bei den Rigol Logikkanälen nicht implementiert, damit sind die
> störanfälliger als bei einer korrekten Implementierung der Definition
> für Logikfamilen.
Wie geschrieben: Das was du dir vorstellst (erkennung verbotener 
Bereich) gibt es nicht in den normalen Logikfamilien. Da hast du einfach 
etwas falsch verstanden. Der Eingang des Rigol verhält sich wie jeder 
andere normale Logikeingang auch. Nur mit einstellbarem Schwellwert und 
kleiner festgelegter Hysterese.

Gruß
Carsten

: Bearbeitet durch User
von Olaf (Gast)


Lesenswert?

> Wie ist das denn beim RTB?

Etwa so wie man das bei einem Handy erwarten wuerde wenn man den 
Touchscreen nutzt.

Olaf

von Patrick L. (Firma: S-C-I DATA GbR) (pali64)


Lesenswert?

Carsten S. schrieb:
> Was soll denn Latch- und Samplebetrieb sein?
> ISt das eine damals von Dolch verwendete Bezeichnung für die Umschaltung
> zwischen den Betriebsarten State- und Timinganalyse?

Im Latch Betrieb, übernimmt der LA eine Änderung des Pegels der 
irgendwann zwischen den Clocks(oder auch Samples) aufgetreten sind auf 
d.h.:

ich habe eine S-Tmg. von 10µs eingestellt, der Pegel liegt auf "0".
Nun während den 10µs (Nehmen wir an 3µs sind vergangen geht jetzt der 
Pegel für 1/2µs auf "1" und fällt wieder auf "0" zurück, wird aber eine 
"1" übernommen und auch in den eigentlich 10 µs langen Zeitraum als 1 
angezeigt.
Dies ist sehr praktisch um eben "Glitches" zu finden die nur sehr kurz 
auftreten.

Im Sample Betrieb, übernimmt der LA immer das Signal auf, welches gerade 
dann anliegt wen der Clock(Sample) stattfindet, Also würde etwaige 
Glitches nicht entdeckt werden, oder eben nur dann wenn sie genau zum 
Samplezeitpunkt auftreten.

Carsten S. schrieb:
> Die Firma DOLCH DLI hat als solche im Jahr 1988 aufgehört zu existieren.
> Das ist jetzt 34 Jahre her... Der genannte LA muss also MINDESTENS
> 34JAhre alt sein. eher Älter.

Ist 100% Richtig, und der Gould den ich noch habe ist noch älter :-)
aber dennoch, haben die gegenüber dem teuren Tek (etwa 3 J. alt), noch 
Vorteile dass grad der Dolch DLI eben auch auf ein Logiclevel von 24V, 
oder halt auf 23,9V usw. eingestellt werden, beim Tek ist bei 12V 
Schluss!
(oder man nimmt eine x10 Logicprobe dann geht der Tek auf 120V aber löst 
nicht mehr fein auf) und gerade 24V wird hier immer noch oft gebraucht, 
(Rep von Relais gesteuerten Steuerungen, wie Ampelanlagen) und da will 
ich ein "Glitch" von 24V auf 23,8V eben sehen können. Da hat der 
Oldtimer eben seinen Vorzug, Moderne LA's können nicht damit umgehen.

Wie gesagt benutze ich auch gerne Moderne und vor allem PC Basierende 
LA's da man dort ohne Umstände die Signale ansehen und Speichern kann.

Beim DLI muss ich diese mühsam über RS232 auf den PC übertragen.

Was ich aber bei den PC Basierten bspw. Saleae vermisse, ist (Wenn ich 
Oldtimer PC oder Arcade repariere) dass ich das Aufgezeichnete, grad 
Disassemblieren kann, diese Funktion im DLI war grad bei meinem ZX81 
Clon Nachbauanalyse einfach herrlich,
1
Der DLI stellt die Software dar und Markiert gerade ein Sprung ins Nirwana,
2
bemerkt dass die CPU eigentlich diesen Sprung gar nicht hätte ausführen dürfen
3
(Disassemblierten LD) Befehl und das Programm läuft plötzlich an einer anderen Adresse weiter)
4
Ursache war ein Glitch auf der Datenleitung Bit 7 wenn die Adresskombination AAAA Ansteht
5
und nur Dann trat das auf, schlussendlich war es ein Bleistiftstrich der der Zusamenbauer gemacht hatte als er das Print bestückte...)
gerade solche Sachen sind da mit dem DLI wunderbar zu finden, was mann 
sonst Ewigkeiten von Hand sucht. und auch die 1MOhm Eingangsimpedanz an 
den ALP's ist da sehr hilfreich, was beim Rigol z.B. einiges tiefer ist!

Die Funktionen wie [IlegalCall] oder [MissInstruct] oder [LoadFail] 
finden dann in der Aufzeichnung, oder auch während dem Life-abbild 
solche Bug's :-)

Für Moderne sag mal Günstige wie der Saleae wäre eine Disassemble 
Funktion für Moderne µP (nicht µC da hat man ja den Debugger für dass) 
sehr willkommen.
Ist aber scheinbar eine solche Nischenanwenndung, dass man da kaum was 
brauchbares findet.

OK genug ausgeschweift. nun wieder OnTopic :-)

PS: Man Verzeihe mir etwaige Vertipper oder Interpuktationswahnsin, aber 
ein so langer Text auf dem Handy und nicht mal in der Muttersprache, ist 
eine Qual :-D

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
Noch kein Account? Hier anmelden.