USB2UART (QinHeng) gibt nur Müll aus

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.

> QinHeng USB2UART Wandler
Der kann nur chinesisch.

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:
> 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?

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."

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:
> 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.