Hallo Zusammen, ich habe hier einen QinHeng USB2UART Wandler (lsusb sagt ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter), der bei 9600Baud nur Müll ausgibt (Fragezeichen etc) Ein anderer USB2UART Wandler (Prolific) mit der gleichen Datenquelle funktioniert super. Erkannt wird der QinHeng Wandler gut (dmesg meldet Erfolg und gibt /dev/ttyUSB0 an), Loopbacktest funktioniert auch ohne Probleme, selbst am Oszilloskop sehen die Signale identisch aus. Warum sehe ich am Terminal nur unlesbare Zeichen?
Moritz S. schrieb: > Warum sehe ich am Terminal nur unlesbare Zeichen? Hast du mal die Baudrate nachgemessen? Vielleicht liegt der Takt daneben.
Moritz S. schrieb: > Warum sehe ich am Terminal nur unlesbare Zeichen? Zieh Dir Hterm und schau mal nach wie das in Hexadezimal aussieht. Oder ist der eine ein UART und der andere RS232? Die haben unterschiedliche, vor allem auch invertierte Datenpegel.
Moritz S. schrieb: > selbst > am Oszilloskop sehen die Signale identisch aus. Glaube ich nicht. Von weitem vielleicht.
Moritz S. schrieb: > der bei 9600Baud nur > Müll ausgibt (Fragezeichen etc) erhöhe mal auf 2 Stopp-Bits. W.S.
Danke für die vielen konstruktiven Kommentare! hp-freund schrieb: > 7bit / 8bit richtig eingestellt? W.S. schrieb: > erhöhe mal auf 2 Stopp-Bits. > > W.S. Beides am PC ausprobiert, leider kein Erfolg. Oder meint ihr, dass der USB2UART Adapter nur 7bit / nur 2stoppbits versteht und ich das daher HW-seitig (am ATmega) umstellen muss? Jim M. schrieb: > Zieh Dir Hterm und schau mal nach wie das in Hexadezimal aussieht. Hterm hab ich nicht, aber das Kommandozeilenprogramm xxd zeigt auch in hex an (/dev/ttyUSB0 ist der QinHeng Wandler, /dev/ttyUSB1 der funktionierende):
1 | moritz@desktop:~$ cat /dev/ttyUSB0 9600 | xxd |
2 | 0000000: a9f6 b69f bf2f 9d8b 9fbf 259d 9f8b 9fbf ...../....%..... |
3 | 0000010: 259d 8b93 bf19 8b97 8fbf 9f3b 9d9f 9f9f %..........;.... |
4 | 0000020: a9f6 b69f bf2f 9d8b 9fbf 259d 9f8b 9fbf ...../....%..... |
5 | 0000030: 259d 8b93 bf19 8b95 9fbf 9f3b 9d9f 9f9f %..........;.... |
6 | 0000040: 9d9f 9f9f 9d9f 9f9f e5eb 00a9 f6b6 9fbf ................ |
7 | 0000050: 2f9d 8b9f bf25 9d9f 8b9f bf25 9d8b 93bf /....%.....%.... |
8 | 0000060: 198b 959d bf9f 3b9d 9f9f 9f9d 9f9f 9f9d ......;......... |
9 | 0000070: 9f9f 9fe5 eb00 a9f6 b69f bf2f 9d8b 9fbf .........../.... |
10 | 0000080: 259d 9f8b 9fbf 259d 8b93 bf19 8b95 9bbf %.....%......... |
11 | 0000090: 9f3b 9d9f 9f9f 9d9f 9f9f 9d9f 9f9f e5eb .;.............. |
12 | 00000a0: 00a9 f6b6 9fbf 2f9d 8b9f bf25 9d9f 8b9f ....../....%.... |
13 | 00000b0: bf25 9d8b 93bf 198b 9599 bf9f 3b9d 9f9f .%..........;... |
14 | ^C |
15 | moritz@desktop:~$ cat /dev/ttyUSB1 9600 | xxd |
16 | 0000000: 6831 303a 3020 6831 3a30 206d 3130 3a30 h10:0 h1:0 m10:0 |
17 | 0000010: 206d 313a 3720 733a 3232 2030 6230 0a0a m1:7 s:22 0b0.. |
18 | 0000020: 6831 303a 3020 6831 3a30 206d 3130 3a30 h10:0 h1:0 m10:0 |
19 | 0000030: 206d 313a 3720 733a 3233 2030 6231 3030 m1:7 s:23 0b100 |
20 | 0000040: 3030 3030 3030 3030 3030 300a 0a68 3130 00000000000..h10 |
21 | 0000050: 3a30 2068 313a 3020 6d31 303a 3020 6d31 :0 h1:0 m10:0 m1 |
22 | 0000060: 3a37 2073 3a32 3420 3062 3130 3030 3030 :7 s:24 0b100000 |
23 | 0000070: 3030 3030 3030 300a 0a68 3130 3a30 2068 0000000..h10:0 h |
24 | 0000080: 313a 3020 6d31 303a 3020 6d31 3a37 2073 1:0 m10:0 m1:7 s |
25 | 0000090: 3a32 3520 3062 3130 3030 3030 3030 3030 :25 0b1000000000 |
26 | ^C |
27 | moritz@desktop:~$ |
Das zweite und dritte Zeichen ("1" und "0" haben aufeinander folgende
ASCII Werte, selbst davon sieht man bei dem QinHeng Wandler nichts!
(Jedes Telegram fängt mit "h10" an. Es handelt sich dabei um eine
Binäruhr.)
> Oder ist der eine ein UART und der andere RS232? Die haben
> unterschiedliche, vor allem auch invertierte Datenpegel.
Das habe ich als allererstes geprüft. Beide machen TTL-Pegel.
Wolfgang schrieb:
> Hast du mal die Baudrate nachgemessen?
> Vielleicht liegt der Takt daneben.
Ich bin mir nicht ganz sicher, was du meinst. Ich hab im Atmega 9600Baud
eingestellt und der funktionierende Wandler zeigt das richtige an, wenn
ich 9600Baud einstelle. Im Loopbacktest stimmen die Bitzeiten (104us)
zwischen den beiden Wandlern überein.
Arduino F. schrieb:
> Moritz S. schrieb:
>> selbst
>> am Oszilloskop sehen die Signale identisch aus.
> Glaube ich nicht.
> Von weitem vielleicht.
Zu beiden Beiträgen: Meine Datenrichtung ist ausschliesslich ATMega -->
PC. Die USB2UART Wandler müssen also nur empfangen. Die Datenrichtung
des fraglichen USB2UART Wandlers kann ich ja nur im Loopbacktest
nachprüfen. Da sahen die Signale der beiden Wandler identisch aus.
Ich habe im Moment den Verdacht, dass der QinHeng zwar mit TTL-Pegeln
arbeitet, die Signale aber trotzdem invertiert (erwartet). Das muss ich
heute abend prüfen, muss jetzt erstmal zur Arbeit.
Moritz S. schrieb: > Ich bin mir nicht ganz sicher, was du meinst. Es geht nicht um den Takt und die Baudrate der Wandler, sondern um den Deines AVR. Der wird üblicherweise mit einem RC-Oszillator erzeugt, und ist so ungenau und unstabil, daß es bei seriellen Übertragungen zu Problemen kommen kann. Das scheint bei Dir aber nicht das Problem zu sein. Sieh Dir mal Deine Platine mit dem CH-340 genauer an. Welche Variante des CH-340 ist darauf verbaut? Laut Datenblatt* gibt es einen CH340R, dessen Verhalten durch den Pegel an Pin 17 zwischen normalem seriellen Betrieb (offen bzw. High) und IR-Betrieb (low) umgeschaltet werden kann. *) https://www.olimex.com/Products/Breadboarding/BB-CH340T/resources/CH340DS1.PDF
Moritz S. schrieb: > Beides am PC ausprobiert, leider kein Erfolg. Oder meint ihr, dass der > USB2UART Adapter nur 7bit / nur 2stoppbits versteht und ich das daher > HW-seitig (am ATmega) umstellen muss? Nein, der kann auch ganz normal 8 bit + 1 stopbit. Was der unter Linux allerdings bei den etwas älteren Kerneln (*buntu 14.04 bis ?) gar nicht kann sind Parity bits. Schließ doch mal die beiden Wandler zusammen und öffne mal zwei Terminals, da müsste dann ja was im einen raus geht im anderen reinkommen. Ich benutze ganz gerne Picocom, das hat nicht so viel Schnickschnack und ist für fast jede Distri verfügbar.
1 | picocom --echo -b 9600 /dev/ttyUSB0 |
und zum beenden einfach <Ctrl-a>,<Ctrl-x>
Die Vermutung hat gestimmt, die Signalpegel haben zwar TTL-Level, sind aber tatsächlich invertiert. Eine einfache Emitterschaltung zwischen Signalquelle und Qinheng Wandler sorgt ganz spontan für fehlerfreie Telegramme :) Rufus Τ. F. schrieb: > Laut Datenblatt* gibt es einen CH340R, dessen Verhalten durch den Pegel > an Pin 17 zwischen normalem seriellen Betrieb (offen bzw. High) und > IR-Betrieb (low) umgeschaltet werden kann. Danke für den Tipp, das Ändern des Pegels an Pin 17 wäre eine super Option, wenn der Chip nicht im vergossenen D-SUB9 Gehäuse stecken würde. Dazu sieht es so aus, als wäre der Die direkt auf die Platine gebondet, mit dem entsprechenden schwarzen Blob obendrauf. Da finde ich dann wahrscheinlich auch keinen Pin 17 mehr. Ich denke, ich mach mir einfach eine kleine Adapterplatine mit zwei Emitterschaltungen, die dann dauerhaft am Qinheng Wandler angesteckt bleibt.
Moritz S. schrieb: > Hterm hab ich nicht, aber das Kommandozeilenprogramm xxd zeigt auch in > hex an (/dev/ttyUSB0 ist der QinHeng Wandler, /dev/ttyUSB1 der > funktionierende): Hast du Internetanschluss? Dann kannst du dir HTerm einfach runter laden und brauchst nicht einmal irgendetwas zu installieren. Heutzutage würde man wohl sagen, dass es sich um ein tragbares Programm handelt. Und störe dich nicht dran, dass es als Beta-Version bezeichnet ist. Das ist seit 8 Jahren so. Die möglicherweise verhandenen Bugs haben es bisher auch nicht gemerkt ;-) http://www.der-hammer.info/terminal/ Wilde Zeichenfolgen sind meist ungeeignet, um systematischen Bitfehlern auf die Spur zu kommen. Um den Fehler einzukreisen, ist es sinnvoll, bestimmte Einzelzeichen oder folgen aus genau zwei Zeichen zu übertragen, um Signalpolarität, Fehler der Symbolzeit oder inkompatible Stop-Bit Anzahl gezielt zu prüfen. Sonst siehst du den Wald vor lauter Bäumen nicht. Um Zeichen auf dem Oszi zu prüfen, musst der Adapter Zeichen senden. Beim Empfang kannst du erst ganz am Ende der Übertragungskette, nämlich auf dem Terminal, kontrollieren und das macht die Sache oft unübersichtlich.
Moritz S. schrieb: > Die Vermutung hat gestimmt, die Signalpegel haben zwar TTL-Level, > sind aber tatsächlich invertiert. Eine einfache Emitterschaltung > zwischen Signalquelle und Qinheng Wandler sorgt ganz spontan für > fehlerfreie Telegramme :) > > Rufus Τ. F. schrieb: > Laut Datenblatt* gibt es einen CH340R, dessen Verhalten durch den Pegel > an Pin 17 zwischen normalem seriellen Betrieb (offen bzw. High) und > IR-Betrieb (low) umgeschaltet werden kann. > > Danke für den Tipp, das Ändern des Pegels an Pin 17 wäre eine super > Option, wenn der Chip nicht im vergossenen D-SUB9 Gehäuse stecken würde. Der Wandler hat einen dsub9, und du steuerst den mit "UART Pegeln", also TTL an?
Simon K. schrieb: > Der Wandler hat einen dsub9, und du steuerst den mit "UART Pegeln", also > TTL an? Wird wohl! Ein TTL <-> Rs232c Wandler invertiert. (Meist) Also alles Richtig so, nur das falsche Werkzeug.
W.A. schrieb: > Dann kannst du dir HTerm einfach runter laden und brauchst nicht einmal > irgendetwas zu installieren. Heutzutage würde man wohl sagen, dass es > sich um ein tragbares Programm handelt. Mir ist Hterm durchaus bekannt, das es "tragbar" ist, war mir hingegen nicht bekannt. Arduino F. schrieb: > Simon K. schrieb: >> Der Wandler hat einen dsub9, und du steuerst den mit "UART Pegeln", also >> TTL an? > > Wird wohl! > Ein TTL <-> Rs232c Wandler invertiert. > (Meist) > Also alles Richtig so, nur das falsche Werkzeug. Alles richtig finde ich nicht. Mir sind zwei Normen bekannt: 1) RS232 mit +-3...12V, invertierte Pegel, mechanisch D-SUB9 und 2) TTL mit 0V und 5V, keine invertierten Pegel, mechanisches Interface nicht definiert (meist Pinleisten) Der Qinheng macht TTL Pegel, die aber invertiert werden müssen, um lesbar zu sein. Wie ganz oben geschrieben, habe ich zu Beginn die Pegel geprüft. Ich habe 0V/5V gesehen und gedacht "super, kein RS232, müsste alles so funktionieren."
Moritz S. schrieb: > Wie ganz oben geschrieben, habe ich zu Beginn die Pegel geprüft. Ich > habe 0V/5V gesehen und gedacht "super, kein RS232, müsste alles so > funktionieren." Ein Irrtum! Einen Billig Wandler erwischt, der zwar invertiert, aber keine RS232C korrekten Pegel fertigt. Ein Max war dem Hersteller wohl zu teuer... (Griff ins Klo) + (falsche Annahme) = Problem ;-)
Arduino F. schrieb: > Moritz S. schrieb: > Wie ganz oben geschrieben, habe ich zu Beginn die Pegel geprüft. Ich > habe 0V/5V gesehen und gedacht "super, kein RS232, müsste alles so > funktionieren." > > Ein Irrtum! > > Einen Billig Wandler erwischt, der zwar invertiert, aber keine RS232C > korrekten Pegel fertigt. Ein Max war dem Hersteller wohl zu teuer... > > (Griff ins Klo) + (falsche Annahme) = Problem > > ;-) Da stimme ich zu! Man sieht: der Fehler ist immer da wo man ihn nicht vermutet. Hättest du alle Informationen von Anfang an reingestellt wäre das evtl früher aufgefallen. ;-)
Simon K. schrieb: > Da stimme ich zu! Man sieht: der Fehler ist immer da wo man ihn nicht > vermutet. Hättest du alle Informationen von Anfang an reingestellt wäre > das evtl früher aufgefallen. ;-) Man weiss halt nie, welche Informationen wichtig sind und welche nicht. Ich hätte auch schreiben können, dass der Wandler ein blaues Gehäuse und ein klares Kabel hat. Arduino F. schrieb: > (Griff ins Klo) + (falsche Annahme) = Problem trifft die Sache aber schon recht gut :)
Moritz S. schrieb: > Man weiss halt nie, welche Informationen wichtig sind und welche nicht. Hmm... Ein Link zu den Dingern, hätte es sofort klar gemacht. Ich sach nur: SUB-D Moritz S. schrieb: > trifft die Sache aber schon recht gut Danke, für die Blumen.
Moritz S. schrieb: > Simon K. schrieb: >> Da stimme ich zu! Man sieht: der Fehler ist immer da wo man ihn nicht >> vermutet. Hättest du alle Informationen von Anfang an reingestellt wäre >> das evtl früher aufgefallen. ;-) > > Man weiss halt nie, welche Informationen wichtig sind und welche nicht. > Ich hätte auch schreiben können, dass der Wandler ein blaues Gehäuse und > ein klares Kabel hat. Auf dem Oszi hätte man gesehen das der IDLE Pegel falsch ist. Das hätte gereicht.
Ein Schaltplan wäre auch hilfreich gewesen. Oder mindestens ein Schaltbild.
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.