Forum: PC Hard- und Software USB Kommunikation mit DSO 1062D unter Linux


von Christoph R. (cherub)


Lesenswert?

Moin,

ich bin froher Besitzer des DSO-1062D von Voltcraft. Im standalone 
Betrieb bin ich voellig zufrieden und immer wieder erstaunt, wie gut 
Messungen gelingen.

Anyhow, es geht nicht um eine Produktbesprechung, sondern um einige 
Fragen.

Fuer ein paar weitergehende Anwendungen wuerde ich gerne per PC an die 
gemessenen Datenpunkte des Geraets kommen. Leider gestaltet sich das 
schwieriger als erhofft. Mangels eines Windows-Systems (und Ahnung 
davon) wollte ich das ganze unter Linux machen. Jetzt stecke ich seit 
drei Tagen mehr oder weniger fest.

Was ich bislang habe ist einmal die Protokoll-Beschreibung von tinman ( 
https://www.mikrocontroller.net/articles/Hantek_Protokoll )

Was mir nicht gelingt ist das DSO (verlaesslich) zur Kommunikation zu 
bewegen. Ich sollte erwaehnen, dass meine USB Kenntnisse in den letzten 
Tagen zwar stark erweitert sind, aber wahrscheinlich immer noch nicht 
ausreichen.
Beim Verbinden des Geraets mit dem Rechner sehe ich das device; output 
von 'lsusb -v' ist unten angehangen. Demnach sollte es nur eine 
Konfiguration geben, die device class ist natuerlich (?) "vendor 
specific".
Mein Vorgehen:
Ich checke, dass der kernel driver nix mit dem device macht, bzw. 
release es. Ich selektiere und aktiviere die Konfiguration, es gibt nur 
eine. Ich kann das device claimen (wenigstens bekomme ich keinen 
Fehler). Ich hole mir die beiden endpoints fuer input, bzw. den output 
(aus host/PC Sicht).

Und trotzdem hole ich mir selbst bei den einfachsten requests timeouts. 
Es ist also klar, dass mir noch irgendeine Information oder ein Schritt 
fehlt.
Falls ich das hinbekomme, dann werde ich den source code auch zur 
Verfuegung stellen. Im Prinzip kann man dann auch eine Anzeige und 
Steuerung vom PC aus machen -- wenn ich denn endlich lerne, wie man mit 
dem Teil sprechen kann.

Ach ja, momentan (und vielleicht auch in Zukunft) schreibe ich das ganze 
in Python. Das backend ist variabel, da ich momentan am meisten mit 
pyusb herumprobiere -- standardmaessig heisst das also libusb1.

Hat jemand einen Vorschlag oder noch eine Idee? Ich habe mir in der 
Bibliothek "USB complete" ausgeliehen, aber das ist ziemlich viel 
Lesestoff -- da werde ich eine Weile brauchen und hoffe erstmal nur, 
dass ich den Fehler finde.

Fuer jede Hilfe dankbar,
Gruesse, Christoph

Zusatzinfo:

Eine typische Fehlermeldung beim Senden von '0x0' ( also "Echo" ) an den 
passenden endpoint erhalte ich:
1
  File "/nowhere/usb_tests/pyusb/usb/core.py", line 948, in write
2
    self.__get_timeout(timeout)
3
  File "/nowhere/usb_tests/pyusb/usb/backend/libusb1.py", line 824, in bulk_write
4
    timeout)
5
  File "/nowhere/usb_tests/pyusb/usb/backend/libusb1.py", line 920, in __write
6
    _check(retval)
7
  File "/nowhere/usb_tests/pyusb/usb/backend/libusb1.py", line 595, in _check
8
    raise USBError(_strerror(ret), ret, _libusb_errno[ret])
9
usb.core.USBError: [Errno 110] Operation timed out


Output von 'lsusb -v' (nur fuer das interessante device)
1
Bus 003 Device 004: ID 049f:505a Compaq Computer Corp. Linux-USB "CDC Subset" Device, or Itsy (experimental)
2
Device Descriptor:
3
  bLength                18
4
  bDescriptorType         1
5
  bcdUSB               2.00
6
  bDeviceClass          255 Vendor Specific Class
7
  bDeviceSubClass         0 
8
  bDeviceProtocol         0 
9
  bMaxPacketSize0        64
10
  idVendor           0x049f Compaq Computer Corp.
11
  idProduct          0x505a Linux-USB "CDC Subset" Device, or Itsy (experimental)
12
  bcdDevice           24.30
13
  iManufacturer           1 Linux 3.2.35 with s3c-hsudc
14
  iProduct                2 Gadget Serial v2.4
15
  iSerial                 0 
16
  bNumConfigurations      1
17
  Configuration Descriptor:
18
    bLength                 9
19
    bDescriptorType         2
20
    wTotalLength           32
21
    bNumInterfaces          1
22
    bConfigurationValue     1
23
    iConfiguration          3 Generic Serial config
24
    bmAttributes         0xc0
25
      Self Powered
26
    MaxPower                2mA
27
    Interface Descriptor:
28
      bLength                 9
29
      bDescriptorType         4
30
      bInterfaceNumber        0
31
      bAlternateSetting       0
32
      bNumEndpoints           2
33
      bInterfaceClass       255 Vendor Specific Class
34
      bInterfaceSubClass      0 
35
      bInterfaceProtocol      0 
36
      iInterface              0 
37
      Endpoint Descriptor:
38
        bLength                 7
39
        bDescriptorType         5
40
        bEndpointAddress     0x02  EP 2 OUT
41
        bmAttributes            2
42
          Transfer Type            Bulk
43
          Synch Type               None
44
          Usage Type               Data
45
        wMaxPacketSize     0x0200  1x 512 bytes
46
        bInterval               0
47
      Endpoint Descriptor:
48
        bLength                 7
49
        bDescriptorType         5
50
        bEndpointAddress     0x81  EP 1 IN
51
        bmAttributes            2
52
          Transfer Type            Bulk
53
          Synch Type               None
54
          Usage Type               Data
55
        wMaxPacketSize     0x0200  1x 512 bytes
56
        bInterval               0
57
Device Qualifier (for other device speed):
58
  bLength                10
59
  bDescriptorType         6
60
  bcdUSB               2.00
61
  bDeviceClass          255 Vendor Specific Class
62
  bDeviceSubClass         0 
63
  bDeviceProtocol         0 
64
  bMaxPacketSize0        64
65
  bNumConfigurations      1
66
Device Status:     0x0000
67
  (Bus Powered)

von pegel (Gast)


Lesenswert?

Ich dachte mir:

https://sourceforge.net/directory/os:linux/?q=DSO-1062

bringt aber nur ein paar Sachen für DSO-2xxx.
Vielleicht ist aber doch eine Anregung dabei.

von Christoph R. (cherub)


Lesenswert?

Achso, ja. Ich habe mehrere verfuegbare Kommunikationstools ausprobiert; 
z.B. openHantek, oder auch das tool von Peter Dreisiebner. Aber alle 
sind entweder outdated, nicht lauffaehig oder versagen auch in der 
Kommunikation.

Was ich auch schreiben sollte ist, dass ich die Kommunikation zu anderen 
USB devices herstellen kann. Fuer die funktioniert zwar auch der 
generische Kernel-Treiber; aber zum Lernen taugt es auch. Z.B. ein 
memory stick, ein ADC Wandler, meine Maus.

von pegel (Gast)


Lesenswert?

Christoph R. schrieb:
> versagen auch in der Kommunikation.

Das würde mir zu denken geben und ich würde die Original Win Software, 
notfalls mit einem Test Win in VitualBox ausprobieren.

Ich habe mal etwas geentet (nicht gegooglet ;) ) und bin dabei auf die 
Seite gestossen:
http://musicdiver.com/wordpress/2013/02/stolzer-oszilloskop-besitzer/

Durch die baugleichen Oszis lässt sich dann die Suche erweitern und es 
findet sich sogar der 200MHz Hack unter Linux:
https://randomprojects.org/wiki/Voltcraft_DSO-3062C

Von Problemen mit der Kommunikation habe ich eigentlich nichts gefunden.

von pegel (Gast)


Lesenswert?

Gehst du direkt an USB am PC oder über HUB?

von Christoph R. (cherub)


Lesenswert?

Ich gehe direkt per Kabel vom Host-PC an das DSO.

Die Seite auf musicdiver habe ich mir auch angeguckt; die andere kannte 
ich noch nicht. Vom source code her mache ich eigentlich genau das 
gleiche; testen kann ich erst heute abend.

Was mir im Gegensatz z.B. zur Protokoll Dokumentation auf 
https://www.mikrocontroller.net/articles/Hantek_Protokoll auffaellt ist, 
dass es auf DSO/Firmware Seite ein anderer Treiber verwendet wird -- der 
dort bereits erwaehnte "gadget Treiber". Wenn ich heute abend wieder am 
Rechner bin, kann ich mal die entsprechenden Daten posten.

So langsam frage ich mich halt, ob es nicht irgendeinen bug gibt.

VirtualBox habe ich nicht auf dem Rechner, erscheint mir auch etwas 
overkill. Immerhin besitze ich noch Windows-Lizenzen mit den ich das 
probieren koennte. Ueber wine hat es zumindest nicht geklappt; aber ich 
weiss nicht ob oder wie die Peripherie virtualisiert wird, in dem Fall 
USB.

Ich habe eine firmware Version als source code, sowie ein passendes 
update auf voltcraft.info gefunden. Siehe 
http://voltcraftdownload.info/Default.aspx?modelno=DSO-1062D

Ueber die Quelle habe ich nichts in Erfahrung bringen koennen. Die 
Firmware ist weder signiert, noch gibt es eine checksum. Kann man der 
Quelle trauen?

von Christoph R. (cherub)


Lesenswert?

Hi,

ich komme immer noch nicht wirklich weiter. Eine weitere Seltsamkeit 
ist, dass sich das Teil einerseits als usb-Device anmeldet/gemeldet wird 
und als Netzwerk-Device anmeldet [als s3c-hsudc Gadget Serial 2.4].

Ich habe versucht mir die Kommunikation per wireshark anzugucken; so 
richtig schlau werde ich daraus bislang nicht. Eigentlich wollte ich mir 
auch garnicht den Netzwerk-traffic damit angucken, sondern die USB 
Kommunikation.

Sobald ich allerdings pyusb zum Direktzugriff auf das DSO benutze, muss 
ich ja das Kernelmodul entkoppeln -- womit das network device nicht mehr 
existiert und ich mich nicht mehr per wireshark an die Kommunikation 
haengen kann. Ich lese noch...

Was ich auch nicht verstehe sind die vorhandenen/nicht vorhandenen 
Antworten. Ich kann z.B.an den IN Endpoint schicken:
1
 device.write(0x02, [0x53, 0x01, 0x00, 0x00, 0x54])
(laut Protokoll ein einfaches Echo)
Dann kann ich auf dem falschen Endpoint lesen:
1
print("Read: " + str(device.read(0x02, 64)))
Und ich erhalte eine Antwort:
1
Read: array('B', [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0])

Auf dem richtigen Kanal (
1
device.read(0x81, 64)
) gibt's nur timeouts:
1
     raise USBError(_strerror(ret), ret, _libusb_errno[ret])
2
usb.core.USBError: [Errno 110] Operation timed out

(siehe oben)

von Jim M. (turboj)


Lesenswert?

Christoph R. schrieb:
> print("Read: " + str(device.read(0x02, 64)))

Das hätte eine dicke Fehlermeldung geben müssen, denn der 0x02 kann nur 
für PC->Device benutzt werden.

In die andere Richtung hieße er 0x82, denn das oberste Bit entscheidet 
ob IN oder OUT.

Ich denke das PyUSB da einen Fehler nicht korrekt behandelt und Dir Müll 
zurück gibt.

Übrigens hat device.read() auch noch einen Timeout Parameter. Setz den 
mal auf was dickes wie 10000.

von Christoph R. (cherub)


Lesenswert?

Hi Jim,

wie kommst Du darauf, dass die Kommunikation nicht ueber die 
Endpoint-Adresse 0x02 laufen kann? Aus der Device Beschreibung laut 
lsusb, als auch ueber die direkte Kommunikation ueber USB Kabel bekomme 
ich die Info:
1
  Endpoint Descriptor: [...]
2
        bEndpointAddress     0x02  EP 2 OUT
3
         [...]
4
      Endpoint Descriptor:[...]
5
        bEndpointAddress     0x81  EP 1 IN [...]

Wie gesagt, vielleicht fehlt mir (immer noch) das notwendige Wissen.

Fuer mich war's es bislang: DSO per USB an den Rechner haengen, 
Kommunikation per pyusb starten. Die Initialisierung laeuft auch 
ziemlich exakt so ab, wie im Beispielcode/update script auf Seite 
https://randomprojects.org/wiki/Voltcraft_DSO-3062C#USB_.28Linux.29 
beschrieben.

von Christoph R. (cherub)


Lesenswert?

OK, jetzt vertraue ich einfach mal, dass ich meinen Teil der 
Kommunikation richtig mache.

Kann jemand bestaetigen oder bestreiten, dass das Hantek-Protokoll auch 
fuer das DSO1062D funktioniert?

Falls es nicht funktioniert, wie kaeme ich da ran? Hat jemand einen 
Windows-Rechner und weiss, wie man die USB-Kommunikation mitschneiden 
kann?


Danke & Gruesse

von Christoph R. (cherub)


Lesenswert?

Moin,

nach mehreren weiten Anlaeufen bin ich endlich ein paar Schritte 
weitergekommen.

Vielen Dank an turboj fuer den Hinweis auf das Erhoehen des timeouts. Es 
ist je nach Anfrage, bzw. Rueckgabe entscheidend wie hoch der timeout 
gesetzt wird. Anders gesagt: manche Antworten passen in das 
Standardfenster (1000), andere allerdings erst in das Fenster 10000. 
Jedenfalls erhalte ich jetzt meistens aussagekraeftigere return values 
beim read().

Ganz schluessig ist das ganze noch nicht, da ich die Werte noch nicht 
richtig interpretieren kann. Vielleicht mache ich auch noch was falsch 
beim Senden der Anfragen. Tastendruecke kann ich auch per Linux 
ausloesen; aber nicht immer mit dem gewuenschten Ergebnis. Zudem ist das 
DSO danach verwirrt, d.h. echte Tastendruecke bekommen eine andere 
Bedeutung...?

Was auch auffaellt ist, dass die Pruefsumme der Befehle einigermassen 
egal zu sein scheint.

Kann mir jemand auf die Spruenge helfen, wie man das LSB und das MSB bei 
einer Anfrage selbst ausrechnen kann? Ich stehe da irgendwie auf dem 
Schlauch.

Gruesse,
Christoph

Bitte 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
Noch kein Account? Hier anmelden.