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
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
> 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,
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
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
> 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
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?
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…).
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.
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
> 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
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.
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
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.
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
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
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
> 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
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.
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.
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.
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)
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
> 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
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.
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
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
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
> Wie ist das denn beim RTB?
Etwa so wie man das bei einem Handy erwarten wuerde wenn man den
Touchscreen nutzt.
Olaf
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.