Hello
I’m using ConnectPort x8 and XBee adapter. I’ve loaded standard files included in X-CTU into ConnectPort, so data transfer with adapter is via specific port on coordinator IP.
When I set rs parameters as: 2400,8,e,1 and set Packetization Timeout different than 1ms, adapter looses some bytes in frame. Setting 1ms solves problem of loosing bytes, but it’s not very satisfying solution. Frame has about 160 bytes. Has some met such a problem ?
On adapter I have the newest firmware version - 0x1247
I have done extensive serial tests with the Xbee modules at 9600 baud with Modbus/RTU. I can easily move tens of thousands of full 255 byte packets with no loss.
I leave the packetization at 3 or put to 5. This is not milliseconds, but “character times”, so setting it to 1 at 2400 baud should give you a roughly 4 msec time.
The XBee should not have trouble handling 160 bytes at one time - it would need to send as at least 3 packets, plus you should have nearly a 300 msec “gap” between the three since the subsequent packets will not move until a buffer has filled, and it fills at only 1 byte per 4 msec.
Note that the PDF manuals are not fully accurate as they indicate (for example) you will receive a max of 72 bytes, but in truth you might receive any number up to 100 depending on the technology in use. So my code looks for 256 bytes and gracefully handles seeing only 64 or 75.
You will need to use non-blocking serial reads on the X8, plus allow a second or more to defragment the message. You need patience on a mesh, use adequately long timeouts.
Glad it was so easy - by the way, that burned my first Modbus tests as well! I too would “fetch” 72 bytes from mesh, and lose those 3.
I detected my problem by running the “set trace state=on mask=mesh:*” and seeing that 75, not 72 bytes were being returned and the “UDP Sockets” interface does no buffering, so reading 72 of 75 bytes causes the remaining 3 data bytes to be flushed.
So you should ask for 255 bytes, not even 75 as Digi Mesh and other technologies move more bytes than 75. When sending you need to know how many, but when receiving it should be trivial enough to ask for more than you’ll get.
If you are capable of handling an “n” byte message at maximum, attempting a UDP recv of “n+1” bytes is all that is required. If you read “n+1” bytes, you by definition have an overflow condition.
Of course the only way to know the actual number of bytes is to read into a “large enough” buffer, as posted above.