Übertragungsunterschiede bei RS232?

Hi,

hat denn keiner einen Vorschlag woran das liegen kann?

Gruß kami

Das kann ein Konvertierungsproblem sein, (ASCII->UTF8) oder auch mit den 
unterschiedlichen Newline codierungen zu tun haben.
Lass dir die Daten als Hex-Code darstellen und vergleiche sie.

Naja wenn die Baudrate nicht stimmt schaut's etwa so aud wie im Zweiten. 
Zwei Prozent falsch genuegen...
 Allerdings ist  7bit, even parity, 1 stop hinreichend exotisch. 
Standard ist 8bit no parity, 1 stop.

Hi,

also das komisch ist, das ich inzwischen mit zterm unter Mac und mit 
Hterm unter Windows das richtige ergebnis bekommen. Kann es ein 
Kodierungsproblem unter Linux sein? Das mir diesen Output liefert? Ich 
verstehe es nicht mehr. Wie kann ich das unter Linux testen, ob es an 
der Codierung liegt?

Vielen Dank.

Gruß kami

@ Stefan S.
Installiere unter linux das Programm "moserial", da sind dann zwei 
Fenster in denen du die empfangenen Bytes als ASCII und hex sehen 
kannst.
sudo apt-get install moserial
Speichere dann einen Abschnitt und Poste den als Datei hier.

Man kann sich das dann mit einem Hex-editor anschauen oder unter Linux 
mit einem Texteditor der die Daten UTF Codiert.

Hi,

problem mit moserial ist, ich habe nur eine console das ist ein server 
und ich kann da nicht gtk installieren. Gibt es noch ein anderes Tool.

Vielen dank.

Gruß kami

Hi

okay hier ist der Output:

00000000  af c5 53 59 35 d1 33 44  41 b1 30 30 b4 a0 56 33 
|..SY5.3DA.00..V3|
00000010  2e 30 b2 8d 0a 8d 0a b1  2d 30 3a 30 2e 30 2e 30 
|.0......-0:0.0.0|
00000020  aa b2 35 35 28 30 b2 b7  33 30 b1 b1 30 30 33 b4 
|..55(0..30..003.|
00000030  36 33 a9 8d 0a b1 2d 30  3a b1 2e b8 2e 30 aa b2 
|63....-0:....0..|
00000040  35 35 28 30 30 30 30 b1  33 b4 30 2e b1 39 35 35 
|55(0000.3.0..955|
00000050  b1 35 33 aa eb d7 e8 a9  8d 0a b1 2d 30 3a b2 b1 
|.53........-0:..|
00000060  2e b7 2e b2 35 35 aa b2  35 35 28 30 30 30 30 36 
|....55..55(00006|
00000070  b4 2e 33 36 aa d7 a9 8d  0a b1 2d 30 3a b4 b1 2e 
|..36......-0:...|
00000080  b7 2e b2 35 35 aa b2 35  35 28 30 30 30 33 b8 b1 
|...55..55(0003..|
00000090  2e b4 35 aa d7 a9 8d 0a  b1 2d 30 3a 36 b1 2e b7 
|..5......-0:6...|
000000a0  2e b2 35 35 aa b2 35 35  28 30 30 30 b1 b1 b7 2e 
|..55..55(000....|
000000b0  39 33 aa d7 a9 8d 0a b1  2d 30 3a b1 2e b7 2e b2 
|93......-0:.....|
000000c0  35 35 aa b2 35 35 28 30  30 30 35 36 33 2e b7 b4 
|55..55(000563...|
000000d0  aa d7 a9 8d 0a b1 2d 30  3a 39 36 2e 35 2e 35 aa 
|......-0:96.5.5.|
000000e0  b2 35 35 28 b8 b2 a9 8d  0a 30 2d 30 3a 39 36 2e 
|.55(.....0-0:96.|
000000f0  b1 2e b2 35 35 aa b2 35  35 28 b1 c5 53 59 b1 30 
|...55..55(..SY.0|
00000100  b1 b1 30 30 33 b4 36 33  a9 8d 0a 21 8d 0a 
|..003.63...!..|
0000010e

habe aber auf dem Server kein X laufen :)

Gruß kami

Im Hexdump sind Bytes mit gesetztem Bit 7 zu sehen - das passt nicht zu 
den angeblichen 7 Datenbits. Und das wird auch das Darstellungsproblem 
sein, wenn man nämlich 7 Bit + Parity als 8 Bit ohne Parity empfängt, 
dann ist das Paritybit das Bit 7.

Mhh,

und jetzt nochmal für doofe warum kriege ich mit hterm und mit zterm 
einen output so wie ich will und mit cat nicht?

Weil in einem Fall Deine serielle Schnittstelle anders konfiguriert 
wird als im anderen.

Okay wie kriege ich das unter Linux hin, das der Output so aussieht wie 
ich will? es muss doch irgendwie gehen?

Gruß kami

mhh damit komme ich jetzt gar nicht klar.

Verstehe nicht wie und was ich da einstellen soll?

Gruß kami

okay,

das habe ich schon probiert der Output sieht immer noch gleich aus. und 
stty -a liefert:

speed 9600 baud; rows 0; columns 0; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = 
<undef>; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = 
<undef>;
stop = <undef>; susp = <undef>; rprnt = <undef>; werase = <undef>; lnext 
= <undef>; flush = <undef>; min = 0; time = 16;
parenb parodd cs7 -hupcl -cstopb cread clocal -crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon 
ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 
bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop 
-echoprt -echoctl -echoke

Gruß kami

Okay auch bei dem -parodd sieht der Output noch identisch aus.

Gruß kami

> okay hier ist der Output:
>
> 00000000  af c5 53 59 35 d1 33 44  41 b1 30 30 b4 a0 56 33

Wenn cs7 bei stty angegeben wird, dann sollte das nicht rauskommen 
können. af, d1, b1 und b4 sind offensichtlich größer als 7f und damit 
nicht mit 7 Bit darstellbar.

Da ist dann irgendwas kaputt, entweder lässt der Treiber der seriellen 
Schnittstelle auf dem System keine 7 Bit Wortlänge zu, oder stty ist 
doch anders aufgerufen worden.


Eine mögliche Abhilfe wäre ein kleines Skript, das jedes Byte aus der 
mit

cat /dev/ttyUSB0 > temp.data

erzeugten Datei temp.data vom Bit 7 befreit und wiederum irgendwohin 
ausgibt.

Die Unixkenner hier (ich bin keiner) werden wissen, wie das am 
geschicktesten geht.

Hi,

sorry das ich erst jetzt antworte, aber ich bin gerade erst von der 
Arbeit wieder gekommen. Also erstmal vielen Dank für die ganze Hilfe und 
Tipps. Ich habe mal alles getestet und das einzige was klappt ist:

stty sane raw 9600 cs8 -cstopb istrip -F /dev/rfcomm0

Damit kriege ich wunderschön den Output mit cat /dev/rfcomm0 den ich 
möchte.
Sieht super aus und ist alles drin. Nun möchte ich aber gerne die Daten 
mit einem Perlskript auswerten. Dafür nehme ich eigentlich das CPAN 
Module use Device::SerialPort;

Hier mal mein Skript. Das klappt aber so noch nicht und müsste angepasst 
werden. Oder wie soll ich das machen???

use strict;

use warnings;
use Device::SerialPort;

use POSIX;

$| = 1;


my $port = Device::SerialPort->new( "/dev/rfcomm0" );
$port->baudrate(9600);
$port->databits(8);
$port->stopbits(1);
$port->parity("none");
$port->read_const_time(1000);
$port->write_settings || undef $port;

my $count=0;
my $byte="";

while(1) {
  ($count,$byte)=$port->read(270);
      if ($count > 0) {
      print "$byte";

}


}

Vielen Dank.

Gruß kami

ja habe ich selbes problem.

Gruß kami

Dann kann möglicherweise rfcomm keine 7-Bit-Übertragung. Aber das macht 
nichts, denn Du wirst auch in Perl an dieser Stelle

1

while(1) {

2

  ($count,$byte)=$port->read(270);

3

      if ($count > 0) {

4

      print "$byte";

das Bit 7 der empfangen Daten löschen.

Hi,

danke für die Tipps. Leidr bin ich was das abschneiden von irgendwelchen 
Bits angeht nicht so gut. Könnte mir jemand vielleicht das Skript 
entsprechend anpassen?

Vielen Dank.

Gru0 kami

Ich nicht, ich hab bei Perl keinen Fuß in der Tür, das sieht mir 
meistens so aus, als wäre eine Katze über die Tastatur gelaufen.

Hehe, ja das Problem kenne ich. Vielleicht wäre ja jemand anderes so 
nett.

Gruß kami

Vielen Dank.

Problem gelöst läuft super :)

Vielen Vielen Dank an alle hier.

Gruß kami