USB-Protokoll herausfinden

[martin w. (Gast)]

Hallo Leute,

ich möchte gerne diesen 16-Kanal-A/D-Wandler mit USB-Schnittstelle an 
einem Raspberry Pi betreiben:

http://www.bmcm.de/index.php/de/externe-messysteme/usb-ad16f.html

Vom Hersteller wird das Protokoll auf der USB-Schnittstelle leider nicht 
veröffentlicht. Stattdessen gibt es eine Bibliothek für Windows und 
Linux mit einem dokumentierten API. Allerdings nur als Binary, nicht im 
Quelltext. Wobei das Linux-Binary nur für Intel-Plattformen verfügbar 
ist, nicht für ARM. Also läuft es auf dem Pi nicht. Damit möchte ich 
mich aber nicht abfinden. Das Protokoll kann ja nicht derartig 
kompliziert sein, dass man sich nicht schnell ein C-Progrämmchen dafür 
schreiben könnte.

Nur wie herausfinden, was auf der Schnittstelle passiert? Ich habe es 
mit Wireshark versucht. Allerdings schreibt das scheinbar den gesamten 
USB-Overhead mit und ich verstehe nur Bahnhof.

Kann jemand aus dem angehangenen PCAP irgendwelche sinnvollen Dinge 
herauslesen?

Aufgezeichnet ist die Kommunikation zwischen dem Wandler und einem PC 
über die vom Hersteller mitgelieferte Library. Es werden nacheinander 
alle 16 Kanäle ausgewählt und die Daten abgefragt.

[Schumi (Gast)]

Was ist ein PCAP?
Was für ein Programm muss da (eventuell auch noch bezahlen) 
herunterladen,
damit ich dir deine Arbeit abnehmen kann?

[Alonso (Gast)]

> Was ist ein PCAP?

In Anbetracht dieser Frage glaube ich nicht, daß Martin Dich 
angesprochen hat.  Trotzdem danke für Deinen konstruktiven Beitrag.

Gruß,
Fernando

[MannMannMann (Gast)]

Schumi schrieb:
> Was ist ein PCAP?

evtl ein protocol capture?

[Rene S. (Firma: BfEHS) (rschube)]

Wenn Martin schreibt das er: "Ich habe es mit Wireshark versucht." dann 
könnte es Möglich sein das die angehängte Datei ein 'protocol capture' 
von Wireshark ist.

[Maxx (Gast)]

Du suchst dir aus dem PCAP die Descriptoren Requests raus (Setup Paket, 
EP0) und die Antworten darauf.

Im Interface Descriptor liest du das Feld Class und SubClass aus.

Für den groben Paketaufbau: 
http://www.beyondlogic.org/usbnutshell/usb6.shtml
Ansonsten siehe USB Spec. Solltest du dir sowieso anschauen, wenn du 
nachher auf Linux Ebene Requests selber abschicken willst.

[Jay (Gast)]

Ich weiß was ein PCAP-File ist, darf ich jetzt antworten? :-)

Im Ernst, googeln der VID/PID ergibt z.B. 
http://ubuntuforums.org/archive/index.php/t-1718390.html

> The card implements the CDC class as ACM.

Also angeblich CDC-ACM. Das ist standardisiert. Ich habe das nicht mit 
dem PCAP-File gegengeprüft. Weitere Untersuchungen mit einem 
Terminal-Emulator würden sich anbieten.

Aus der Reaktion des Herstellers in dem Thread sieht man auch, dass der 
ziemlich am Rad dreht. Vielleicht wäre es besser ein anderes Produkt zu 
wählen.

[Maxx (Gast)]

Okay, gerade mal inc pcap geschaut: USB Class Vendor, also hält er sich 
an keine offiziell Dokumentierte Klasse. Du darfst alle Requests selber 
zerlegen oder jemand finden, der es schon gemacht hat.

[Axel G. (axelg)]

martin w. schrieb:
> Vom Hersteller wird das Protokoll auf der USB-Schnittstelle leider nicht
> veröffentlicht. Stattdessen gibt es eine Bibliothek für Windows und
> Linux mit einem dokumentierten API. Allerdings nur als Binary, nicht im
> Quelltext. Wobei das Linux-Binary nur für Intel-Plattformen verfügbar
> ist, nicht für ARM. Also läuft es auf dem Pi nicht. Damit möchte ich
> mich aber nicht abfinden. Das Protokoll kann ja nicht derartig
> kompliziert sein, dass man sich nicht schnell ein C-Progrämmchen dafür
> schreiben könnte.

Jay schrieb:
> Aus der Reaktion des Herstellers in dem Thread sieht man auch, dass der
> ziemlich am Rad dreht. Vielleicht wäre es besser ein anderes Produkt zu
> wählen.

Maxx schrieb:
> Okay, gerade mal inc pcap geschaut: USB Class Vendor, also hält er sich
> an keine offiziell Dokumentierte Klasse. Du darfst alle Requests selber
> zerlegen oder jemand finden, der es schon gemacht hat.



Ich würde alle Energie dahinein stecken andere Hardware zu finden.

[Pandur S. (jetztnicht)]

Hihi ... Das Protokoll kann ja nicht derartig kompliziert sein, dass man 
sich nicht schnell ein C-Progrämmchen dafür schreiben könnte.

Ja, dann mach mal. Zeitaufwand nach Einarbeitung 6 Monate und mehr. Also 
vergiss es, suche eine andere Loesung.

[Stefan F. (Gast)]

> Das Protokoll kann ja nicht derartig kompliziert sein

Warum nicht? Es könnte sogar absichtlich extrem kompliziert sein, damit 
Leute wie du es nicht reverse enginneeren.

[Pandur S. (jetztnicht)]

Es gibt Firmen, die scheiben dir so ein Basisprotokol, dies koennen sie 
dank der akkumulierten Erfahrung relativ kostenguenstig. Im Bereich von 
drei Nullen hinten dran. siehe  zB thesycon.de

[Sven B. (scummos)]

Wenn du das Gerät ansteckst und dann in dmesg schaust, wird das als 
cdc-acm-Gerät erkannt? Dann fällt eine Protokollschicht schonmal weg und 
das Ganze könnte recht machbar sein. Andernfalls würde ich auch eher 
nach anderer Hardware suchen, das lohnt die Mühe nicht.

[Hans Ulli K. (Gast)]

Ich würde erst mal anfangen nur einen(zwei Kanal zu samplen.

Dann bekomme ich schon mal irgendwo die Kanalnummer heraus.


Das aber der Hersteller bei einem Preis von > 400 EUR nicht mal das 
Protokoll heraus gibt ist sch**.

Vielleicht passt was im drivers/staging/iio in den Kernelsourcen /

[Peter II (Gast)]

Hans Ulli K. schrieb:
> Das aber der Hersteller bei einem Preis von > 400 EUR nicht mal das
> Protokoll heraus gibt ist sch**.

was ist denn das Protokoll von USB?

Bei RS232 war da noch einfach. Bei USB muss man ja erst mal den Layer 
festlegen.

[Hans Ulli K. (Gast)]

Peter II schrieb:
> Hans Ulli K. schrieb:
>> Das aber der Hersteller bei einem Preis von > 400 EUR nicht mal das
>> Protokoll heraus gibt ist sch**.
>
> was ist denn das Protokoll von USB?
>
> Bei RS232 war da noch einfach. Bei USB muss man ja erst mal den Layer
> festlegen.

vergleiche das mal mit dem Netzwerk -> OSI Layer
USB macht eben nur Layer1 und Layer 2.

Dazu gibt es noch den "SCSCI" Layer z.B. für Massenspeicher.

Und Netzwerkkarten z.B. Wifi kochen da ihre eigene Suppe

[asdf (Gast)]

Oder D. schrieb:
> Hihi ... Das Protokoll kann ja nicht derartig kompliziert sein, dass man
> sich nicht schnell ein C-Progrämmchen dafür schreiben könnte.
>
> Ja, dann mach mal. Zeitaufwand nach Einarbeitung 6 Monate und mehr. Also
> vergiss es, suche eine andere Loesung.

Könnten 6 Monate sein, oder auch nur 6 Stunden, das hängt ganz vom 
Protokoll ab. Es gibt viele USB-basierte Messgeräte wo das Protokoll 
trivial ist und recht schnell herauszufinden ist.

[asdf (Gast)]

Im Manual steht "Unter Mac OS X, FreeBSD und Linux muss keine 
Treiberinstallation durchgeführt werden.".

Das könnte durchaus bedeuten dass es doch "normales" CDC-ACM ist und der 
normale Kernel-Treiber greift. Oder aber dass kein Treiber nötig ist 
weil sie in ihrer "libad" selber mit libusb o.ä. das gesamte Protokoll 
(ob CDC-ACM oder nicht) im Userspace implementiert haben.

[Jim M. (turboj)]

An dem PCAP File sind ein paar Dinge auffällig:

1. Es werden Bulk Endpoints definiert aber offenbar nicht benutzt - es 
läuft alles über den Control EP.

2. Es finden jede Menge 2-Byte Vendor specific Read requests statt.
Sieht für mich so aus, als würde der jedes 16-Bit Sample einzeln 
anfordern.

Zu Anfang wird auch ein 256 Byte Block übertragen, das könnten 
irgendwelche Konfigurationsdaten sein.


Ohne das Gerät selbst kann man aber nur raten. Es dürfte einfacher sein, 
sich direkt an den Hersteller zu wenden und da mal nachzufragen, ob die 
nicht das Protokoll (eventuell unter NDA) rausrücken.

[Matthias M. (Firma: privat) (quadraturencoder)]

Das ist doch relativ einfach. Die ganze Initialisierungsphase musst Du 
halt 1:1 nachprogrammieren. Also die Endpunkte anfordern und den 
Konfigurationsblock schicken. Die Hardware dürfte auf die gleiche 
Konfiguration ja immer gleich antworten. Wenn Du zusätzliche 
Konfigurationen ausprobieren möchtest, dann must du halt Wireshark noch 
einmal bemühen.

Im Betrieb schickst Du dann die URB Pakete. Dort fragt er ja freundlich 
mit Request Type 0xc0 den Request 98. In wValue steht dann 
wahrscheinlich die Kanalnummer.

Die URB Antwort hat 16 bit Payload, also wahrscheinlich den Analogwert.

Das dritte Paket mit Typ 62 scheint ein Acknowledge oder Status Report 
zu sein, den Du aber wohl einfach ignorieren kannst.

Am Besten Du schreibt den Code um die Endpunkte zu initialiseren und 
kopierst dann einfach die host->client Pakete aus dem Protokoll. In den 
Paketen kannst Du dann schnell sehen, welche Werte sich mit Änderung der 
Analogeingänge ändern.

Für mich sieht das ganz unkomprimiert und unverschlüsselt aus. Also eher 
6 Stunden als 6 Monate Arbeit.

[Sven B. (scummos)]

Wahrscheinlich ist es ein cdc-acm und du hast mit dem USB-Layer 
überhaupt nix zu tun.

[Matthias M. (Firma: privat) (quadraturencoder)]

Achja, genau. Bevor Du irgendetwas mit USB probierst: schau doch erst 
mal nach, ob sich das Teil nicht ganz einfach als serieller Port im 
"/dev" Verzeichnis anmeldet. Also z.B. "/dev/tty.usb1411"

[Hans Ulli K. (Gast)]

Sven B. schrieb:
> Wahrscheinlich ist es ein cdc-acm und du hast mit dem USB-Layer
> überhaupt nix zu tun.

aus pcap
bDeviceClass: Vendor Specific (0xff)

Matthias M. schrieb:
> Achja, genau. Bevor Du irgendetwas mit USB probierst: schau doch erst
> mal nach, ob sich das Teil nicht ganz einfach als serieller Port im
> "/dev" Verzeichnis anmeldet. Also z.B. "/dev/tty.usb1411"

s.o.

0000   1c 00 60 4c 19 02 80 fa ff ff 00 00 00 00 17 00  ..`L............
0010   00 04 00 01 00 80 02 08 00 00 00 00 c0 62 01 00  .............b..
0020   02 00 04 00 

0000   1c 00 60 4c 19 02 80 fa ff ff 00 00 00 00 17 00  ..`L............
0010   00 04 00 01 00 80 02 08 00 00 00 00 c0 62 10 00  .............b..
0020   02 00 04 00                                      ....

liest einen Kanal aus, an Stelle 0x1e ist die Nummer
von 0x01 bis 0x10
Das ganze ist URB Vendor Request

0000   1c 00 60 4c 19 02 80 fa ff ff 00 00 00 00 17 00  ..`L............
0010   00 04 00 01 00 80 02 08 00 00 00 00 c0 62 01 00  .............b..
0020   02 00 04 00

URB Vendor Request davon

001e   c0 62 01 00 02 00 04 00 .b......

Wireshark
URB setup
bmRequestType: 0xc0
1... .... = Direction: Device-to-host
.10. .... = Type: Vendor (0x02)
...0 0000 = Recipient: Device (0x00)
bRequest: 98
wValue: 0x0001
wIndex: 2
wLength: 4

URB Vendor response

0000   1c 00 60 4c 19 02 80 fa ff ff 00 00 00 00 08 00  ..`L............
0010   01 04 00 01 00 80 02 02 00 00 00 01 b0 be        ..............

Da sind in den letzten zwei Bytes die Daten

[Sven B. (scummos)]

Was sagt denn dmesg, nachdem man das Gerät ansteckt?

[martin w. (Gast)]

Moin,

nach einer längeren Pause möchte ich mich jetzt doch wieder mit diesem 
Problem beschäftigen. Zwischendurch hatte ich ein Work-Around mit einem 
Windows-Rechner am Start, aber das ist ziemlich hässlich.

dmesg sagt:

[ 2896.795088] usb 2-1.1: new full-speed USB device number 5 using ehci-pci
[ 2896.890562] usb 2-1.1: New USB device found, idVendor=09ca, idProduct=4132
[ 2896.890570] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2896.890575] usb 2-1.1: Product: USB-BASE Analog/Digital I/O Board
[ 2896.890579] usb 2-1.1: Manufacturer: BMC Messsysteme GmbH
[ 2896.890583] usb 2-1.1: SerialNumber: 000479

Ich werde jetzt mal mit den vorgeschlagenen Lösungen experimentieren.

[martin w. (Gast)]

Und hier noch die Ausgabe von lsusb -v:

Bus 002 Device 005: ID 09ca:4132  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x09ca 
  idProduct          0x4132 
  bcdDevice            1.00
  iManufacturer           1 
  iProduct                2 
  iSerial                 3 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0