# Weird Fragmentation With Multiple XBee Series 1s **URL:** \ **Category:** XBee - 802.15.4\ **Tags:** multipoint, series1, xbee\ **Created:** [June 8, 2015, 2:44pm UTC](https://forums.digi.com/t/weird-fragmentation-with-multiple-xbee-series-1s/14955 "2015-06-08T14:44:39Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Schema](https://avatars.discourse-cdn.com/v4/letter/s/779978/32.png) [@Schema](https://forums.digi.com/u/Schema)\ **Post date:** [June 8, 2015, 2:44pm UTC](https://forums.digi.com/t/weird-fragmentation-with-multiple-xbee-series-1s/14955/1 "2015-06-08T14:44:39Z")
Picture is worth 1000 words: [My Setup](http://i.imgur.com/AhtModK.png) I have four Arduinos collecting data and sending them wirelessly to a PC over Series 1 (802.15.4) XBees. Details: [ul] [li] The data rate is 57600 into the XBees and 115200 into the PC. [/li][li] Range is less than 50 feet.[/li][li] Messages are very short, around 30 bytes.[/li][li] Messages are sent every 10 milliseconds (this can be adjusted if need be).[/li][/ul] This works very well for the most part, but I have noted some occasional weird fragmentation,where one message occasionally appears in the “middle” of another message. This doesn’t make sense to me as the messages are very short and sent in a single burst through Serial.print(). So why does it fragment? Example with a test message: ```auto Hello - I am Device #2. Count=1168 Hello - I am Device #3. Count=948 Hello - I am Device #2. Count=1169 Hello - I am Device #1. Count=1089 Hello - I am Device #3. Count=949 Hello - I am Device #2. Count=1170 Hello - I am Device #1. Count=1090 Hello - I am Device #4. Count=764 Hello - I am Device #3. Count=950 Hello - I am Device #2. Count=1171 Hello - I am Device #1. Count=1091 Hello - I am Device #4. Count=765 Hello - I am Device #3. Count=951 Hello - I am Device #2. Count=1172 Hello - I am Device #1. Count=1092 Hello - I am Device #4. Count=766 Hello - I am Device #3. Count=952 Hello - I am Device #2. Count=1173 Hello - I am Device #1. Count=1093 Hello - I am Device #4. Count=767 Hello - I am Device #2. Count=1174 Hello - I am Device #1. Count=1094 Hello - I aHello - I am Device #3. Count=954 - I am Device #4. Count=768 Hello - I am Device #2. Count=1175 Hello - I am Device #1. Count=1095 Hello - I am Device #3. Count=955 Hello - I am Device #4. Count=769 Hello - I am Device #2. Count=1176 Hello - I am Device #1. Count=1096 Hello - I am Device #3. Count=956 Hello - Hello - I am Device #2. Count=1177 I am Device #4. Count=770 Hello - I am Device #3. Count=957 Hello - I am Device #4. Count=771 Hello - I am Device #2. Count=1178 Hello - I am Device #1. Count=1098 Hello - I am Device #3. Count=958 Hello - I am Device #4. Count=772 Hello - I am Device #2. Count=1179 Hello - I am Device #1. Count=1099 Hello - I am Device #3. Count=959 Hello - I am Device #2. Count=1180 Hello - I am Device #4. Count=773 Hello - I am Device #3. Count=960 ``` I have RO set to 3 (the default), would increasing this be of any benefit? Is there another setting or system configuration I should look at? Series 2/API mode are overkill (we don’t need the range or a mesh), and a colleague has tried this setup with Series 2/API mode with similar results anyway. Any other suggestions? Thanks! ---
**Author:** ![mvut](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.digi.com/mvut/32/31_2.png) [@mvut](https://forums.digi.com/u/mvut)\ **Post date:** [June 9, 2015, 10:18am UTC](https://forums.digi.com/t/weird-fragmentation-with-multiple-xbee-series-1s/14955/2 "2015-06-09T10:18:20Z")
Yes, adjusting RO may help as what is occurring is that your data is getting chopped as your processor is not sending it all out as one data packet. That is part of it is being left with a break that is larger than RO character times of silence on the UART. ---
**Author:** ![Schema](https://avatars.discourse-cdn.com/v4/letter/s/779978/32.png) [@Schema](https://forums.digi.com/u/Schema)\ **Post date:** [June 9, 2015, 3:01pm UTC](https://forums.digi.com/t/weird-fragmentation-with-multiple-xbee-series-1s/14955/3 "2015-06-09T15:01:30Z")
OK, thanks, I’ll do some experiments with the RO parameter. What are the units for the RO parameter? You say “character times”, and X-CTU’s tooltip says that as well. However, Digi’s KB says it’s 200 microsecond increments: [http://knowledge.digi.com/articles/Knowledge\_Base\_Article/How-to-configure-packetizing-control](http://knowledge.digi.com/articles/Knowledge_Base_Article/How-to-configure-packetizing-control) Which is correct? ---
**Author:** ![mvut](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.digi.com/mvut/32/31_2.png) [@mvut](https://forums.digi.com/u/mvut)\ **Post date:** [June 10, 2015, 8:20am UTC](https://forums.digi.com/t/weird-fragmentation-with-multiple-xbee-series-1s/14955/4 "2015-06-10T08:20:01Z")
The link you are referring to is for the 9xtend and not the XBee 802.15.4 modules. RO on this product is a character time on the UART at the baud rate you are running at. That means a character time is a Bit time at that data rate. ---
**Author:** ![Schema](https://avatars.discourse-cdn.com/v4/letter/s/779978/32.png) [@Schema](https://forums.digi.com/u/Schema)\ **Post date:** [June 10, 2015, 9:00am UTC](https://forums.digi.com/t/weird-fragmentation-with-multiple-xbee-series-1s/14955/5 "2015-06-10T09:00:54Z")
OK thanks. Does is say that on the article anywhere? Anyway, I upped the RO parameter on my XBees to 10 and now it’s working perfectly. Thanks for the guidance. ---
**Author:** ![mvut](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.digi.com/mvut/32/31_2.png) [@mvut](https://forums.digi.com/u/mvut)\ **Post date:** [June 10, 2015, 9:28am UTC](https://forums.digi.com/t/weird-fragmentation-with-multiple-xbee-series-1s/14955/6 "2015-06-10T09:28:03Z")
No it does not directly indicated that and it probably should but it is reference commands that are only supported by the Xtend and XBee PRO XSC S3B modules and not the 802.15.4 you are using. What I would suggest is use what XCTU and the product manual indicate as Accurate as they are telling you specifically what that product supports. The KB does not always tell you that.