Ich verwende bisher einige Delock Adapter USB 2.0 zu 1 x Seriell RS-422/485 um die RS-422-Daten von/zwischen Maschinen mit einem Notebook (ohne Netzteil) abzuhören, aber dabei zeigen sich Geister-Bytes, Wert 0xff, die nicht auf den Leitungen sind, wie ich auch mit dem Oszilloskop (über Trenntravo versorgt) sehe. Dagegen hilft auch nicht a) je 100 Ohm zwischen Rx+ und Rx-, Rx+ und Gnd, Rx- und Gnd, sowie zusätzlich b) je 0,1 µF zwischen Rx+ und Rx-, Rx+ und Gnd, Rx- und Gnd. Also Terminierung differentiell sowie gegen Masse und auch Tiefpassfilterung differentiell und gegen Masse. Masseschleifen gibt es nicht, weil Notebook und Oszi ohne Masse sind. Mit dem Oszi sehe ich nur noch winzige vereinzelte Störpulse viel kleiner als 100 mV aber trotzdem ist rund jedes vierte Byte ein Geister-Byte mit Wert 0xff, das irgendwann zwischen den realten Bytes vom Adapter gemeldet wird. Meist kommt es wenige ms nach einem realen Byte. Gibt es irgendwelche Tricks mit denen diese Geister-Bytes weggefiltert werden können? Und welche anderen Adapter zeigen nicht dieses Problem?
> Dagegen hilft auch nicht a) je 100 Ohm zwischen Rx+ und Rx-, Rx+ und > Gnd, Rx- und Gnd, sowie zusätzlich b) je 0,1 µF zwischen Rx+ und Rx-, > Rx+ und Gnd, Rx- und Gnd. Lass mich mal raten. Du hast keine Ahnung von dem was du da machst oder? > Gibt es irgendwelche Tricks mit denen diese Geister-Bytes weggefiltert > werden können? Jeder der ein Mindestmas an Erfahrung hat wird ein Protokoll definieren das damit klarkommt wenn in Uebertragungspausen mal Muell reinkommt. Einfach weil soetwas immer mal passieren kann. Ansonsten koennen auch Widerstaende nach Masse und Vcc etwas helfen um die Differentiale beim umschalten der Datenrichtung festzulegen. Aber wichtiger ist ein Protokoll dem das egal ist! Olaf
Hallo Rolf, ich kenne sowas nur von falsch terminierten, oder vertauschten Leitungen. Überprüfe doch deine Terminierungswiderstände - bei jeweils zwei verdrillten Adern muß an jedem Ende ein ca. 150-Ohm Widerstand, zwischen D+ und D-, sein. Bei Vierdraht also insgesamt 4 Widerstände. Nichts gegen GND und kein Kondensator. Sonst fällt mir nur noch eine getauschte Polarität ein (R/T+ mit R/T- vertauscht). Habe da schon Verbindungen erlebt, welche trotzdem funktionieren, aber eben sehr störanfällig. Viel Erfolg. Tom
Rolf F. schrieb: > a) je 100 Ohm zwischen Rx+ und Rx-, Rx+ und > Gnd, Rx- und Gnd, Rx+ gehört auch gegen VCC, nicht gegen GND, angeschlossen...
Hallo Justus, ich nenne die Leitungen D+/-, weil es für die Betrachtung egal ist, ob es Rx+/- oder Tx+/- ist. Es wäre falsch, die D+ Leitung gegen Vcc vorzuspannen, da dadurch der Störspannungsabstand verkleinert wird. Wenn schon, dann D+ gegen GND und D- gegen Vcc vorspannen, denn das vergrößert den Störspannungsabstand, aber nicht mit zu kleinen Widerständen (1k - 10k). Im Grunde sollte es aber bei Kabellängen unter 100m, bei normalen Störbedingungen und Baudraten < 100kBaud, keine Vorspannung nötig sein. Gruß. Tom
WIrd doch wohl keine FTDI Problematik sein ???? http://www.heise.de/newsticker/meldung/FTDI-Proaktive-Fake-Chip-Abwehr-2430780.html
TomA schrieb: > Im Grunde sollte es aber bei Kabellängen unter 100m, bei normalen > Störbedingungen und Baudraten < 100kBaud Was hat das mit der Baudrate zu tun. Wenn Geister-0xFF auftauchen, hat der Empfänger offensichtlich ein Startbit gewittert, wo keins war. IMHO heißt das, dass der Empfänger sich einen Störimpuls eingefangen hat und den als Start gewertet hat. Das könnte also an der Logik im Empfängerbaustein liegen, die ein Startbit nicht durch Mehrfachabtastung verifiziert oder an wirklich langen Störimpulsen. Vorschlag wäre, dem Empfänger in der Richtung mal mit einem Pulsgenerator auf den Leib zu rücken.
Wolfgang schrieb: > Das könnte also an der Logik im > Empfängerbaustein liegen, die ein Startbit nicht durch Mehrfachabtastung > verifiziert oder an wirklich langen Störimpulsen. Vorschlag wäre, dem > Empfänger in der Richtung mal mit einem Pulsgenerator auf den Leib zu > rücken. So kleinkarriert muss man erst mal sein. Erst mal den Fehler beim Hersteller suchen, dann schauen ob man vielleicht selbst zu dumm war ?! Das soll wohl ein kleiner Scherz sein. Du bist so einer im Forum: "Hilfe Compilerfehler - gcc hat einen Bug" oder ? Und ziehst dann gleich ein Ticket fürs GCC-Dev Team. Und dann merkst du, dass du den Strichpunkt hinter a=0; vergessen hast.
Hallo Wolfgang, das hat sehr viel mit der Baudrate zu tun. Bei 100kBaud ist die Bitzeit 10µs und bei 10MBaud ist die Bitzeit 0,1µs - also nur 1/100tel. Die Wahrscheinlichkeit einen Störimpuls von 0,1µs als Startbit zu erkennen ist deutlich größer als bei einer Bitzeit von 10µs. Gruß. Tom
TomA schrieb: > das hat sehr viel mit der Baudrate zu tun. Das ist gerade die Frage, ob und wie der Empfänger das Startbit auswertet. Wenn der auf die erste Flanke losläuft, ohne während der Bitzeit noch mal zu prüfen (mit der Möglichkeit wieder in Idle zu gehen) wäre das Kind in den Brunnen gefallen und unabhängig von der Datenrate. Die Datenbits werden üblicherweise mehrfach abgetastet. Über die Details der Starterkennung schweigen sich die Datenblätter meist aus. Mit dem Pulsgenerator hat man eine relativ einfache Möglichkeit, das festzustellen. Kondensatoren, die einen Störpuls verlängern, können kontraproduktiv, wenn die Pulsenergie ausreichend hoch ist und der Empfänger auf die Länge guckt.
Hallo Wolfgang, alle UART's (asynchron) die ich kenne, synchroniosieren auf die erste Flanke des Startbit und werten anschließend in der Mitte der Bit den Leitungszustand aus. Ausgewertet werden die Bit durch Mehrfachentscheidung, deshalb ist der Takt des UART höher als die Baudrate. Das nächste Zeichen wird dann, durch das neue Startbit, neu synchronisiert. Anders macht das auch wenig Sinn, wenn man mit einer gewissen Toleranz gegen Taktabweichungen auskommen muß. Problematisch wird es erst, wenn durch die Taktabweichung, die Auswertung aus der Bitzeit herausläuft. Aber da kommt mir noch eine Idee für Rolf. Sind denn die Parameter bei beiden Geräten gleich eingestellt? Ich habe schon öfter Fehler gesucht, dabei waren nur die Baudraten, oder andere Parameter, ungleich eingestellt. Gruß. Tom
Olaf schrieb: > Jeder der ein Mindestmas an Erfahrung hat wird ein Protokoll definieren > das damit klarkommt wenn in Uebertragungspausen mal Muell reinkommt. > Einfach weil soetwas immer mal passieren kann. Hier geht es doch nur um das Abhören, um rohe Bytes. Da gibt es nur Bytes hintereinander und kein Protokoll. Was Du meinst ist einige ISO-Schichten höher, weit weg.
dummschwätzer schrieb: > WIrd doch wohl keine FTDI Problematik sein ???? > > http://www.heise.de/newsticker/meldung/FTDI-Proaktive-Fake-Chip-Abwehr-2430780.html Die Problematik legt den Chip still, zerstört ihn. Das ist zwar reparabel, aber digital: Entweder arbeitet er normal oder überhaupt nicht.
Rolf F. schrieb: > Dagegen hilft auch nicht a) je 100 Ohm zwischen Rx+ und Rx-, Rx+ und > Gnd, Rx- und Gnd, Natürlich hilft das nicht! Wie denn auch? Du mnusst laut Spezifikation (die hast Du gelesen, oder?) im Ruhezustand wenn alle Transceiver auf RX sind und keiner den Bus treibt mindestens 200mV zwischen + und - vorspannen damit es sicher als Mark erkannt wird. Das nennt sich Failsafe Pull-Up Widerstände. Google das!
:
Bearbeitet durch User
USB/UARTs melden manchmal auch "Framing Error" oder andere Fehler durch "Geisterzeichen" (zumindest unter Linux bekommt man dann zusätzlich 0x00). U.U. mal "diverse" ignore Optionen wie "IGNPAR" (linux) versuchen. Du schreibst auch, dass das Notebook nicht am Netzteil hängt. Dann sollte also der Adapter "galvanisch" getrennt sein. Oder hast Du noch andere Strippen (z.B. Ethernet) dran, die das dann doch wieder relativieren?
Achim K. schrieb: > USB/UARTs melden manchmal auch "Framing Error" oder andere Fehler durch > "Geisterzeichen" (zumindest unter Linux bekommt man dann zusätzlich > 0x00). U.U. mal "diverse" ignore Optionen wie "IGNPAR" (linux) > versuchen. Nein das passiert nie. Ansonsten wäre die Hardware defekt oder falsch konfiguriert. Wie zum Beispiel bei OP mit seinen falsch angeschlossenen D+ und D- Leitungen. Und bezüglich der Parität muss man auch nicht raten, die stellt man einfach so ein wie vereinbart.
1 | IGNBRK Ignore BREAK condition on input. |
2 | |
3 | BRKINT If IGNBRK is set, a BREAK is ignored. If it is not set but |
4 | BRKINT is set, then a BREAK causes the input and output queues |
5 | to be flushed, and if the terminal is the controlling terminal |
6 | of a foreground process group, it will cause a SIGINT to be |
7 | sent to this foreground process group. When neither IGNBRK |
8 | nor BRKINT are set, a BREAK reads as a null byte ('\0'),
|
9 | except when PARMRK is set, in which case it reads as the |
10 | sequence \377 \0 \0. |
11 | |
12 | IGNPAR Ignore framing errors and parity errors. |
Manchmal sind die Namen zwar sprechend, aber die Implementierung entspricht dann doch nicht dem Namen ;-).
TomA schrieb: > Aber da kommt mir noch eine Idee für Rolf. Sind denn die Parameter bei > beiden Geräten gleich eingestellt? Ja, die empfangenen Daten stimmen, auch deren Reihenfolge und auch die gelogten Zeiten dazu, nur ist in den Logfile noch mehr, die Geister-Bytes. Es ist auch so das wenn ich Testdaten rausschicke über einen weiteren USB-RS-422-Adapter, das dessen Daten ohne Geister-Bytes eingelesen werden. Mit dem Oszi sieht man als Unterschied nur das dort das Rauschen nicht im Bereich 10 mV sondern unter 1 mV liegt. Und wenn die Parameter falsch sind, empfängt man normalerweise nichts oder nur wenig Müll, aber nichts zusätzliches wie Geister-Bytes.
:
Bearbeitet durch User
Achim K. schrieb: > USB/UARTs melden manchmal auch "Framing Error" oder andere Fehler durch > "Geisterzeichen" (zumindest unter Linux bekommt man dann zusätzlich > 0x00). Ja, die habe ich auch gesehen und mit niederohmiger Terminierung beseitigen können. Allerdings ist es so das ich das Problem schon beim Abhören an einem Loop-Adapter an einer Maschine habe und die Maschine beim Testen des Adapters weder 00 noch ff sieht, auch weil sie eine fail-safe-Terminierung verwendet. Deshalb habe ich es als "das Gras wachsen hören" bezeichnet. > Du schreibst auch, dass das Notebook nicht am Netzteil hängt. Dann > sollte also der Adapter "galvanisch" getrennt sein. Ja, das Notebook steht auch auf Plastik, das ist gut isoliert.
> > Ja, die habe ich auch gesehen und mit niederohmiger Terminierung > beseitigen können. > Allerdings ist es so das ich das Problem schon beim Abhören an einem > Loop-Adapter an einer Maschine habe und die Maschine beim Testen des > Adapters weder 00 noch ff sieht, auch weil sie eine > fail-safe-Terminierung verwendet. > Deshalb habe ich es als "das Gras wachsen hören" bezeichnet. > Mein Kenntnisstand bei "failsafe" ist, dass es zwei Arten von Receivern gibt: - die einen (klassisch) brauchen eine "Vorspannung", da ihr Logikpegel der (alten?) Norm entsprechend zwischen 0,2 und -0,2V (oder 0,3 :-) ) nicht definiert ist. Wenn dann kein Sender aktiv ist, ist der Bus bei 0V und undefiniert. Daher muss man mit einem Widerstandsnetzwerk zwischen (VCC) - R(Ohm) - (R+) - R(Ohm) - (R-) - R(Ohm) -GND eine entsprechende Vorspannung einstellen. Wenn Du nur Widerstände gegen GND hast, hilft das hier nichts. - die anderen Receiver habe in ihrer Spec oft "fail safe" angegeben. Dort ist der undefinierte Bereich verschoben, so dass er für 0V definiert ist. Diese brauchen nur die Terminierung. Meine Erfahrung ist, dass besonders bei den günstigen USB/RS422/485 Wandlern die klassischen Bauteile verbaut werden und man aktive Vorspannen muss. Versuch es mal mit 390 Ohm zwischen +5V und R+ und zwischen R- und GND. und 100/120 Ohm zwischen R+ und R-.
Der GND ist aber verbunden? dh zwischen RS422 Sender, Empfaenger und Horchstation, und Oszilloskop ist der GND verbunden ?
Siebzehn Zu Fuenfzehn schrieb: > Der GND ist aber verbunden? dh zwischen RS422 Sender, Empfaenger und > Horchstation, und Oszilloskop ist der GND verbunden ? Ja, natürlich. Alle Adern mit 1 mm² Kupfer und die USB-Kabel sind nur 1 m lang. Das Oszi anzuschließen ändert an den Geistern nichts und nur wegen den Geistern ist es überhaupt zu den RS-422-Adern gekommen. Zudem wird das Oszi mit Trenntravo genutzt um kein Rauschen über Erdschleifen einzufangen, d. h. sternpunktförmige Erdung über die Maschine mit der RS-422-Buchse sicherzustellen.
Hallo Rolf, wenn es mit einem anderen Adapter funktioniert, muß es am verwendeten Adapter liegen. Falls möglich, mit dem funktionierenden Adapter betreiben. Den Nichtfunktionierenden mal einer gründlichen Sichtkontrolle unterziehen - sind alle Bauteile vorhanden? Sind die Bausteine richtig verlötet? Befinden sich Znnbrücken zwischen Bahnen/Pins? Bei vielbeinigen SMD-Bauteilen mal mit einer Nadel an den Beinchen entlang fahren, ein nicht verlöteter Anschluß unterscheidet sich deutlich im Klang. Oder das Teil einfach durch einen Neuen ersetzen. Viel Erfolg. Tom
TomA schrieb: > Hallo Rolf, > > wenn es mit einem anderen Adapter funktioniert, ... Mit den Delock-Adaptern geht es nicht, denn die beiden zum Abhören verwendeten zeigen den gleichen Bug! Das ist ein Chargenfehler oder Serienfehler. Gemerkt habe ich das gemäß Murphys Law erst daraußen beim Kunden. Da kann ich auch nichts machen, weil die Maschinen seit Jahren kommunizieren. Und es soll da einfach gemessen werden, d. h. funktioniert der eine Adapter nicht, muss der Schrott weg und ein funktionierender her. Ein Kollege von einer anderen Firma, der die gleiche Leitung gleichzeitig mit anderen Adaptern und eigenem Notebook abhörte, hatte das Problem nicht.
Hallo Rolf, du könntest noch versuchen, die D+ und D- Leitungen mit Spannungsteilern vorzuspannen ( D+ ca 100mV-200mV negativer als D-), das vergrößert den Störspannungsabstand. Aber besser, die funktionierenden Adapter verwenden. Denn wenn der Fehler bei zwei der Delock-Adapter auftritt, wird er auch beim 3. 4. 5..... da sein. Eines fällt mir noch ein: Wenn möglich, mal mit einer geringeren Baudrate probieren. Gruß. Tom
Angehängte Dateien:
-
scope_13.png
12 KB -
scope_12.png
13 KB
Angehängt sind zwei Aufnahmen von den RS-422-Signalen: Gelb und grün die beiden Signale, violett-rosa die Differenz, alles mit 2 V/Kästchen. Aufgezeichnet wurden die Signale am direkt aufgesteckten Loop-Adapter mit 1:10-Tastköpfen, mit Oszi am Trenntravo und der Terminierung wie sie in der Maschine ist, wobei man hier bei nur 19,2 kBaud ist und daher auf Terminierung verzichten könnte. Die Kabellänge beträgt hier ja nur 3 cm. Zu sehen ist hier ein Test bei dem ca. alle 40 ms ein hochgezähltes Byte gesendet wird, also 0x12, 40 ms Pause, 0x13 usw.. Also sehr deutliche Signale, wenig Rauschen und trotzdem kommen aus den Delock-Adaptern Geister-Bytes.
:
Bearbeitet durch User
Hallo Rolf, jetzt fällt mir noch etwas ein. Verwendest du abgeschirmte Kabel? Dann ist vielleicht auf beiden Seiten der Schirm mit GND verbunden und bildet eine Erdschleife (Brummschleife). Das würde auch das zyklische auftreten der "Geisterbyte" erklären. Die funktionierenden Adapter haben vermutlich Schirm und GND getrennt. Wäre meiner Meinung nach einen Versuch wert, das nachzusehen/nachzumessen. Gruß. Tom
Hallo Rolf, habe jetzt erst die Bilder gesehen. Auf den Bildern ist alles wie aus dem Lehrbuch, ich kann da nichts aussergewöhnliches sehen. Der Pegelhub sieht auf den Bildern aus, wie 3V. Der gelbe Kanal (D-) liegt in Ruhe auf 3V und schaltet nach 0V, das sind 0,5V in Ruhelage vorgespannt. Für den grünen Kanal (D+) ist es umgekehrt. Ich nehme an er liegt in Ruhe auf 2V und schaltet nach +5V, also auch 0,5V vorgespannt. Sieht so aus, als wären die Leitungen mit jeweils 0,5V vorgespannt und damit der Störspannungsabstand bereits um 1V vergrößert. Der Pegel auf den Bildern ist etwas groß. Für einen 1:1 Tastkopf wäre er richtig -> von 1/2Ub nach VCC 5V sind 2,5V (1 1/4 Raster) und von 1/2Ub nach 0V sind 2,5V. Mit einem 1:10 Tastkopf wären die Pegel dann aber 25V. Ich denke der Tastkopf ist 1:1 und damit könnte das Signal gar nicht schöner sein. Gruß. Tom
TomA schrieb: > Der Pegel auf den Bildern ist etwas groß. Für einen 1:1 Tastkopf wäre er > richtig -> von 1/2Ub nach VCC 5V sind 2,5V (1 1/4 Raster) und von 1/2Ub > nach 0V sind 2,5V. Mit einem 1:10 Tastkopf wären die Pegel dann aber > 25V. Nein, das rechnet das Oszi selbst um. Eingestellt ist ein üblicher 1:10-Tastkopf und die Daten werden so angezeigt, wie sie an der Messspitze sind.
TomA schrieb: > Hallo Rolf, > > jetzt fällt mir noch etwas ein. Verwendest du abgeschirmte Kabel? Nein. Der Loop-Adapter verbindet mit 3 cm kurzen Drähten Eingang auf Ausgang. Und an dem Loop-Adapter hängt nur eine Maschine.
Wir verwenden einen US-324 von brainboxes.com: http://www.brainboxes.com/product/us-324/1-port-rs422-485-usb-to-serial-adapter Die haben eigene Treiber und lebenslange Garantie. RS und Farnell liefern für ca. 50 Euro.
Hallo Rolf, drei cm Kabellänge ist nicht viel. Da habe ich keine Erfahrung damit, ich kenne eher Probleme mit langen Leitungen in industrieller Umgebung. Könnte mir aber vorstellen, daß die fehlende Dämpfung des Kabels die Probleme verursacht. Du könntest also mal probieren eine Art "Kabelsimulator" in die Übertragung zu schalten, nur mal zum ausprobieren, ob es besser wird. Im einfachsten Fall hinten und vorne ein Kondensator zwischen D+ und D- und dazwischen in beiden Leitungen je einen Widerstand von ein paar Ohm. Aus dem Bauch ca. 47pF/4,7Ohm, um die Dämpfung von ein paar Meter Kabel zu simulieren. Wenn es funktioniert, findest du sicher die genaue Berechnung irgendwo im Netz. Viel Erfolg. Tom
Rolf F. schrieb: > TomA schrieb: >> Hallo Rolf, >> >> jetzt fällt mir noch etwas ein. Verwendest du abgeschirmte Kabel? > > Nein. > Der Loop-Adapter verbindet mit 3 cm kurzen Drähten Eingang auf Ausgang. > Und an dem Loop-Adapter hängt nur eine Maschine. Wirf noch einmal einen Blick auf Deine Failsafe-Bias-Pullups. So wie Du es in Post#1 beschrieben hast sind sie falsch. Ist das ein Schreibfehler? Beachte bitte auch daß manche Hersteller A und B in ihren Datenblättern vertauscht haben und deshalb viele Beispielschaltungen im Netz kursieren mit falscher Beschriftung der beiden Datenleitungen. Poste mal eine Skizze Deiner Schaltung, sonst kann man nur spekulieren. Wenn alles richtig ist dann ist die Hardware defekt (-> Tonne). Wenns auf 3 cm schon nicht geht wirst Du auf realen Distanzen im realen Einsatz (egal ob echt oder simuliert) erst recht nicht glücklich.
:
Bearbeitet durch User
Das Problem scheint ja nun auf den Delock-Adapter einzugrenzen zu sein. Wie wäre es, so einen mal zu "opfern", d.h. zu öffnen um sich die Beschaltung anzusehen?
Rolf F. schrieb: > RS-422/485 um die RS-422-Daten von/zwischen Maschinen mit einem Notebook > (ohne Netzteil) abzuhören, aber dabei zeigen sich Geister-Bytes, Wert > 0xff, die nicht auf den Leitungen sind, wie ich auch mit dem Oszilloskop > (über Trenntravo versorgt) sehe. Also liegt es offensichtlich nicht an den Leitungen bzw. Signalen. > Dagegen hilft auch nicht a) je 100 Ohm zwischen Rx+ und Rx-, Rx+ und > Gnd, Rx- und Gnd, sowie zusätzlich b) je 0,1 µF zwischen Rx+ und Rx-, > Rx+ und Gnd, Rx- und Gnd. Wäre ja auch komisch, da es nicht an den Signalen liegt. Auch wenn Dein Laptop nicht geerdet ist, würde ich trotzdem mal gucken, wie groß der Potentialunterschied ist. Ansonsten --> anderer Adapter. Delock zählt ja nun (preislich) nicht zu den Premiumprodukten, auch wenn ich bisher keine schlechten Erfahrungen mit Delock gemacht habe. VG, Hartmut
Nebenbei wäre auch interessant welche Adapter mehr als nur die Tx- und Rx-Adern haben, denn daneben gibt es auch die RTS, CTS und allgemein auch die anderen (RI, DCD, DSR, DTR). Die Delock-Adapter haben nur die Tx- und Rx-Adern. BTW: Die Karten von Brainboxes sind ja richtig schnell mit 18 Mbaud bei RS422/485 und 15 Mbaud bei RS232: http://www.brainboxes.com/high-speed-serial-cards Aber welche Mikrocontroller-UARTs kann man ebenso hoch takten?
:
Bearbeitet durch User
Hier ist mal ein typischer Ausschnitt aus einem Log: Date time daylight-saving-time device-number (hex)data: 2014-10-23 16:16:10.055629 1 1 eb 2014-10-23 16:16:10.055629 1 0 eb 2014-10-23 16:16:10.056815 1 1 ff 2014-10-23 16:16:10.095814 1 1 ec 2014-10-23 16:16:10.095955 1 0 ec 2014-10-23 16:16:10.135536 1 0 ed 2014-10-23 16:16:10.135536 1 1 ed 2014-10-23 16:16:10.136895 1 0 ff 2014-10-23 16:16:10.175683 1 0 ee 2014-10-23 16:16:10.175683 1 1 ee ff 2014-10-23 16:16:10.176922 1 0 ff 2014-10-23 16:16:10.215710 1 1 ef 2014-10-23 16:16:10.215877 1 0 ef Hierbei gehen die Daten vom Loop-Adapter auf die Eingänge 0 und 1 und bis auf den bei USB nicht-kleinen Jitter treffen die da auch gleichzeitig ein, im 40 ms-Raster. Und wenige ms danach kommen diese Geister-Bytes, von denen man im Oszi überhaupt nichts sieht. Mit nur einem statt zwei Adaptern sieht es ebenso aus (wobei der zweite Adapter ausgeblendet ist), d. h. die Geister-Bytes sind unabhängig davon ob man einen oder zwei Adapter verwendet.
Rufus Τ. Firefly schrieb: > Das Problem scheint ja nun auf den Delock-Adapter einzugrenzen zu sein. > > Wie wäre es, so einen mal zu "opfern", d.h. zu öffnen um sich die > Beschaltung anzusehen? Also das Aufschneiden ergab dass in dem braunen Plastik nicht einfach die Leiterkarte drinn ist sondern die Leiterkarte mit hellgrauer harter Vergussmasse. Da kommt man wohl nur mit Spezial-Chemikalien wie Trichlorameisensäure und einem Magnetrührer weiter.
:
Bearbeitet durch User
Also ich habe noch mit den stty-Parametern experimentiert und es zeigte sich das die Hardware ok ist und nur der Parameter parenb (generate parity bit in output and expect parity bit in input) fehlt ... Wie das aber Geister-Bytes erzeugen kann und warum das nur sporadisch auftritt und zusätzlich mit wechselndem Timing kann ich nicht nachvollziehen. Naja, jedenfalls funktioniert es jetzt. Übrigens kann man die BRAINBOXES US-313 USB - SERIELL,2 PORT,RS422/485 auf bis zu 3 Mbaud einstellen und unter Linux wird die ohne Treiber-Installation richtig erkannt.
Kann es sein, daß der Treiber Parity- oder Framing- Fehler signalisiert, indem er ein Markierungsbyte (hier eben ff) einfügt?
Nosnibor schrieb: > Kann es sein, daß der Treiber Parity- oder Framing- Fehler signalisiert, > indem er ein Markierungsbyte (hier eben ff) einfügt? Denkbar wäre es, aber das ff erschien ja nicht-deterministisch; verschiedene Messeungen mit immer der gleichen Byte-Sequenz ergaben ganz andere Logfiles. Mal erschien ff an beiden Eingängen mit gleichem Eingangssignal, mal nur an einem der beiden und mal überhaupt nicht. Das kann man als elektronischen Würfel verwenden.
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.