www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Digitales Speicheroszilloskop UT 4042 C (z.B. von Reichelt)


Autor: Stefan Frings (sfrings)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Stefan Frings (sfrings)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lalala (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
#!/usr/bin/awk -f
BEGIN {
     f["V"] = 1
     f["mv] = 1e-3
}
{
   print $1 * f[$2]
}

> 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:
'#'           - Magic Number. Das ASCII Zeichen '#'
'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)
'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.

Autor: Stefan Frings (sfrings)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Stefan Frings (sfrings)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt haben wir auch eine Variante für Excel.

Autor: Thomas Kohler (gentoo-thomas)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Kohler (gentoo-thomas)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Stefan Frings (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jens G. (jensig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>  REM byte1..byte6: 0xAA, 0x55 ....

Interessant - 'ne Bootsektorkennung in solch einem File.

Autor: Thomas Kohler (gentoo-thomas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Kohler (gentoo-thomas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.