SBL2e fragmented receive data

[mrburns42]

I have a SBL2e connected via an RS232 level shifter to a Chroma Load Box. The Chroma communicates in clear text at 9600 Baud. It is working for the most part. However, sometimes the receive data is only partially available from the SBL2e. I will receive only part of the serial data. I thought it was due to async events between the Chroma and the timer within the SBL2e, so I started reading twice with 200mS between the reads. My plan was to concatenate the two reads for the entire message. However, the second read via TCPIP does not find any additional data. Then, several seconds later I will get the missing data during a portion of the code where the Chroma was doing a write only access.
I connected a logic analyzer to the receive pin going into the SBL2e and the complete data is there and is not seriously delayed. Sometimes the Chroma will pause for 10 to 20 mS within the datastream. The amount of data is small, it is always less than 12 bytes with a typical of about 8 bytes.

Any ideas what I have setup wrong or what additional I should be doing? I have a TCPIP socket open and just call "recv"

ssize_t nFirstNumBytes, nSecondNumBytes;
char cFirstBuf[MAXDATASIZE], cSecondBuf[MAXDATASIZE];
nFirstNumBytes = recv(m_sockfd, cFirstBuf, MAXDATASIZE-1, 0);


Thanks.

[pbreed]

Not clear exactly what you are asking...

I think
Chroma -> RS-232 ->Sbl2e ->TCP -> (something else)

What is something else?

What does the code on "somethign else" look like?

If you capture the outbound data from Sbl2E via wireshark do you see the delays there?
Why are you using custom code rather than the stock sbl2e serial to tcp code?

[mrburns42]

The "something else" is an NXP embedded ARM processor. It has no available ports to attach the Chroma Load Box to, which is why the Ethernet adapter is needed. This NXP processor is running Linux. All I received was the NetBurner and the manual "SBL2e Dual Serial-to-Ethernet User's Manual". That is why I wrote my own code. From the receive side, the call is literally the recv() that I posted. I make that call twice, over 250mS apart to try and catch sync timing errors between the Chroma and the NetBurner sync. The second call never gets any additional data.
I verified operation with a logic analyzer. Have a screen shot, but do not see a way to attach it.
On the embedded side, I send the command to the Chroma to return a reading. Then I set a flag bit to show the initial time delay that I allow for network overhead and the Chroma processing. Before attempting to read the return data from the NetBurner, I clear the flag bit. What I see on the analyzer is the serial output from the NetBurner, followed by the response from the Chroma. This all happens while the flag is still high. Therefore, it is not a latency in the network or my code not waiting for the Chroma to respond. I also have attached another USB to serial converter and see the data correctly sent from the Chroma. The NetBurner always returns valid characters. Just sometimes it does not send all the data. I can see bytes on the logic analyzer that the NetBurner does not return until several seconds later during a different transaction.

[pbreed]

Can you please provide the Netburner code your using to send the tcp data...

[pbreed]

Also can you determine when the entire Chroma response is done and do the TCP write as a single write?
Can you capture the TCP connection via wireshark?

[mrburns42]

Below is the code. It is taking for the standard TCP examples on the Internet.

I have very little experience with Wire Shark. It is also difficult in that the Ethernet connection is a local private network and not the network that a PC is running on. It will probably be next week before I can get that captured.

Most of the time is works. When it does happen, the receive data is not lost, it just gets fragmented into two packets rather than one. The second packet either arrives over 1 second later or does not get flushed back until I send more data.



*****************************************************************
/* Code to Open the TCP Port to the NetBurner */
// Socket connection to NetBurner not established, so do it now.
memset(&hints, 0, sizeof hints);
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
char MyIP[20] = "169.254.0.55";
rc = getaddrinfo(MyIP, PORT, &hints, &servinfo);
if (rc)
{
CDiagUtil::GetInstance().LogError("CChromaLoad::Init() getaddrinfo() (return code = %d: %s)\n",
rc, strerror(rc));
TRETURN(ERROR_FILE_OPEN);
}

// loop through all the results and connect to the first we can
for(p = servinfo; p != NULL; p = p->ai_next)
{
if ((m_sockfd = socket(p->ai_family, p->ai_socktype, p->ai_protocol)) == -1)
{
perror("client: socket");
continue;
}

if (connect(m_sockfd, p->ai_addr, p->ai_addrlen) == -1)
{
close(m_sockfd);
perror("client: connect");
continue;
}

break;
}

if (p == NULL)
{
CDiagUtil::GetInstance().LogError("CChromaLoad::Init() Failing TCP Connection to Chroma Load Box.)\n");
TRETURN(ERROR_FILE_OPEN);
}

// Put the socket in non-blocking mode since Chroma Load maybe disconnected and we
// do not want to hang the code.
rc = fcntl(m_sockfd, F_SETFL, fcntl(m_sockfd, F_GETFL) | O_NONBLOCK);
if(rc < 0)
{
close(m_sockfd);
CDiagUtil::GetInstance().LogError("CChromaLoad::Init() To place socket into non-blocking mode.)\n");
TRETURN(ERROR_FILE_OPEN);
}

inet_ntop(p->ai_family, get_in_addrC((struct sockaddr *)p->ai_addr),
s, sizeof s);

freeaddrinfo(servinfo); // all done with this structure

/* Code to Send data */
int32_t nNumBytes;
int n = sString.length();
char cBuf[n + 1];
strcpy(cBuf, sString.c_str());
nNumBytes = send(m_sockfd, cBuf, strlen(cBuf), 0);

/* Code to Receive Data */
ssize_t nFirstNumBytes, nSecondNumBytes;
char cFirstBuf[MAXDATASIZE], cSecondBuf[MAXDATASIZE];
nFirstNumBytes = recv(m_sockfd, cFirstBuf, MAXDATASIZE-1, 0);
tanmsleep(950);
nSecondNumBytes = recv(m_sockfd, cSecondBuf, MAXDATASIZE-1, 0);

[mrburns42]

The Chroma Load Box sends a LineFeed (0xA) character as a terminator. Since the remainder of the data is clear text, if the last character is not 0xA, then I know that fragmentation is occurring. I added code to detect this event. When I find it, then I go into a loop rechecking for receive data every 250mS. After ten loops of no data, then I send some spaces and a carriage return, I call if a benign TX set. If no receive data for several more loops, then I send a second block of spaces and a carriage return. About 30-50% of the time, the first benign TX set will then cause the receive data to show up. If the first TX set does not get the receive data back, then the second TX set is almost always successful. Probably about 10% of the fragmentation cases, still have un-received data after the two TX sets. The amount of fragmented data missing from the end is small. It is at most three characters. Often it is just the LineFeed terminator. (The data in the benign TX sets mean nothing to the Chroma. The Chroma ignores this data and sends back nothing.)

If I remove the benign TX sets, then receive data never shows up. This data only pops up after some TX data is sent to the SBL2e.

[pbreed]

I'll try one more time...
What code are you running on the NetBurner!
You keep sending me the chroma code, I want to know what application you are running on the SBL2E?
Are you running the standard factory app?
If so please send me a picture to the configuration page?

My guess is your msleep(950) IE sleep for 0.950 seconds is the source of your delay...
TCP packets are a stream and not guaranteed to arrive on one monolithic chunk.

Try setting up a select loop to wait for recieved data...


Lastly if you running the SBL2E factory app and you data is always terminated with a LF aka 10 aka 0x0A turn on custom packetization and put 10 in the (0x0A) in the Flush field....

[pbreed]

If your running the standard SBL2E code see:
https://www.netburner.com/download/sbl2 ... rs-manual/
Section 4.6

[mrburns42]

I do not appreciate the tone of your replies. I am doing my very best to provide the information that you are request. The problem is you are not clearly asking for what you want. You ask for the NetBurner code. I provided the code that interfaces with the NetBurner because that is what I thought you asked for. I have no personal code executing on the NetBurner. It is running the stock firmware. I have no knowledge of how to change or add code running on the NetBurner.
What I deduce that you want is the NetBurner configuration. That is much different that the code. I cannot provide that until next week, as I cannot physically access the HW on the weekend. The only things that I changed in the Web Page setup was the IP address, the Baud rate of the serial ports, and timeout for a idle TCP port. I changed the timeout to 5 minutes.

You are not understanding the 950mS sleep time. That time is to allow for data being returned in two separate TCP packets. Originally the 950mS was 150mS since the NetBurner default is to accumulate data for 100mS and I allowed a 50% safety margin. I increased it to 950mS to make sure that no amount of latency would delay the packets.
Attached is a simplified flow chart. It always does two READS to check for data in multiple packets. It merges this data and then checks for the terminator. If found, it exits. If the terminator is not found, then it goes into a loop rechecking the data every 250mS. If that loop expires with no additional data, then it sends a bogus TX packet to the Chroma in order to wake up the NetBurner. On the flowchart, I placed the letters "A" "B" and "C" at the exit points. The code will never exit through path "B". Even when I know that data remains due to the missing terminator, it is never delivered. For the missing terminator case, the data is only delivered AFTER doing a bogus TX. Sometimes only one bogus TX is required. Sometimes three of them are required.