search

ngocthanhit / xig

Automatically exported from code.google.com/p/xig
0 stars 0 forks source link

XIG Will Not Accept more than 72 characters in a transmission #15

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Xig dont accept more than 72 characterr
Test with XCTU 9600 and 115200
Ver 1.3.0b2

Accept only the first 72 bytes

Original issue reported on code.google.com by Celine.h...@gmail.com on 29 Nov 2011 at 6:31

GoogleCodeExporter commented 9 years ago 
The Packetization Timeout (RO) must be to 0

Original comment by Celine.h...@gmail.com on 30 Nov 2011 at 1:30

GoogleCodeExporter commented 9 years ago 
We should be parsing URLs independently of the packetization timeout.  It 
should be parsing on the newline boundary and it's not.  We acknowledge the 
failure.  It's been scheduled to be worked on and we'll get out a new release 
just as soon as we can!

Original comment by Jordan.H...@gmail.com on 2 Dec 2011 at 1:31

GoogleCodeExporter commented 9 years ago 
After looking into this failure some more this weekend it appears as though the 
XIG is working as it should be.  In fact, it appears as though there may be an 
XBee bug (I'm using firmware version 228C).  If one sends an XBee a long string 
of data using RTS/CTS flow control and if the XBee parameter D6=1, then the 
XBee should be able to say "wait!" to the entity sending it serial data, send 
the data it's already got in it's local buffers, then unpause the serial stream 
and continue until all data is sent.  Instead, what appears to be happening is 
that the XBee isn't saying "wait!" and data loss is occurring.

There is a work around: if you need to send the XIG a long URL (>72 characters) 
send it to the XBee in a delay loop such as the following:

1. Write up to 72 characters of the string to the XBee
2. Wait 250ms
3. Write another 72 characters of the string
4. Repeat steps 2-3 until string is transmitted

Although not ideal (at all!) this work around should work.

The issue has been reported to Digi.  I'm going to keep this issue open until 
we can get it resolved.

Jordan

Original comment by Jordan.H...@gmail.com on 10 Dec 2011 at 10:24

GoogleCodeExporter commented 9 years ago 
As it turns out it wasn't an XBee bug but a good ol' fashioned bug in the XIG.  
Digi support did some work to exonerate the XBee and verify that hardware flow 
control was indeed working.

I chased the I/O path up from remote XBee, to gateway XBee, to the C stack in 
the ConnectPort (#> set trace state=on mask=xbee:*) and up into Python.  It 
turns out all the bytes were in fact arriving at the gateway XBee but they 
weren't all being read in by the Python program.  As I had re-written the XIG 
to be able to work in very large networks and be aware of the MTU when using 
source routing, I had also inadvertently set the MRU to be smaller than the 
actual maximum receive size of packets coming in off the network causing data 
loss any time more than 72 bytes were stuffed into a Series 2 radio packet.

A simple change was made to calculate the proper MRU/MTU size for the various 
radio types and now all is right as rain.  v1.3.2 will include this fix.

Please use it in good health!

-Jordan

Original comment by Jordan.H...@gmail.com on 15 Dec 2011 at 4:04

GoogleCodeExporter commented 9 years ago

Original comment by Jordan.H...@gmail.com on 15 Dec 2011 at 4:05