Sending Unsigned Bytes Over Socket In Java

Question

I am attempting to send the following Byte Array to a device running C.

BYTES TO SEND:
80 3f 10 01 00 3c b2 5f 0d

BYTES RECEIVED BY MACHNINE:
00 3f 10 01 00 3c 32 5f 0d

It seems for some reason that java is turning the signed bit into a 0 which is manipulating what the C Machine is reading.

80 -> 00
b2 -> 32

Here is an example of my code:

try
{
    String response;
    Socket clientSocket = new Socket(iPAddress, port);
    DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStream());
    BufferedReader inFromServer = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));

    byte[] bytes = new byte[] { (byte)0x80, 0x3f, 0x10, 0x01, 0x00, 0x3c, (byte) 0xb2, 0x5f, 0x0d};
    outToServer.write(bytes);

    response = inFromServer.readLine();   
    System.out.println("FROM SCU: " + response);
    clientSocket.close();
}
catch(Exception e)
{
    e.printStackTrace();
}

I am absolutely lost as to what I can do now as it seems nothing will work. I do not have access to the C Machine in order to change code.

have you tried reading from the byte array? your `(byte) 0x80` cast is very suspicious, because it could clear the sign bit. the `write(byte[])` method should not be the culprit. — Silly Freak, Mar 24 '14 at 16:08
try `printf("0x%02X 0x%02X%n", bytes[0], bytes[6]);` for debugging this — Silly Freak, Mar 24 '14 at 16:08
That's because you cast your data to `byte`. In Java, `byte` is signed and the maximum positive value it can take is 127; therefore, casting a greater value to byte will chop anything beyond bit6. Your question by the way is possible duplicate of **[THIS](http://stackoverflow.com/questions/7276363/unsigned-bytes-in-java)** and **[THIS](http://stackoverflow.com/questions/4266756/can-we-make-unsigned-byte-in-java)** question. — Powerslave, Mar 24 '14 at 16:15
@Powerslave: that’s nonsense. A byte has 8 Bits, regardless of how you interpret it. Casting an `int` value to `byte` will not touch any of the lowest 8 bits. — Holger, Mar 24 '14 at 16:23
I think the questions are related but not the same, from everything I can tell the array has been setup correctly up until the point it is sent over the socket. Then the bit is lost. — David Byrne, Mar 24 '14 at 16:24
@David Byrne: There’s nothing wrong with that code. The problem must lie in a code outside of that piece you have shown to us. Maybe it is even on the receiving side… — Holger, Mar 24 '14 at 16:24
There is nothing else to the code. There are a few variable settings for IP Address and Port. The device I am connecting to sends bytes to uart1. — David Byrne, Mar 24 '14 at 16:29
I will create a simple java server in the morning to see if it still receives the bytes with the signed bit taken away. — David Byrne, Mar 24 '14 at 16:31
@Holger You have actually misinterpreted my comment. Do you see now how interpretation matters? :) If you cast `0x80` to `byte`, you'll get `0` since bit7 has a different meaning and bit8 and upwards do not exist, leaving you with the 7 least significant bits. To be honest, all mid- and high level programming is about interpretation of otherwise very uniform bytes/words/dwords. Casting an *unsigned* `int` to *unsigned* `byte` will not touch any of the lowest 8 bits, however, working with signed values, anything greater than 127 would be corrupted without careful conversion. — Powerslave, Mar 25 '14 at 08:51
@Powerslave: Again, casting an `int` to `byte` does **not** change the lower eight bits. Interpreting `0x80` as signed byte yields to `-128`, casting `0x80` to `byte` will result in `0xffffff80` (in local variables and on the stack) which is still `-128` but in the `int` range; now storing that value to a `byte` field or array will cut the upper 24 bits yielding to `0x80` which is still `-128` *in the byte range*. However, the lower eight bits never changed during these operations. If you have no clue, why don’t you try it out instead of claiming such a nonsense? — Holger, Mar 25 '14 at 10:29
@Holger Well, yes, it turns out to be right; yet, your style is unacceptable. If I had time to experiment and verify my stance I'd have posted the exact solution as an answer, not just a comment. As simple as that. Mistake were my thoughts - nonsense is your attitude. Please be a bit more professional. — Powerslave, Mar 25 '14 at 14:07
@Powerslave: You’re right, the style left room for improvement. However, you have been corrected once and you had a whole day to think about it (and you could have had more if necessary) rather than just repeating yourself the next day. Can you imagine that such a behavior may annoy others? — Holger, Mar 25 '14 at 15:46
@Holger I can of course. But please keep in mind that I don't spend my day thinking about questions on SOF, but come back occasionally, spot something, think just a littlebit about it and, in some cases post some. Sometimes I'm just wrong like I was and I have no excuse for that. Yet I'm really not a fulltime SOF staff member to just sit around and experiment with the problems posted here. Sorry for being dull, really, but it just seemed right - and the SW I'm working on right now really makes most of us around tired. — Powerslave, Mar 26 '14 at 15:13

score 1 · Accepted Answer · answered Mar 24 '14 at 16:30

1

For me it looks like your "C Machine" use only 7 bits.

0x80 binrary represented is 1000 0000, and 0xB2 binary is 1011 0010. If you get 7 bits from right it is 000 0000 = 0x00 and 011 0010 = 0x32

I hope this may help you

answered Mar 24 '14 at 16:30

djm.im

3,295
4
30
45

It seems you may be correct. I cannot believe I have overlooked this. I will check in the morning and post up the status. – David Byrne Mar 24 '14 at 16:34
Thank you very much for your help. It seems the device on the other end rebooted this morning and never reverted back to 8 databits. – David Byrne Mar 24 '14 at 16:39

Sending Unsigned Bytes Over Socket In Java

1 Answers1