Hameg HMO3524

Das HMO3524 ist gerade nicht in Reichweite, aber ich habe hier neben mir das HMO3522 angeschaltet und mit dem Funktions- generator ein 2Vss 1Hz Sinussignal raufgegeben. Es sind keine Spikes zu sehen. Funktionsgenerator ist ein Hameg HM8130.

alsdenn, Jens

Michael Koch schrieb:

so ähnlich.

nicht nötig

nicht nötig

Ja. Nicht nur Spikes sondern gleich ca. 25ms breite Aussetzer. Auch bei langsamerer Zeitbasis.

Servus

Oliver

Hi,

Es wäre schön wenn du diesen Test bei Gelegenheit noch mit dem HMO3524 machen könntest. Welche Software-Version ist bei deinem Gerät drauf? Bei mir tritt dieser Fehler reproduzierbar auf, und scheint mit zunehmender Temperatur stärker zu werden. Ich bin mir absolut sicher dass die Spikes nicht am Eingang anliegen, weil ich schon mehrere verschiedene Signalquellen getestet habe, und ausserdem hängt direkt am Eingang noch ein 1kHz Tiefpass. Scheint wohl ein Montags-Gerät zu sein. Die Bus-Decodierung geht auch nicht richtig, wenn man längere Zeiträume speichert und dann reinzoomt. Aber an diesem Fehler wird bei Hameg schon gearbeitet.

Gruß Michael

Hi,

Alles klar. Ganz so breit sind die Aussetzer bei mir nicht, aber sehen kann ich sie gelegentlich auch. Hat der Hameg-Service schon was dazu gesagt?

Gruß Michael

Michael Koch schrieb:

den Fehler kannte ich bis vorhin noch nicht, ich nutze "Rollen" nicht. Ich habe auch schon genügend andere Dinge mit dem Hameg-Support diskutiert, den hier überlasse ich Dir.

Mit Deinem Setup habe ich noch einen neuen Fehler gefunden: Wenn das Menü aus ist und "Auto" Trigger triggert, wird die "Cursor Select" Taste aktiv, m.a.W. "Scrollbar" oder "Intensity/Persist" fliegen 'raus. Den habe ich schon zu Hameg geschickt.

Ansonsten ist für mich momentan der einzige "Showstopper" im HMO der zeitliche Versatz von "Busdaten" (z.B. seriell decodiert) zu restlichen Daten (analog/digital). Wegen dieses Fehlers habe ich schon ein paar Stunden lang in meiner Schaltung nach einem Fehler gesucht, bis ich herausfand, daß das HMO falsch anzeigt. Der Fehler hat wohl die höchste Priorität, ich hoffe auf baldige Behebung, sonst muß ein anderes Oszi her.

Kein richtiger Fehler, aber IMNSHO extrem lästig: Die Anzeigedaten verschwinden, wenn man die Anzeige (Horizontalposition, Zeitbasis, Zoomeinstellungen) ändert. Wenn man vorher "Stop" einstellt, funktioniert es. Mich trifft das, weil ich oft "Einzelschüsse" analysiere, die schwierig herbeizuführen sind. Einmal "Stop" vergessen und ich darf von vorne anfangen. Immerhin hat Hameg das auf die Wunschliste gesetzt. Beim Tektronix kann ich sogar nachträglich die Vertikalverstärkung oder -position ändern, es rechnet (im Rahmen der Möglichkeiten) um.

Oder die umständliche Einstellung der Horizontal-Nullposition. Wer ist nur auf die Idee gekommen, das in die dritte Menüebene zu packen, statt direkt ins Horizontalmenü, wo sogar noch ein Softkey frei ist? Ich stelle das am Tek dauernd um.

Und wie findet Ihr die Screenshotfarben in der Variante mit weißem Hintergrund ("invertiert")?

Trotzdem ist das Hameg ein gutes Gerät mit einem _ausgezeichneten_ Preis-/Leistungsverhältnis. Geringes Rauschen, gute Eingangsempfindlichkeit, großer Offsetbereich, fast unhörbar.

Servus

Oliver

Hi,

ok, diesen Fehler habe ich dem Support bereits mitgeteilt.

Einen zeitlichen Versatz habe ich noch nicht bemerkt, weil die serielle Decodierung für meinen Anwendungsfall überhaupt nicht funktioniert hat. Ich wollte einige Sekunden mit voller Abtastrate speichern, und dabei auf ein bestimmtes Wort auf einem RS232 Bus triggern. Triggern tut er auch, aber wenn man anschliessend in die Daten reinzoomt, dann funktioniert die Bus-Decodierung nicht -- mit anderen Worten es werden gar keine oder falsche decodierte Daten angezeigt. Da fällt ein eventuell vorhandener Versatz dann auch nicht auf. Leider scheint es immer mehr in Mode zu kommen, Geräte zu verkaufen bevor sie fertig entwickelt wurden.

Gruß Michael

Michael Koch schrieb:

Hast Du auch auf Stop geschaltet, bevor Du reinzoomst? Sonst verschwindet ja das ganze Signal.

Hier hat das einwandfrei funktioniert - Triggern auf "Break", Stop drücken, Kurven analysieren.

Servus

Oliver

Hi,

Weiss ich nicht mehr. Jedenfalls war das Problem nicht dass die Daten verschwinden, sondern dass die RS232 Decodierung nicht funktioniert. Der Service hat das Problem auch nachvollziehen können und sucht seitdem (>5 Wochen) nach einer Lösung. Scheint ein schwieriges Problem zu sein, irgendwas mit Speichermanagement und FPGA-Programmierung.

Aber nicht dann, wenn viel Speicher verwendet werden muss, z.B. einige Sekunden Abtastzeit mit >=50kHz Sample-Rate, damit 9600 Baud sicher decodiert werden kann. Man muss die Zeitbasis so einstellen, dass einige Sekunden auf den Bildschirm passen. Um die hohe Abtastrate zu gewährleisten, muss man Acquire / Waveform Rate / Max.Sa.Rate einstellen. Nachdem das Gerät getriggert hat, kann man reinzoomen und sieht, dass man nichts sieht :-(

Gruß Michael

Michael Koch schrieb:

Gerade stelle ich fest, daß ich mit Busanzeige nur auf 24000 Samples komme, z.B. 100kS/s bei 20ms Zeitbasis. Schalte ich die Busanzeige aus, steigt die Samplerate auf 6,25MS/s.

Damit wird ab 50ms Zeitbasis die Decodierung von 9600bps unmöglich.

Kannst Du ein Beispiel geben, Zeitbasis und Samplerate _mit_ aktiver Busanzeige?

Servus

Oliver

Hi,

Die Sample Rate wird sowieso falsch angezeigt, bzw. das was angezeigt wird, das ist nicht die Sample Rate mit der die Daten in den Speicher geschrieben werden, sondern die Sample Rate mit der die Daten angezeigt werden. Man erkennt das daran, dass es bei aktivem Zoom-Fenster zwei unterschiedliche Sample-Rates gibt (obwohl es die gleichen Daten sind und das eine nur ein Ausschnitt aus dem anderen Fenster ist).

Gruß Michael

Hi,

Welche Software-Version hast du drauf? Bei V02.501 wurde angeblich irgendwas bei der angezeigten Sample-Rate verändert. Dennoch kann der angezeigte Wert nicht das sein, was man normalerweise unter "Sample-Rate" versteht. Inzwischen gibt es V02.502, aber das ändert nichts an den beschriebenen Problemen.

Gruß Michael

Holla, das ist aber eine lange Liste! Da kann ich nur hoffen, dass mein altes 754 TEK noch eine Weile durchhält.

Hmm, mal sehen, wie sie die Sachen mit der Firmware angehen. Klar, der Preis ist unschlagbar, wenn die Hardware gut ist. Aber es wäre auch bei weitem nicht die erste Firma, die zwar gute, preiswerte Hardware bauen kann, sich aber mit Programmieren reichlich schwer tut.

Marcel

Das Scope kenne ich nicht. Nur als Idee:

Wenn es ein auf der Kante sitzendes Timing ist muesste eine behutsam abgegebene Dosis Kaeltespray die Sache zumindest einkreisen. Bei vielen Scopes werden die AD Wandler bei maximaler Sample Rate am oder tief im roten Drehzahlbereich betrieben.

Aber bloss nicht voll draufhalten bis ein Eispanzer da ist, das koennte in die Hosen gehen.

Hi,

Nee, die Kiste bleibt schön geschlossen solange da noch Gewährleistung drauf ist. Ich will auch gar nicht wissen _warum_ die Fehler auftreten. Es genügt, wenn die Fehler in angemessener Zeit beseitigt werden.

Gruß Michael

Michael Koch schrieb:

Hmm, ich weiß nicht so recht. "Sample Rate mit der die Daten angezeigt werden" ergibt für mich nicht wirklich Sinn.

Nur bei aktiver "Busauswertung", sonst sind die angezeigten Abtastraten identisch.

Es sieht eher so aus, als ob die Samplerate im Übersichtsfenster angibt, mit welcher Geschwindigkeit Busdaten erfaßt werden.

Im Zoomfenster sieht man die Geschwindigkeit, mit der die restlichen Daten (Analog- und Digitalkanäle) erfaßt werden. Seltsam.

Die Busdaten im Zoomfenster wechseln auch wirklich nur mit der oben im Übersichtsfenster angezeigten Samplerate den Zustand, während die anderen Kanäle schneller wechseln.

Da muß ich nächste Woche in Nürnberg wohl doch mal die Alternativen näher unter die Lupe nehmen.

Zum anderen Posting: Hier läuft die 02.502 auf einem HMO2524.

Servus

Oliver

Marcel Müller schrieb:

das relativiert sich aber, wenn man sich ansieht, wie gravierend die einzelnen Punkte sind. Wirklich schwerwiegend ist m.E. nur die Sache mit den Busdaten.

TDS754C? Das hat halt gar keine Busdekodierung.

Das Problem dürften alle Hersteller haben. Bei unserem TDS3012B ist ein m.E. schwerwiegender Firmwarefehler immer noch nicht behoben (und wird es auch nicht mehr): Bei manchen mathematischen Berechnungen werden unter bestimmten Bedingungen (Eingangsdaten) total unsinnige Werte angezeigt.

Und anfangs waren da auch viele "Quirks" drin, die erst nach und nach behoben wurden. FFT war anfangs kaum benutzbar.

Und auf meine speziell für Tektronix eingerichtete Mailadresse erhielt ich einmal Werbung von TI...

Servus

Oliver

Stimmt, man sollte erwarten dass der Hersteller das bereinigt. Kann aber noch schlimmer kommen: ARB-Generator aus China gekauft, nicht so sehr wegen des guenstigen Preises sondern weil der Features hat wo andere kaum mitkommen. Bei vielen Frequenzen macht der fette Phasenspruenge. Offenbar haben die Jungs die Chose mit dem DDS nicht so ganz geschnallt und derzeit ist nach dem Einsenden meiner Scope Plots grosses Kopfkratzen angesagt. Vermutlich sind auch viele chinesische Flueche ueber die Lippen gekommen.

Joerg schrieb:

Nach dem was ich so über den "Support" chinesischer Messgerätehersteller gehört habe, ist vermutlich eher großes Ignorieren Deines Bugreports angesagt.

Christian

Ich weiss, und sie schneiden sich damit ins eigene Fleisch. Dann muessten sie den Generator zuruecknehmen (Haendler ist in USA) und es spraeche sich rum. Zumindest hat diese Firma aber geantwortet dass sich die Ingenieure die Sache ansehen.

Mangelnde Zusammenarbeit mit Endkunden ist bei uns in einigen Bereichen der Grund warum sich hiesige Hersteller (bis jetzt jedenfalls) nicht ganz soviel Sorgen um asiatische Konkurrenz machen muessen. Im Bereich der Investitionsgueter zieht sowas nicht, da bleibt man dann immer hinten dran.