Avoiding packetization with multiple Xbee receivers

[fozzyvis]

Hi all,

I need to send one single byte of data at 19200baud every 400 ms to a couple of receivers.
As I had a couple of Xbee S2B pro's at hand I want to use these. I've got a test set-up consisting of

- One Xbee XBP24BZ7 configured as Coordinator AT (version 20a7).
- One Xbee XBP24BZ7 configured as Router (or endpoint, there's no difference) AT 22A7

When entering the router's address as the destination address in the coordinator, all is fine.
When I put the broadcast address in the coordinator (0xFFFF) packets start coming in packetized. Every few seconds I get bursts of data. No packets are lost, and data is not corrupted. I need the data continuously however.
Configuring them one-on-one is not an option as I need multiple receivers.

I've found quite a lot of forum posts around with the same question but no answer in the end. Configuring RO = 0 to minimize the buffering is proposed every time, but doesn't help.

I've also tried to send every byte ten/twenty times hoping the buffer would fill up quicker, but to no avail. Again, when configuring them one-on-one it's working fine.
I've read about using the CTS line but I can't seem to figure this out as this seems to work the other way around: notifying the Xbee the senders' receive buffer is full is useless as it's only sending. On the receiving end there's no use as the sender is still sending in bursts.

So... Any clues?

[David_AVD]

I needed to do something similar only a few weeks ago.  I tried S1 and S2 Xbees with no success.  In my case the packets were every 100ms or so and about 10 bytes each before transmission.

I didn't get a chance to view the received data stream to see exactly what was happening.  I suspected that the original packets were being split and the receiving equipment was seeing the gaps as timeouts.  The transmitting and receiving equipment were both by another manufacturer so no chance to fix either end.

I ended up throwing three $150 radio modems at the job to get it down done.  Somewhat more $$ than the Xbees I started with !

The overall feeling I got was that Xbees just don't cut it for one to many (1 to 2 in my case) streaming transmissions.

[fozzyvis]

Damn .
$150 radios are not really an option for this project. May I ask which ones you ended up using anyway?

[HackedFridgeMagnet]

Just a few points to help me jog my memory.
The series II is the multipoint network, which can be set up as a self healing mesh.
Whether you are router or coordinator doesn't actually matter as far as sending receiving data goes. it only signifies who is managing the network.
Even the coordinator has a normal address as well as the special coordinators address.

I cant give you much of an answer but maybe some of this will help.
Are you using AT mode or API mode? I only ever used API mode, but i think this could be important.

I guess the bursts of data you are getting are the network management. I dont think you can get rid of these.  In API mode you might be able to do things differently.

Maybe you need a lower level device with no network management. Like the ones they use for RC cars.

Also you can turn off retransmits, sometimes it is more important that the new data gets through immediately than the old data is even received.
Retransmits can really lock up a network that has a low fade margin.

I have been recently using HopeRF RFM69WH, they are only $4 each but take a bit of time to get going.

[ovnr]

If you're getting bursts of data, I'd imagine it's due to buffering by the transmitter. Try finding out how big the transmit buffer is, and pad your data so it fits perfectly/overflows? That way, the transmitter will be forced to transmit when you want it to, as opposed as to when it has collected "enough" data.

I should note that I've never used Xbee radios myself, so take my advise with a grain of salt.

[fozzyvis]

I cant give you much of an answer but maybe some of this will help.
Are you using AT mode or API mode? I only ever used API mode, but i think this could be important.

I guess the bursts of data you are getting are the network management. I dont think you can get rid of these.  In API mode you might be able to do things differently.

Maybe you need a lower level device with no network management. Like the ones they use for RC cars.

I'm using AT mode as it is the most basic of the two. I also can't seem to figure out how to use API mode to send basic packets (each time one byte) of data. Lots of info on sending commands, setting pins remotely and such, but I still have to find an understandable guide on how to simply send data.

I figured the network management would be one of the possible reasons for the packetization, but haven't found out how to avoid it doing that.

You're right in that a more basic device would possibly be better but
a) I have these at hand
b) I'd like to figure out what's going wrong or how I can get it right with the Xbees, so that in the future I know what to expect.

I seems such a trivial set-up I can't believe it isn't possible to get it working with Xbee the way I need it to work

[fozzyvis]

If you're getting bursts of data, I'd imagine it's due to buffering by the transmitter. Try finding out how big the transmit buffer is, and pad your data so it fits perfectly/overflows?

That's what I figured as well and why I tried sending each byte many times (like 10, 20, 40 times), but it's still not really working the way it should. Also, it seems weird to send 40 times as much data as needed just to get one single byte of data to the receivers every 500 ms

[amyk]

Data is buffered in the serial receive buffer until one of the following causes the data to be packetized and
transmitted:
•No serial characters are received for the amount of time determined by the RO (Packetization Timeout)
parameter. If RO = 0, packetization begins when a character is received.
•The Command Mode Sequence (GT + CC + GT) is received. Any character buffered in the serial
receive buffer before the sequence is transmitted.
•The maximum number of characters that will fit in an RF packet is received.

Have you tried this option too?

Of course if you don't want to spend $$ there's always the time-consuming and challenging (but possibly more rewarding) route of firmware modding...

[fozzyvis]

•The Command Mode Sequence (GT + CC + GT) is received. Any character buffered in the serial
receive buffer before the sequence is transmitted.

Of course if you don't want to spend $$ there's always the time-consuming and challenging (but possibly more rewarding) route of firmware modding...

I haven't tried that yet, no. Looks like a hack that could possibly work. I'll try it tonight and post back, even (or especially) if it works .
The firmware modding part might sound cool, but beyond the scope of my knowledge...

Thanks!

[fozzyvis]

So... It doesn't seem to work unfortunately.
I let my PIC send one byte every second, followed by having the Xbee enter command mode, but that doesn't seem to trigger a transmit of the bytes in the buffer.
Also, even though my few lines of code produce an nice cyclic pattern the xbee doesn't always respond by going into command mode.
I have verified with a logic analyser that the timing is exactly the same, and sometimes the xbee seems to skip a few times or waits for almost a second before going into command mode.
Tried reprogramming the Xbee modules, using older firmwares and swapping them to no avail.

I have no idea why they are behaving that way.
As I am not really on a tight schedule I might try to get in touch with Digi, maybe they have some useful ideas/info...

[fozzyvis]

Interesting fact: if I connect the modules the other way around (the coordinator as the receiver and the router/endpoint as the sender), it seems to work perfectly. Sadly, the sender will be the only one that will consistently be powered, the others will be without power from time to time.

[JamesAus]

Use point to multipoint firmware and adjust the packetization timeout accordingly, so after x char times of silence it will transmit whatever is in the buffer. Forget all the meshing rubbish if you care at all about packet fragmentation. Been there, tried that, and not just with XBees, all these stacks only seem to be good for non time critical apps.

[David_AVD]

Damn .
$150 radios are not really an option for this project. May I ask which ones you ended up using anyway?

The ones we used were these ones.

[David_AVD]

Use point to multipoint firmware and adjust the packetization timeout accordingly, so after x char times of silence it will transmit whatever is in the buffer. Forget all the meshing rubbish if you care at all about packet fragmentation. Been there, tried that, and not just with XBees, all these stacks only seem to be good for non time critical apps.

We tried all that too.  Still no luck when the packets were coming in more than once every few seconds.   

[amyk]

So... It doesn't seem to work unfortunately.
I let my PIC send one byte every second, followed by having the Xbee enter command mode, but that doesn't seem to trigger a transmit of the bytes in the buffer.
Also, even though my few lines of code produce an nice cyclic pattern the xbee doesn't always respond by going into command mode.
I have verified with a logic analyser that the timing is exactly the same, and sometimes the xbee seems to skip a few times or waits for almost a second before going into command mode.
Tried reprogramming the Xbee modules, using older firmwares and swapping them to no avail.

I have no idea why they are behaving that way.
As I am not really on a tight schedule I might try to get in touch with Digi, maybe they have some useful ideas/info...

Another thing I can think of is that firmware may be restricting transmit durations for regulatory reasons, or there's some interference in the air (tons of stuff in the 2.4GHz band) and it's waiting for a clear channel before transmitting.

[JamesAus]

I'm really surprised it isn't working as a simple point-multi point "cable replacement" type scenario. I use them like this all the time, for timing critical protocols, with upto a hundred or more peers. I haven't used the  2.4 s2 units specifically, but the s1 pro, and every variant of the 900 pro, s3, and Xsc. Packet sizes are typically 6 to 12 bytes and repetition rates in excess of every 400ms ( of course things slow down a bit if running at 10k OTA though ). Any chance you could set them up as p2p, save your config and paste the contents of your .pro here?

To the user of the synapse units.....I'm glad you managed to get them working to suite your needs. I had a play with them a year or so ago. They looked impressive on paper, but for me failed to live upto expectations in so many ways. Maybe they have matured somewhat.

[David_AVD]

We got the Synapse units working good enough for the job at hand, but I'm not sure that I'd buy them again.

For the money they cost I was expecting flawless performance, but they still dropped the odd packet.