Hallo, da man bei Reichelt keine Erfahrungsberichte hinterlegen kann, mache ich es hier. Zunächst möchte ich sagen, dass ich dieses Gerät für einfache Ansprüche ausreichend finde. Die Bedienung ist einfach und schnell. Allerdings: Vielmehr als ein gewöhnliches analoges Oszilloskop kann das Gerät nicht. Trotz der digitalen Technik handelt es sich nach wie vor um ein grobes Schätzeisen - eben ein Oszilloskop (nicht mehr und auch nicht weniger). Was es mehr (verglichen mit einem analogen Gerät) kann: - Berechnungen am angezeigten Bild durchführen, wie: Anstiegszeiten, Minimal-Wert, Maximal-Wert, Frequenz, Spektrum-Analyse, etc. - Bildschirmfotos speichern - Messwerte speichern (in binär-format) - Benötigt keine Aufwärmphase - Bei TV Signal gezielt einzelne Bild-Zeilen anzeigen - Triggern auf Pulse mit bestimmter Breite - Über Windows GUI fernsteuerbar (mal ehrlich: wozu soll das gut sein?) Dafür kann es nicht: - Mehrere Messungen mit einem Nachleucht-Effekt übereinander Zeichnen (jedenfalls nicht so schön, wie es Analoge Oszilloskope Bauartbedingt alle tun) - Senkrechte Flanken von Rechtecksignalen je nach Steilheit unterschiedlich hell und breit zeichnen. Nun zu meinen Kritikpunkten: Im Datenblatt steht, dass das Gerät 1024k Abtastpunkte speichert. Man könnte glauben, dass Oszilloskop sei imstande, nach dem Trigger eine Millionen aufeinander folgende Messungen (Samples) durchzuführen. Das ist aber nicht der Fall! Die Wahrheit ist folgende: Das Gerät Speichert pro Messung und pro Kanal 1024 Abtastpunkte. Das Messergebnis erscheint auf dem Display verkleinert auf etwa 280 Pixel breite. Durch eine Zoom Funktion kann man mehr Details sehen, und die PC Software zeigt den Graph auch mit mehr Details (Pixeln) an. Die 1024k beziehen sich auf den Speicher des Rekorders. Dabei handelt es sich um eine Funktion, die eine Folge von Messungen (zu je 1024 Abtastpunkten) in ein 1MB Ram einliest. Man muss sich das Vorstellen, wie eine Serienbild-Funktion aus lauter Screenshots. Zwischen diesen Messungen gibt es Pausen, in denen nicht gemessen wird, und jede einzelne Messung erfordert einen Trigger-Impuls. Diese Daten kann man weder zum PC noch auf den USB Memory Stick übertragen, sondern man kann sie lediglich wie ein Video wieder abspielen, solange man das Gerät nicht aus schaltet (denn dann sind die Daten weg). Mit dieser Rekorder-Funktion kann man - soweit ich es einschätze - kaum mehr anfangen, als mit einem Videoclip, den man mit einer Kamera macht, die man auf das Display richtet. Wobei Videoclips von Kameras ausgelesen werden können, was deren Nutzmöglichkeiten deutlich erhöht. Ein USB Stick kann verwendet werden, um Screenshots (in der echten geringen Auflösung des Displays) zu speichern. Man kann auch Die Daten speichern, und zwar wahlweise 1024 oder 2500 Abtastpunkte pro Kanal. Diese Daten werden in einem proprietären Dateiformat gespeichert, dass man mit der Windows Software wieder einlesen und grafisch anzeigen kann. Wer sich diese DAT Dateien mal in einem Hex-Editor anschaut, bemerkt schnell, dass das Dateiformat ganz simpel ist. Zuerst kommt ein Header von etwa 16 Bytes, dann folgen die Rohdaten. Im Einkanal-Betrieb hat man einfach eine Folge von Bytes, entsprechend der von den A/D Wandlern gemessenen Samples. Im Zweikanal-Betrieb hat man immer abwechselnd ein Byte von Kanal 1 und eins von Kanal 2. Eigentlich ganz simpel. Schade, dass man diese Daten nicht im CSV Format abspeichern kann. Mit der Windows Software kann man Daten im Excel Format exportieren, allerdings erfordert das eine Kabelverbindung zwischen PC und DSO, sowie eine neue Messung. Vorher gespeicherte Daten kann man nicht ins Excel Format exportieren. Mit dem Dateiformat ist allerdings etwas faul, denn trotz der Endung XLS handelt es sich in Wirklichkeit um eine Plain-Text Datei in tabellarischem Format. Ich habe mit diesem Dateiformat ein riesen Problem, denn die Einheiten wechseln. Bei einem Rechtecksignal im Bereich 0V / 3V, findet man in der Excel Datei dann Werte nach diesem Muster: 0.03 mv 0.05 mv 0.12 mv 2.97 V 3.00 V 2.99 V 0.05 mv 0.08 mv 0.11 mv 2.96 V 3.01 V 2.99 V Ich habe keine Ahnung, warum man innerhalb einer Messung die Maßeinheit wechselt. Das muss man erstmal mit einem Script wieder gerade biegen, da kann ich besser gleich die binären DAT Dateien einlesen. Leider kann man diese Datensätze vom USB Stick auch nicht drucken. Zum Drucken braucht man eine Kabel-Verbindung zum Gerät und es wird zum Zeitpunkt des Druckens eine neue Messung durchgeführt - total Kacke. Das ist sehr schade, denn das Druckformat an sich finde ich ganz toll. Der Ausdruck hat eine viel höhere Auflösung, als das Display und er beinhaltet zudem die ganzen automatischen Messwerte, sowie alle Einstellungen, mit denen die Messung durchgeführt wurde. Leider funktioniert das Windows Programm nicht unter Linux im Windows Emulator Wine. Es stürzt ab, sobald man Daten lädt. Ich denke, ich werde demnächst ein Openoffice-Makro entwickeln, mit dem ich auf USB Stick gespeicherte Daten in eine Tabelle importieren kann.
:
Verschoben durch Admin
Kleine Korrektur: Die Dateien auf USB Stick enthalten 500 (short) oder 2560 (long) Abtastpunkte. Die Dateigrößen sind jedoch 1038 (short) oder 2580 (long) Bytes. Die kleinere Datei enthält eine Menge Füllbytes. Die Größere Datei enthält immer genau 20 Header Bytes, gefolgt von 2560 Datenbytes. Die Header Bytes habe ich noch nicht entschlüsselt. Die Datenbytes sind vom Typ unsigned short integer. Die Koppelung AC/DC, sowie die vertikale Position (DC Offset) findet offensichtlich VOR dem A/D Wandler statt. Die Zahlenwerte in der Datei spiegeln wieder, was auf dem Display erscheint. Untere Kante = 0x00, obere Kante = 0xFF. Mittellinie = 0x80.
Stefan Frings schrieb: > Ich denke, ich werde demnächst ein Openoffice-Makro entwickeln, mit dem > ich auf USB Stick gespeicherte Daten in eine Tabelle importieren kann. Wenn schon Linux, warum nicht ein einfaches Post-Processing mit üblichen Bordmitteln? Aus dem Ärmel, ohne es getestet zu haben
1 | #!/usr/bin/awk -f
|
2 | BEGIN { |
3 | f["V"] = 1 |
4 | f["mv] = 1e-3 |
5 | }
|
6 | {
|
7 | print $1 * f[$2] |
8 | }
|
> Die Größere Datei enthält immer genau 20 Header Bytes, gefolgt von 2560 > Datenbytes. Die Header Bytes habe ich noch nicht entschlüsselt. Wenn die Datei mit ASCII '#' beginnt, dann ist das SCPI Block Data Format. Allerdings sind nur die ersten paar Bytes einheitlich:
1 | '#' - Magic Number. Das ASCII Zeichen '#' |
2 | '1' - '9' - Länge des Byte Counts, eine ASCII Ziffer, die die Länge des folgenden Eintrags bezeichnet (d.h. wie viele weitere Ziffern folgen) |
3 | '0' - '9' ... - Byte Count, Datenlänge in ASCII Ziffern, so viele Ziffern wie die vorherige Längenziffer angibt. |
Dann folgen binären Daten. No-Name Hersteller kopieren dabei gerne irgendein Tek oder HP Datenformat.
Die angehängte OpenOffice Tabelle enthält ein Makro zum Importieren der DAT Dateien. Das Makro ist mir lieber, als der Excel-Export der Windows Software, weil - unabhängig vom Betriebssystem - funktioniert über USB Stick (also ohne Kabel)
Jetzt haben wir auch eine Variante für Excel.
Hallo Stefan, habe seid kurzem auch so ein Gerät (UT 2042 C) - erfüllt meine einfachen Anforderungen hervorragend. Danke für Deine Makros ich konnte damit schon gut loslegen. Jetzt habe ich den Header-Bereich schon recht gut entschlüsselt und Dein Makro noch etwas verbessert. Unten ein Ausschnitt aus dem Makro. Im Anhang die Makros, welche ich benutze, als Textfiles. Das erste liest auch die mir bekannten Daten aus dem Header. Das Zweite liest alle 10 Files als Rohdaten nacheinander ein (Header noch nicht benutzt). Viel Spaß damit, Thomas REM file header 20 bytes REM byte1..byte6: 0xAA, 0x55, 0x00, 0x01, 0x00, 0x00 REM byte7: 0x00 = CH1, 0x01 = CH2 REM byte8: 0x00..0xA0 = y/DIV in steps, see switch-case below REM byte9: 0x00..0xFA = y-offset 0..250 pixels REM y-resolution: internal +- 5DIV in each direction (10DIV absolut), but upper and lower DIV not viewable REM y-resolution: value in byte9 for y-offset go from "0x00" to "0xFA" (dec 250), 0V = 0x7E (dec 126) REM byte10+11: unknown (trigger or inverted inputs?) REM some values are 0x0C10, 0x7D12, 0xF413, 0xF412, 0xFA12, 0x7114, 0x0611, 0x2A0B REM byte12: 0x00 (unknown) REM byte13: 0x02..0x20 = x/DIV in steps, see switch-case below REM byte14: (0x00) 0x19..0xE1 (0xFA) = x-Offset 0..250 pixel, 0s = 0x7D (dec 125) REM byte15-20: 0x0000 0x0100 0x0000 (unknown) REM in x and y direction there are 25 units (or pixels) per div
Hallo Leute, hier das neuste Update der Dateien, diesmal komplett als OpenOffice-Datei. Habe noch ein paar Bytes geknackt - vielleicht mag jemand ein kleines Java-Tool daraus machen? Bis bald, Thomas REM file header 20 bytes REM byte1..byte3: 0xAA, 0x55, 0x00 REM byte4: 0x00 = 1x, 0x01 = 10x, 0x02 = 100x, 0x03 = 1000x REM byte5..byte6: 0x00, 0x00 (unknown) REM byte7: 0x00 = CH1, 0x01 = CH2 REM byte8: 0x00..0xA0 = y/DIV in steps, see switch-case below REM byte9: 0x00..0xFA = y-offset 0..250 pixels REM y-resolution: internal +- 5DIV in each direction (10DIV absolut), but upper and lower DIV not viewable REM y-resolution: value in byte9 for y-offset go from "0x00" to "0xFA" (dec 250), 0V = 0x7E (dec 126) REM byte10+11: unknown (trigger moment?) REM some values are 0x0C10, 0x7D12, 0xF413, 0xF412, 0xFA12, 0x7114, 0x0611, 0x2A0B REM byte12: 0x00 = invert off, 0x01 = invert on REM byte13: 0x02..0x20 = x/DIV in steps, see switch-case below REM byte14: (0x00) 0x19..0xE1 (0xFA) = x-Offset 0..250 pixel, 0s = 0x7D (dec 125) REM byte15: coupling? 0x00 = AC, 0x01 = DC REM byte16-20: 0x0000 0x0000 0x00 (unknown)
Gute Arbeit. Mir persönlich haben in der Praxis allerdings doch immer die Screenshots vom Gerät gereicht. Ich dachte zunächst, ich könnte die Excel/Calc Tabellen brauchen, um die Grafiken schöner aufzubereiten. Letztendlich habe ich mir dann doch nie die Mühe gemacht. Bisher hatte kein Kunde reklamiert, dass die Screenshots schlecht wären.
> REM byte1..byte6: 0xAA, 0x55 ....
Interessant - 'ne Bootsektorkennung in solch einem File.
Ups, da hat sich in Zeile 56 ein Fehler eingeschlichen. Hatte in beiden
case-zweigen "CH1" stehen - muss natürlich bei case 1 "CH2" heißen. Hier
der relevante Ausschnitt, mit Korrektur:
REM --------- get channel -------------
get #1,7,raw_data
select case raw_data
case 0
channel_name = "CH1"
case 1
channel_name = "CH2"
case else
channel_name = "CH?"
msgbox "Channel name not found set CH?"
End Select
Nachdem ich mich intensiv dem Header gewidmet hatte, habe ich mir jetzt den Datenbereich angesehen. Da passt was noch nicht mit der Verechnung der Offsets (Zeit und Wert) - also obiges Makro noch nicht verwenden. Neue Version folgt, wenn ich die Fehler eliminiert habe. Gruß Thomas
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.