RIGOL DS4000er

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!

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

Warum? Nur raus damit!

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?

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.

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.

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.

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.

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.

Der DS2202 hat einen "TimeOut Trigger". Laut Beschreibung ist es wohl 
genau das, was gesucht wird.

mfg