Hallo, hat von euch jemand ein Scope der neuen RIGOL 4000er-Serie zwecks Vergleich? Wie sieht's mit Bugs in der Firmware aus? Habe festgestellt, dass mein DS4012er hin- und wieder nach dem Einschalten auf Chinesisch statt dem voreingestelltem Englisch schaltet. Kommt selten und nicht-periodisch vor. Sind solche Bugs bei RIGOL hinzunehmen? Ich meine, das Scope ist ansonsten der Hammer und bei dem Preis wäre ich da tolerant. Also, Erfahrungsaustausch erwünscht.
Verglichen mit den Macken meines OWON würde mich so ein Fehler nicht stören. Was willst du sonst machen? Neue Firmware schreiben dauert Jahre - in der Zwischenzeit hättest du selbst mit einen Ein-Euro-Job genug Geld für ein professionelles Scope verdient. Und im lauf der Zeit fallen einem die Macken sowieso nicht mehr auf.
Kein Name schrieb: > Verglichen mit den Macken meines OWON würde mich so ein Fehler nicht > stören. Nun ja, das RIGOL kostet schon etwas mehr als das OWON und ist sicher eine höhere Klasse. Kein Name schrieb: > Was willst du sonst machen? Neue Firmware schreiben dauert Jahre Nö, sowas macht der Hersteller i.d.R. in ein paar Monaten. Habe andere Scopes, wo das passiert. Kein Name schrieb: > in > der Zwischenzeit hättest du selbst mit einen Ein-Euro-Job genug Geld für > ein professionelles Scope verdient. Hä? Abgesehen davon, dass meine Frage darauf nicht abzielte, ist die RIGOL DS4000er-Serie den teuren Agilents ebenbürtig, von denen ich beruflich zwei im Wert von ca. jeweils 8000,-€ auf dem Tisch stehen habe. Selten so ein professionelles Gerät wie das 4012er zu so einem Preis gesehen. Meine Frage war, ob andere dieselbe Serie besitzen und etwas über Bugs berichten können. Würde dann eine Liste erstellen und zum Firmware-Bugfixing an den Hersteller senden. Das OWON ist ein Lowcost-Scope, die 4000er RIGOLs sind es definitiv nicht.
Hast ja recht. Meine nur Bugreports haben da wenig Sinn. Agilent und Rigol bedienen total unterschiedliche Kunden. Agilent verkauft für angemessene Preise einwandfreie Geräte. Wenn du einen Fehler meldest, wird er von einem Techniker behoben. Hat dann halt seinen Preis. Rigol verkauft dagegen große Stückzahlen an Leute, die 999€/1999€/2999€ ausgeben wollen. Wenn du einen Fehler meldest, entscheiden erst mal die BWLer, ob sich der Aufwand rechnet. Ob sie mehr Geräte verkaufen, wenn sie die bekannten Fehler beheben, oder ob sie mehr Geräte verkaufen, wenn sie neue Features einbauen. Wenn schon, dann musst du so lange hartnäckig reklamieren, bis die Kosten für die Reklamationen höher werden, als die Kosten für die Fehlerbehebung.
Kein Name schrieb: > Meine nur Bugreports haben da wenig Sinn. Würde ich nicht behaupten, alles eine Frage der Resonanz. Wenn Rigol merkt, dass sie bei Support besser verkaufen, dann werden die nachziehen. Kein Name schrieb: > Agilent und Rigol bedienen total unterschiedliche Kunden. Das war bei den kleinen Scopes bis dato der Fall. Inzwischen hat Rigol aber sowohl bei den Analyzern wie auch bei den höherwertigen Scopes mit Agilent bis zu den 8000,-€-Geräten fast gleichgezogen. ASICs mit 110.000 wfm/s war bis dato in dieser Preisklasse fast ausschliesslich bei Agilent vorzufinden, die hat RIGOL in den 4000er nun auch drin, angeblich Eigenentwicklung. Die Abtastrate liegt bei 4GSa/s, der Speicher bei 140MPts (!!!) - der Hammer! Display groß, Busanalyse per Option, LAN, USB, VGA, umfangreiche Trigger usw. Ich kenne die Agilents sehr gut, ein paar Teks auch, habe private ein großes HMO mit 4 Kanälen und Busoptionen, also RIGOL ist Agilent da mächtig in die Quere gekommen! Schaut man in die Service-Unterlagen der DS4000er, so kann man starke Ähnlichkeiten zu den Agilents der 3000er-Reihe erkennen, zumindest was die ASICs angeht. Und die Dinger waren bei Agilent immer ausschlaggebend für die hohen wfm/s. Zudem hat das RIGOL die Megazoom-Tech der Agilents ebenso drauf, zumindest Pan&Zoom und v.a. Zoom im gestoppten Rollmode. Ich wäre also sehr vorsichtig, Agilent und Rigol in andere Kundenkreise zu stecken. Bisher wollte ich privat immer ein Agilent haben, es war immer am Preis gescheitert. Seitdem ich das Rigol habe, ist das hinfällig, ist gefällt mir sogar besser, da es einen immens großen Speicher und anständige Suchfunktionen innehat. Die 6000er-Rigols gehen sogar in den 1GHz-Bandbreitenbereich, ebenfalls mit einem Riesenspeicher im Vergleich zu Agilent. Man merk deutlich, dass der MArkt in Bewegung ist. Agilent hat da wieder einen Vorsprung, wo es um richtig hohe GHz-BAndbreite geht. Zuletzt von 62,5GHz gelesen, wo sie LeCroy nun getopt haben. Dort ist Rigol sicher nicht zu finden. Kein Name schrieb: > Wenn du einen Fehler meldest, entscheiden erst mal die > BWLer, ob sich der Aufwand rechnet. Das ist wie in jeder anderen Firma auch. Ich habe viel mit dem Support diverser Scopehersteller telefonisch zu tun gehabt. Es muss nicht immer der teuerste Anbieter sein, der den besseren Support liefert. Und Rigol hat vor ein paar Monaten eine deutsche Niederlassung in Puchheim eröffnet, für Marketing & Support. Es ist wohl klar, dass sich Geräte besonders im mehrere tausend Euro-Bereich ohne Support langfristig nicht verkaufen lassen, denn diese Geräte zielen mehr auf Businessbereich als auf Privatkunden ab. Ich denke, da ist noch Einiges im Aufbau, besonders bei Rigol, die sich Support leisten können, wenn sie höherpreisige Geräte verkaufen. Kein Name schrieb: > Wenn schon, dann musst du so lange hartnäckig reklamieren, bis die > Kosten für die Reklamationen höher werden, als die Kosten für die > Fehlerbehebung. Es geht mir gar nicht darum, hartnäckig um Firmware zu betteln. Ich sammel einfach Bugs und sende sie, zum Teil schon passiert, es gibt einen Bug-Report im Account. Wenn dann mal was kommt, dann gut, wenn nicht, auch nicht schlimm, das Scope habe ich schon sehr ausgiebig getestet und bis dato waren es nur zwei Kleinigkeiten mit denen ich leben kann. Ist zudem noch recht neu im Markt. Ich weiß nicht, ob du die Geräte kennst, aber schau die bei Interesse mal die Teile bei Batronix an, oder auf der EU-Webseite. Ich bin sicher kein Anfänger und habe einige Geräte hier stehen, bei Rigol fällt aber der Vorstoß in ein neues Marktsegment deutlich auf, da müssen Agilent und Co. aufpassen. Sollte deren Support nachziehen, gibt es keinen Grund mehr, die Geräte auch im Businessbereich einzusetzen. Würde mich aber auch nicht wundern, wenn Agilent die ASICs an Rigol hintenrum per Lizenz vertickt, denn die Ähnlichkeiten sind enorm ;-)
Ich grabe den Thread hier mal aus, weil hier ja anscheinend ein paar Leute ein DS4000 haben. Hätte da nämlich ein paar Fragen, die mir nach Studium des Handbuchs nicht so ganz klar sind: 1) Mißt das DS4000 im Samplespeicher (wie LeCroy und Hameg) oder aus dem Bildschirmspeicher (wie Agilent)? Sprich: ändert sich die Genauigkeit einer Messung abhängig von der Zoomstufe? Falls nein: kann man bei automatischen Messungen zu einer Genauigkeit in der Größenordnung der Abtastfrequenz erreichen? 2) Müssen die Cursor bei der manuellen Messung immer gleichzeitig sichtbar sein, oder kann man sie auch einzeln in hohen Zoomstufen setzen, ohne den jeweils anderen (gerade nicht auf dem Bildschirm sichtbaren) Cursor zu verschieben. Falls ja: kann man so Zeiten in einer Genauigkeit in der Größenordnung der Abtastfrequenz ausmessen? 3) Im Handbuch klingt es so, als seien die Protokoll-Trigger (SPI usw.) immer verfügbar, obwohl die Dekodieroptionen ja optional (und nebenbei bemerkt schweineteuer) sind? 4) Ich finde im Handbuch keine Option, um Pulse/Flanken zwischen zwei Cursors zu zählen. Geht das indirekt über die Statistik oder fehlt diese Feature generell? Um nochmal auf die Punkte #1..#3 zu kommen. Folgendes Testszenario: ich habe einen Puls von 100µs Länge, verlängere ihn dann um 10ns auf 100.01µs und will das am Scope (1GA/s oder 500MSa/s) prüfen und per Screenshot dokumentieren: Mit einem LeCroy WaveRunner geht das unabhängig von der dargestellen Auflösung, solange die Samplefrequenz hoch genug ist. Geht auch automatisch mit Statistik und schnick und schnack. Mit einem Agilent MSO7000A geht das automatisch schon mal gar nicht, weil es ja im Displayspeicher mißt und bei 100µs/div nicht genügend Auflösung hat. Man kann es aber manuell hinbekommen, wenn man weit genug reinzoomt und beide Cursor auf die Flanken verschiebt. Dokumentieren kann man es aber nicht so recht, weil beim Rauszoomen die Auflösung wieder verlorengeht. Mit meidem Owon SDS kann ich das gar nicht messen, weil es anscheinend ebenfalls im Displayspeicher mißt und die Cursor beim Reinzommen beide an ihrer Bildschirmposition bleiben (sich also relativ zur Sampleposition verschieben). Kurzum: wie schlägt sich das Rigol DS4000 bei solch einem Fall?
Volker O. schrieb: > Ich grabe den Thread hier mal aus, weil hier ja anscheinend ein paar > Leute ein DS4000 haben. Hätte da nämlich ein paar Fragen, die mir nach > Studium des Handbuchs nicht so ganz klar sind: > > 1) Mißt das DS4000 im Samplespeicher (wie LeCroy und Hameg) oder aus dem > Bildschirmspeicher (wie Agilent)? Sprich: ändert sich die Genauigkeit > einer Messung abhängig von der Zoomstufe? Falls nein: kann man bei > automatischen Messungen zu einer Genauigkeit in der Größenordnung der > Abtastfrequenz erreichen? Geh mal davon aus, dass RIGOL sich mit der 4000er-Reihe stark an Agilent orientiert. Scheint so, als hätten sie deren ASICs entweder in Lizenz oder verdammt gut kopiert. Bei Hameg meinst du die HMOs? > 2) Müssen die Cursor bei der manuellen Messung immer gleichzeitig > sichtbar sein, oder kann man sie auch einzeln in hohen Zoomstufen > setzen, ohne den jeweils anderen (gerade nicht auf dem Bildschirm > sichtbaren) Cursor zu verschieben. Falls ja: kann man so Zeiten in einer > Genauigkeit in der Größenordnung der Abtastfrequenz ausmessen? Eigentlich nicht, es gibt verschiedene Modi. Davon heisst einer "Track", und der ermöglicht, dass ein gesetzter Cursor seine Position auch nach ausblenden des entsprechenden Signalteils nicht verlässt. In deinem Fall sollte er also auf der nicht-sichtbaren Flanke bleiben, so dass du den anderen Cursor auf die sichtbare Flanke justieren kannst. Allerdings scheint das Rigol 4000er hier noch einen Bug zu haben, denn als ich gestern deinen Fall nachstellen wollte, ist mir aufgefallen, dass sich der nicht-sichtbare Cursor nur so lange an der zuvor eingestellten Position hält, so lange der andere nicht verändert wird. Habe dieses Fehlverhalten gestern noch an den deutschen Support gemailt, die haben mir schon vor Wochen recht schnell & kompetent mit einem Update ausgeholfen. Ist halt noch eine neue Serie. > 3) Im Handbuch klingt es so, als seien die Protokoll-Trigger (SPI usw.) > immer verfügbar, obwohl die Dekodieroptionen ja optional (und nebenbei > bemerkt schweineteuer) sind? Im Handbuch steht schon, dass es sich um Optionen handelt, allerdings etwas schwer erkennbar und nicht überall, da hast du Recht. Allerdings sind die Protokollanalysen zum Testen für 1950 Minuten freigeschaltet. Hahe privat neben dem HMO2524 von Hameg das DS4012 von Rigol (der Thread hier stammt von mir, konnte mich damals nicht einloggen). Die Busoptionen des HMO sind besonders nach dem Hardware-Update weitaus umfangreicher als bei Rigol, auch billiger. Allerdings funktionieren die von Rigol auch sehr gut, zudem bieten sie für Automotive auch Flexray an. Preislich orientiert sich Rigol eher an Agilent, das Scope gleicht auch eher Agilent-Modellen, besonders durch die schnellen ASICs mit 110.000 wfm/s. Hier kommt Hameg wiederum nicht mit. Ein weiterer Vorteil sind die umfangreicheren Triggermöglichkeiten auf USB-Pakete usw., die auch ohne Busanalyse aktiv sind. > 4) Ich finde im Handbuch keine Option, um Pulse/Flanken zwischen zwei > Cursors zu zählen. Geht das indirekt über die Statistik oder fehlt diese > Feature generell? HAbe ich auch noch nicht gefunden, brauche ich auch selten. Auf der anderen Seite habe ich das HMO2524, die beiden ergänzen sich perfekt. Sicher eine Preisfrage, sich beide leisten zu wollen/können. > Um nochmal auf die Punkte #1..#3 zu kommen. Folgendes Testszenario: ich > habe einen Puls von 100µs Länge, verlängere ihn dann um 10ns auf > 100.01µs und will das am Scope (1GA/s oder 500MSa/s) prüfen und per > Screenshot dokumentieren: > Mit einem LeCroy WaveRunner geht das unabhängig von der dargestellen > Auflösung, solange die Samplefrequenz hoch genug ist. Geht auch > automatisch mit Statistik und schnick und schnack. > > Mit einem Agilent MSO7000A geht das automatisch schon mal gar nicht, > weil es ja im Displayspeicher mißt und bei 100µs/div nicht genügend > Auflösung hat. Man kann es aber manuell hinbekommen, wenn man weit genug > reinzoomt und beide Cursor auf die Flanken verschiebt. Dokumentieren > kann man es aber nicht so recht, weil beim Rauszoomen die Auflösung > wieder verlorengeht. Denke, das ist beim Rigol wie beim Agilent. > Mit meidem Owon SDS kann ich das gar nicht messen, weil es anscheinend > ebenfalls im Displayspeicher mißt und die Cursor beim Reinzommen beide > an ihrer Bildschirmposition bleiben (sich also relativ zur > Sampleposition verschieben). Nun ja, die billigen OWONs sind mit der 4000er-Serie nicht mehr vergleichbar. Mit diesen Scopes geht RIGOL in den höherwertigen Scopebereich, was schon an den ASICs und am Preis erkennbar ist. > Kurzum: wie schlägt sich das Rigol DS4000 bei solch einem Fall? Wenn RIGOL den Bug beseitigt, kannst du wie mit Agilent-Scopes durch reinzoomen mittels Track-Mode beim Cursor messen. Bei Hameg HMOs heisst diese Funktion "Kleben". Du hast recht, für Dokumente ist dies sicher etwas weniger schön, wenn du das gesamte Signal darstellen willst, aber sonst perfekt gelöst. Ich warte mal auf die Rückantwort vom Support, wenn du Interesse daran hast, kurz mitteilen, dann poste ich das Resultat hier. Gruß Gunb
Erstmal Danke für die ausführliche Antwort ;) Gun B. schrieb: > Geh mal davon aus, dass RIGOL sich mit der 4000er-Reihe stark an Agilent > orientiert. Scheint so, als hätten sie deren ASICs entweder in Lizenz > oder verdammt gut kopiert. > Hatte ich irgendwie befürchtet. Agilent Scopes sind halt IMHO nicht so der Brenner. Da hätte Rigol besser woanders kopiert. > Bei Hameg meinst du die HMOs? > Jupp. > Habe dieses > Fehlverhalten gestern noch an den deutschen Support gemailt, die haben > mir schon vor Wochen recht schnell & kompetent mit einem Update > ausgeholfen. Ist halt noch eine neue Serie. > In Summe klingt das so, als könnte man die 100.01µs derzeit weder automatisch noch manuell ausmessen. Neues Scope hin oder her, aber das ist traurig. Bei meinem "preiswerten" Owon kann man da zähneknirschend ein Auge zudrücken, aber bei Scopes, die irgendwo zwischen 2000 und 6000€ liegen, ist das schon ein wenig beschämend. Zumal sie so neu jetzt auch schon nicht mehr sind. > Im Handbuch steht schon, dass es sich um Optionen handelt, allerdings > etwas schwer erkennbar und nicht überall, da hast du Recht. > Auf die Gefahr hin, schwerfällig zu wirken, aber sind die Protokoll-Trigger jetzt optional (wie die Dekodierung) oder immer vorhanden? > Die Busoptionen des HMO sind besonders nach dem Hardware-Update weitaus > umfangreicher als bei Rigol, auch billiger. Allerdings funktionieren die > von Rigol auch sehr gut, zudem bieten sie für Automotive auch Flexray > an. Preislich orientiert sich Rigol eher an Agilent, das Scope gleicht > auch eher Agilent-Modellen, besonders durch die schnellen ASICs mit > 110.000 wfm/s. Hier kommt Hameg wiederum nicht mit. > Wobei ich diesen Waveforms/Sekunde-Fetischismus nicht ganz teilen kann. Das ist irgendwie eine analoge Denke. Wenn man wirklich gute Triggerbedingungen und gute Meß- und Analysefunktionen hat, braucht man Glitches nicht durch Starren auf das Display zu erkennen: man kann sie direkt Messen oder in Aufzeichnungen suchen. Mir ist unverständlich, warum Agilent bei Triggerbedigungen, Triggerverschachtelung, Analyse und Meßmöglichkeiten in der Jungsteinzeit verharrt und stattdessen riesige Summen in die Simulation einer analogen Anzeige verballert. Anscheinend wollen das tatsächlich viele Leute, aber IMHO verschenkt man so die Möglichkeiten eines DSOs weitestgehend. > Ein weiterer Vorteil sind die umfangreicheren Triggermöglichkeiten auf > USB-Pakete usw., die auch ohne Busanalyse aktiv sind. > Das klingt jetzt wieder so, als seien die Protokolltrigger immer vorhanden. > HAbe ich auch noch nicht gefunden, brauche ich auch selten. Auf der > anderen Seite habe ich das HMO2524, die beiden ergänzen sich perfekt. > Sicher eine Preisfrage, sich beide leisten zu wollen/können. > Also bevor ich mir zwei für das Geld zwei halb brauchbare Scopes kaufen würde, hätte ich mir lieber ein richtig ordentliches gekauft. Aber eigentlich liegt bereits ein HMO1024 neu über meiner privaten Schmerzgrenze. Und DS4014 ist ja nochmal teurer. Beide zusammen sind ein No-Go. > Denke, das ist beim Rigol wie beim Agilent. > Sehr, sehr traurig. Frage mich, ob die Entwickler bei Agilent und Rigol nicht auch ab und zu mal die Scopes der Konkurrenz angucken. Bei einem Yokogawa oder LeCroy sollten denen die Tränen in die Augen kommen. Stattdessen fokussieren sich immer nur Tek und Agilent. > Nun ja, die billigen OWONs sind mit der 4000er-Serie nicht mehr > vergleichbar. Mit diesen Scopes geht RIGOL in den höherwertigen > Scopebereich, was schon an den ASICs und am Preis erkennbar ist. > Zweifelsfrei ist das Owon softwaretechnisch nur knapp über der Unbrauchbarkeit und das Rigol ist auch hardwareseitig deutlich besser. Aber leider haben sich ja alle meine Befürchtungen bestätigt. Das macht das DS4000 dann für mich persönlich auch nicht so viel attraktiver als mein Owon. Und für die Firma kann ich das in dem Zustand überhaupt nicht in Erwägung ziehen. Dann lieber etwas Asche drauflegen und ein Tek DPO3000 oder zur Not halt ein Agilent DSOX3000. Da tun wenigstens die Grundfunktionen. > Wenn RIGOL den Bug beseitigt, kannst du wie mit Agilent-Scopes durch > reinzoomen mittels Track-Mode beim Cursor messen. Bei Hameg HMOs heisst > diese Funktion "Kleben". Du hast recht, für Dokumente ist dies sicher > etwas weniger schön, wenn du das gesamte Signal darstellen willst, aber > sonst perfekt gelöst. > Nö, perfekt ist was anderes. Das man manuell genau messen kann, ist eine Mindestanforderung für ein Scope in der >2k€-Klasse. Wenn das nicht geht, ist das eigentlich ein K.O.-Kriterium. Ich persönlich finde aber Messen im Displaybuffer und Darstellung der Meßergebnisse mit einer Nachkommastellen eh unfassbar gedankenlos implementiert. > Ich warte mal auf die Rückantwort vom Support, wenn du Interesse daran > hast, kurz mitteilen, dann poste ich das Resultat hier. > Klar, das wäre nett. Wobei ich selber schon mal eine Mail an den chinesischen Service geschrieben habe, der mich aber leider ignoriert hat. Aber wenn wir schon mal beim Thema sind. Die HMOs haben zwar auch ein paar Macken und der Speicher ist etwas mickrig, aber bei den Meßmöglichkeiten haben sie sich wenigsten ein paar Gedanken mehr gemacht als Agilent und Rigol. Aber richtiges Gating (automatische Messung zwischen zwei Cursorpositionen) können sie nicht, oder? So wie ich das verstehe, gibt es eine halbmanuelle Messung, die einige Messungen (Pulse zählen und so) zwischen den beiden Cursorpositionen erlaubt. Aber bei den richtigen automatischen Messungen wird immer der ganze Bildschirm benutzt, oder? Und last but not least: obwohl das HMO-Handbuch explizit erwähnt, daß immer im Samplespeicher gemessen wird, erscheint mir die Auflösung der (manuellen und automatischen) Messungen etwas mau (bestenfalls eine Nachkommastelle im dreistelligen Mikrosekundenbereich). Irgendwie sieht es auf den Bildern im Handbuch nicht so aus, als könnte ich hier meine 100.01µs ausmessen. Täuscht das, oder sind die Hamegs hier unterm Strich genauso schusselig programmiert wie die Agilents und Rigols?
Wozu noch diskutieren, deine Meinung ist doch eindeutig. Ob's stimmt, ist ein anderes Thema, aber auf einen weiteren Thread zum Thema "Glaubenskrieg der Oszilloskope" möchte ich verzichten. Volker O. schrieb: > Klar, das wäre nett. Wobei ich selber schon mal eine Mail an den > chinesischen Service geschrieben habe, der mich aber leider ignoriert > hat. Mich nicht, ich habe den deutschen Support kontaktiert und hatte im April innerhalb von 2 Stunden ein Update.
Gun B. schrieb: > Wozu noch diskutieren, deine Meinung ist doch eindeutig. Ob's stimmt, > ist ein anderes Thema, aber auf einen weiteren Thread zum Thema > "Glaubenskrieg der Oszilloskope" möchte ich verzichten. > Da hab ich auch andere Hobbies. Trotzdem darf man sich doch ärgern, wenn Hersteller eine sehr ordentliche Hardware bauen und dann die Software so vermurksen, daß man bei >1GSa/s gerade mal auf 1µs oder bestenfalls 100ns genau messen kann, ohne sich einen abzubrechen. Wie auch immer: könntest Du trotzdem noch kurz auf meine beide letzten Fragen zum HMO eingehen? Wäre nett...
Hallo, also mal wieder ein wenig Zeit zum Diskutieren. Volker O. schrieb: > Gun B. schrieb: >> Wozu noch diskutieren, deine Meinung ist doch eindeutig. Ob's stimmt, >> ist ein anderes Thema, aber auf einen weiteren Thread zum Thema >> "Glaubenskrieg der Oszilloskope" möchte ich verzichten. >> > Da hab ich auch andere Hobbies. Trotzdem darf man sich doch ärgern, wenn > Hersteller eine sehr ordentliche Hardware bauen und dann die Software so > vermurksen, daß man bei >1GSa/s gerade mal auf 1µs oder bestenfalls > 100ns genau messen kann, ohne sich einen abzubrechen. Ehrlich gesagt halte ich diese Argumentation für etwas übertrieben. Dein Fall ist nur einer von vielen Aufgaben, und ich wüsste nicht, was da SO vermurkst sein soll, dass man nicht mit ein paar Einstellvorgängen einen Puls genau ausmessen könnte. Sicher, die Genauigkeit sollte unabhängig von der Zeitbasis erhalten bleiben, so wie Hameg das macht. Hier musst du ebenfalls die Flanke durch eine genauere Zeitbasis einstellen, den Cursor setzen und dies für die andere wiederholen. Danach bleibt diese aber auch erhalten, egal, welche Zeitbasis du einstellst. Du hast sicher Recht, das Agilent das etwas schlechter gelöst hat, verstehe ich ehrlich gesagt auch nicht, könnte man wirklich besser umsetzen. Bei Rigol habe ich den Bug inzwischen gemeldet und auch Antwort bekommen. Der deutsche Support hat's reproduzieren können und an die Entwickler weitergegeben. Zuletzt hatte ich sehr schnell ein Update, mal sehen. Selbst wenn Rigol das wie Agilent implementiert haben sollte, so sollte es wenigstens möglich sein, einen Puls wie von dir genannt sauber ausmessen zu können, sonst nutzt die beste Hardware nichts, absolute Zustimmung. Nur würde ich wegen dieses Bugs nicht gleich das gesamte Scope herabstufen. Bei den Automatikfunktionen messen alle der o.g. Scopes aus dem Bildspeicher, was meiner Meinung nach auch Sinn macht. Ich habe z.B. momentan mit einem proprietären Datenprotokoll (Rechtecksignal) zu tun, dass aus vielen Pulsen unterschiedlicher Breite besteht. Möchte ich nun automatisch die Breite messen lassen, so stellt sich doch für den Algorithmus die Frage, welcher der Pulse nun gemessen werden soll? Bei Agilent, Rigol und Hameg ist es so, dass bei mehreren der Erste auf dem Schirm automatisch herangezogen wird. Möchte man nun nur einen von mehreren Pulsen messen, dann stellt man die Zeitbasis eben so, dass der gerade interessante alleine auf dem Screen ist, ohne dass die Cursor verstellt werden müssen. Würde man hier aus dem Samplespeicher messen, woher sollte der Algorithmus dann wissen, welchen Puls er nehmen soll? Den gerade Sichtbaren? Dann kann man auch direkt wieder aus dem Bildspeicher messen. Der Einsatz von Automatikmessungen im Zusammenhang mit Genauigkeit halte ich eh für fraglich. Wenn das Signal verrauscht ist und von Puls zu Puls in der Amplitude schwankt, dann muss der Algorithmus erst einmal beurteilen können, wo denn nun die Hälfte der Flanke zu finden ist. I.d.P. sehe ich hier meist springende Messmarker. Da gehe ich lieber selbst ans Werk und messe von Hand. > Wie auch immer: könntest Du trotzdem noch kurz auf meine beide letzten > Fragen zum HMO eingehen? Wäre nett... Ob das, was du als Gating bezeichnest, deinen Anforderungen entspricht, weiß ich nicht genau. Aber: das HMO nutzt nach Drücken der AUTO MEASURE - Taste für die hinterlegten Funktionen (und das sind einige) immer den gesamten Screen. Durch Drücken der CURSOR MEASURE - Taste werden weitere Messfunktionen angeboten, die im Menü per Drehregler ausgewählt werden können. Dabei bezieht sich die Messung auf den Teil des Screens, der sich zwischen den beiden Cursor befindet - sollte deinem Gating entsprechen. Das kann das RIGOL zwar nicht in diesem Umfang wie das Hameg, allerdings gibt es auch hier die Möglichkeit, zwischen Screen und Cursor-Bereich zu wählen. Zuletzt noch etwas dazu: Volker O. schrieb: > Also bevor ich mir zwei für das Geld zwei halb brauchbare Scopes kaufen > würde, hätte ich mir lieber ein richtig ordentliches gekauft. Aber > eigentlich liegt bereits ein HMO1024 neu über meiner privaten > Schmerzgrenze. Und DS4014 ist ja nochmal teurer. Beide zusammen sind ein > No-Go. Es war nicht beabsichtigt, zwei Scopes zu kaufen. Das HMO2524 habe ich vor 2 Jahren erworben und kann nur sagen, dass es ein klasse Allrounder ist, das für die meisten Bereiche sowohl im Analog- als auch Digitalbereich mehr als ausreicht. Für FPGA und µC besitzte ich beide Digitalprobes mit insgesamt 16 Kanälen sowie die Busanalyse für RS232, SPI, I2C, Parallel und UART, die ich rege gebrauche. Seit Februar sind umfangreiche Suchfunktionen für analog als auch Busanalyse hinzugekommen - ich bin mit der Kiste bis dato sehr gut gefahren. Ein Manko gibt es allerdings: das Zoomen im gestoppten Rollmode. Und hier kam das Rigol ins Spiel, da ich diese Funktion sehr häufig brauche. Deshalb habe ich das kleinste DS4000er gekauft. Das die Rigols zu teuer seien, kann ich nicht teilen. Denn vergleicht man mal die Funktionalität und den Umfang, kosten vergleichbare Agilents schon einiges Geld mehr. Wir haben genug davon und Teks sowie Fluke in der Firma stehen. Wenn du nun mit LeCroy anfängst und den Waverunner nennst, so ist dessen Vergleich mit Agilent sicher gerechtfertigt, weil gleiche Preiskategorie, aber mit den Rigols sicher nicht, denn da liegen ein paar Euros dazwischen. Gefallen hat mir LeCroy bisher nicht. Sicher Geschmackssache, mit welcher Firmenphilosophie man sich persönlich anfreunden möchte. Bugs: also was das Thema angeht, könnte ich hier Geschichten erzählen, die so schnell kein Ende nehmen. Eine davon: als der erste Waverunner 2004/5 auf meinem Schreibtisch stand, ist dessen Betriebssystem mehrfach abgeschmiert und eingefroren. Soweit ich mich erinnere, hatten die Windows als Plattform, was für mich ein No-Go war/ist. So ein Schrott gehört nicht in ein Messgerät. Da machen andere Hersteller mit einem Mess-OS einen weitaus besseren Job, selbst das HMO. Agilents und Teks mit Fehlern kenne ich auch genug, dagegen ist das DS4000 recht stabil und sauber implementiert - bis auf o.g. Bug - und hat sei Erscheinen weniger Fehler als die HMOs in den letzten zwei Jahren. Alles nicht schlimm, heutige Scopes sind einfach zu softwarelastig - Hauptsache die Updates kommen und die Fehler sind raus. Schönes WE!
Oszi OscBorn schrieb: > Nö, sowas macht der Hersteller i.d.R. in ein paar Monaten. Dann sollten sie sich bei manchen Scopes vielleicht noch etwas mehr Zeit für's Testen und Debuggen nehmen, auch wenn die BWLer dann maulig sind. Kein Name schrieb: > Rigol verkauft dagegen große Stückzahlen an Leute, die 999€/1999€/2999€ > ausgeben wollen. Wenn du einen Fehler meldest, entscheiden erst mal die > BWLer, ob sich der Aufwand rechnet. Ob sie mehr Geräte verkaufen, wenn > sie die bekannten Fehler beheben, oder ob sie mehr Geräte verkaufen, > wenn sie neue Features einbauen. Dann muß man den BWLern durch entsprechende Rückmeldungen und potentiellen zukünftigen Käufern durch Verbreitung auftretender Fehler in Internetforen mal klar machen, dass die Featureitis nicht das alleinige Glück der Welt ist, sondern ein Gerät, was fehlerfrei tut was es verspricht, durchaus ein Verkaufsargument ist.
Sicher gibt es verschiedene Präferenzen, die man bei einem Scope haben kann. Das hängt vermutlich auch davon ab, ob man es vorher gewohnt war, mit analogen Scopes zu arbeiten oder gleich mit digitalen angefangen hat. Außerdem gibt es natürlich einfach Aufgaben, die spezielle Features benötigen. Nur mal so als Beispiel: In der Firma müssen wir relativ viele Messungen machen, mit denen wir nachweisen müssen, daß ein Ereignis A in einem bestimmten Zeitfenster zu Ereignis B stattfindet (z.B. 50µs). Oder wir müssen Die Auflösung des Tastverhältnisses von PWMs meßtechnisch nachweisen bzw. wie groß der Fehler bei bestimmten Tastverhältnissen und Frequenzen ist. In einigen speziellen Fällen braucht man dazu nicht nur eine genaue, von der Bildschirmauflösung unabhängige Automatikmessung mit Statistik, sondern auch ein ausgereiftes Triggersystem (komplexe Bedingungen und/oder kaskadierbar) und die Möglichkeit, die Automatikmessung nur in einem bestimmten Bereich des Meßfensters zu machen (Gating), also z.B. nur direkt nach der Triggerbedingung. Und in all diesen Fällen braucht man optimalerweise einen Screenshot zur Dokumentation, in dem die Messung mit voller Genauigkeit und Statistik zu sehen ist. Man denkt halt immer, daß man nicht der einzige ist, der ein Oszilloskop für solche Zwecke einsetzt und insofern verwundert es mich schon sehr, daß es z.B. von Agilent IMHO in absolut keiner Preisklasse ein Scope gibt, das auch nur eines dieser Features besitzt. Auch die >10k€ Scopes von Agilent haben weder vernünftige Triggerbedingungen, noch messen sie automatisch im Meßspeicher, noch erlauben sie Gating oder haben ansonsten eine brauchbar implementiert Automatikmessung. Stattdessen geht es in Agilentprospekten fast ausschließlich darum, daß sie mal wieder noch mehr wfs/s können. Obwohl ich noch nicht mit moderneren Teks gearbeitet habe, befürchte ich irgendwie fast, daß es bei den DPOs in eine ähnliche Richtung geht und die TDS-Scopes haben ohnehin lächerliche Speichertiefen. Von Yokogawa und R&S habe ich viel Gutes gehört, aber die sind halt etwas exotisch und liegen preislich eher über LeCroy. Wie auch immer: ich hoffe halt immer, daß mal ein Hersteller die Chance wahrnimmt, über beeindruckende technische Daten hinaus mal wirklich ein bezahlbares Scope mit vernünftigen Meß- und Triggerfunktionen auf den Markt zu werfen. Da bin ich natürlich nicht wirklich begeistert, wenn Rigol und Hameg beide die Chance vertun, mit einer wirklich durchdachten Meßfunktionen zu punkten. Schließlich muß ich immer unserem Chef erklären, warum alles unter einem Waverunner für uns nur sehr eingeschränkt nutzbar ist ;) Nebenbei habe ich nicht die Preise der Rigols kritisiert, sondern die Preise der Protokolloptionen. Bei Rigol kostet ein Protokoll soviel wie bei Agilent und Tek ein Bundle aus 2 Protokollen. Nur LeCroy ist nochmal deutlich teurer. Und um es nochmal auf den Punkt zu bringen: eher friert die Hölle zu, als daß ich mich davon überzeugen lasse, daß es in irgendeinem Universum sinnvoll sein könnte, Messungen im Displayspeicher zu machen, wenn man Daten mit viel höherer Auflösung im Abtastspeicher hat. Das ist entweder schlampig entworfen bzw. implementiert oder (was ich zumindest bei Agilent fast eher glaube) ein Nebenprodukt des Waveform/s-Fetischismus, für den so viel Augenmerk auf den möglichst schnellen Transfer in der Displayspeicher gelegt wurde, daß die für Meßfunktion vermutlich ebenfalls vom ASIC im Displayspeicher gemacht wird. Und was das Gating angeht: wenn man ein gepulstes PWM hat oder vor mir aus ein PWM, bei dem zwecks Synchronisation ab und an eine oder mehrere Perioden fehlen, dann muß eine vernünftige Automatikmessung so konfigurierbar sein, daß man z.B. auf solch eine Lücke triggert und dann mit das Meßfenster so legt, daß nur normale Perioden erfaßt werden, damit die Lücken die Messung nicht verfälschen. Außerdem müssen natürlich für die Stastistik alle Perioden in diesem Fenster erfaßt werden und nicht z.B. nur die erste, wie es IMHO Tek, Hameg und Rigol machen. Ich verstehe nicht so recht, was daran so schwer ist, wenn man nicht wirklich an jedem FPGA-Gatter sparen muß. Also klar, von einem Owon erwarte ich das nicht, aber von Hameg an aufwärts würde ich eigentlich schon annehmen, daß man nicht einfach die erstbeste Minimallösung implementiert, sondern sich schon mal ein paar Gedanken macht.
Hallo Volker, ich stimme dir zu, dass die Hersteller oft zu wenig die realen Anwendungen berücksichtigen. Und du hast Recht, gerade was Agilent angeht, ist mir durch dein Beispiel erst einmal aufgefallen, wie dumm es ist, wenn sich die Genauigkeit in Abhängigkeit der Timebase ändert. Noch dümmer, wenn das ältere 54622 sich so verhält wie auch die neueren Scopes. Da bin ich ja schon froh, dass Hameg wenigstens die Genauigkeit hält, wenn man die Timebase ändert. Ich war zudem erstaunt, als wir in der Firma das DSO6034 erhielten, und zum Preis von über 8000,-€ viele Funktionen nicht mehr drin hatten, die im alten 54622D noch enthalten waren. Die will Agilent extra bezahlt haben, das zu horrenden Preisen. Da fährt man mit Hameg ja schon besser! Die wfm/s sind auch aus meiner Sicht mehr Marketing als Notwendigkeit, da habe ich hier auch schon mächtig gegengehalten. Brauchen tut man sie nur für wenige Anwendungen, allerdings wollte ich anmerken, dass Rigol sie schon für weitaus weniger anbietet, und wenn dann mal Jitter oder Spikes genauer untersucht werden sollen, ist es eben angenehm, dieses nice-to-have Feature für Preise weit unter Agilent mit dabeizuhaben. Die Rigol-Optionen sind sicher zu teuer, sehe ich auch so. Die haben sich klar an Agilent-Preisen orientiert und sind 60,-€ darunter geblieben, um etwas billiger zu sein. Hatte diese bei Hameg schon dabei, war die Datatec-Bonusaktion. Selbst wenn man diese zusätzlich kaufen muss, ist sie vergleichsweise günstig und auch weitaus leistungsfähiger. Ach ja, Hameg. Da habe ich die letzten 2 Jahre schon so einige Buglisten gemailt, sowohl was das HMO als auch den HMF-Generator angeht. Auch die neue Suchfunktion ist sicher klasse gemacht, allerdings habe ich soeben wieder einen Bug gefunden, den ich wieder mal reporten werde. Anfangs habe ich nur den Kopf geschüttelt, wie die Hersteller insgesamt die Geräte heute mehr beim Kunden reifen lassen, statt sie selbst anständig zu debuggen. Eigentlich bezahle ich für ein gut validiertes Gerät, nicht für Betaversionen. Nachdem ich aber selbst bei den teuren Geräten so einige Bugs gefunden habe, schone ich meine Nerven und denke lieber nicht mehr drüber nach. Das Rigol hätte ich mir sicher nicht gekauft und mir die zusätzlichen 1950,-€ gespart, wenn Hameg den Zoom im gestoppten Rollmode implementiert hätte. Wird wohl auch nicht mehr kommen. Hast recht, anders kann man's nicht kommentieren. Die Scopehersteller sollten lieber ihre bestehende Palette besser pflegen, als dauernd neue Geräte rauszuhauen. Wertarbeit ist der Globalisierung geopfert worden.
Was die Agilents angeht: wir haben in der Firma mehrere MSOs aus der 7000A Serie und da gibt es selbst optional praktisch keine Features. Trotz innerer Widerstände habe ich kürzlich noch ein DSOX3024 mit ein paar Optionen für die Abteilung bestellt - einfach weil nicht mehr genug Geld für ein LeCroy da war und sich einige meiner Kollegen noch mit Urgestein aus den frühen 90ern rumquälen. Dort ist es wiederum das Gegenteil: da kann man den Preis des Scopes locker verdreifachen, wenn man noch ein paar Features kauft und jeder Scheiß ist nur optional - selbst Kram wie der Maskentest, die Speicherwerweiterung auf 4Mpts usw. Leider immer noch nicht da - würde trotz allem gerne damit rumspielen, um meine Vorurteile zu verlieren oder (wahrscheinlicher) zu erhärten... Und zu den Hameg: was mich da in der Tat etwas irritiert ist, daß die Firmware der "großen" HMOs zuletzt vor einem Jahr geändert wurde (6/2011). Angesichts der Tatsache, daß es noch keine Nachfolger, aber ja wohl noch Bugs gibt, ist das jetzt nicht unbedingt mein Verständnis von tollem Support. Und wenn man als deutsches Unternehmen gegen China-Billigkonkurrenz bestehen will, sollte man eigentlich nicht am Support sparen. Aber ok, haben vermutlich nicht die Ingenieure beschlossen. Bestimmt gab's nach der Übernahme durch R&S erstmal eine Restrukturierung mit neuen Ergebniszielen (doppelter Umsatz bei halbierten Entwicklungskosten oder so). Ist ja inzwischen überall so. Na ja, mal sehen. Ich hatte ja zumindest gehofft, daß das DS4000 bzw. die bald erscheinenden DS2000er die Preise bei Hameg, Agilent und Tek etwas rutschen lassen. Ist nur leider bislang nicht wirklich eingetreten. Leider ist nur das Tek DPO2000 in den letzten Monaten signifikant preiswerter geworden und das hat 'ne gruselige Auflösung und gar keine Statistik...
Volker O. schrieb: > Und zu den Hameg: was mich da in der Tat etwas irritiert ist, daß die > Firmware der "großen" HMOs zuletzt vor einem Jahr geändert wurde > (6/2011). Angesichts der Tatsache, daß es noch keine Nachfolger, aber ja > wohl noch Bugs gibt, ist das jetzt nicht unbedingt mein Verständnis von > tollem Support. Doch, das Update gibt es, es wird nur aus gutem Grund nicht auf den Server gelegt. Hameg muss die großen HMOs umbauen, weil die Firmware sonst nicht läuft - muss eingesendet werden. Die kleinen HMOs sind neuer, da geht's auch ohne. Mein HMO war Anfang des Jahres weg, hat also neue Hardware und Firmware. Volker O. schrieb: > Angesichts der Tatsache, daß es noch keine Nachfolger, aber ja > wohl noch Bugs gibt, ist das jetzt nicht unbedingt mein Verständnis von > tollem Support. Und wenn man als deutsches Unternehmen gegen > China-Billigkonkurrenz bestehen will, sollte man eigentlich nicht am > Support sparen. Aber ok, haben vermutlich nicht die Ingenieure > beschlossen. Bestimmt gab's nach der Übernahme durch R&S erstmal eine > Restrukturierung mit neuen Ergebniszielen (doppelter Umsatz bei > halbierten Entwicklungskosten oder so). Ist ja inzwischen überall so. Genau so ist es. Volker O. schrieb: > Na ja, mal sehen. Ich hatte ja zumindest gehofft, daß das DS4000 bzw. > die bald erscheinenden DS2000er die Preise bei Hameg, Agilent und Tek > etwas rutschen lassen. Wird wohl schwierig, den entwickelt wird mit deutschen Lohnkosten - was mich nicht stört, sichert Arbeitsplätze. Allerdings sollten die ihre Updates mal schneller und sauberer releasen. Volker O. schrieb: > Leider ist nur das Tek DPO2000 in den letzten Monaten > signifikant preiswerter geworden und das hat 'ne gruselige Auflösung und > gar keine Statistik... Ja, gefällt mir auch nicht. Verstehe nicht, was Tek da macht. Die Geräte, die was taugen, sind alle wiederum zu teuer. Bin mit dem HMO trotz der kleineren Querelen sonst sehr zufrieden. Hameg ist halt ressourcenmäßig nicht so ausgestattet wie die Großen, deshalb irgendwo noch verzeihbar.
Ok, unterm Strich sind mir die HMOs schon auch sympathisch. Aber für privat dann halt doch noch zu teuer, zumal ich dann schon gerne das 2024 hätte. Aber nur für den unwahrscheinlichen Fall, daß ich mir eines fernen Tages ein günstiges "großes" HMO bei eBay schießen kann: ab welcher Firmwareversion kann man denn sicher sein, daß kein Umbau mehr notwendig ist? Und läuft der Umbau grundsätzlich kostenlos oder nur innerhalb einer Kulanzzeit oder am Ende gar nicht?
Volker O. schrieb: > Ok, unterm Strich sind mir die HMOs schon auch sympathisch. Aber für > privat dann halt doch noch zu teuer, zumal ich dann schon gerne das 2024 > hätte. Natürlich war das bei mir privat auch keine Kurzschluß-Entscheidung, aber nachdem ich in den 90ern lange mit meinem HM407 als Student gearbeitet hatte, wollte ich ein anständiges Scope mit guter Zoomfunktion sowie mind. 4MB Speicher. Da neben der Nachrichtentechnik auch der embedded-Bereich vertreten ist, habe ich das HMO als ideal für diese Aufgabe erworben. Das 2024 ist eines der neuen HMOs, dass die Firmware eh schon drin hat. Die Displays der HMOs sind klasse, und im Gegensatz zum Rigol hört man die Kisten überhaupt nicht. Ich habe neben dem HMO auch den HMF-Funktionsgenerator. Die Kiste war am Anfang eine echte Katastrophe. Da haben sie die gesamte Firmware neu entwickelt, seitdem läuft er recht stabil, wenn ich auch da schon einige Buglisten an Hameg gemailt habe. Updates sind da aus kosmetischen wie auch funktionalen Gründen sicher noch notwendig, wenn man auch mit dem Gerät inzwischen gut arbeiten kann. Ich nutze ihn derzeit besonders mit Arbiträrsignalen, die ich mit MATLAB generiere und dann als CSV-File an den HMF übertrage. Ebenfalls nehme ich Screenshots vom HMO und speichere sie per Memorystick direkt auf den HMF. Feine Sache, wenn es um Signale mit proprietären Datenformaten geht! Wenn man von Hand in Excel Signale anlegen will, geht das mit dem HMF auch recht einfach, um Weiten weniger kompliziert als beim Rigol DG1022, den ich auch hier stehen habe. Da konnte ich mir erst einmal ein Makro besorgen, um da mit Excel ohne dieses Ultrawave-Gedrisse eigene Signale zu erzeugen. Volker O. schrieb: > ber nur für den unwahrscheinlichen Fall, daß ich mir eines fernen Tages > ein günstiges "großes" HMO bei eBay schießen kann: ab welcher > Firmwareversion kann man denn sicher sein, daß kein Umbau mehr notwendig > ist? Bei mir ist die 4er-Version geflashed. Dies ist schon wieder eine Neuere des noch nicht erhältlichen Updates, weil ich einen Fehler mit Kanal_1 entdeckt hatte und der Support mir einige Wochen später dann diese gemailt hat. Seitdem sind viele Bugs der neuen Version gefixed. Volker O. schrieb: > Und läuft der Umbau grundsätzlich kostenlos oder nur innerhalb > einer Kulanzzeit oder am Ende gar nicht? Bei mir war's auf Kulanz, denke, dass ist bei allen großen HMOs, die bis ca. Mitte letzten Jahres gebaut worden sind, der Fall. Die neueren Großen der letzten Monate müssen wohl nicht mehr eingesendet werden, die sind schon korrekt gebaut. "Gar nicht" kann ich mir nicht vorstellen, denn dann könnte ein guter Teil der HMO-Besitzer kein zukünftiges Update mehr flashen, das kann Hameg wohl kaum machen, weder im rechtlichen Sinne wie auch aus Gründen der Kundenfreundlichkeit. Da ich viel mit Hameg in Kontakt stand/stehe, war ich einer der Ersten, die den Umbau bekommen haben. Denke, sie sammeln derzeit von den Kunden mit Update erste Berichte und Bugreports, um dann dem Rest eine bereinigte Version anbieten zu können.
OK, Danke für die Infos. Nebenbei, weil Du den HMF und Rigol DG erwähnt hast: der Agilent 33521A (bzw. 33522A als 2-Kanal-Lösung) ist ein wirklich toller Arbiträrgenerator. 1ppm Zeitbasis, Jitter im Picosekundenbereich, 1MPts Arbiträrspeicher, den man preiswert auf 16MPts erweitern kann. Und dazu wirklich komplett über USB/VISA fernsteuerbar. Und das für 1200€ (netto)... Nur die Software dafür (Waveform Builder Pro) ist unverhältnismäßig teuer, aber man braucht sie nicht wirklich, weil man die Signale halt einfach per Script oder Programm generieren und dann per USB einspielen kann. Ist ein einfaches Textformat.
Hallo, ja, die Agilent Funktionsgeneratoren kenne ich. Bevor die von dir genannten herauskamen, hatte ich mir in der Firma den 33220A gekauft. Der verrichtet auch seine Dienste, allerdings kam ich dann auf den HMF2525, der bis zu 256kPts pro Signal macht, insgesamt 4MPts Speicher hat und 250MSa/s abtastet. Agilent kam dann später mit der neuen Serie.
Meine ehemalige Firma hatte sich hinreissen lassen und 2 Rigols dieser Serie gekauft. Da man ja nichts schlecht reden darf, halte ich mich mit Kommentaren zurück. Vielleicht soviel: Ich werde mir keins davon kaufen :-9
Robert K. schrieb: > Meine ehemalige Firma hatte sich hinreissen lassen und 2 Rigols dieser > Serie gekauft. Da man ja nichts schlecht reden darf, halte ich mich mit > Kommentaren zurück. Vielleicht soviel: Ich werde mir keins davon kaufen > :-9 Hallo, also deinen Eiwand verstehe ich nicht, natürlich darfst du hier negative Kritik äußern, völlig demokratisch. Wenn man aber die positiven Eigenschaften hier hervorhebt, was ich ja ebenfalls getan habe, so muss ich Volker auch Recht geben, was die Nachteile der 4000er Serie angeht. Man sollte nur den Funktionsumgang und Geräte aus gleichem Preissegment vergleichen, sonst macht's keinen Sinn. Denke, dass die Diskussion hier eigentlich recht fair und sachlich abläuft. Gruß Gunb
@Robert K.: An deinen Ansichten zum RIGOL wäre ich noch immer interessiert. Was ist denn nun so schlecht am DS4000? In meinem HMO habe ich derzeit auch wieder Bugs entdeckt, und die sind nicht ohne, einer führt zum Totalabsturz. Wahrscheinlich darf ich es nun zum 4.ten Mal einsenden, bin ziemlich sauer! Verglichen damit ist das RIGOL DS4012 ein fehlerfreies Scope. Gruß Gunb
Sorry, aber ich muß nochmal nerven: Zum Rigol: 1) Wie laut ist es denn im vergleich zu einem sehr leisen Hameg oder einigermaßen leisen Agilent? Eher laut oder noch ok? 2) Wieviele Nachkommastellen zeigt es bei automatischen und manuellen Messungen an, wenn man drei Vorkommastellen hat (100.1µs oder 100.10µs usw.)? 3) Hat sich der Support schon zu dem Cursorbug geäußert? Und gibt es überhaupt irgendwo frei zugängliche Firmwareupdates und Änderungshistorien? Und zum Hameg HMO: 1) Sehe ich das richtig, daß das HMO bei Messungen (automatisch und manuell) maximal 2 Nachkommastellen anzeigt (also z.B. 100.01µs?). 2) Kann man beim A/B-Trigger einen anderen Kanal für den B-Trigger wählen oder ist das nur ein B-Ereignis auf dem selben Kanal? Nebenbei: weil ich oben auf die Agilents geschimpft habe: wir haben inzwischen unser DSO-X3024 bekommen und es ist eigentlich ganz nett. Hat zwar nach wie vor ein paar Macken, aber auch deutliche Verbesserungen zur den 7000ern, die mich so sehr nerven. z.B. hat es zwar auch keinen Knopf für Auto/Normal-Trigger, aber man kann einen Utility-Knopf entsprechend belegen. Und es mißt zwar nach wie vor im Displayspeicher, zeigt bei automatischen Messungen zwei Nachkommastellen an, die auch noch bei mäßigen Rauszoomen einigermaßen exakt sind. Und bei der manuellen Messung mißt es auf Nanosekunden genau und behält den Meßwert auch dann, wenn man komplett rauszoomt. Gating gibt's auch noch nicht, aber wenn man das Zoomfenster "fein" verstellt, kann man einigermaßen was Ähnliches hinkommen. Von diesen Macken abgesehen kein schlechtes Scope für den Preis. Privat wär's mir allerdings noch einen Tausender zu teuer.
Volker O. schrieb: > 1) Wie laut ist es denn im vergleich zu einem sehr leisen Hameg oder > einigermaßen leisen Agilent? Eher laut oder noch ok? HMO hört man nicht, Rigol in etwa wie alte Agilents, etwas leiser aber gut hörbar. Bin da nicht ganz so empfindlich, aber vielleicht nach den 3 Jahren Garantie neuer Lüfter. Volker O. schrieb: > 2) Wieviele Nachkommastellen zeigt es bei automatischen und manuellen > Messungen an, wenn man drei Vorkommastellen hat (100.1µs oder 100.10µs > usw.)? Ersteres, 1. Volker O. schrieb: > 3) Hat sich der Support schon zu dem Cursorbug geäußert? Und gibt es > überhaupt irgendwo frei zugängliche Firmwareupdates und > Änderungshistorien? Cursorbug bestätigt und nach Peking gemeldet. Ein paar Wochen muss man denen schon geben, dauert bei den anderen auch. Dafür, dass die Geräte erst seit letztem Jahr im September auf dem Markt sind, läuft die Firmware recht sauber, wenn man das mal mit anderen Herstellern vergleicht, und da weiss ich, wovon ich spreche. Firmware gibt's nicht direkt, nur über Händler/Support. Volker O. schrieb: > Und zum Hameg HMO: > 1) Sehe ich das richtig, daß das HMO bei Messungen (automatisch und > manuell) maximal 2 Nachkommastellen anzeigt (also z.B. 100.01µs?). ja. Volker O. schrieb: > 2) Kann man beim A/B-Trigger einen anderen Kanal für den B-Trigger > wählen oder ist das nur ein B-Ereignis auf dem selben Kanal? 1 Kanal, macht Sinn, dafür ist die Funktion gedacht. Bedingungen auf 2 Kanälen gehören eher in den Digibereich, dass geht dann mit den Digitalprobes. Volker O. schrieb: > wir haben > inzwischen unser DSO-X3024 bekommen und es ist eigentlich ganz nett. und genau den Kisten habe ich das Rigol vorgezogen, weil: - echte 1mV/DIV, statt 2mV/DIV bei Agilent - 140MPts Speicher serienmässig statt 2MPts, wobei weitere 2MPts bei Agilent stolze 391,-€ netto zzgl. MwST. kosten - Jogdial für Speichersuche - Recorderfunktion - Preis: 1900,-€ statt 2600,-€ für 100MHz-Modelle und 2 Kanäle. Volker O. schrieb: > Und es mißt zwar nach wie vor im Displayspeicher, So lange ich messen kann, ist mir das eigentlich recht egal. Hauptsache, Rigol unternimmt etwas mit Hinblick auf die Cursor. Volker O. schrieb: > Von diesen Macken abgesehen kein schlechtes Scope für den Preis. Na wenn du nun so argumentierst, kannst du auch das Rigol in Betracht ziehen - vorausgesetzt, sie bugfixen die Cursormessung. Denn billiger als das 3000er Agilent ist es allemal, von der Bedienung finde ich es besser, vom Speicher sowieso. Ich habe das 4000er Rigol einfach mal kommen lassen, um es zu testen. Am Ende habe ich es behalten, weil es mehr konnte, als auf den ersten Blick aus der Anleitung ersichtlich war - den Zoom im gestoppten Roll-Mode - und das genau fehlt mir im HMO, sonst hätte ich sicher nur das HMO hier stehen.
Na ja, wie gesagt, auf den ersten Blick klingen die DS4000er schon sehr sexy. Und die DS2000er sind ihnen sehr ähnlich und haben neben einem niedrigerem Grundpreis sehr (!) viel günstigere Dekodieroptionen. Gibt halt nur keine 4-kanaligen Versionen und die SPI-Dekodierung unterstützt keinen CS über ext. Trigger wie die Hamegs. Aber das Fehlen exakter Meßmöglichkeiten und einer Suchfunktion im Speicher relativieren den Vorteil des großen Speichers. Ehrlich: einen Puls zwischen 100 und 999µs nur auf 100ns genau messen zu können, empfinde ich als erheblichen Designfehler. Die 10ns bei den Hamegs machen mich auch nicht glücklich, aber das wäre gerade noch so diskutabel. Dann noch das Fehlen einiger automatischen Messungen und ich habe schon drei Punkte, die mir die Freude an einem Rigol verleiden. Daß es keine frei verfügbaren Downloads gibt, ist dann nur noch der letzte Nagel im Sarg. Kunden für Updates betteln zu lassen, ist allgemein kein gutes Zeichen. Und was den A/B-Trigger angeht: andere Scopes haben durchaus Triggeroptionen über zwei Kanäle. Auch das DSOX3000 und das Rigol DS2000 können das (letzteres allerdings nur mit optionalem Triggerpaket AT-DS2. Ist also durchaus keine typisch digitale Option und ich habe sowas auch schon ein paarmal gebraucht. Kein wirkliches Must-Have, aber nett zu haben.
Sorry, aber diese Diskussion ist langsam ein Witz. Du fragst etwas und weisst anschliessend alles besser. Also ich kenne die Vor- und Nachteile in den betrachteten Preissegmenten selbst, unnötig mir das zu erklären. Jeder, der ein Messgerät kauft, sollte vorher die Datenblätter und/oder Manuals studieren, bei offenen Fragen die Hersteller kontaktieren und nachfragen. Jedem, der ein Scope in der Polo-Klasse kauft, ist bewußt, dass er nicht alle Funktionen geboten bekommt, die im HighEnd-Bereich vorhanden sind. Sowohl die HMOs als auch die Rigols sind nun einmal auch nach eigenen Aussagen der Hersteller Geräte, die zwar über den LowCost-Scopes wie den OWONs liegen, aber dennoch nicht mit den 7000,-Geräten konkurrieren können - und wollen. Du schimpfst einmal über Agilent, dann relativierst du wieder, dann ist dir das eine Rigol wieder nicht gut genug, dann fehlt dir am HMO wieder das andere - Entschuldigung, aber du müsstest eigentlich selbst zu dem Schluss kommen, dass es für den von dir anvisierten Preis kein Scope mit deinen Wünschen gibt! Entweder, du kaufst dann eben ein höhepreisiges Gerät, dass deinen Ansprüchen genügt, oder du musst es eben lassen, Diskussionen mit mir werden da wohl kaum etwas bringen. Ich kann nur sagen, dass Hameg einen hervorragenden Support hat, mit dem ich seit langer Zeit das ein oder andere Feature diskutiert, Bugs gemeldet habe. Erklär denen doch, was du brauchst, nicht mir zum wiederholten Male. Ich habe in den 80ern selten Scopes gesehen, die nur annähernd die Features der Geräte der heutigen Zeit besitzen, da bin ich inwzischen mehr als zufrieden, vielleicht auch gerade deswegen. Wenn ich deine Anmerkung aller deiner Beiträge mal überschaue, fasse ich zusammen, dass du eigentlich an allem etwas auszusetzen hast, bis auf LeCroy, die mir persönlich zwar nicht zusagen, aber gut, dass ist Geschmackssache, ich will und werde darüber jetzt nicht diskutieren. Man sollte nur einen Waverunner ab 7000,-€ nicht mit einem Gerät für rund 1900,-€ oder HMOs vergleichen, die bekanntlich andere Kundschaft und Marksegmente bedienen. Und Bugs in den Vergleich mit einzubeziehen, ist ebenso falsch, hier muss Gleichstand her. So, Ende der Diskussion, langsam nervt's wirklich. Der Hersteller kann dir sicher besser helfen, abgesehen davon, dass das auch im Gegensatz zu Diskussionen hier effektiver ist, die können deine Kritik nämlich als Anmerkung für zukünftige Updates aufnehmen, ich nicht.
Bin mir nicht ganz sicher, warum Du meine Kritik an offensichtlichen Implementierungsschwächen diverser Scopes so persönlich nimmst. Und ja: alle Scopes haben irgendwelche Macken und keins hat alle Features. Nur ist es halt schon nervig, wenn es an so einfachen Sachen wie dem Abschneiden von Nachkommastellen scheitert. Abgesehen davon unterscheide ich zwischen Scopes, die ich in der Firma kaufen würde und solchen, die ich privat kaufen würde. Für zuhause ziehe ich ein HMO ein Erwägung, für die Firma eher nicht. Und für die Firma ziehe ich ein Agilent in Erwägung, das ich mir privat wohl nicht kaufen würde. Sind verschiedene Anforderungspofile, die ich nicht immer aufgedröselt habe.
Volker O. schrieb: > Bin mir nicht ganz sicher, warum Du meine Kritik an offensichtlichen > Implementierungsschwächen diverser Scopes so persönlich nimmst. Der Einzige, der dass permanent macht, bist du selbst. Mich stören sie nicht, geht aus meinen Aussagen oben hervor. Was nervt, sind deine Wiederholungen. Die meisten älteren Kollegen haben mehrere Geräte im Heimlabor oder am Arbeitsplatz, die Antwort auf das Warum sollte klar sein. Volker O. schrieb: > Und ja: > alle Scopes haben irgendwelche Macken und keins hat alle Features. Nö, von Bugs einmal abgesehen, die hier nicht zählen, haben Scopes wie andere Geräte auch bestimmte Zielgruppen, für die sie entwickelt worden sind, was oft dazu führt, dass ein Teil schwächer auf Kosten des anderen designed wird. Ist immer so. Volker O. schrieb: > Nur > ist es halt schon nervig, wenn es an so einfachen Sachen wie dem > Abschneiden von Nachkommastellen scheitert. Nervig sind eher Leute, die keine Messtechnik beherrschen. Wer zwei Nachkommstellen braucht, der kauft eben ein solches Gerät, das es mitbringt. Wer von einem Gerät aber mehr Nachkommastellen verlangt, als dieses auflösen kann, der sollte sich besser noch einmal mit den Grundlagen beschäftigen. Ich konnte bis dato alles messen, was ich brauchte, und dazu brauche ich nicht unbedingt "Ich will nicht denken"-Automessfunktionen, die hatte ich vor 32Jahren mit meinem ersten Scope auch nicht. Täte der Facebook-/Handygeneration von heute auch mal gut zu lernen, wie man mit Kästchenzählen weiterkommt, wenn auch nur begrenzt. Unser neuer Kollege lachte letztens über das Floppylaufwerk in meinem Agilent 54622D, ist aber nicht in der Lage, ein Scope zu bedienen, obwohl der Nachrichtentechnik - sorry, d.h. ja heute Kommunikationstechnik, studiert hat. Das sagt eigentlich alles. Volker O. schrieb: > Abgesehen davon unterscheide ich zwischen Scopes, die ich in der Firma > kaufen würde und solchen, die ich privat kaufen würde. So, tust du das? Na schön, dann hast du hier ja was gelernt. Mit Verlaub, aber das tun alle, die etwas Erfahrung haben. Volker O. schrieb: > Für zuhause ziehe > ich ein HMO ein Erwägung, ...obwohl dich das ja nicht glücklich macht... Volker O. schrieb: > Und für die Firma > ziehe ich ein Agilent in Erwägung, ... das ja deiner Meinung nach total vermurkst ist ... Volker O. schrieb: > Sind verschiedene Anforderungspofile, die ich nicht immer > aufgedröselt habe. ... die wir sicher alle haben und hier nicht nennen. Und weil's bei mir wie bei anderen Kollegen nicht anders ist, ist deine Argumentation von Anfang an eben sehr spezifisch auf dich persönlich zugeschnitten und nicht zu verallgemeinern, was von Anfang an meine Argumentation war und ist. Tja, und deswegen bin ich mit meinem gesamten privaten wie beruflichen Messgerätepark bestens bedient und weitestgehend so zufrieden, dass ich im Gegensatz zu dir weder von Implementierungsschwächen rede noch irgendetwas bis dato nicht damit messen konnte. P.S.: im Übrigen kann das Rigol auch auf 2 Nachkommastellen messen, es kommt eben darauf an, wie weit die Cursor auseinanderliegen. Ansonsten dreht man einfach an der Zeitbasis und löst feiner auf, dann steht die Genauigkeit vor dem Komma. Ich kann dir hier nicht jedes Detail dieses Scopes beschreiben, dazu habe ich weder Lust noch Zeit. Wenn's dich interessiert, lass dir ne Kiste zur Probe kommen oder wende dich an den Hersteller in Puchheim. Ansonsten würde ich mal mehr ins Manual/Datenblatt schauen, das ist beim HMO wie beim Rigol doch gar nicht so schlecht!
Ich will das jetzt nicht in allen Details auswalzen, aber um das zum Abschluß zu bringen: Wenn ich ein Scope mit >2GS/s kaufe, dann ist das ein Meßinstrument, mit dem man nach Datenblatt Zeiten im Nanosekundenbereich locker ausmessen können müßte. Das ist aber leider nicht der Fall und zu den Details der herstellerspezifischen Beschränkungen schweigen sich Handbücher und Datenblätter üblicherweise leider aus. Ich habe die Datenblätter und Handbücher vor meinem Einstieg in diesen Thread sehr genau studiert und nur Sachen gefragt, die dort nicht eindeutig beantwortet wurden. Das hast Du getan und dafür nochmal vielen Dank. Nicht persönlich nehmen, aber wenn Du Dir diesen Thread mit einigem emotionalen Abstand nochmal durchliest, wirst Du feststellen, daß ich Dich in keinster Weise angegriffen habe, während man das andersherum leider nicht konstatieren kann. Im Gegenteil hast Du Dich zu allerhand Unfreundlichkeiten hinreißen lassen, die zudem fast ausschließlich auf falschen Annahmen und Unterstellungen basieren. Aber Schwamm drüber. Ich klinke mich hier aus.
Volker O. schrieb: > Wenn ich ein Scope mit >2GS/s kaufe, dann ist das ein Meßinstrument, mit > dem man nach Datenblatt Zeiten im Nanosekundenbereich locker ausmessen > können müßte. Das ist aber leider nicht der Fall Nochmal, du kannst sowohl beim Rigol wie beim HMO locker im ns-Bereich messen, wenn du die Zeitbasis z.B. auf sagen wir 100ns/DIV einstellst und die Cursor in diesem Rahmen setzt. Dann stehen deine ns vor dem Komma, und das ziemlich genau und verlässlich. Du kannst aber keinen 100µs-Puls mit einer Zeitbasis von z.B. 20µs/DIV mit 3 Stellen nach dem Komma messen. Der Grund dafür dürfte in der Signalverarbeitung, der Speichergröße, die nicht konstant ist, sondern von der Zeitbasis abhängt, im Double Buffering des Sample-/Bildspeichers liegen, oder sonstwo. Bei sagen wir 2,5GSa/s Abtastrate kommt alle 0.4ns ein Sample. Bei einem Display der Breite 800 Pixel könntest du ohne Weglassen von Samples maximal 320ns darstellen. Folglich müssen bei einem Puls der Breite 100µs ziemlich viele Samples ausgelassen werden, um diesen komplett auf 800 Pixel zu bekommen, was auch gemacht wird. Würde dein Cursor nun bis auf 0.4ns bei dieser Zeitbasiseinstellung genau messen, woher soll er dann die Daten nehmen, aus dem Bildspeicher oder aus dem Samplespeicher? Aus dem Bildspeicher ist einfach zu implementieren, denn dann bedeutet eine kleine Drehung am Regler ein sofortiges Bewegen des Cursors, nämlich zum nächsten angezeigten Pixel. Hingegen aus dem Samplespeicher mit einer Auflösung von 0.4ns dürftest du dich totdrehen, bis der Cursor sich mal um 1 Pixel auf dem Screen fortbewegt, denn diese werden ja interpoliert dargestellt. Denke, da wollte niemand mit arbeiten. Das kann man übrigens auch ganz einfach ausprobieren, wenn man die Cursor bei dem 100µs-Puls mal auf einen ns-Abstand einstellt und dann die Zeitbasis auf 100ns stellt. Wenn du dann die Cursor auseinanderdrehst und das mal für 100µs machst, dann Prost Mahlzeit, da kannst du dir ne Kurbel an den Regler basteln, damit du ankommst. Die Hersteller werden als nicht umsonst den gegangenen Weg beschritten haben, und das ganze Zeitbasis abhängig gemacht haben. Beim HMO ist das insofern aber brauchbar gelöst, weil du eben aufdrehen und ziemlich genau auf die Flanken justieren kannst. Beim Verstellen der Zeitbasis bleibt wenigstens die Genauigkeit erhalten. Rigol - abwarten. Es mag noch andere Lösungsansätze geben, aber in aller Regel kostet sowas mehr Aufwand, eventuell mehr oder hochwertigere Hardware, was auch immer. Dafür müssten bei gleichem Preis wohl andere Features weggelassen werden, womit der Verwendungszweck sicher recht beschränkt wäre. Da gefällts mir so besser. > und zu den Details der > herstellerspezifischen Beschränkungen schweigen sich Handbücher und > Datenblätter üblicherweise leider aus. Deshalb lässt man sich ja i.d.R. auch erst einmal ein Gerät zur Probe kommen, bevor man es kauft, und untersucht, ob es den eigenen Ansprüchen genügt. Anrufen beim Hersteller hilft, dort habe ich für Einschränkungen bei Funktionen oft eine detaillierte Erklärung des Warum bekommen. Volker O. schrieb: > Im Gegenteil hast Du Dich zu allerhand > Unfreundlichkeiten hinreißen lassen, die zudem fast ausschließlich auf > falschen Annahmen und Unterstellungen basieren. > Aber Schwamm drüber. Ich klinke mich hier aus. Irrtum, nur hast du dich dermaßen auf deinen Fall der Pulsbreitenmessung festgefahren, so dass ja scheinbar kein Gerät mehr etwas taugt, das hier nicht die perfekte Lösung liefert. Ob das Rigol nun eine Suchfunktion hat oder nicht, 140MPts zu diesem Preis sind allemal ein Hammer, da kannst du bei allen anderen Suchen. Ziehst du dir eben die DAten auf den PC, kannst die Speichertiefe ja einstellen. Wenn du dann die hobe Abastrate nimmst, die recht hohe wfm/s, die alles andere als Quatsch sind, wenn du Jitter suchst oder eben die Störer nicht kennst, auf die du Triggern willst, dann ist dieses Gerät ein klarer Agilent-Konkurrent zum besseren Preis. Meiner Meinung nach haben die bei denen während der Produktion im eigenen Haus sowieso ordentlich abgekupfert. Und wenn du beim DS4000 die Maske mit der Recorderfunktion nutzt, kannst du zumindest hier Abweichungen sehr leicht frameweise erkennen. Die werden nämlich am unteren Bildschirmrand durch verschiedene Farbabstufungen in einem extra Balken dargestellt und sind so leicht zu finden. Es ist also nicht so, dass du keine Suchfunktion hättest. Das Rigol bei den höherwertigen Geräten mehr Geld für Busoptionen als bei den kleineren nimmt, ist gängige Praxis, machen alle. Hier punktet allerdings Hameg, die die bessere Busanalyse mit mehr Funktionen bieten, und das zum vergleichsweise Dumpingpreis aller anderen. Der Support ist hier auch da, die Kombinationsmöglichkeiten sind auch erste Sahne. Ich habe lange nach einem gebrauchten Agilent 54622D gesucht, dass ich u.a. auf der Arbeit habe. Die Teile haben 100MHz, 200MSa/s Abtastrate und so um die 4MPts-Speicher. Gebrauchthändler wollen dafür noch immer locker 2000,-€, neu waren sie vor 8 Jahren bei ca. 7000,- aufwärts. Da kam das Rigol letztes Jahr und bot in allen Punkte mehr, bei gleicher Bandbreite, und kostet 1902,-€ - bis auf den Bug dem Agilent in allem überlegen und billiger - vollkommen zufrieden. So kann man das auch mal betrachten.
Gun B. schrieb: > Irrtum, nur hast du dich dermaßen auf deinen Fall der Pulsbreitenmessung > festgefahren, so dass ja scheinbar kein Gerät mehr etwas taugt, das hier > nicht die perfekte Lösung liefert. Das hat nichts mit festgefahren zu tun, sondern das sind halt meine Anforderungen - in diesem Fall sowohl beruflich als auch privat. Also werde ich sicher weder für zuhause noch für meine Abteilung ein Scope kaufen, daß diese Anforderungen nicht erfüllt. Und ganz sicher werde ich mich nicht mal eben davon überzeugen lassen, daß meine Anforderungen Quatsch sind. Sorry, aber dazu mache ich meinen Job schon zu lange. Egal, was Du denken magst: nicht jede Meinung, die Du nicht teilst, basiert grundsätzlich auf Dummheit oder Unerfahrenheit. Und das anderen Leuten dauernd zu unterstellen, macht eine sachliche Diskussion relativ schwierig. Der Fall mit den 100µs und 100.01µs ist übrigens keinesfalls konstruiert. Das mußte ich kürzlich für ein Privatprojekt nachmessen und mit meinem Owon war mir das trotz 1GS/s bzw. 2GS/s (zunächst) nicht möglich, also habe ich's dann in der Firma gemacht - was natürlich dem Sinn eines privaten Scopes etwas widerspricht. Mit einem DSOX3000 könnte ich das ausmessen, mit einem Rigol DS4000 nicht, aber auch nicht mit einem Tektronix DPO2000-4000. Mit einem Hameg HMO ginge es mal gerade eben so - wobei da die Auflösung quasi im Bereich der Meßgröße liegt. Das sagt nichts über die Fähigkeiten dieses Scopes in anderen Bereichen aus, aber die sind mir halt nicht alle ganz so wichtig wie Dir oder wem auch immer. Also sorry, wenn das für Dich kein wichtiger Fall ist, aber für mich ist es das schon. Und nein, das hat nichts mit Meßtechnik oder meiner Ignoranz zu tun - das Abschneiden von Nachkommastellen ist bloß das Resultat einer gedankenlosen Implementierung. Denn wenn man die Scope-GUI umgeht, kann man das in den Rohdaten durchaus messen. Selbst mit meinem Lowend-Owon-SDS und seiner ultramiesen Mager-PC-Software geht das. Auch bei Tek ist das mit externer Software kein Problem. Sprich: auch mit dem Rigol wird man mit voller Auflösung messen können, wenn man an die Rohdaten kommt. Aber es ist halt irgendwie auch nicht so recht befriedigend, wenn man sich für ein paar tausend Euro ein Scope hinstellt und dann doch wieder für jede kleine Messung den PC anwerfen, Scipte schreiben usw. muß, um Designfehler zu umgehen, die der Hersteller leicht vermeiden oder wenigstens korrigieren könnte.
Volker O. schrieb: > Und nein, das hat nichts mit Meßtechnik oder meiner > Ignoranz zu tun - das Abschneiden von Nachkommastellen ist bloß das > Resultat einer gedankenlosen Implementierung. Erklär mir mal anhand meines obigen Beispiels, wie du das machen würdest. Ich glaube, als Ingenieur der NAchrichtentechnik, der selbst DSPs und FPGAs neben Mikrocontrollern programmiert, bin ich da offen für deinen Implementierungsvorschlag. Mein Beispiel oben wirft ja ein Problem auf, wie würdest du das lösen? Volker O. schrieb: > Denn wenn man die > Scope-GUI umgeht, kann man das in den Rohdaten durchaus messen. Selbst > mit meinem Lowend-Owon-SDS und seiner ultramiesen Mager-PC-Software geht > das. Auch bei Tek ist das mit externer Software kein Problem. Sprich: > auch mit dem Rigol wird man mit voller Auflösung messen können, wenn man > an die Rohdaten kommt. Logisch, aber da war bisher keine Rede von, dass ist ein ganz anderes Thema. Natürlich kannst du die Rohdaten auslesen, wo die Samples dann mit der Abtastrate vorliegen. Egal welches Scope. Auch wenn das bisher nicht das Thema war, die Signalanalyse findet dann auf dem PC statt, wo du dann eben nicht in Echtzeit eine Messung vornimmst, und das im Parallelbetrieb mit anderen Prozessen, die auch bedient werden wollen, um die Echtzeitfähigkeit zu garantieren wie es dein Scope erst einmal meistern muss. Die PC-CPU bekommt dann noch Support von der GPU, die beide zusammen wohl einiges mehr an Power haben, als ein Scope, und wo dann nicht parallel noch ein Signal halbwegs zügig aktualisiert werden muss. Dafür darfst du dann aber erst einmal die ganzen Samples auf den PC schaufeln, was i.d.R. sehr lange dauert. Das wiederum zeigt aber auch, was ein modernes Scope alles in Echtzeit erledigen muss, und warum es Grenzen gibt. Und da ist es nicht einfach damit getan zu sagen, die Samples sind doch im Speicher, also brauche ich doch nur dort zu messen, wo sie liegen. Im Übrigen befindet sich ein Scope dann auch im STOP-Modus, wo anders als im normalen Refresh-Betrieb der Speicher vollgeschrieben wird und nicht andauernd in die eine Hälfte gesampelt, während die andere angezeigt wird. Ist dir das bewußt? Ein weiterer Punkt der begrenzten Ressourcen im Echtzeitbetrieb. Ich habe viel mit Hameg telefoniert. In den Gesprächen ging es oft um technische Details, und wenn ich darüber hier auch nicht sprechen werde, es gibt nun einmal Grenzen und Kompromisse, die die Hersteller zugunsten anderer Funktionen eingehen müssen und auch aus Gründen begrenzter Ressourcen. Wenn du dann mehr haben willst, musst du eben tiefer in die Tasche greifen und dir ein weitaus teureres Scope kaufen - dann weisst du auch, warum die Kisten eben so teuer sind. Mit Ignoranz hat das absolut nichts zu tun, dass kann sich heute kein Scopehersteller mehr erlauben, wenn er überleben will. Wie gesagt, ruf bei den Herstellern an, die haben gerade bei dem heutigen Konkurrenzkampf ein offenes Ohr und implementieren bei Machbarkeit oft Kundenwünsche. Mir scheinst du ja eh nicht zu glauben. Volker O. schrieb: > nd dann doch wieder > für jede kleine Messung den PC anwerfen, Scipte schreiben usw. muß War bei mir noch nie der Fall, und wenn's mal vorkommen sollte, was ich nicht ausschliesse, dann tut's mir für den Sonderfall auch nicht weh, dafür bin ich Ingenieur. Volker O. schrieb: > Aber es ist halt irgendwie auch nicht so recht befriedigend, wenn man > sich für ein paar tausend Euro ein Scope hinstellt die paar tausend Euro zahlst du ja auch für das Gesamtpaket, nicht für eine einzelne perfekte Funktion, und hier punktet gerade Hameg hervorragend mit den HMOs. Ob ich nun Hochfrequenztechnik, µC oder FPGAs mache, das HMO ist da ein super Allrounder. An deinem Implementierungsvorschlag bin ich aber dennoch sehr interessiert!
Ich sehe das Problem nicht. Natürlich kann man einen 100µs Puls mit einer 20µs-Zeitbasis mit drei Stellen nach dem Komma messen - wenn man im Samplespeicher mißt und die Abtastrate stimmt. Das macht jedes LeCroy so. Laut Tek machen das auch die DPOs so - sie beschneiden die Ergebnisse nur in der GUI. Wenn man aber die Messungen (nicht die Rohdaten!) per GPIB/VISA ausliest, bekommt man angeblich die volle Auflösung. Laut Hameg-Handbuch messen auch die HMOs immer im Samplespeicher - also stimmt das entweder nicht, oder sie schneiden ebenfalls Nachkommastellen zu Darstellungszwecken ab. Und das mit dem Cursor ist ein Scheinargument: genau dazu sollen ja die automatischen Messungen dienen. Falls die aber halt (warum auch immer) ungenau sind, muß man wenigstens die Cursor in höheren Zoomstufen genau setzen können, ohne daß einem das Scope beim Rauszoomen die Nachkommastellen abschneidet. Das können wie gesagt selbst die neueren Agilents. Offensichtlich aber weder Rigol noch Hameg noch Tek. Und mal ehrlich: dafür gibt es absolut keine sinnvolle Begründung. Egal ob man die Rohdaten auf einen PC schaufelt und dort mißt oder ob man die Messung vom FPGA/ASIC machen läßt - solange man die Rohdaten benutzt, ist das alles kein Thema. Wenn man natürlich anfängt im Displayspeicher zu messen, geht es mit der Genauigkeit den Bach runter. Mir fehlt bislang nur ein plausibler Grund, warum man das tun sollte. Meine einzige Erklärung ist, daß der Signalpfad bei Agilent (und Rigol?) so sehr auf die hohe wfs/s-Rate gemünzt ist, daß die Messung mit den echten Sampledaten gar nicht mehr möglich ist.
Volker O. schrieb: > Ich sehe das Problem nicht. Natürlich kann man einen 100µs Puls mit > einer 20µs-Zeitbasis mit drei Stellen nach dem Komma messen - wenn man > im Samplespeicher mißt und die Abtastrate stimmt. Geh doch mal auf mein Beispiel ein. Wie genau macht LeCroy das? Auch bei denen ist das Display pixelmässig begrenzt, auch LeCroy zeigt bei 100µs und einer Abtastrate von sagen wir 2,5GSa/s nicht alle Pixel des Samplespeichers an. Misst der Cursor aber im Samplespeicher, liegen diese im Abstand von 0.4ns vor. So, nun bist du wie du sagst auf der 3. Nachkommastelle, also 1ns-Schritte. Nun drehst du am Regler und du bist auf der nächsten Nanosekunde, dritte Nachkommstelle halt, ca. 3 Samples. Auch komisch, wären dann nämlich 1,2ns statt 1ns, wäre dann auch geschummelt. Nun zum Screen. Nehmen wir mal an, dass LeCroy hat 1024 Pixel, um mal großzügig zu sein (mehr oder weniger, macht den Braten nicht fett). Im Samplespeicher liegen die Samples nach obigem Beispiel im Abstand von 0.4ns vor. Deine Zeitbasis ist auf 20µs/DIV eingestellt, bei sagen wir 14DIV sind das dann insgesamt 280µs, von denen dein Puls 100µs einnimmt. Nun entsprechen: 280µs : 700.000 Samples 100µs : 250.000 Samples , die logischerweise nicht alle auf den Screen passen, auch bei LeCroy nicht. Also nimmt man eben so viele, dass es passt und den Rest erst bei Bedarf, wenn der Anwender also reinzoomed bis auf's kleinste Pixel. Rechnerisch komme ich da auf 700.000/1024 = 683, also jedes 683ste Sample wir angezeigt. Der Rest liegt dunkel im Samplespeicher und wartet eventuell gezoomed oder überschrieben zu werden. Was heisst das jetzt? Das bedeutet, dass zwischen je 2 Pixeln auf dem Screen 683 * 0.4ns = 273ns liegen. Auf einem Hameg kann man diese Sprünge beim Drehen beobachten, weil es im Bildspeicher misst. Bei LeCroy ist das deiner Aussage nach nun anders, die erlauben Drehen im 1ns-Intervall. Nehmen wir nun einmal an, dass pro Umdrehung 20ns gestellt werden, dann müsste der Anwender ca. 273/20 = 13 Umdrehungen machen, damit er den Cursor um 1 (!) Pixel auf dem Screen bewegen könnte. Bei 1024 Pixeln horizontal wären das dann 1024*13= 13312 Rotationen. Würde mich wundern, wenn das so wäre. Selbst wenn man das ganze Drehgeschwindigkeits abhängig macht, wäre das noch zum "Durchdrehen" viel. Also, wie machen die das? Ich habe kein LeCroy zur Hand, so dass ich es ausprobieren könnte. > Das macht jedes LeCroy > so. Auch die Kleinen, die man bei Reichelt bekommt? Dann kauf dir doch so eines und dein Problem müsste doch gelöst sein. Wo ist der HAken? > Laut Tek machen das auch die DPOs so - sie beschneiden die > Ergebnisse nur in der GUI. Logisch, machen alle Scopes so. Der Grund ist die begrenzte Auflösung des Screens, ich kann nicht mehr anzeigen als ich Pixel habe. > Wenn man aber die Messungen (nicht die > Rohdaten!) per GPIB/VISA ausliest, bekommt man angeblich die volle > Auflösung. Die Rohdaten sind die Basis, die Messung ist mehr oder weniger ein Ausschnitt davon. Und wenn sie dann eben nur den gerade sichtbaren Bereich plus der unsichtbaren Samples dazwischen uploaden, dann ist das auch nichts anderes als eben ein Fenster aus den Rohdaten. Macht den Upload zum PC eben schneller. Kann mein HMO auch, damit man nicht 30Minuten warten muss, bis der gesamte Speicher im PC ist. Kann man wählen, ob man das eine oder andere möchte. Hat aber alles nichts mehr mit dem Ausgangsthema zu tun. > Laut Hameg-Handbuch messen auch die HMOs immer im > Samplespeicher - also stimmt das entweder nicht, oder sie schneiden > ebenfalls Nachkommastellen zu Darstellungszwecken ab. Nein, laut Handbuch nutzen sie einen Pufferspeicher (Anleitung 250MHz/350MHz HMO Serie, Kapitel 8, S.29), der muss nicht automatisch der Samplespeicher sein. Und bevor ich mich totkurbele, ist mir das auch lieb so. > Und das mit dem Cursor ist ein Scheinargument: genau dazu sollen ja die > automatischen Messungen dienen. Falls die aber halt (warum auch immer) > ungenau sind, muß man wenigstens die Cursor in höheren Zoomstufen genau > setzen können, ohne daß einem das Scope beim Rauszoomen die > Nachkommastellen abschneidet. Das können wie gesagt selbst die neueren > Agilents. Offensichtlich aber weder Rigol noch Hameg noch Tek. Und mal > ehrlich: dafür gibt es absolut keine sinnvolle Begründung. Also irgendwie hast du's noch immer nicht verstanden: da wird nichts abgeschnitten, wenn du die Cursor auf die Flanken gesetzt hast und rauszoomst. Das habe ich dir oben schon am Anfang erklärt, da bleiben die 2 Nachkommastellen in jeder Zeitbasis beim HMO erhalten, beim Rigol kann's logischweise mit den derzeitigen Einschränkungen nicht überprüft werden. Die Nachkommastellen ändern sich nur dann in Abhängigkeit der Zeitbasis, WENN du die Cursor konstant stehen lässt, sie also nicht auf die Flanken klebst. Und dann kannst du selbst beim RIGOL im ns-Bereich sehr genau messen, nur eben keine Änderungen im ns-Bereich bei einem Puls im 100µ-Bereich. Das ginge NUR, wenn sich die Cursor beim TRACK-Mode nicht verschieben würden, wie ganz am Anfang erklärt. Echt, lass dir die Kiste kommen und probier's aus! Man kann nicht in einem Forum ein ganzes Gerät in alle Details erklären. Und wenn der Hersteller eben angibt, bis auf 2 Nachkommastellen genau zu messen, dann sind das eben die Spezifikationen des Geräts. Da braucht man nichr drüber diskutieren, das ist dann eben so. > Egal ob man die Rohdaten auf einen PC schaufelt und dort mißt oder ob > man die Messung vom FPGA/ASIC machen läßt - solange man die Rohdaten > benutzt, ist das alles kein Thema. Absoluter Quatsch. Es ist ein enormer Unterschied, ob ich in Echtzeit rechnen muss, oder offline am PC eine Sequenz analysieren lasse. Ich habe mehrere embedded OS auf ARM-Derivaten laufen, mit und ohne Bildschirmbeschleunigung. Wenn du davon etwas verstehen würdest, dann wäre dir schnell klar, wie falsch deine Aussage ist. > Wenn man natürlich anfängt im > Displayspeicher zu messen, geht es mit der Genauigkeit den Bach runter. Logisch. > Mir fehlt bislang nur ein plausibler Grund, warum man das tun sollte. Eben wegen o.g. Gründen. Und weil's den meisten Anwendern wohl genau genug ist. Beweis das Gegenteil. > Meine einzige Erklärung ist, daß der Signalpfad bei Agilent (und Rigol?) > so sehr auf die hohe wfs/s-Rate gemünzt ist, daß die Messung mit den > echten Sampledaten gar nicht mehr möglich ist. Quatsch, was du immer mit deiner wfm/s hast. Gerade die ASICs von Agilent sind sauschnell, da kommen die meisten anderen gar nicht mit. Deren Philosophie ist eben eine andere, und scheinbar haben bis dato so wenige Leute dein Problem, dass es jemanden so sehr stören würde. Komisch, wenn alle LeCroys das können, wieso hast du dir nicht schon lange ein kleines gekauft? Kosten doch nix.
Puh, diese ganze emotionale Art zu diskutieren und der zunehmend feindliche Unterton sind zwar sichere Indizien dafür, daß ich es bereuen werde, hier überhaupt gepostet zu haben. Es wäre auch hilfreich, wenn Du meine Postings nicht nur überfliegen würdest, dann würdest Du eventuell nicht dauernd Sachen in den Raum stellen, auf die ich schon eingegangen bin. Aber ok: Die Granularität der Cursorbewegung hat nichts damit zu tun, ob im Displayspeicher oder im Samplespeicher gemessen wird. Natürlich kann kann den Cursor in einer niedrigen Zoomstufe nicht unendlich fein bewegen. Aber man kann es in höheren Zoomstufen. Wenn man nun wieder herauszoomt, sollten die Cursor an ihren Positionen im Samplebuffer stehen bleiben und nicht aufgrund ihrer Positionen auf dem Bildschirm neu im Samplebuffer positioniert werden. Das macht ein DSOX3000 wie gesagt inzwischen richtig, während es ein DSO7000A noch falsch gemacht hat. Bei einer automatischen Messung gibt es das von Dir gesehene Problem ohnehin nicht. Deine Annahme, daß ein Hameg im Displayspeicher mißt, weil sich der Cursor nur gemäß der Displayauflösung bewegen läßt, widerspricht also nicht nur der klaren Aussage im Handbuch, sondern basiert alleine darauf, daß Du die Bewegung des Cursors in der Displayauflösung mit der Messung im Displayspeicher gleichsetzt, obwohl das ganz unterschiedliche Dinge sind. Natürlich ist auch nicht völlig ausgeschlossen, daß das Hameg entgegen der Herstelleraussage doch im Displayspeicher mißt - aber aus Deinen Analysen geht das eben nicht schlüssig hervor. Wenn man sich dagegen mit dem DSOX3000 ein Scope ansieht, das ganz sicher im Displayspeicher mißt (und das auch ganz klar im Handbuch sagt), dann sieht man, daß sich der automatische Meßwert in einem per Single-Trigger aufgenommenen Signal abhängig von der Zoomstufe ändert. Sprich: aus 100.01µs in einer höheren Zoomstufe werden plötzlich beim selben Signal, dem unveränderten Samplebuffer und der identischen Anzahl dargestellter Nachkommastellen 100.00µs, wenn man herauszoomt. Aber wie bereits erwähnt: das DSOX3000 unterliegt dieser eigentümlichen Beschränkung nur bei automatischen Messungen. Die manuelle Messung ist wie gesagt sehr vernünftig implementiert. Im Umkehrschluß ist jede manuelle Messung, die Nachkommastellen abschneidet oder die Positionen der Cursor im Samplebuffer beim Rauszoomen ändert, keine vernünftige Implementierung. Bei automatischen Messungen bin ich eigentlich der gleichen Meinung, aber da wäre zumindest noch denkbar, daß die Auflösungsbeschränkungen im Hardwaredesign begründet und damit nicht per SW-Update behebbar sind. Wäre für mich privat auch nicht so tragisch, solange die Messung nicht vollkommen ungenau ist und ich manuell exakt messen kann. In der Firma brauchen wir zwar exakte Automatikmessungen mit Statsitik, aber da ist ja auch genügend Geld für ein LeCroy da.
Tja, dann sind die Hersteller alle blöd, ich als Entwickler auch, und da brauchen wir jemanden wie dich, der uns allen zeigt, wie's geht ;-) Finde ich schon lustig, dass du mir dauernd was von Geräten erzählst, die ich hier stehen habe, während du nur das Handbuch kennst. Noch offene Fragen: - warum kaufst du dir kein LeCroy, wenn "JEDES" das kann, was du brauchst? - was machst du bei Automessungen, wenn der Puls im ns-Bereich stark jittert, die Zeitbasis aber im µs-Bereich steht? Die Automessfunktion würde nie einen konkreten Wert anzeigen, wenn sie im Samplespeicher messen würde. Wie machen? - warum wendest du dich nicht an die Hersteller und erklärst denen, was sie falsch machen? - wo steht im Handbuch von Hameg, dass sie im Samplespeicher messen?
Volker O. schrieb: > Die Granularität der Cursorbewegung hat nichts damit zu tun, ob im > Displayspeicher oder im Samplespeicher gemessen wird. Ganz entscheidend sogar. Geringe Zeitbasis bei hoher Abtastrate = wenig Cursorbewegung, wenn Samplespeicher. Zügiges Abklappern von Pixel zu Pixel, wenn Bildspeicher. Das nennt man nicht Granularität, sondern Empfindlichkeit.
Bin mir nicht sicher, ob Ihr mich absichtlich nicht verstehen wollt, oder es wirklich nicht tut. Bloß weil man den Cursor um einen Pixel bewegt und das halt ein Schritt von mehreren Werten im Abstastspeicher entspricht, mißt man noch lange nicht in Displayspeicher. Das Agilent mißt aber bei Automatikmessungen wirklich nicht im Samplespeicher - wie mein obiges Beispiel zeigt, das Ihr so vehement ignoriert. Daß diese ganze Cursordiskussion hanebüchen am Thema vorbei ist, habe ich ja auch schon mehrfach dargelegt und es ist mir echt zu anstrengend und deprimierend, daß jetzt noch hundertmal mit anderen Worten darzulegen, wenn Ihr die entscheidenden Teile eh ignoriert. Mit sowas schlage ich mich schon immer die ganze Woche rum, aber da werde ich wenigstens dafür bezahlt.
Volker O. schrieb: > in mir nicht sicher, ob Ihr mich absichtlich nicht verstehen wollt, > oder es wirklich nicht tut. Ich glaube, dass ist eher dein Problem, dass du nicht verstehst, was andere dir sagen wollen. Volker O. schrieb: > Bloß weil man den Cursor um einen Pixel > bewegt und das halt ein Schritt von mehreren Werten im Abstastspeicher > entspricht, mißt man noch lange nicht in Displayspeicher. Das hat ja auch niemand behauptet, am wenigsten ich. Wenn du aber die These aufstellst, dass so ziemlich alle Hersteller außer LeCroy nicht der Lage sind, hier eine anständige Lösung zu finden, dann habe ich dir oben vorgerechnet, warum das eben auch nicht so einfach ist. Und ich kann dir 300%tig garantieren, dass die Rechnung stimmt und dies auch so gemacht wird. Meine Frage an dich war/ist, wie LeCroy das dann macht, und die hast du bei allem Drumherumgelaber leider noch immer nicht beantwortet. Deine Ausgangsthese war, dass ein 100µs-Puls bei LeCroy bis auf 1ns 3 Stellen nach dem Komma aufgelöst werden kann, gleichzeitig der ganze Puls angezeigt wird. Nun gut, dass mag ja sein, dazu musst du aber sicher vorher auf die Flanken zoomen, wenn du sie von Hand so genau einstellen willst, denn auch LeCroy wird nicht darum herumkommen, bei 20µs/DIV weniger Pixel anzuzeigen, als im Samplespeicher stehen. Das geht nicht, und das habe ich dir mit o.g. Rechnung auch ausführlich gezeigt. Jedes Verstellen des Cursors bedeutet auch da mit Sicherheit, dass du auf das nächste 683te Sample springst, meinetwegen auch irgendwas dazwischen. Du wirst aber sicher bei 20µs/DIV nicht in 1ns-Schritten die Cursor ohne vorher reinzoomen zu müssen verstellen können, denn dann würde sich lange nichts bewegen, das ist absolut logisch und machen alle Scopehersteller. Bei den analogen CRTs wäre das anders, da sie nicht den horizontalen Pixelbeschränkungen unterliegen, gibt's ne sehr gute App.Note von Hameg, alt aber gut. Volker O. schrieb: > Das Agilent > mißt aber bei Automatikmessungen wirklich nicht im Samplespeicher - wie > mein obiges Beispiel zeigt, das Ihr so vehement ignoriert. Du verstehst einfach nicht, dass das niemand bestreitet! Das Thema hatten wir lange durch. Der Fehler, den du machst ist, dass du von Agilents sprichst. Ich arbeite mit 3 verschiedenen Agilents, die alle in der Lage sind, deinen Puls auszumessen. DAzu gehört aber nicht das 7000er, mit dem du arbeitest. Auch da hast du gut verständlich klar gemacht, dass man es damit nicht messen kann - genau wie mit meinem Rigol. Das ist längst akzeptiert (s. ganz oben) und wirklich Mist, wenn sowas mit solchen hochwertigen Geräten nicht geht. Ich warte deshalb auf eine Antwort von Rigol, ob das Absicht ist oder ein Bug, letzteres wäre verzeihbar, ersteres wirklich Murks, wie du es nennst. Ich hätte Agilent an deiner Stelle längst kontaktiert. Eigentlich undenkbar, dass das en Feature sein soll, statt eines Bug. Ich arbeite mit den 54622, dem 54622D und dem DSO6034, die alle die Cursor nicht verlieren, wo du aber recht hast (wie oben auch schon mehrfach akzeptiert), dass diese Geräte mit größerer Zeitbasis die NAchkommastellen abschneiden, was eher ziemlich blöd ist, wenn man wie du einen Screenshot vom Gesamten machen will - alles keine Frage, vollkommen richtig, stimme ich dir zu. Und deine Beispiele ignoriert keiner, aber es sollte auch erlaubt sein, diese zu korrigieren, und da lässt du dir wenig sagen. Deshalb versuche ich es dir noch einmal zu erklären, wie Hameg das beim HMO macht. Du schreibst: Volker O. schrieb: > Deine Annahme, daß ein Hameg im Displayspeicher mißt, weil sich der > Cursor nur gemäß der Displayauflösung bewegen läßt, widerspricht also > nicht nur der klaren Aussage im Handbuch, sondern basiert alleine > darauf, daß Du die Bewegung des Cursors in der Displayauflösung mit der > Messung im Displayspeicher gleichsetzt, obwohl das ganz unterschiedliche > Dinge sind. 1.) Habe ich eben nicht behauptet, das Hameg im Displayspeicher misst, sondern habe dir absichtlich das Dokument mit Kapitel und Seitenzahl genannt, wo's steht: Hameg miss aus einem Pufferspeicher - OK? 2.) Das widerspricht eben nicht dem Manual und auch nicht meiner Aussage, ganz im Gegenteil, man kann's leicht verifizieren, wenn man die Kiste auf dem Schreibtisch hat. 3.) Die Bewegung des Cursors passiert eben doch in Abhängigkeit der Displayauflösung, weil auch Hameg das Problem nicht aus der Welt schaffen kann, dass bei einem horizontal begrenzten Display eben bei 700.000 Samples im Speicher eben nur ein paar hundert angezeigt werden können, und sie den Cursor nicht auf den genannten 700.000 Pixel laufen lassen, wenn du bei z.B. 20µs/DIV eben diesen verstellst. Bevor du nun voreilig von einem Widerspruch ausgehst - was ich an dieser Stelle verstehen könnte, lass dir von mir erklären, was Hameg macht: Der im Manual genannte Pufferspeicher ist immer eine Kopie des gerade sichtbaren Displayspeichers - ja Displayspeicher! Warum das? Um bei deinem Beispiel zu bleiben, musst du bei manueller Messung ja die Zeitbasis so empfindlich einstellen, dass du die Flanken siehst. Also stellst du auf die linke Flanke und stellt Cursor 1 darauf. Auch hier wandert der Cursor nur auf den angezeigten Pixeln im Displayspeicher, nicht auf denen im Samplespeicher. Da aber die Zeitbasis nun kleiner ist, ist der Cursor genauer zu positionieren. Dann machst du das gleiche für die rechte Flanke, folglich zeit dir das Scope die 100.01µs genau an. Und jetzt kommt's: anders als bei Agilent, die dann die Nachkommastellen abschneiden, bleibt beim HMO die Genauigkeit erhalten, auch wenn du jetzt auf 20µs/DIV zurückdrehst. Am unteren Rand stehen nach wie vor 100.01µs. Und wie soll das gehen, wenn Hameg nun im Displayspeicher messen würde? Garnicht, denn den hast du ja verstellt. Also waren sie so schlau und haben einen kleinen Pufferspeicher bereitgestellt, der erst dann wieder updated wird, wenn der Anwender die Cursor erneut verstellt, was dann in der Genauigkeit des jetzt gerade aktuellen Bildspeichers passiert. Einfach genial gelöst. Den reinen Samplespeicher siehst du NUR, wenn du auf 2ns/DIV-Zeitbasis einstellst, dann wanderst du tatsächlich mit dem Cursor über die Pixel im 400ps-Abstand, was man auch schön sehen kann, wenn man die Interpolation abschaltet und die Cursor dann entsprechen auf die Sample&Hold-Balken stellt. Das alles steht mit meinen obigen Aussagen sowie mit dem HMO-Manual im Einklang, nur ist das eben nicht so einfach alles mit einmal Lesen zu verstehen. Ich kenne kein Scope, dass direkt im Samplespeicher misst, was außer bei der kleinsten Zeitbasis auch keinen Sinn macht. Es gibt aber sehr wohl Unterschiede beim Messen im Displayspeicher oder einer Kopie davon, wie es Hameg genialerweise macht. Ob die ns dann vor oder nach dem Komma stehen, ist mir egal, HAuptsache, ich kann sie messen. Die Autofunktionen könnten theoretisch im Samplespeicher z.B. die Hälfte der Amplitude genau finden und dann auch bei sagen wir 20µs/DIV genau messen. Das Problem ist nur, dass bei einem stark jitternden Signal bei kleinen Zeitbasen kein vernünftig stehender Wert mehr zustande käme, und da kann ich dir mehr als ein Lied von singen. Also geht man hin und verfolgt den Ansatz in der Genauigkeit der gerade eingestellten Zeitbasis zu messen und gibt so dem Anwender die Möglichkeit, ein stark im ns-Bereich jitterndes Signal im µs-Bereich noch messen zu können, weil dies hier nicht sichtbar ist. Damit mittelt die begrenzte Anzahl an angezigten Samples auch automatisch, zumindest visuell, den Zeitwert. Ich meine, dass ich dir das nun gut genug erklärt habe, und dafür auch einige Zeit aufgewendet habe. Es zeigt, dass das eben nicht mal 08/15 alles umgesetzt werden kann, wie man das persönlich gerne immer hätte, denn im Hintergrund ist manches komplizierter oder eben kompromissbehaftet umgesetzt, damit die Breite Masse der Anwender diese Funktionen auch nutzen kann. In deinem Fall brauchst du eben präzisere Geräte, wenn dir das HMO z.B. nicht reicht (war ich ja bezweifle). Geräte, die hier mehr können, können das oft nicht ohne zusätzlichen Hard- und/oder Softwareaufwand, und der kostet. Rigol DS4000 und dein DSO7000 möchte ich aus der Diskussion nun ein für alle Mal rauslassen, die können's eben nicht. Ende.
Gun B. schrieb: > Deine Ausgangsthese war, dass ein 100µs-Puls bei LeCroy bis auf 1ns 3 > Stellen nach dem Komma aufgelöst werden kann, gleichzeitig der ganze > Puls angezeigt wird. Nun gut, dass mag ja sein, dazu musst du aber > sicher vorher auf die Flanken zoomen, wenn du sie von Hand so genau > einstellen willst, denn auch LeCroy wird nicht darum herumkommen, bei > 20µs/DIV weniger Pixel anzuzeigen, als im Samplespeicher stehen. Wo soll das Problem sein? Wenn mit 1 GSPS aufgenommen wird, liegen die Daten auch mit 1ns Auflösung vor. Also sollte folgendes möglich sein: - Anfang grob suchen, Hereinzoomen, Cursor 1 (Anfang) auf 1ns genau einstellen - Herauszoomen, Ende grob suchen - Cursor 2(Ende) auf 1ns genau einstellen Schon hat man eine Genauigkeit von 1ns bei einer Pulslänge von mehrereren (100) us. Das funktioniert natürlich nur, wenn man im Samplespeicher arbeitet und nicht im Bildschirmspeicher. Aber genau das sollte technisch möglich sein.
Mine Fields schrieb: > Wo soll das Problem sein? Wenn mit 1 GSPS aufgenommen wird, liegen die > Daten auch mit 1ns Auflösung vor. Also sollte folgendes möglich sein: Also bevor hier ein Missverständnis passiert: für mich ist das kein Problem ;-) Mine Fields schrieb: > - Anfang grob suchen, Hereinzoomen, Cursor 1 (Anfang) auf 1ns genau > einstellen > - Herauszoomen, Ende grob suchen > - Cursor 2(Ende) auf 1ns genau einstellen > > Schon hat man eine Genauigkeit von 1ns bei einer Pulslänge von > mehrereren (100) us. Ganz genau, korrekt. Irgendwie gibt's aber Leute, denen das zu viel ist und deswegen von den Automessfunktionen genau dies Schritte erwarten, was die aber nicht machen, weil sie eben auf dem Bildspeicher und nicht dem Samplespeicher arbeiten. Tja, die zeigen dann eben im Rahmen der Genauigkeit der aktuellen Zeitbasis an, was für mich bis heute kein Problem darstellt. Will ich genau messen, mache ich's wie du es beschrieben hast. Bei den meisten Geräten geht das tadellos, beim Rigol DS4012 und dem Agilent DSO7000 scheint hier ein Bug, die verlieren immer den gerade nicht aktiven Cursor. Sowas ist natürlich Mist. Mine Fields schrieb: > Das funktioniert natürlich nur, wenn man im Samplespeicher arbeitet und > nicht im Bildschirmspeicher. Das stimmt nicht, und genau das habe ich oben beschrieben, sogar rechnerisch gezeigt. Entscheidend ist, dass du soweit reinzoomst und damit immer weniger Samples zwischen je zwei ausgelassen werden, dass du die geforderte Genauigkeit erreichen kannst. Und entscheidend ist, dass das Scope diese Genauikeit dann bei rauszoomen nicht wieder verliert, was das HMO per Pufferspeicher erreicht. Auch die Agilents werden so machen, nur das meine älteren dann die Nachkommstellen nicht mehr anzeigen. Beim Reinzoomen stimmt's aber noch, also speichern sie ebenfalls. Hameg zeigt so lange das zuvor gezoomte Resultat an, bis man die Cursor wieder verstellt - und das ist besser. Ein Ausschnitt des Samplespeicher ist bei einem Scope erst dann 1:1 sichtbar, wenn auf die gesamte Horizontale bei gegebener Zeitbasis die Samples im Abstand der Abtastrate passen.
Gun B. schrieb: > Ganz genau, korrekt. Irgendwie gibt's aber Leute, denen das zu viel ist > und deswegen von den Automessfunktionen genau dies Schritte erwarten, > was die aber nicht machen, weil sie eben auf dem Bildspeicher und nicht > dem Samplespeicher arbeiten. Tja, die zeigen dann eben im Rahmen der > Genauigkeit der aktuellen Zeitbasis an, was für mich bis heute kein > Problem darstellt. Wieso sollten sie? Wenn ich z.B. eine Effektivwertmessung möchte, erwarte ich, dass diese auch mit 1 GPSPS (bzw. mit allen gespeicherten Samples) gerechnet werden, völlig unabhängig von der gerade eingestellten Zeitbasis.
Mine Fields schrieb: > Gun B. schrieb: >> Ganz genau, korrekt. Irgendwie gibt's aber Leute, denen das zu viel ist >> und deswegen von den Automessfunktionen genau dies Schritte erwarten, >> was die aber nicht machen, weil sie eben auf dem Bildspeicher und nicht >> dem Samplespeicher arbeiten. Tja, die zeigen dann eben im Rahmen der >> Genauigkeit der aktuellen Zeitbasis an, was für mich bis heute kein >> Problem darstellt. > > Wieso sollten sie? Wenn ich z.B. eine Effektivwertmessung möchte, > erwarte ich, dass diese auch mit 1 GPSPS (bzw. mit allen gespeicherten > Samples) gerechnet werden, völlig unabhängig von der gerade > eingestellten Zeitbasis. Meinetwegen, habe nichts dagegen. Tatsache ist aber, dass der Kollege sich darüber beschwert, dass ihm der 100.01µs-Puls mit den Automessfunktionen nicht eben so genau angezeigt wird, und dass eben, weil diese auf dem Bildspeicher arbeiten, statt auf dem Samplespeicher - kann ich leider nix dafür, deswegen: bitte bei den Herstellern meckern. Sag du uns, warum sie das nicht machen?
Mine Fields schrieb: > Wo soll das Problem sein? Wenn mit 1 GSPS aufgenommen wird, liegen die > Daten auch mit 1ns Auflösung vor. Also sollte folgendes möglich sein: > > - Anfang grob suchen, Hereinzoomen, Cursor 1 (Anfang) auf 1ns genau > einstellen > - Herauszoomen, Ende grob suchen > - Cursor 2(Ende) auf 1ns genau einstellen > > Schon hat man eine Genauigkeit von 1ns bei einer Pulslänge von > mehrereren (100) us. > Klar, das ist bei einer ordentlich implementierten manuellen Messung kein Problem. Aber leider schneiden viele Scopes dabei Nachkommastellen ab. Ein Rigol DS4000 kürzt das Delta zwischen den Cursorpositionen auf 4 Stellen und reduziert die Genauigkeit auf 100ns. Ein Tek kürzt sogar auf drei Stellen -> 1µs. Ein HMO kürzt auf 5 Stellen -> 10ns. Ältere Agilents schneiden messen beim Rauszoomen in der Bildschirmauflösung neu -> Messung abhängig von Zoomlevel. All das ist natürlich suboptimal, auch wenn GunB das offensichtlich anders sieht - oder auch nicht. Wer weiß das schon bei seiner Argumentationsstrategie. > Das funktioniert natürlich nur, wenn man im Samplespeicher arbeitet und > nicht im Bildschirmspeicher. Aber genau das sollte technisch möglich > sein. > Eben. Und bei Automatikmessungen sollte das schon gar kein Problem sein. Auch wenn von mir aus das letzte Bit jittert. Alles noch lange kein Grund, die Messung auf 100ns oder gar eine µs zu verkrüppeln.
Gun B. schrieb: > Meinetwegen, habe nichts dagegen. Tatsache ist aber, dass der Kollege > sich darüber beschwert, dass ihm der 100.01µs-Puls mit den > Automessfunktionen nicht eben so genau angezeigt wird, und dass eben, > weil diese auf dem Bildspeicher arbeiten, statt auf dem Samplespeicher - > kann ich leider nix dafür, deswegen: bitte bei den Herstellern meckern. > Das ist Dein Drama. Ich konstatiere, daß die Implementierung Murks ist und Du fühlst Dich persönlich angegriffen und erklärst mir wortreich, daß es nicht anders geht und ich das nur nicht verstehe. Um dann am Ende doch wieder anderer Meinung zu sein... Und nochmal: nicht alle Scopes messen im Displayspeicher - eben weil es dafür absolut keine Notwendigkeit gibt und es halt zu suboptimalen Ergebnissen führt. Sicher ist das aber nach wie vor nur bei Agilent.
Volker O. schrieb: > Wer weiß das schon bei seiner > Argumentationsstrategie. Also wenn du mal eine hättest! Du sprichst einmal die manuelle Messung an, dann die Automessung, dann vom Upload der Daten auf den PC, die Echtzeitverarbeitung und Speicher im Scope spielen deiner Meinung nach keine Rolle, dann frage ich dich, wie's LeCroy macht, und bekomme bis dato kein gründliche Antwort. Dann komme ich dir mit einer sicher langen, aber klaren Ausführung zu EINEM der Themen, die du wohl nicht verstanden hast, und stelle lediglich fest, wie's ist, ohne Zweifel daran zu haben, dass man manches besser machen könnte - und du kommst mir hier mit solchen Sprüchen. Kollege, ich habe verdammt viel Zeit investiert, um dir Details zu nennen und zu helfen, da solltest du dir die Zeit nehmen, einen Punkt nach dem anderen abzuhaken, statt hier rumzuschlingern, dann bleibt der Ton anständig und auch das Diskutieren übersichtlicher. Volker O. schrieb: >> Das funktioniert natürlich nur, wenn man im Samplespeicher arbeitet und >> nicht im Bildschirmspeicher. Aber genau das sollte technisch möglich >> sein. >> > Eben. Und bei Automatikmessungen sollte das schon gar kein Problem sein. Eben nicht, es reicht, wenn die Abstände der Samples deinen Anforderungen entsprechen, also meinetwegen 1ns zwischen zwei dargestellten Samples liegt, egal, wieviele dann noch im Samplespeicher in noch kleineren Abständen liegen - kapieren müsste man das. Volker O. schrieb: > Auch wenn von mir aus das letzte Bit jittert. Es geht nicht um das letzte jitternde Bits, sondern um jitternde Flanken eines Rechtecks, sowie ich es heute mal mit einem Generator erzeugt habe. Da schwanken die Flanken locker 50ns, die Automessung bei 10ns/DIV ebenfalls, bei 100ns/DIV entsprechend weniger, weil du das Jittern nicht mehr siehst. Folglich bekommst du ruhigere Messwerte angezeigt. Dieses Verhalten funktioniert aber nur, wenn die Automessung eben auf dem Bildspeicher arbeitet, statt im Samplespeicher. Auch hier könnte man sicher zusätzliche Lösungen finden, z.B. Mitteln im Samplespeicher, wie man das bei unruhigeren A/D-Wandlern auch macht, aber dann hast du auch eben nur noch gemittelte Werte, und keine genauen mehr. Sicher eine Frage der Hersteller-Philosophie, was weiss ich?! Zeigt, dass du auch da nicht verstanden hast, was ich dir sagen wollte. Ob man's besser machen kann oder nicht, keine Ahnung, musst du - wie sooft angemerkt - den Hersteller einfach mal anrufen, statt dich mit mir anzulegen. Ich stelle nur fest wie's ist, nicht, ob's deinen Ansprüchen genügt.
Volker O. schrieb: > Ich konstatiere, daß die Implementierung Murks ist > und Du fühlst Dich persönlich angegriffen Nochmal: mir ist das persönlich völlig egal, ich habe dein Problem nicht. Und wie oben schon einmal erklärt, du wiederholst immer wieder das gleiche. Hallo, ich hab's beim ersten Mal schon verstanden - und du hast Recht, wie ebenfalls bald in jedem Beitrag angemerkt, also mehr kann ich wohl nicht dazu sagen, oder? Volker O. schrieb: > und erklärst mir wortreich, > daß es nicht anders geht und ich das nur nicht verstehe. Ich erkläre dir wortreich, WIE sie's umgesetzt haben, NICHT, dass es nicht anders geht! Nur ergeben sich beim Überdenken der Art, wie sie's gemacht haben, schon logische Begündungen und auch Fragen, wie man's machen würde, wenn man es eben nach deinen Vorstellungen machen würde. Und da habe ich keine Antwort, deshalb frage ich dich und bekomme wieder keine konkrete, außer, dass alles Murks ist. Volker O. schrieb: > Und nochmal: nicht alle Scopes messen im Displayspeicher - eben weil es > dafür absolut keine Notwendigkeit gibt und es halt zu suboptimalen > Ergebnissen führt. Schön, und wieso erklärst du mir dann noch immer nicht an meiner gelieferten Rechnung, wie ich bei 20µs/DIV in 1ns-Schritten per Drehregler auf dem Samplespeicher in eben diesen Schritten messen kann, OHNE mir den Wolf kurbeln zu müssen? Ich meine, ich bestreite nicht, dass es Scopes gibt, die auf dem Samplespeicher messen, aber da du dich da besser auszukennen scheinst als ich, und das ist absolut nicht ironisch gemeint, könntest du mir das doch endlich mal an meinem Beispiel oben erklären. Wenn ich sowas implementieren müsste, wie mache ich das dann, dass die GUI nutzerfreundliches Scrollen in 1ns-Schritten erlaubt, bei einer gleichzeitigen 20µs/DIV Zeitbasis. Und da bekomme ich von dir keine Antwort, wo ich dir immer sehr genaue Daten zu deinen Fragen geliefert habe, und diese alle auf direkten Versuchen am HMO und Rigol basieren, die ich extra für dich durchgeführt habe.
Dein Scope soll die wüst jitternden Flanken Deines Generators rausmitteln? Und das soll als Argument gegen eine exakte Automatikmessung herhalten? Ernsthaft? Ich will jedenfalls kein Scope, daß mir ein stabiles Signal ausmißt, obwohl es in Wirklichkeit jittert wie die Hölle. Ich will den Jitter statistisch ausmessen. Sorry, aber das ist mal wieder genau die Art von Argumentation, die es schwierig macht, mit Dir zu diskutieren. Aber schon klar: in Wirklichkeit schlingert meine Argumentation wie ein betrunkener Seemann und überhaupt verstehe ich es halt einfach nicht. Egal. Ich werde mal höflichst bei Hameg anfragen, ob die Limitierung auf 2 Nachkommastellen in Stein gemeißelt ist oder nicht. Aber lieber von der Firmenadresse, das macht mehr her. Rigol ignoriert mich ja wie gesagt leider. Und was ein Tek-Applikationsingenieur mir geantwortet hat, habe ich ja bereits oben eingestreut.
Volker O. schrieb: > Dein Scope soll die wüst jitternden Flanken Deines Generators > rausmitteln? > Und das soll als Argument gegen eine exakte Automatikmessung herhalten? > Ernsthaft? > > Ich will jedenfalls kein Scope, daß mir ein stabiles Signal ausmißt, > obwohl es in Wirklichkeit jittert wie die Hölle. Ich will den Jitter > statistisch ausmessen. Und wieder hast du es in den falschen Hals bekommen, und wieder bist DU es, der sich persönlich angegriffen fühlt. Es war ein Erklärungsversuch, warum sie es so gemacht haben könnten, nicht meine persönliche Meinung oder gar Rechtfertigung dazu. Volker O. schrieb: > Sorry, aber das ist mal wieder genau die Art von Argumentation, die es > schwierig macht, mit Dir zu diskutieren. Wir diskutieren über Fakten, wie sie nun einmal umgesetzt sind, dafür kann ich nichts, oder? Volker O. schrieb: > Aber schon klar: in > Wirklichkeit schlingert meine Argumentation wie ein betrunkener Seemann > und überhaupt verstehe ich es halt einfach nicht. Ja, du reisst die Dinge inzwischen nur noch aus dem Kontext, um irgendwie permanent Front gegen meine Erklärungen zu machen, die nun einmal sachlich fundiert am Scope nachgemessen wurden. Ich kann weder etwas dafür, dass die Hersteller zum Großteil wohl alle deine Anforderungen nicht umsetzen, noch, dass das HMO so misst wie es misst, oder das Rigol oder dein Agilent es nicht kann. Statt auf meine Fragen einzugehen, machst du ein Faß nach dem anderen auf. Schade. Volker O. schrieb: > Egal. Ich werde mal höflichst bei Hameg anfragen, ob die Limitierung auf > 2 Nachkommastellen in Stein gemeißelt ist oder nicht. Aber lieber von > der Firmenadresse, das macht mehr her. Tu das. Herr Grimm konnte mir damals immer sehr kompetent die Sachverhalte erklären, auch die Einschränkungen der Hardware, die so manches nun einmal beim HMO begrenzen. Kannst du denen ja ihre Hardware erklären ;-) Volker O. schrieb: > Rigol ignoriert mich ja wie > gesagt leider. Tja, weil du auch da nicht auf mich hörst und einfach mal in Puchheim den deutschen Support anschreibst/anrufst. Ich hatte immer innerhalb eines Tages mit Herrn Rau einen kompetenten Ansprechpartner - seltsam. Volker O. schrieb: > Und was ein Tek-Applikationsingenieur mir geantwortet > hat, habe ich ja bereits oben eingestreut. Auch sehr schön. Aber helfen konnten die dir auch nicht, oder? Bist wohl ein schwieriger Fall, genau wie deine Signale.
Diese ganze Diskussion wäre erheblich entspannter, wenn Du diese andauernden Anfeindungen etwas herunterfahren könntest. Es ist bei solchen Diskussionen im Zweifelsfall immer weise, dem Gegenüber nicht pausenlos Beschränktheit zu unterstellen, weil man zum einen nicht genau weiß, mit wem man es zu tun hat und zum anderen der Rückzug aus einer eigenen Fehleinschätzung so unnötig erschwert wird. Und obwohl ich dieses Thema bereits für mehrfach beantwortet halte: weil Du ja immer und immer wieder darauf zurückkommst, hier meine kleine Anleitung zum exakten manuellen Messen im Samplespeicher: 1) Die beiden Cursor werden intern als absolute Positionen im Samplespeicher definiert. 32bit reichen für alle derzeit erhältlichen Scopes locker aus. 2) In jeder Zoomstufe bestimmt man aus der Abtastrate und den Pixeln pro Div einen Faktor, um die Pixelposition des Cursors zu berechnen. Dann muß man nur noch die Startposition und Breite des Zoomfensters kennen und kann so die Position der Cursor auf dem Bildschirm berechnen. Wenn man den Cursor einen Tick nach links oder rechts verschiebt, wird er auf das nächste gradzahlige Vielfache des Umrechnungsfaktors und damit auf den jeweils nächsten Pixel verschoben. Trotzdem zeigen die Cursor immer auf Positionen im Samplespeicher und die zugehörigen Spannungswerte werden auch direkt aus dem Samplespeicher gelesen. 3) Um den Cursor schnell zu bewegen, wechselt man auf eine niedrigere Zoomstufe, um ihn exakt zu bewegen, wechselt man auf eine höhere Zoomstufe. Beim Zurückwechseln in eine niedrigere Zoomstufe wird der Cursor nicht automatisch auf ein Vielfaches des jeweiligen Umrechnungsfaktors zurückgesetzt, sondern bleibt auf seiner absoluten Position im Samplespeicher stehen. Umgekehrt wird seine Bildschirmposition wie gehabt über den Umrechnungsfaktor aus der Position im Samplespeicher ausgerechnet. Erst bei einer Bewegung nach links/rechts wird der Cursor wieder auf ein gradzahliges Vielfaches der des Umrechungsfaktors gesetzt und entspricht damit wieder einer exakten Pixelposition. Wo ist also das Problem? Ich verstehe echt nicht, warum Du dieses Thema immer wieder generell in Abrede stellst, obwohl doch bereits relativ preiswerte Scopes wie das DSOX3000 zeigen, daß eine (auf eine Nanosekunde) exakte manuelle Messung vollkommen problemlos möglich ist und daß man dabei nicht ohne Not Nachkommastellen in die Tonne treten muß.
Volker O. schrieb: > Diese ganze Diskussion wäre erheblich entspannter, wenn Du diese > andauernden Anfeindungen etwas herunterfahren könntest. Es ist bei > solchen Diskussionen im Zweifelsfall immer weise, dem Gegenüber nicht > pausenlos Beschränktheit zu unterstellen, weil man zum einen nicht genau > weiß, mit wem man es zu tun hat und zum anderen der Rückzug aus einer > eigenen Fehleinschätzung so unnötig erschwert wird. Da liegt eben leider auch dein Problem. Denn es reicht aus, einmal oder zweimal anzumerken, dass ein Gerät, Funktion, was auch immer nichts taugt. Und wenn dein Gegenüber dir dann auch zustimmt, sollte eigentlich ein Punkt auch mal abgehakt sein, oder? Diese "pausenlose Beschränktheit", wie du es nennst, habe ich dir sicher nicht unterstellt, dass du aber mehr Fragen stellt und detailliert beantwortet bekommen hast, während du die eine von mir konkret gestellte bis zu deinem letzten Beitrag offen gelassen hast, wo ich dich - wie du ja selbst feststellst - oft genug gefragt habe, ist dann auch deinem Gegenüber sehr unhöflich. Man muss auch nicht andauernd betonen, wie schlecht das ein oder andere ist, es reicht, wenn man das einmal macht. DANN kann eine Diskussion auch so weiterlaufen, wie sie auch hier angefangen hatte: höflich & freundlich. Volker O. schrieb: > Und obwohl ich dieses Thema bereits für mehrfach beantwortet halte: Ja? Wo denn? Habe deine gesamten Beiträge gerade noch einmal abgescannt, nichts gefunden, außer "das hat damit überhaupt nichts zu tun". Danach wolltest du mir den Widerspruch zwischen Handbuch, HMO und Samplespeicher erklären, wo ich dir den Hinweis auf den Pufferspeicher gegeben habe, sogar mit Kapitel und Seitenzahl. Und da liege ich noch immer richtig. Kann man leicht mit dem HMO nachprüfen. Volker O. schrieb: > Wo ist also das Problem? Gar keines! DAnke, auf diese Erklärung habe ich nun zig Beiträge gewartet, einfach aus Interesse, wie man so etwas anders machen könnte. Insofern solltest du spätestens jetzt kapiert haben, dass ich eben NICHT "pausenlos Beschränktheit" unterstellen, sondern einfach eine Alternative zum derzeit Implementierten haben wollte. Und bis dato hast du das nirgend so beschrieben, wenn doch, bitte belegen. Volker O. schrieb: > ch verstehe echt nicht, warum Du dieses Thema > immer wieder generell in Abrede stellst, obwohl doch bereits relativ > preiswerte Scopes wie das DSOX3000 zeigen, daß eine (auf eine > Nanosekunde) exakte manuelle Messung vollkommen problemlos möglich ist > und daß man dabei nicht ohne Not Nachkommastellen in die Tonne treten > muß. Nochmal, ich habe da überhaupt nichts in Abrede gestellt, ich habe dir die ganze Zeit das beantwortet, was du wissen wolltest und WIE sie es in den derzeitigen Scopes gemacht haben. Und ich habe dir mehrfach recht gegeben. Und ich habe dir die Frage gestellt, wie man es denn anders machen soll, wo bis auf deinen letzten Beitrag keine konkrete Antwort kam. Stattdessen hast du meine Frage als persönlichen Angriff interpretiert, was ja Sprüche wie pausenlose Beschränktheit belegt. Der Hinweis, diesen Vorschlag den Herstellern zu unterbreiten, kam von mir auch mehr als einmal, aus gutem Grund. Beim HMO sind in den letzten JAhren sehr viele neue Funktionen mit Updates hinzugekommen, sicher auch, weil die Geräte irgendwann in den Markt mussten und Hameg nicht alles von Anfang an implementieren konnte. Vielleicht haben sie ein offenes Ohr für deinen Vorschlag, auch schon öfters angesprochen, was eben auch zeigt, dass das Thema für mich eben NICHT in Abrede gestellt wird, wie du es mir dauernd unterstellst. Meine Bemerkungen mit Hinblick auf Echtzeitfähigkeit und techn. Möglichkeiten waren auch nicht einfach so aus dem Himmel gegriffen, dahinter verbergen sich Gespräche mit Hameg, deren Inhalt ich hier aus Fairness nicht nennen möchte. Ich sage nur soviel: ich wollte immer einen Zoom im gestoppten Rollmode im HMO und habe darum fast 1,5 Jahre gebettelt. Am Ende wurde mir mitgeteilt, dass es leider nicht möglich sei, dies zu implementieren, da es Einschränkungen technischer Art gibt. So, das Thema wäre von der theoretischen Seite auch leicht abzuhandeln, praktisch geht's aber nicht mit dem HMO. Und das ist es, was ich dir sagen will, ich sehe vieles ein, aber ob's dann auch immer so einfach umsetzbar ist, oder andere Funktionen nicht mehr funktionieren, ist eine andere Sache. Die Folge war dann bei mir der ergänzende Kauf des Rigols, das in dieser Hinsicht ist es klasse, in deiner eben nicht. Und das lasse ich mir dann auch nicht in jedem deiner Beiträge durch dein spezielles, wenn auch gerechtfertigtes, Problem versauern. Schönen Sonntag noch.
Also, wen's nach all dem Hin- und Her noch interessiert, weil heute ausprobiert: das Agilent DSO6034A macht es wie Volker es beim DSOX3000 beschrieben hat. Um ohne die Zeitbasis umschalten zu müssen dennoch schnell über den Screen scrollen zu können, wenn der Cursor im Samplespeicher misst, ist die Drehreglerfunktion geschwindigkeitsabhängig implementiert. Bei den alten Agilents ist das nicht so, die schneiden wie oben beschrieben die Nachkommastellen beim Verstellen auf größere Zeitbasis ab, verlieren die zuvor eingestellte Genauigkeit aber nicht, so dass beim erneuten Reinzoomen wieder die korrekten Werte angezeigt werden. Das HMO zeigt sie die ganze Zeit an, egal welche Zeitbasis man einstellt, da es sie beim Reinzoomen einmal abspeichert, bis zum nächsten Verstellen der Cursor. Die neue Suchfunktion zeigt beim Ausmessen 4 Stellen hinter dem Komma an, also auch bei Pulsbreitenmessungen, allerdings scheint das noch nicht in trockenen Tüchern zu liegen, den die beiden niedrigsten Stellen scheinen konstant auf 0 zu stehen. Zum eigentlich Thread: Rigol DS4000 Ich habe am Freitag eine Mail an den Support gesendet, der mir das Verstellen des gerade nicht sichtbaren Cursors im TRACK-Mode als Bug bestätigt hat. Es wird für die Rigol DS4000er-Reihe ein Update geben. Ob sich was an den Nachkommastellen ändert, keine Ahnung. Hauptsache, man kann Pulse wie in o.g. Beispiel überhaupt messen. Gruß
gb r. schrieb: > Ich habe am Freitag eine Mail an den Support gesendet, der mir das > Verstellen des gerade nicht sichtbaren Cursors im TRACK-Mode als Bug > bestätigt hat. Es wird für die Rigol DS4000er-Reihe ein Update geben. Hallo, gibt es das Update schon bzw. kann weis jemand, ob das in der aktuellen Firmware auch noch auftritt? Ich überlege mir zur Zeit auch, so ein Gerät anzuschaffen und es wäre für mich schon wichtig, dass man auch längere Pulse genau ausmessen kann.
Hallo, also, der dt. Support hatte nach mehreren Nachfragen in Peking die Rückmeldung bekommen, dass es kein Update geben wird, um den TRACK-Mode über die Bildschirmgrenzen hinaus zu ermöglichen (s.o.). Es handelt sich um keinen Bug, sondern um eine Funktion, die so gewollt ist und die man auch nicht erweitern möchte. Aber: natürlich kann man lange Pulse mit den o.g. Scopes sowohl von Hameg wie auch Rigol messen, das ging in der ganzen Diskussion von Anfang an völlig unter. Messung über Verschiebung des Triggerpunkts ermöglicht dir das Ausmessen auch von langen Pulsen bis mehrere Stellen nach dem Komma ziemlich genau, abhängig von der gerade gewählten Sampleauflösung. Hat mir bis dato immer gereicht, bin in Zeiten mit Scopes aufgewachsen, wo's eh diese ganzen Automessfunktionen nicht gab. Würde sagen, Preis, Häufigkeit der Verwendung und eigene Bedürfnisse sind hier die Kriterien, ob man's wirklich braucht. Ansonsten sind die Automessfunktionen ausreichend. Gruß Gunb
Soweit mir bisher bekannt ist befinden sich im Rigol keinerlei ASCIs, sondern lediglich ein paar umgelabelte Bausteine von TI und einige unkenntlich gemachte Bausteine von AD. Das ist kein Nachteil, lediglich eine Richtigstellung. Die 2000er Serie beruht wohl auf der 4000er und erstere ist ja schon gut dokumentiert und reversed engineered. So befindet sich bspw. der LMH6518 zusammen mit dem LMH6552 an Board. Auch der AD-Wandler wurde hier als ADC08DL502 bei 1GHz Taktrate identifiziert. Leider hat noch niemand Bilder vom Inneren der 4000er Serie bereitgestellt, denn dann könnte man vergleichsweise schnell beurteilen, wieviel zwischen beiden Serien gleich ist. Mich würde es aber nicht wundern, wenn bspw. die Eingangsstufen fast identisch sind. Bei der 6000er Serie wäre ich mir diesbezüglich aber nicht mehr so sicher. Das sind aber nur Spekulationen, die solange aufrecht erhalten bleiben, bis wir mal Bilder von den Innereien gesehen haben. Was mich bei der 4000er Serie sehr stört ist der doch nicht unerheblich laute Lüfter. Das haben sie bei der 2000er Serie deutlich besser hinbekommen. Mich erinnert der Krach irgendwie an meine alte HP4194A-Kiste auf Arbeit, auf Dauer einfach unerträglich und man ist froh wenn man das Gerät wieder abschalten kann. Ansonsten sind beide Serien wirklich schöne Geräte, mit der ein oder anderen Einschränkung. So bin ich bisher von meinem Scope auf Arbeit gewöhnt, dass auch die volle Sampleanzahl für die FFT benutzt wird. Bei 10s auf dem Bildschirm und einer Abtastrate von 250KSps zeigt mir die FFT auch den Frequenzbereich von 0,1Hz - 125kHz an. Das Rigol reduziert die Sampleanzahl vor der FFT noch einmal erheblich,sodass nur ein eingeschränktes Spektrum zur Verfügung steht und man das Spektrum durch Mehrfachmessung in verschiedenen Zeitablenkungen zusammensetzen oder aber offline mit einem Mathematikprogramm durchführen muss. Letzteres ist dann wiederum mit einem erheblichen Zeitaufwand beim Abspeichern der Messpunkte auf einen USB-Stick verbunden. Schade ist, dass sie die 2000er Serie nicht als 4-Kanal-Variante anbieten, das wäre dann ganz klar mein Favorit. Auch fehlt ihr leider, neben dem wählbaren internen Abschlusswiderstand, der VGA-Anschluss, wobei der verbaute Bildschirm zwar kleiner gegenüber der 4000er Serie ist, aber auch nicht winzig. Mein Fazit, die Geräte sind, wenn auch nicht uneingeschränkt, empfehlenswert.
gb r. schrieb: > Messung über Verschiebung des Triggerpunkts ermöglicht dir das Ausmessen > auch von langen Pulsen bis mehrere Stellen nach dem Komma ziemlich > genau, abhängig von der gerade gewählten Sampleauflösung. Meinst du das so, dass man zuerst die Position der ersten Flanke messen muss (relativ zum Triggerzeitpunkt), dann den Triggerpunkt so weit verschiebt, dass man die zweite Flanke messen kann und dann die beiden Zeitpunkte subtrahiert? Kann man das auch hinterher noch machen, also wenn man die Messung schon gemacht hat oder muss man den Triggerpunkt vorher schon entsprechend verschieben? Das hört sich schon ziemlich umständlich an und von einem digitalen Oszi erwarte ich eigentlich, dass so etwas besser funktioniert. Natürlich ist das Rigol günstiger als ein Lecroy-Gerät, aber das ist doch nur eine Software-Funktion, die außer etwas Programmieraufwand eigentlich nichts kostet.
Johannes E. schrieb: > Meinst du das so, dass man zuerst die Position der ersten Flanke messen > muss (relativ zum Triggerzeitpunkt), dann den Triggerpunkt so weit > verschiebt, dass man die zweite Flanke messen kann und dann die beiden > Zeitpunkte subtrahiert? Richtig, bis auf das Subtrahieren, das kannst du dir sparen. Einfach die Triggerverschiebung ablesen und fertig. Wenn du vorher auf 0 getriggert hast, dann auf die 2.Flanke verschiebst, zeigt dir das Scope doch die Breite automatisch an. Johannes E. schrieb: > Kann man das auch hinterher noch machen, also wenn man die Messung schon > gemacht hat oder muss man den Triggerpunkt vorher schon entsprechend > verschieben? Klar hinterher, du weisst doch vorher nicht, wie breit dein Puls wird. Johannes E. schrieb: > Das hört sich schon ziemlich umständlich an und von einem digitalen Oszi > erwarte ich eigentlich, dass so etwas besser funktioniert. Es ist nur umständlich, wenn man es so machen würde, wie du es angenommen hast, so wie ich es beschreibe nicht. Johannes E. schrieb: > Natürlich ist das Rigol günstiger als ein Lecroy-Gerät, aber das ist > doch nur eine Software-Funktion, die außer etwas Programmieraufwand > eigentlich nichts kostet Tja, watt weiss ich, warum weshalb wieso die Implementation so ist wie sie ist. Ehrlich gesagt, habe ich jetzt auch keine Lust den obigen Mist erneut zu diskutieren. Wenn du fragen hast, helfe ich dir gerne. Diskutieren, ob's dir gefällt oder nicht, werde ich hier jetzt nicht mehr. Gruß Gunb
branadic schrieb: > Soweit mir bisher bekannt ist befinden sich im Rigol keinerlei ASCIs, > sondern lediglich ein paar umgelabelte Bausteine von TI und einige > unkenntlich gemachte Bausteine von AD. Das ist kein Nachteil, lediglich > eine Richtigstellung. Richtig ist, dass RIGOL mit ASICs wirbt, die Leistungsbausteine aber in erster Linie Xilinx FPGAs der Spartan6-Baureihe sind. Der Rest mag das sein, was du nennst. branadic schrieb: > Die 2000er Serie beruht wohl auf der 4000er Ja. branadic schrieb: > Leider hat noch niemand Bilder vom Inneren der 4000er Serie > bereitgestellt, denn dann könnte man vergleichsweise schnell beurteilen, > wieviel zwischen beiden Serien gleich ist. Was bringt mir das? Wenn ich ein Auto kaufe, dann nehme ich auch nicht gleich den Zylinderkopf ab, um die Leistungsfähigkeit zu beurteilen. Im eevblog sieht man doch bereits die 2000er zerlegt, die 4000er werden sicher nicht viel anders aussehen. Für's tägliche Messen für mich beides irrelevant. branadic schrieb: > Was mich bei der 4000er Serie sehr stört ist der doch nicht unerheblich > laute Lüfter. Stimmt, etwas laut, aber kein Hindernis. Wen's stört, wechselt das Teil halt mal. branadic schrieb: > Das haben sie bei der 2000er Serie deutlich besser > hinbekommen. Ob sie's besser hinbekommen haben, oder nicht notwendig ist, sei dahingestellt. Die 4000er machen mehr wfm/s und haben höhere Abtastraten, ob damit mehr Wärmeentwicklung entsteht, wissen die Entwickler vorerst mal alleine, so lange sich keiner die Mühe macht, es auszumessen. branadic schrieb: > Ansonsten sind beide Serien wirklich schöne Geräte, mit der ein oder > anderen Einschränkung. Na gut, aber wo hast du die nicht? Die 3000er Agilents machen 2mV/DIV maximal, die 4000er echte 1mV/DIV - was braucht man mehr, FFT oder eine vernünftige Auflösung?! branadic schrieb: > Schade ist, dass sie die 2000er Serie nicht als 4-Kanal-Variante > anbieten, das wäre dann ganz klar mein Favorit. Auch fehlt ihr leider, > neben dem wählbaren internen Abschlusswiderstand, der VGA-Anschluss, > wobei der verbaute Bildschirm zwar kleiner gegenüber der 4000er Serie > ist, aber auch nicht winzig. Stimmt. Tja, nichts ist umsonst - leider. Aber wie du sagst, das Preis-/Leistungsverhältnis ist recht gut, Abstriche macht man immer. Was mir noch so als positive Nebensache aufgefallen ist: die 50Ohm im 4000er sind mit Schutzrelais ausgestattet. Bei zu hoher Spannung schaltet das Scope die Eingänge weg, damit die Widerstände nicht wegbruzzeln. Das haben sogar viele Markengeräte heute noch nicht. Gruß Gunb
gb r. schrieb: > Was bringt mir das? Wenn ich ein Auto kaufe, dann nehme ich auch nicht > gleich den Zylinderkopf ab, um die Leistungsfähigkeit zu beurteilen. Im > eevblog sieht man doch bereits die 2000er zerlegt, die 4000er werden > sicher nicht viel anders aussehen. Für's tägliche Messen für mich beides > irrelevant. Mag für dich zutreffend sein, aber wenn man großspurig mit ASCIs wirbt und dann gezeigt wird, dass es umgelabelte Consumer-Ware ist, dann sieht das plötzlich doch etwas anders aus. Ich sagte ja auch, es ist kein Nachteil, nur falsch platzierte Werbung. gb r. schrieb: > Stimmt, etwas laut, aber kein Hindernis. Wen's stört, wechselt das Teil > halt mal. Komisch, in dem Fall lenkst du ein und sagst das es Sache des Gestörten wäre. Du weißt ja das solche Eingriffe mitunter zum Verlust der Garantie führen ;) gb r. schrieb: > was braucht man mehr, FFT oder eine > vernünftige Auflösung?! Diskussion hinfällig, kommt immer auf die Anwendung drauf an.
gb r. schrieb: > Die 3000er Agilents machen 2mV/DIV maximal, die 4000er echte 1mV/DIV Ich frage mich allerdings, ob das nützlich ist. Wenn ich bei meinem DS4054 bei kurzgeschlossenem Eingang auf 1 mV/Div drehe, habe ich einen 2 cm breiten Rauschbalken (2 mVpp). Genug um mit 4 Kanälen gleichzeitig den Bildschirm komplett mit farbigem Rauschen zu bemalen. Da wären mir 2 mV/Div lieber wenn es nur 1 mVpp rauschen würde.
gb r. schrieb: > Am unteren Rand stehen nach wie vor 100.01µs. Mine Fields schrieb: > Schon hat man eine Genauigkeit von 1ns bei einer Pulslänge von > mehrereren (100) us. Volker O. schrieb: > Ein HMO kürzt auf 5 Stellen -> 10ns. Hier werden wieder mal Auflösung und Genauigkeit verwechselt. Hameg z.B. spezifiziert die Genauigkeit mit 15ppm für HMO35xx & HMO25xx und 50 ppm für HMO20xx und kleiner. Bei einem 100 µs breiten Puls (Abstand der Curser) entsprechen 1ns gleich 10 ppm. Ein Oszi ist kein Präzisionsinstrument. Für solche Messungen nimmt man einen geeigneten Frequenzzähler.
Angehängte Dateien:
-
Rigol_DS2072.png
25 KB -
Rigol_DS4012.png
27 KB
Kurt Moser schrieb: > Ich frage mich allerdings, ob das nützlich ist. Da muss ich leider zustimmen. Auch hier kann das DS2000 klar punkten (siehe Bilder anbei, jeweils ein Kanal mit und ein Kanal ohne Bandbreitenbegrenzung).
Die Frage zum Update ist beantwortet, die zum Ausmessen von langen Pulsen auch. FFT, Lüfter usw. sind ein Thema für sich, um das es nicht ging. Mein Fehler, darauf überhaupt eingegangen zu sein. Und Ende.
Hans Franz schrieb: > Volker O. schrieb: >> Ein HMO kürzt auf 5 Stellen -> 10ns. > > Hier werden wieder mal Auflösung und Genauigkeit verwechselt. > Nö. Ich kritisiere nur eine gedankenlose Umsetzung, die ohne Not gemessene Nachkommastellen abschneidet. Es gibt nebenbei bemerkt eine Aussage vom HMO-Support, daß das im nächsten Update 2013 verbessert werden soll. Bei der Suche im Speicher geht es ja schon. Mal sehen, was dabei rauskommt. > Bei einem 100 µs breiten Puls (Abstand der Curser) entsprechen 1ns > gleich 10 ppm. > Die PPM-Angaben beziehen sich üblicherweise auf die Abtastgenauigkeit, im wesentlichen auf den Quarz. Das hat rein gar nichts mit dem Wegschmeißen von gemessenen Werten zu tun.
Hans Franz schrieb: > gb r. schrieb: >> Am unteren Rand stehen nach wie vor 100.01µs. > > Mine Fields schrieb: >> Schon hat man eine Genauigkeit von 1ns bei einer Pulslänge von >> mehrereren (100) us. > > Volker O. schrieb: >> Ein HMO kürzt auf 5 Stellen -> 10ns. > > Hier werden wieder mal Auflösung und Genauigkeit verwechselt. > > Hameg z.B. spezifiziert die Genauigkeit mit 15ppm für HMO35xx & HMO25xx > und 50 ppm für HMO20xx und kleiner. > > Bei einem 100 µs breiten Puls (Abstand der Curser) entsprechen 1ns > gleich 10 ppm. > > Ein Oszi ist kein Präzisionsinstrument. Für solche Messungen nimmt man > einen geeigneten Frequenzzähler. Eben. Und wenn doch mit dem Scope, dann locker mit der Triggerfunktion durch Verschieben bis in den ns-Bereich - ist also nicht so wie vor 6 Monaten behauptet, dass es gar nicht ginge. Das geht beim HMO, und auch beim Rigol.
Volker O. schrieb: >> Bei einem 100 µs breiten Puls (Abstand der Curser) entsprechen 1ns > >> gleich 10 ppm. > >> > > Die PPM-Angaben beziehen sich üblicherweise auf die Abtastgenauigkeit, > im wesentlichen auf den Quarz. Das hat rein gar nichts mit dem > Wegschmeißen von gemessenen Werten zu tun. Falsch. Wenn Dein Quarz die Genauigkeit nicht bringt, kannst Du die Stellen auch wegschmeisen. Die Abtastgenauigkeit geht sehr wohl auch auf die Zeitmessung im Oszi ein, viel mehr ist das Quarz die Referenz für alles zeitliche in Deinem Oszi.
Volker O. schrieb: > Nö. Ich kritisiere nur eine gedankenlose Umsetzung, die ohne Not > gemessene Nachkommastellen abschneidet. Tja, da waren wir uns ja schon einig. Und dennoch war es schon von Anfang an möglich, Pulse wie der von dir genannte auszumessen. Ich habe das HMO, das Rigol und ein Picoscope. Selbst das Picoscope, schon 6 Jahre alt, misst im Samplespeicher. > Es gibt nebenbei bemerkt eine Aussage vom HMO-Support, daß das im > nächsten Update 2013 verbessert werden soll. Bei der Suche im Speicher > geht es ja schon. Mal sehen, was dabei rauskommt. Tja, wäre ja schön. Deinen Einwand kann ich sicher verstehen, auch wenn ich's persönlich so selten brauche, dass Pulse dieser Art bei mir mit dem Trigger gemessen werden - oder eben dem Frequenzzähler.
Volker O. schrieb: > Nö. Ich kritisiere nur eine gedankenlose Umsetzung, die ohne Not > gemessene Nachkommastellen abschneidet. > Es gibt nebenbei bemerkt eine Aussage vom HMO-Support, daß das im > nächsten Update 2013 verbessert werden soll. Bei der Suche im Speicher > geht es ja schon. Mal sehen, was dabei rauskommt. Von gedankenlos kann da nicht die Rede sein. Ich finde es schade, wenn sich HAMEG aus Marketinggründen dazu hinreisen lässt, unnötig viel Auflösung vorzugaukeln, wo die Genauigkeit nicht mithalten kann. Gilt insb. für die kleinen Oszi's, 50 ppm sind jetzt nicht so doll.
branadic schrieb: > Kurt Moser schrieb: >> Ich frage mich allerdings, ob das nützlich ist. > > Da muss ich leider zustimmen. Auch hier kann das DS2000 klar punkten > (siehe Bilder anbei, jeweils ein Kanal mit und ein Kanal ohne > Bandbreitenbegrenzung). Oh weia, kann man ja wirklich nicht unkommentiert lassen. Ich setzte mal voraus, dass dein Testaufbau genau gleich war. 1.) wenn auch nur gering, beim 2000er tastest du mit kleinerer Samplerate ab 2.) das 4000er macht mehr wfm/s als das 2000er Beides führt automatisch zu weniger sichtbaren Rauschen beim 2000er. Mal abgesehen davon, dass mein 4000er nicht so stark rauscht wie das von dir abgebildete, was dann aber auch bedeuten könnte, dass wir hier Exemplarstreuungen hätten, die beide Bautypen beträfen, will ich hoffen, dass dein Test zwei Geräte mit gleicher Bandbreite betrifft, denn ein 4000er mit mehr kann auch mehr hochfrequentes Rauschen darstellen. Im Falle der Bandbegrenzung wäre sind sie ja gleich, was die Amplitude betrifft. Der sattere Blauton beim 4000er zeigt, dass es mit höherer wfm/s arbeitet und einfach mehr anzeigt, das Rauschen ist beim 2000er genau so vorhanden, kann aber eben wegen der kleineren Refreshrate nicht angezeigt werden. Wenn ich einen rauscharmen Generator an das HMO oder das Rigol anschliesse, ein Signal mit 5mV anlege, kann ich mit beiden Geräten die 1mV sauber ausnutzen, beim HMO einen Tick besser. Der Kurzschlussfall ist kein alleiniges Qualitätskriterium.
eben nachgeschaut: DS2072: 70MHz DS4012: 100MHz, nenne ich mein Eigen. Mehr Bandbreite, mehr Rauschleistung messbar. Also noch ein Punkt, der deinen Vergleich unbrauchbar macht.
gb r. schrieb: > Wenn du fragen hast, helfe ich dir gerne. Eine Frage habe ich noch: Beruflich arbeite ich mit einem Lecroy-Oszi und das hat einen Dropout-Trigger, das ist im Prinzip ein Flankentrigger der dann triggert, wenn für eine bestimmte Zeit keine Flanke kommt. Wenn ich das Manual des Rigol DS4014 richtig interpretiere, dann gibt es bei diesem Gerät diese Funktion nicht; ebenso beim Hameg HMO1024. Weiß jemand, ob es bei diesen Geräten bzw. bei einem von beiden eine Möglichkeit gibt, auf den Ausfall eines periodischen Signals zu triggern. Speziell bei der Fehlersuche in Schaltnetzteilen ist das sehr hilfreich, wenn man auf das Abschalten der PWM triggern kann. Mir ist schon klar, dass man sich so einen Trigger auch irgendwie in Hardware erzeugen kann, aber es ist ein tolles Feature, was mir die Entscheidung für oder gegen eines dieser beiden Geräte evtl. erleichtern würde.
Johannes, beim HMO kannst du den Trigger auf IMPULS stellen und durch Drücken der Taste FILTER u.a. die Vergleichsoption ti > t nutzen, dann die Zeit variieren plus Toleranz (extra einstellbar), was deinem Dropout-Beispiel nahekommen sollte. Beim Rigol gibt es ebenfalls einen Trigger namens PULSE, der dir diverse Triggeroptionen für t > xyz bietet. Für Details kannst du ja danach mal in den Manuals suchen. Hier müsstest du fündig werden, ob dein Fall damit realisierbar ist. Gruß Gunb
Johannes E. schrieb: > Wenn ich das Manual des Rigol DS4014 richtig interpretiere, dann gibt es > bei diesem Gerät diese Funktion nicht; ebenso beim Hameg HMO1024. vergessen: ich beziehe mich auf das HMO2524 und das DS4012.
Der DS2202 hat einen "TimeOut Trigger". Laut Beschreibung ist es wohl genau das, was gesucht wird. mfg
gb r. schrieb: > Oh weia, kann man ja wirklich nicht unkommentiert lassen. Überheblich bist du gar nicht oder? Wie immer gilt, der Ton macht die Musik! Auch wenn du glaubst ein ganz helles Köpfchen zu sein. > Ich setzte mal voraus, dass dein Testaufbau genau gleich war. Na selbstverständlich, alles andere wäre Quatsch! gb r. schrieb: > will ich hoffen, > dass dein Test zwei Geräte mit gleicher Bandbreite betrifft, denn ein > 4000er mit mehr kann auch mehr hochfrequentes Rauschen darstellen. gb r. schrieb: > Also noch ein Punkt, der > deinen Vergleich unbrauchbar macht. 70MHz vs. 100MHz ist aber nun auch kein all zu großer Unterschied, da wirst du mir sicherlich zustimmen. Unbrauchbar, soso. Offenbar bist du nicht in der Lage Grafiken richtig zu interpretieren. Dir ist zwar aufgefallen, dass das 2000er bei der Messung mit 200kS und das 4000er mit 250kS abgetastet hat, der Unterschied von 50kS erklärt aber den 4x größeren Rauschteppich nicht. Da zieht auch dein Argument "mehr wfm/s" nicht, denn beide Geräte haben hier einen SingleShot durchgeführt, da ist nichts mit "sichtbarem Rauschen". Btw: Gibt es auch unsichtbares Rauschen? gb r. schrieb: > Im Falle der Bandbegrenzung wäre sind sie ja gleich, was die Amplitude > betrifft. Gleich, ahja. Ich würde sagen 500µV/div ~= 1mV/div, aber das nur am Rande. gb r. schrieb: > Der Kurzschlussfall ist kein alleiniges Qualitätskriterium. Kein alleiniges, aber ein entscheidenes! Wenn die Eingangsstufe selbst schon rauscht, dann ist Hopfen und Malz verloren und das tut sie im Falle des 4000er eindeutig mehr.
branadic schrieb: > Gleich, ahja. Ich würde sagen 500µV/div ~= 1mV/div, aber das nur am > Rande. Stehe ich zu, mein Fehler. Ändert trotzdem nichts dran, dass mein DS4012 nicht so stark rauscht wie deines im Bild. Und deswegen die Frage nach Streuung oder standardmässige Unterschiede in den Geräten, oder doch Bugs, von denen verschiedene Messbereiche betroffen sind? Und: die 30MHz machen den Braten nicht fett, die Frage ist nur, um die Eingangsstufe des 2000er-Gerätes wirklich besser ist oder rapide mit ansteigender Bandbreite verschlechtert? Ich würde mich wundern, wenn Rigol diese komplett anders designed haben sollte als die der höheren 4000er. Da möchte ich dann Gleiches mit Gleichem verglichen sehen, bevor ich am Ende wirklich sagen kann, dass es besser ist. Dafür habe ich zu lange in der Validation gearbeitet und die Schummeleien gesehen, die zu oft mit höheren Anforderungen an die Hardware ans Licht kamen. Deshalb ist ein solcher Vergleich für mich erst einmal fraglich. Gruß Gunb
** Lötlackl schrieb: > Der DS2202 hat einen "TimeOut Trigger". Laut Beschreibung ist es wohl > genau das, was gesucht wird. > > mfg Wenn ich da hinten ins Handbuch schaue, gehört der Timeout-Trigger zur Option AT-DS2, die noch einmal mit ca. 220€ erworben werden muss, oder?
Thread beobachten
Seitenaufteilung abschaltenBitte 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.