Home/Support/Support Forum/How to extend 32 bytes serial data limit with Connect Me4 9210
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

How to extend 32 bytes serial data limit with Connect Me4 9210

0 votes
Hi,

I just had my Connect Me4 9210. I have another TCP/serial port using from another brand.
But, I like to try out Digi products as well. So, I have an MCU based board with TX-RX-GND pins to connect LAN port for sending some data when needed.

So, I have just made some basic settings on the Connect Me and substituted with my another brand. So, Connect-Me is connected well and I can populate data sent my MCU board to the my custom TCP server. So far it is relatively straight forward. Then, I started to check data integrity. This is where I am stopped.

I can only read first 32 bytes out of my 50 bytes data and the remaining part of data is sent as another set of data.

How can I extend allowed data length in order to receive complete data at once?

Note that: I picked the Category for the post almost randomly, don't pay attention to it.

Device: Connect ME 9210 with plug-and-play firmware
Protocol: TCP-Serial, 115200 baudrate (I tried higher or lower baudrates but no difference)

Thank you.
asked Aug 27, 2018 in Plug N' Play by Sener New to the Community (3 points)
recategorized Aug 30, 2018 by rmaroun

Please log in or register to answer this question.

1 Answer

0 votes
 
Best answer
Hi again,

I have got my answers from Digi. That guys over there were quite helpful and prompt in their answers, I really appreciate that, thank you guys.

So, if we back to the issue, they said that this is the first time they heard this issue. Weird enough.

Anyway, after some trial and errors, playing with some settings, I found a solution, it is maybe more a work-around.

Let me give you some details about what was happening. if I send some data using serial, the module sends data to the tcp server in pieces. In the first place, I though that there is a static packet size (32 bytes) and made concrete for data transmission. But, I noticed that, it is not that true. There is still some sort of packet size management in the module but it is looking dynamic instead of being static and it is quite sensitive to timing. To me, it looks like a race condition, before the serial input complete, data is sent out and the remaing part is a bit later.

Here are some samples with varying packet sizes and how they sent out by the module over TCP:

If I have data length 50 bytes;
First 32 bytes => 12345678901234567890123456789012
Second 18 bytes => 345678901234567890

If I have data length 57 bytes;
First 32 bytes => 12345678901234567890123456789012
Second 25 bytes => 3456789012345678901234567
But for this case, occasionally;
Only single transmission as 57 bytes => 123456789012345678901234567890123456789012345678901234567

If I have data length 70 bytes;
First 32 bytes => 12345678901234567890123456789012
Second 38 bytes => 34567890123456789012345678901234567890

So, here another story, second transmission is not limited to 32 bytes.

If I have data length 100 bytes;
If you exceed 81, then you can start seeing 64 bytes on the first transmission.

First 64 bytes => 1234567890123456789012345678901234567890123456789012345678901234
Second 36 bytes => 567890123456789012345678901234567890

So, it is pretty confusing, isn't it.

Here is what I did;

From the web interface of the module;
Go to "Serial Port Configuration":
Advanced Serial Settings > TCP Settings > Send data only under any of the following conditions:
Send after the following number of idle milliseconds = 100ms

If I place some delay (100ms) before transmitting a data it gives some moment to the device before sending the payload and allowing all the data to be populated (buffered) by the serial section of the module.

After the delay, even I sent more than 500 bytes, I get it at once each time.

If you would like follow the same solution, you should beware and make sure that your sending interval is bigger than 100ms.
By the way, I didn't try myself, but I believe even a lower delay like 10ms, 50ms, etc... might still work. For me, 100ms is quite OK.

Good luck.
answered Aug 30, 2018 by Sener New to the Community (3 points)
selected Aug 31, 2018 by Sener
...