Zuverlässigkeit von USB-RS232-Adaptern?

OP #3325519
Hallo,

ich arbeite gerade an Software zum Auslesen eines Gerätes über RS232. 
Das Geräte sendet selbstständig Zeichenfolgen raus, welche in der 
Software ausgewertet werden sollen.

Für die Entwicklung der Software verwende ich anstatt dem Gerät selbst 
ein Laptop, der die Datenausgabe simuliert. Hierfür besitzt dieser einen 
Delock 61460 USB 2.0 > 1 x Seriell Adapter.

Der Rechner auf dem die Software läuft besitzt im Moment so einen 
Billigadapter:
http://www.ebay.de/itm/USB-2-0-TO-RS232-SERIAL-DB9-9-PIN-ADAPTER-CABLE-GPS-PDA-/170378256745?pt=US_Parallel_Serial_PS_2_Cables_Adapters&hash=item27ab55e169

Beide sind mit einem Null-Modem-Adapter verbunden.

Hin und wieder kommt es vor, dass die vom Simulationslaptop 
ausgesendeten Zeichenfolgen nicht korrekt an dem anderen Rechner 
ankommen.

Meiner Meinung nach kommen hierfür nur die USB-RS232-Adapter in Frage.

Hat hier schon jemand Erfahrungen, was die Zuverlässigkeit von Marken- 
und Billigteilen angeht? Prinzipiell würde ich dem Delock-Produkt eher 
vertrauen als dem Billigteil aus China.

Dafür spricht auch, dass der Billigadapter an dem Simulationslaptop mit 
Win7 überhaupt nicht erkannt wird. Der Rechner mit der Auswertesoftware 
läuft mit Linux. Dort wird der Billigadapter erkannt.

Preislich unterscheiden sich die Adapter ca. um den Faktor 10.

Danke
In der Tat habe ich auch schon Probleme mit ähnlichen "billig Adaptern" 
gehabt. Mal hören die auf zu funktionieren, mal kommt ein BSOD während 
der Datenübertrgung.
Meiner bescheidenen Erfahrung nach entscheidet sich die Qualität von USB 
Seriel Adapter hauptsächlich am verwendeten Chipsatz. Ich bevorzuge USB 
Seriel Adapter von FTDI z.b. DIGITUS DA-70156
Gast
Wir haben mal einige Billig-Dinger von Pollin erworben. Da ist ein 
Prolifick Chip drin. Die sind aus genau diesen Gründen nach kurzer Zeit 
in den gelben Sack gewandert.
Gast
Bloß kein Prolific:
Vor einem Jahr hatten die einen bösen Bug im Treiber für 32-Bit Windows:
Nach einigen Stunden bis Tagen problemloser Kommunikation verschluckt 
der Treiber das letzte empfangene Datenbyte. Wenn dann wieder neue Daten 
vom seriellen Device kommen, kommt das fehlende Byte, dafür fehlt dann 
das letzte Byte von den neuen Daten. Manchmal wird es auch schlimmer, 
und es werden mehrere Bytes auf diese Art verschluckt. Schließen und neu 
Öffnen des virtuellen COM-Ports hilft dann wieder für ein paar Stunden.
Den Fehler haben die dann irgendwann durch Treiberupdate gefixt. Vor ein 
paar Wochen habe ich dann festgestellt, daß der aktuelle Treiber für 
64-bit WIndows den Bug immer noch hat.
Für den Zeitaufwand der Fehlersuche hätte man auch ne Palette 
FTDI-Konverter kaufen können...
Tassilo H. schrieb:
> Vor einem Jahr hatten die einen bösen Bug im Treiber für 32-Bit Windows:

Wow. Dann ziehe ich mal mein "normalerweise anstandslos" zurück. Hab die 
meist nur unter Linux länger im Einsatz, unter Windows nur testweise, da 
ist mir das nicht aufgefallen, oder ich hatte Glück mit meiner 
Treiberversion.
Gast
hinzu kommt das ich bei den billig adaptern gesehen habe das diese gar 
keine pegel wandlung machen.
Die bleiben einfach bei den 0-5 V des USB.

kan auch ein vorteil sein :)
man kann die oft direkt an den UART eines ATmegas anschließen und diesen 
gleich mit strom versorgen. Die Bits sind dann lediglich invertiert.
Gast
Zu den Adaptern mit FTDI-Chip, kann ich nur Gutes sagen. Zu Prolific 
eher nicht. Einmal und nie wieder.

Der Support von FTDI ist auch okay. Wir setzen die Haufenweise in 
unseren Geräten um via virtuellen COM-Port eine Text-Konsole zu 
realisieren. Einzig von der SPI-Funktion mancher Modelle muss man etwas 
Abstand nehmen. Offenbar gibt es da Probleme mit einigen USB3-Host 
Controllern.
OP
Die von euch beschriebenen Fehler kann ich jetzt bestätigen. Der 
Billigadapter hat sich nun von seiner wahren Seite gezeigt.

Er hat empfangene Zeichenfolgen nicht vollständig an den Rechner 
weitergeleitet. Zudem waren einige der empfangenen Zeichen 
verfälscht/verändert. Ich hoffe, dass heute der neue Adapter eintrifft.
Gast
1
[ 5238.576949] usb 1-1.3: new full speed USB device using ehci_hcd and address 6
2
[ 5238.670059] usb 1-1.3: New USB device found, idVendor=067b, idProduct=2303
3
[ 5238.670068] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
4
[ 5238.670076] usb 1-1.3: Product: USB-Serial Controller
5
[ 5238.670081] usb 1-1.3: Manufacturer: Prolific Technology Inc.
6
[ 5238.670279] usb 1-1.3: configuration #1 chosen from 1 choice
7
[ 5238.670597] pl2303 1-1.3:1.0: pl2303 converter detected
8
[ 5238.672480] usb 1-1.3: pl2303 converter now attached to ttyUSB0
9
[ 5365.776834] usb 1-1.4: new full speed USB device using ehci_hcd and address 7
10
[ 5365.869693] usb 1-1.4: New USB device found, idVendor=067b, idProduct=2303
11
[ 5365.869703] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
12
[ 5365.869710] usb 1-1.4: Product: USB-Serial Controller
13
[ 5365.869715] usb 1-1.4: Manufacturer: Prolific Technology Inc.
14
[ 5365.869917] usb 1-1.4: configuration #1 chosen from 1 choice
15
[ 5365.870174] pl2303 1-1.4:1.0: pl2303 converter detected
16
[ 5365.872251] usb 1-1.4: pl2303 converter now attached to ttyUSB1

Die zwei hier habe ich hier seit Jahren an einem Linux System OHNE 
Probleme laufen.
Gast
Εrnst B✶ schrieb:
> Norbert schrieb:
>> Die zwei hier habe ich hier seit Jahren an einem Linux System OHNE
>> Probleme laufen.
>
> Echte oder gefälschte?

Wer kann das schon sagen?

Eines ist ein fertiges Kabel, USB auf Sub9 (vom großen R)
Das Andere ein halbes China Kabel USB auf vier offene Drähte (5V 
Pegel)...

> Linux nimmt beide, Windows mit Original-Treiber nur echte.
>
> Wär interesssant ob die oben genannten Byte-Verluste Fehler des
> Windows-Treibers oder des Chips sind.

Gab früher(tm) auch mal vereinzelt Probleme mit Linux Kernel Modulen und 
sechsstelligen Baudraten. Da reden wir aber vom letzten Jahrtausend! ;-)

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 13 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.