# RXTX Geschwindigkeit? Codebeispiel dabei.



## Only08 (21. Apr 2008)

Hey,

ich arbeite gerade an meiner Diplomarbeit und muss dafür einen konstanten Datenstrom eines Empfängers auswerten. Dieser ist über USB an den Rechner angeschlossen und wir am COM-Port5 erkannt und wird mit einer Baudrate von 250000 angesprochen.
Mein Problem ist nun dass ich RXTX-API verwenden möchte, aber im Moment nur Quatsch vom Port gelesen bekomme. In einem Terminaltool kommen die Daten kbyte-wesie und in Java bekomme ich zwei Zeichen pro Sekunde.

Ist das ein Problem von Java oder des Codes?

```
import gnu.io.*;

import java.io.IOException;
import java.io.InputStream;
//import java.io.OutputStream;
import java.util.Enumeration;
import java.util.TooManyListenersException;

//import OeffnenUndSenden.serialPortEventListener;



public class EinfachEmpfangen implements Runnable {

	public static void main(String[] args)
	{
		Runnable runnable = new EinfachEmpfangen();
		new Thread(runnable).start();
		System.out.println("main finished");
	}
	
	CommPortIdentifier serialPortId;
	Enumeration enumComm;
	SerialPort serialPort;
	//OutputStream outputStream;
	InputStream inputStream;
	Boolean serialPortGeoeffnet = false;

	int baudrate = 250000;
	int dataBits = SerialPort.DATABITS_8;
	int stopBits = SerialPort.STOPBITS_1;
	int parity = SerialPort.PARITY_NONE;
	String portName = "COM5";
	
	public EinfachEmpfangen()
	{
		System.out.println("Konstruktor: EinfachSenden");
	}
	
    public void run()
    {
        if (oeffneSerialPort(portName) != true)
        	return;
    	
    }
    
	boolean oeffneSerialPort(String portName)
	{
		Boolean foundPort = false;
		if (serialPortGeoeffnet) {
			System.out.println("Serialport bereits geöffnet");
			return false;
		}
		System.out.println("Öffne Serialport");
		enumComm = CommPortIdentifier.getPortIdentifiers();
		while(enumComm.hasMoreElements()) {
			serialPortId = (CommPortIdentifier) enumComm.nextElement();
			if (portName.contentEquals(serialPortId.getName())) {
				foundPort = true;
				break;
			}
		}
		if (foundPort != true) {
			System.out.println("Serialport nicht gefunden: " + portName);
			return false;
		}
		try {
			serialPort = (SerialPort) serialPortId.open("Öffnen und Senden", 500);
		} catch (PortInUseException e) {
			System.out.println("Port belegt");
		}
		try {
			inputStream = serialPort.getInputStream();
		} catch (IOException e) {
			System.out.println("Keinen Zugriff auf InputStream");
		}
		try {
			serialPort.addEventListener(new serialPortEventListener());
		} catch (TooManyListenersException e) {
			System.out.println("TooManyListenersException für Serialport");
		}
		serialPort.notifyOnDataAvailable(true);
		try {
			serialPort.setSerialPortParams(baudrate, dataBits, stopBits, parity);
		} catch(UnsupportedCommOperationException e) {
			System.out.println("Konnte Schnittstellen-Paramter nicht setzen");
		}
		
		serialPortGeoeffnet = true;
		return true;
	}

	void schliesseSerialPort()
	{
		if ( serialPortGeoeffnet == true) {
			System.out.println("Schließe Serialport");
			serialPort.close();
			serialPortGeoeffnet = false;
		} else {
			System.out.println("Serialport bereits geschlossen");
		}
	}
	
	void serialPortDatenVerfuegbar() {
		try {
			byte[] data = new byte[150];
			int num;
			while(inputStream.available() > 0) {
				num = inputStream.read(data, 0, data.length);
				System.out.println("Empfange: "+ new String(data, 0, num));
			}
		} catch (IOException e) {
			System.out.println("Fehler beim Lesen empfangener Daten");
		}
	}

	class serialPortEventListener implements SerialPortEventListener {
		public void serialEvent(SerialPortEvent event) {
			System.out.println("serialPortEventlistener");
			switch (event.getEventType()) {
			case SerialPortEvent.DATA_AVAILABLE:
				serialPortDatenVerfuegbar();
				break;
			case SerialPortEvent.BI:
			case SerialPortEvent.CD:
			case SerialPortEvent.CTS:
			case SerialPortEvent.DSR:
			case SerialPortEvent.FE:
			case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
			case SerialPortEvent.PE:
			case SerialPortEvent.RI:
			default:
			}
		}
	}	
}
```

Ich habe den Code aus dem Netz und würde nun gerne wissen, ob wiederum einer von euch weiss wo das Problem liegen könnte?

Danke schonmal.

CIAO


----------



## tuxedo (21. Apr 2008)

Vielleicht täusche ich mich ja. Aber "normale" RS232 Ports können nur bis 115.200 Baud. 250.000 Baud sieht mir mehr nach einem "Fehler" oder eine Industrie-RS232-Schnittstelle aus. 

Was für ein Empfänger ist das denn?


- Alex

[edit]

korrektur, ist ja ein Gerät das einen virtuellen COM-Port via USB benutzt ... Also vergiss was ich geschrieben hab. Dennoch ist 250.000 ein recht ungewöhnlicher Wert. Was für ein Gerät ist das denn?


----------



## Only08 (22. Apr 2008)

Es handelt sich um einen Tuner der via USB angeschlossen ist. Ich habe das Gerät mit einem terminaltool abgefragt und mit einer Baudrate von 250000 die richtigen Signale erhalten. Also die Baudrate stimmt schon. Nun ist irgendwie die Frage, ob Java vielleicht doch irgendwo noch andere Zahlen hernimmt, weil das ergebins dem ähnelt, wenn ich im Terminaltool eine kleine Baudrate einstelle.

Jemand vielleicht noch eine Idee?


----------



## tuxedo (22. Apr 2008)

Das Ding hat doch sicher ein Handbuch oder eine okumentation in der die Daten für die serielle Verbindung drin stehen. 250.000 ist auf jeden Fall sehr ungewöhnlich. 

Hyperterminal (das Ding was mit Windows XP mitkommt) hat folgende Baud-Rasterung (und soweit ich weiß sind das "standard" Schritte):

110 Baud
300 Baud
1200 Baud
2400 Baud
4800 Baud
9600 Baud
19200 Baud
38400 Baud
57600 Baud
115200 Baud
230400 Baud
460800 Baud
921600 Baud

Probiers in Java doch mal mit 230400 Baud. Vielleicht geht's dann. Könnte mir vorstellen dass dein verwendetes Terminalprogramm bei einer Einstellung von 250.000 Baud intern zurück auf 230.400 Baud fällt.  Aber ein Blick ins Handbuch schadet auf jeden Fall nicht.

- Alex


----------



## Only08 (22. Apr 2008)

Hey, vielen Dank es waren wirklich die 230400. War mir nicht bewusst dass das Tool runterregelt. Ich bekomme jetzt auch Daten. Das erste Zeichen ist immer das selbe und das stimmt auch im Programm, nur leider ist der Rest noch nicht ganz korrekt. Zumal er manchmal 9 Zeichen und manchmal 8 Zeichen hintereinander schreibt. In der Consolenausgabe sieht das ganze dann so aus:

Öffne Serialport
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
serialPortEventlistener
Empfange: ó™’HHT+Ë
Empfange: üã™Dc'$
Empfange: ´ø
serialPortEventlistener
Empfange: ó
serialPortEventlistener
Empfange: ™²5ÿ
serialPortEventlistener
Empfange: ó
serialPortEventlistener
Empfange: ™òA²*‡*þ

Eigentlich müsste nach dem ó eine 3 kommen, da es sich um den RDS-STrom von Fritz handelt und das der PI-Code wäre der den Sender genau identifiziert und immer gleich übertragen wird. Das ist doch aber schon ASCII was der da ausgibt oder?

EDIT: Zum Thema Handbuch. Es handelt sich dabei um einen Bausatz von ELV, dem eine eher spärliche Beschreibung beilag. Also da ist keine Hilfe zu erwarten 

EDIT 2: So ich hab mal die Baudrate in meinem HTerm, dem Terminaltool dass ich verwend eingegeben und der bringt mir die selben komischen Daten wie mein Java Programm. Allerdings HTerm bei 250000 100% das richtige Ergebnis geliefert. Wenn ich aber 250000 in Java nutze kommt wieder nur Quark. Das irritiert und ärgert mich langsam.


----------



## tuxedo (22. Apr 2008)

>>Das ist doch aber schon ASCII was der da ausgibt oder? 

So wie's aussieht nicht. SOnst wäre es ja irgendwie lesbarer.
Java arbeitet mit "signed" byte-werten. D.h. ein Byte kann -127..128 als Wert haben. Wenn das Gerät (könntest du mir mal nen Link dazu geben? Interessiert mich ...) aber mit "unsigned" arbeitet, geht es von Werten von 0..255 aus. D.h. die codierungen passen nicht zusammen.

Du könntest jedes eingehende Zeichen mal folgendem unterziehen:


```
byte signedbyte = (int) (unsignedByte  & 0xff)
```

Habs nicht getestet. Das mit dem casten wird wohl schief gehen. Aber so in der Art müssts gehen. Aber wie gesagt: ETWAS mehr doku wäre nicht schlecht.

- Alex


----------



## Only08 (22. Apr 2008)

Man man man, du bist zu schnell 
Hatte es schon editiert aber wer weiss ob das noch einer gelesen hat:
So ich hab mal die Baudrate in meinem HTerm, dem Terminaltool dass ich verwend eingegeben und der bringt mir die selben komischen Daten wie mein Java Programm. Allerdings HTerm bei 250000 100% das richtige Ergebnis geliefert. Wenn ich aber 250000 in Java nutze kommt wieder nur Quark. Das irritiert und ärgert mich langsam.


Also es handelt sich um das RDS100 mit optionalen USB-Modul UO100


EDIT: Das mit dem Code hat nicht gefunzt. Es handelt sich dabei um ein Array und ich habe keinen richtigen Index dafür in der While schleife. Solltest du nen anderen weg kennen, würde ich mich sehr freuen.


----------



## tuxedo (22. Apr 2008)

Wie? Ein Array hat immer einen Index. Du musst halt byte für byte durch die Konvertierung jagen. Anders geht's nicht. Und die read() Methode liefert die ja die Anzahl bytes die gelesen wurden.

- Alex


----------



## tuxedo (22. Apr 2008)

Also in der Doku hab ich das hier gefunden:


```
Max. Übertragungsrate: 115,2 kBit/s
```

Also ist >200.000 schonmal _sehr_ seltsam....
Probier das ganze mal mit Hyperterminal und den 115.200 

- Alex


----------



## Only08 (22. Apr 2008)

Also ich muss ganz ehrlich zugeben dass ich noch nicht verstanden habe, wie das mit dem read auf das byte[] funktioniert. Ich habe mir die Dokumentation durchgelesen und wurde trotzdem nicht schlauer.
Im Moment siehts ja noch so aus:

```
void serialPortDatenVerfuegbar() {
		try {
			byte[] data = new byte[150];
			int num;
			while(inputStream.available() > 0) {
				num = inputStream.read(data, 0, data.length);
				System.out.println("Empfange: "+ new String(data, 0, num));
			}
		} catch (IOException e) {
			System.out.println("Fehler beim Lesen empfangener Daten");
		}
	}
```

Ich bin mir jetzt nicht genau sicher wo ich die Transformation von unsigned zu signed machen soll.

Achso und mit Java bekomme ich bei 230400 Baudrate die besten Ergebnisse. Drunter gehts gehts gar nicht!


----------



## tuxedo (22. Apr 2008)

Was mir da noch so einfällt: Wie druckst du denn das Zeug auf der Konsole aus?

Schließlich liest du immer gerade soviel wie gelesen werden kann, und nicht bis ein Zeilenumbruch oder ähnliches kommt.

Finde deshalb auch den Ansatz mit dem SerialPortEventListener etwas ungeschickt. 

Und wie sollten die Daten korrekterweise aussehen (also z.B. in deinem Terminalprogramm, wie schauts da aus?).

Und hast du mal Hyperterminal probiert? Bei welchem Wert kommen da die besten Ergebnisse? 

- Alex


----------



## Only08 (24. Apr 2008)

Hey,

hab mich mal informiert. Jemand der schon mal mit RXTX gearbeitet hat, meinte man solle den String den man erzeugt sagen, wie er die Bytes zu kodieren hat. Ich denke mal das läuft auf

```
new String (data[], Kodierung);
```
hinaus.
Ansonsten habe ich Hyperterminal versucht, das hat mich aber ziemlich schnell im Stich gelassen. Nur soviel, bei einer Baudrate von 230400 kamen falsche Werte raus und er hat immer wieder mal Umbrüche eingebaut, die so keinen Sinn machen. Als ich die Rate dann ändern wollte kam ständig die Nachricht "COM5 konnte nicht geöffnet werden. Prüfen Sie die Anschlusseinstellungen".

Bei HTerm sieht das folgendermaßen bei 250000 aus:
ASCII:    Ó3d<30><16>&»»<\r>
HEX:       D3 33 64 1E 10 26 BB BB 0D
DEC:       211 051 100 030 016 038 187 187 013
BIN:        11010011 00110011 01100100 00011110 00010000 00100110 10111011 10111011 00001101


Welchen Vorschlag hättest du denn, wenn der SerialPortEventListener ungeschickt ist. Ich bin für jeden Vorschlag offen!

Danke schon mal,

CIAO


*EDIT!!!!* Also ich habe gerade nochmal mein Program durchlaufen lassen und was soll ich sagen. Der erste Wert "Empfange: Ó3d&»»" stimmt komischerweise komplett. Das ist wirklich eigenartig. Also scheint es vielleicht doch nicht an der Codierung zu liegen, sondern eher daran dass er sich im weiteren Verlauf irgendwie verhaspelt. Die Sache ist die, dass das gerät eigentlich 9 kbyte-Gruppen sendet.
Soll heissen, dass nach "Empfange: Ó3d&»»" noch ein"\r" kommen müsste. Das Zeichen wird vom Gerät verwendet um zu signalisieren, dass es sich um das Ende der Gruppe handelt. 
Die ganze Ausgabe sah jetzt gerade so aus:

Konstruktor: EinfachSenden
Öffne Serialport
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
serialPortEventlistener
Empfange: Ó3d&»»
ÿ
serialPortEventlistener
Empfange: ó
serialPortEventlistener
Empfange: ™‚D_Èªø
serialPortEventlistener
Empfange: ó
serialPortEventlistener
Empfange: ™²5ÿ
serialPortEventlistener
Empfange: ó

Ist das jetzt auf die Art und Weise zurück zuführen, wie die Daten geholt werden? Ich kenne mich noch nicht so gut mit RXTX aus, um zu sagen, wie man da noch anders rangehen könnte.

Hmm bei nochmaligen Durchlauf kamen wieder andere Daten raus. Das ist doch alles Quark. Ich weiss da langsam nicht mehr weiter.


----------



## tuxedo (24. Apr 2008)

Hier mal ein Codeschnipsel den ich in meiner Studienarbeit (lange ists her) verwendet habe um GPS-Daten von einem Empfänger zu lesen:


```
private void openRealCommunication(String portIdentifier) {
		try {
			//_log.info("getting com-port");
			portID = CommPortIdentifier.getPortIdentifier(portIdentifier);

			//_log.info("registering program");
			rs232 = (SerialPort) portID.open("WAYTRACKING rev"+Config.BUILD, 1);
			
			//_log.info("program is now registered with com-port");

			//_log.info("setting port parameters");
			rs232.setSerialPortParams(Config.COM_BAUDRATE, Config.COM_DATABITS,	Config.COM_STOPBITS, Config.COM_PARITY);

			// Signalisiert wenn neue Daten anliegen, eigtl für uns nicht nötig
			// da wir blockierend lesen. Macht im Non-Bocking-IO Sinn:
			// [url]http://www.eecs.harvard.edu/~mdw/proj/java-nbio/[/url]
			
			rs232.notifyOnDataAvailable(true);

			_log.info("getting rx-stream from com-port");
			inputStream = rs232.getInputStream();
			
			char c;
			String tempRxString = "";
				
			while (!interrupted()) {
				

				// Lese ein zeichen 'c' aus dem Empfangsstream
				c = (char) inputStream.read();
				
				// Das Zeichen ist nur dann gültig wenn es in die ASCII-Tabelle (0..255) passt
				if (c < 256) {	

					/*
					 *  Wenn es den int-Wert 10 hat handelt es sich um ein Linefeed.
					 *  Ein Linefeed ist sogesehen ein Zeilenumbrch und trennt somit
					 *  die einzelnen GPS-Datensätze voneinander. 
					 *  Nur wenn es KEIN Zeilenumbruch-Zeichen ist wird es an einen
					 *  temporäeren Sring angehängt. 
					 */
					if (c!=10) {
						tempRxString+=c;	// hänge das nächste Zeichen an.
					}
					/*
					 * Hat es dann irgend wann mal den Wert 10 ist der GPS-Datemsatz
					 * komplett und kann geparsed werden.
					 * Danach muss der Temp-String zurückgesetzt werden und die 
					 * Geschchte geht von vorne los.
					 */
					else {
						if (!suspend){
							NMEA0183 nmea = new NMEA0183(tempRxString.trim()); 
							// Nur in den Puffer schreiben wenn der Datensatz okay ist ...
							if (nmea.CRC_OKAY) gpsBuffer.add(nmea);
							
							tempRxString="";
						}
					}
				}
				
			}

		} catch (UnsupportedCommOperationException e) {
			// TODO Exception abfangen !!!
			e.printStackTrace();
		} catch (NoSuchPortException e) {
			// TODO Exception abfangen !!!
			e.printStackTrace();
		} catch (IOException e) {
			// TODO Exception abfangen !!!
			e.printStackTrace();
		} catch (PortInUseException e) {
			// TODO Exception abfangen !!!
			e.printStackTrace();
		} catch (RingBufferOverflowException e) {
			e.printStackTrace();
		} catch (NMEASentenceException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
	}
```

Ich hab das ganze in einem EmpfangsThread laufen lassen. Die Daten hab ich Zeichenweise gelesen und jedes Zeichen gecheckt ob es "das Zeilenende" ist. Wenn es das war, war die Zeile quasi komplett da und mittlerweile auch in "tempRxString" gespeichert. Diese Variable hab ich dann in eine Parserklasse gesteckt die mit die im String enthaltenen Daten rausholt und mittels "gettern" in der NMEA0183 Klasse zur verfügung stellt. "gpsBuffer" war ein Ringpuffer, der X solchen Nmea-Objekte speichern konnte. Da hab ich die Daten einfach reingehauen. 
In meiner Hauptprogrammlogik hab ich diesen Ringpuffer dann ausgelesen und auf die einzelnen Datensätze entsprechend reagiert.

ich weiß nicht was du mit deinem Programm vor hast, aber Ringpuffer und Co. brauchst du vielleicht nicht unbedingt. Aber du kannst ja ab Zeile 52 im Else-Fall mit deiner empfangenen Zeile das tun, was du damit tun willst und gut ist.

- Alex


----------



## Only08 (24. Apr 2008)

Hey,

danke schonmal, ich werd mich mal in den Code einarbeiten.
Zu meinem Thema. Ich habe einen Radiotuner dessen RDS-Strom ich auslesen und in Klartext alle Informationen von diesem darstellen möchte. Das halt rigth-on-time. Also was da kommt soll sofort zu sehen sein, weshalb keine richtige Speicherung vorgenommen wird. Vielleicht in einem späteren Schritt könnte ich mitloggen, damit man zu Testzwcken tracen kann, aber erstmal das wichtige 

Also danke nochmal, ich gucks mir an.


----------



## tuxedo (24. Apr 2008)

Naja, die Daten werden nicht so extrem schnell kommen, als dass das irgendwie Probleme mit dem auslesen ode auch zeichenweise auslesen geben wird.


----------



## Gast (24. Apr 2008)

alex0801 hat gesagt.:
			
		

> Hyperterminal (das Ding was mit Windows XP mitkommt) hat folgende Baud-Rasterung (und soweit ich weiß sind das "standard" Schritte):


Bit pro Sekunde. Nicht Baud.


----------



## tuxedo (24. Apr 2008)

Ich wusste das das kommt. Dummerweise wird "bps" (Bits per second), oftmals synonym mit "Baud" verwendet. 

Der althergebrachte, heute nichtmehr so verwendete Begriff war Baud. Und da gab es *dieses* "Baud"-Raster. Wenn man nun wirklich "bps" meint, dann müsste man die 1200 erst "umrechnen". Da aber nach wie vor 1200 da stehen, gehe ich von Baud aus. 

Hinzu kommt auch noch:



			
				http://de.wikipedia.org/wiki/Baud hat gesagt.:
			
		

> 1 Baud ist die Geschwindigkeit, wenn 1 Symbol pro Sekunde übertragen wird.



Naja. Definiere nun mal "Symbol". Entweder ist ein Symbol "1 byte", oder es ist "1 Bit", oder "1 was auch immer". 

Aber bei Wikipedia geht's ja noch weiter:



> Jedes Symbol entspricht einer definierten messbaren Signaländerung im physischen Übertragungsmedium (vergleiche Sampling).



"Eine Signaländerung im physischen Übertragungsmedium". Aha. Also doch ein Bit. In dem Fall wäre bps==Baud. 

Aber:



> Ein Symbol (Signalcode) repräsentiert je nach Codierung unterschiedlich viele Bits eines Datenstromes.



Also kommt's wieder aufs Übertragungsmedium an. Aber im Falle von RS232-Kommunikation gibts nur eine RX und eine TX-Leitung welche mit 2 Spannungswerten für 0 und 1 arbeitet. Folglich müsste/sollte eine pysische Signaländerung einem Bit entsprechen, womit wider bps==baud gelten würde (für RS232 eben).

- Alex


----------



## Gast (24. Apr 2008)

alex0801 hat gesagt.:
			
		

> Ich wusste das das kommt. Dummerweise wird "bps" (Bits per second), oftmals synonym mit "Baud" verwendet.


Das ändert nix daran, dass es einfach falsch ist. Die Erklärung hast du ja teilweise aus der Wikipedia zitiert.



> > Jedes Symbol entspricht einer definierten messbaren Signaländerung im physischen Übertragungsmedium (vergleiche Sampling).
> 
> 
> 
> "Eine Signaländerung im physischen Übertragungsmedium". Aha. Also doch ein Bit. In dem Fall wäre bps==Baud.


Signaländerung != Bit.



> Aber:
> 
> 
> 
> ...



Für RS232 korrekt, aber es gibt andere Übertragungsverfahren, die pro Symbol 4, 8 oder noch mehr Bits übertragen. Siehe z.B. Quadratur-Amplituden-Modulation, Quadraturphasenumtastung.


----------



## tuxedo (24. Apr 2008)

Gast hat gesagt.:
			
		

> alex0801 hat gesagt.:
> 
> 
> 
> ...



Im allgemeinen Fall hast du recht. Im hiesigen speziellen Fall: siehe unten...



> > > Jedes Symbol entspricht einer definierten messbaren Signaländerung im physischen Übertragungsmedium (vergleiche Sampling).
> >
> >
> >
> ...



Via RS232 wird bei jeder Signaländerung ein Bit übertragen. Also gilt für RS232: Signaländerung == Bit



> > Aber:
> >
> >
> >
> ...



Sag ich doch. Hier wird jetzt schon auf der zweiten Seite nur über RS232 geredet. Also lass QAM aus dem Spiel ;-)

Für RS232 ist es unerheblich ob man Baud oder BPS verwendet.

--> back to topic.

- Alex


----------



## Only08 (28. Apr 2008)

Hey,

schön zu sehen dass sich hier so viele wirklich Gedanken machen, das zeugt doch mal von einem guten Forum
Also, kleiner Rückschlag... meine Firma will das Ganze jetzt in LabView haben. Ich bin darübner natürlich nicht erfreut, aber was solls. Ich würde mich allerdings gerne nebenbei weiter mit dem Thema RxTx auf diesem Gerät beschäftigen, weshalb ich einfach mal weitermache.

Also das Problem mit dem signed und unsigned Bytes besteht immernoch. Ich werd  mir nochmal angucken wo man das am besten macht, aber irgendwie habe ich noch keinen Cast schreiben können, den Java akzeptiert... Hat das jemadn schonmal gemacht?

Schöne Grüße


----------



## tuxedo (28. Apr 2008)

Jupp, schau da mal nach: 

http://www.java-forum.org/de/topic68343_werte-nach-java-ber-stream-glich.html

Irgendwo in den letzten Posts hab ich nen Link gepostetder "unsigned nach signed" mit Java erklärt.

- Alex


----------



## Only08 (5. Mai 2008)

Hey,

so hab neben diesem komischen Labview etwas mit Java experiementiert und da hat mir der Link geholfen. Ich habe jetzt einfach mal ne Funkiton geschrieben:

```
void serialPortDatenVerfuegbar() {
		try {
			byte[] signeddata = new byte[10];
			byte[] unsigneddata = new byte [10];
			int num;
			while(inputStream.available() > 0) {
				num = inputStream.read(signeddata , 0, signeddata.length);
				System.out.println("Empfange Signed: "+ new String(signeddata, 0, num));
				for (int z=0; z < num; z++)
				{
					System.out.println("Byte"+z+": "+(signeddata[z]& 0xFF));
					unsigneddata[z]=(byte)(signeddata[z]& 0xFF);
				}
				System.out.println("Empfange Unsigned: "+ new String(unsigneddata, 0, num));
			}
		} catch (IOException e) {
			System.out.println("Fehler beim Lesen empfangener Daten");
		}
	}
```

Wie man sieht mit jeder Menge Ausgabe um die Wandlung verlgeichen zu können. Und tatsächlich war der Zahlenwert vorher im Bereich von -1.. bis +1.. und jetzt bei 0 bis 255.Nur leider sieht die Ausgabe jetzt so aus:


```
Empfange Signed: òA²*‡*þ
Byte0: 242
Byte1: 65
Byte2: 178
Byte3: 42
Byte4: 135
Byte5: 42
Byte6: 254
Empfange Unsigned: òA²*‡*þ
```

Also wie man sieht, hat sich rein ASCii-mäßig nüschtz getan. Hmm naja, ehrlich gesagt ist das ja noch das kleinere Übel. Denn eigentlich brauche ich den Datenstrom als Binärcode, damit ich diesen dann zerlegen kann. Gibt es da schon Methoden für?

EDIT: Also ich denke mal, es bleibt wohl dabei dass die Umwandlung von signed in unsigned der ausschlaggebende Punkt sein wird. Aber ich versteh halt nicht ganz woher die Fehler kommen. Der Wert von "ò" sollte 211 sein und nicht 242. Wenn das stimmt wird sicherlich auch die Umwandlung in die verschiedenen Formate hinhauen, die im Moment auch noch keine korrekten Ergebnisse liefert.


----------

