Ethernet problem sending null characters

Thanks Bill,

I am communicating with an RFID Reader. The command I am sending to the device is not a string of null but contains zeroes as part of the required command string. The device is not hanging up but the command is not getting to it since the transmission is truncated on the first null character. The TCP connection remains open as it should. Is there an escape character that I can include in the message that will prevent the library function from treating the NULL as a string termination character?

Here is the code.

#include <SPI.h>
#include <Ethernet.h>

    byte mac[] = { 0x90, 0xA2, 0xDA, 0x0D, 0x8D, 0x46 };                 // Enter the MAC address of the controller
    char ip[] = "192.168.1.107";                                         // Enter the I/P address of the RFID reader
    char port[] = "3000";                                                // Enter the I/P port of the RFID reader
   
    char poll_msg[]  = { 0x0A, 0xFF, 0x09, 0x88, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x04, 0xFF };
    int  msg_size    = 0;

// Initialize the Ethernet client library
    EthernetClient rfidClient;

//================================================================================
void setup()
{
// Open serial communications and wait for port to open:
    Serial.begin(9600); 
    while (!Serial) { 
      ; // wait for serial port to connect. Needed for Leonardo only 
    } 
    delay(3000); 
    Serial.println("Initializing..."); 

// Get IP Address
    if (Ethernet.begin(mac) == 0) {
      Serial.println("Failed to configure Ethernet using DHCP"); 
      // no point in carrying on, so do nothing forevermore:
      while(true);
    }
// Give the Ethernet shield a second to initialize:
    delay(1000);
}

//================================================================================
void loop()
{
    int     n = 0;
    int     inp_len = 0;
    char    *pch;

//* OPEN CONNECTION TO RFID READER

    rfidClient = connectServer(ip, port);
    if (!rfidClient.connected())
    {
      Serial.println("  *** Connection failed ***"); 
      return;
    }

//* POLL RFID READER

    while (true) {
      delay(2000);
      msg_size = sizeof(poll_msg);
      sendMessageRFID(rfidClient, poll_msg, msg_size);
    }
}

//================================================================================
EthernetClient connectServer(char * addr, char * port)
{
    EthernetClient client;
    byte ip[4];
    int  iport = 80;
    int  count;
    char out_data[60] = "";

//* INITIALIZATION

    count = sscanf(addr, "%hhu.%hhu.%hhu.%hhu", &ip[0],&ip[1],&ip[2],&ip[3]);
    iport=atoi(port);

//* MAIN PROCESSING

    if (count == 4) {
      client.connect(ip, iport);
    }
    else {
      client.connect(addr, iport);
    }
    return client;
}

//================================================================================
int sendMessageRFID(EthernetClient client, char * out_msg, int len)
{
    int      n = 0;
    String   send_data = "";

//* MAIN PROCESSING

  //* THIS DOES NOT WORK. MESSAGE IS TERMINATED PREMATURELY.

    client.print(out_msg);

  //* THIS DOES NOT WORK. MESSAGE IS TERMINATED PREMATURELY.

    for (n = 0; n < len; n++)
    {
      send_data += String(out_msg[n]);
    }
    client.print(send_data);

  //* THIS WORKS WITH SIMULATOR BUT NOT WITH DEVICE ( PERHAPS DUE TO MULTIPLE PACKETS ??? )

    for (n = 0; n < len; n++)
    {
      client.print(out_msg[n]);
    }

}

Ok. RFID data.  So the sketch being run on your UNO is not parsing the data the way you want it to because 0x00 is embedded in the string but it is not supposed to be taken to mean /0, string termination.  I think it will be necessary to convert the binary data to ASCII before sending it along. 

If memory serves, Jeremy Blum did a very good tutorial on the RFID.  You may want to look at it and the supporting sketch.

There should also be examples with working sketches at adafruit.com, parallax.com, and sparkfun.com.

-Happy Trails

I am not sure what you mean by parsing the data or what this has to do with RFID. The problem has has to do with sending a byte via TCP (NULL) which the function (client.print) treats as a termination character. If the function allowed me to specify the number of bytes to send, everything would work fine.

Also, I am sending ASCII data. A binary 00000000 = hex 00 = ascii NUL = /0. Aparently, when the Ethernet library was created, the author may not have considered this situation since the Internet uses the HTTP protocol. The device that I am using was originally designed for a serial interface with TCP added later.

I appreciate your direction and will check out the sites you have referenced. I am not familiar with Jeremy Blum but will google his name.

I said to encode ZERO as ASCII 40 = 0x30 instead of 0x00.

I can't do that. The device requires the actual hex data that I specified. If it would accept text, I could send an Ascii zero.

If I can't find a way to do what I am trying to do, I can communicate to the device's serial port.

As I understand it:

1:  the serial device is attached to SOME piece of hardware

2:  the hardware on the receiving end does a conversion from TCP/ethernet to serial data input to the device

3: you are convinced that the embedded NUL character is a problem

I suggest that you then MUST encode the data to successfully transmit packet.

Opt A:  Invert all the bits

Opt B:  Interleave binary 1s  via XOR 0x11 with every byte.

Opt C:  Add binary 1 to every byte.

It follows that you will have to implement a decode capability on the receiving side.

As I understand it:

1:  the serial device is attached to SOME piece of hardware

2:  the hardware on the receiving end does a conversion from TCP/ethernet to serial data input to the device

3: you are convinced that the embedded NUL character is a problem

I suggest that you then MUST encode the data to successfully transmit packet.

Opt A:  Invert all the bits

Opt B:  Interleave binary 1s  via XOR 0x11 with every byte.

Opt C:  Add binary 1 to every byte.

It follows that you will have to implement a decode capability on the receiving side.