2

I'm using an Arduino (duemilanove) with the official Ethernet shield to send data to the controller for controlling an LED matrix. I am trying to send some raw 32-bit unsigned int values (unix timestamps) to the controller by taking the 4 bytes in the 32-bit value on the desktop and sending it to the arduino as 4 consecutive bytes. However, whenever a byte value is larger than 127, the returned value by the ethernet client library is 63.

The following is a basic example of what I'm doing on the arduino side of things. Some things have been removed for neatness.

byte buffer[32];
memset(buffer, 0, 32);

int data;
int i=0;

data = client.read();
while(data != -1 && i < 32)
{
  buffer[i++] = (byte)data;
  data = client.read();
}

So, whenever the input byte is bigger than 127 the variable "data" will end up getting set to 63! At first I thought the problem was further down the line (buffer used to be char instead of byte) but when I print out "data" right after the read, it's still 63.

Any ideas what could be causing this? I know client.read() is supposed to output int and internally reads data from the socket as uint8_t which is a full byte and unsigned, so I should be able to at least go to 255...

EDIT: Right you are, Hans. Didn't realize that Encoding.ASCII.GetBytes only supported the first 7 bits and not all 8.

Adam Haile
  • 30,705
  • 58
  • 191
  • 286
  • UTF-8 encoding wouldn't give a 63... Does putting a 63 in also yield a 63 out? Are subsequent bytes shifted at all. – Ben Voigt Jan 07 '11 at 05:26

3 Answers3

4

I'm more inclined to suspect the transmit side. Are you positive the transmit side is working correctly? Have you verified with a wireshark capture or some such?

Karl Bielefeldt
  • 47,314
  • 10
  • 60
  • 94
3

63 is the ASCII code for ?. There's some relevance to the values, ASCII doesn't have character codes for values over 127. An ASCII encoder commonly replaces invalid codes like this with a question mark. Default behavior for the .NET Encoding.ASCII encoder for example.

It isn't exactly clear where that might happen. Definitely not in your snippet. Probably on the other end of the wire. Write bytes, not characters.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
0

+1 for Hans Passant and Karl Bielefeldt.

Can you just send the data without encoding? How is the data being sent? TCP/UDP/IP/Ethernet definitely support sending binary data without restriction. If this isn't possible, perhaps converting the data to hex will solve the problem. Base64 will also work (better) but is considerably more work. For small amounts of data, hex is probably the easiest and fastest solution.

+1 again to Karl and Ben for mentioning wireshark. Invaluable for debugging network problems like this.

Peter Schaeffer
  • 371
  • 4
  • 9