trouble with XBEE data streaming

Wireless & IoT
1

hello to everybody in this forum. this is my first message

I am writing a project involving data streaming from several independent peripheral units (each driven by PIC up) and a central unit (a mac pc).

for practical reasons the fastest way to communicate with several different independent units is RF, so I tried XBEE series 2 modules.

The connection works well and seems realiable, particularly if I need to send one or few bytes IN ONE DIRECTION (eg from the coordinator to one end device or vice versa), and even more reliably if I only send 1 byte. it often stops if I try to send a few hundreds beats!

at the opposite if I send a byte to one unit to request sending one byte each time (thus starting a continuous stream of data), then the all thing stops very shortly.

it is clearly not a problem of speed. I have tried different baud rates (9600 and 115200) and also leaving several milliseconds (up to 50) before sending the byte after the request, but without improvement.

on the other hand, if I disconnect the xbee modules and connect the sockets with just wires the all thing works perfectly and the streaming works indefinitely, indicating that there must be something wrong with my use of the XBEE and not with the rest.

this is the configuration that I have used (with X-CTU):

peripheral xbees: ZNET 2.5 router/end device AT

central unit: ZNET 2.5 coordinator AT

ID PAN = 234 (all modules)

scan = 1FFE (all modules)

DH = 0 (all modules)

DL = FFFF (for coordinator) = 0 (for router/end devices)

baud rate: 115200 or 9600 (results will not change)

parity = 0 (disabled)

packetization timeout = 0 (tried also = 3 but no improvement)

D7 config = 0 (disabled) (tried also = 1 but no improvement)

D6 config = 0 (disabled)

well, in my hope this configuration should be a “transparent transmission”

and the coordinator is supposed to be able to talk to each of the peripheral devices, whereas peripheral devices cannot talk between them.

(actually it should correspond to “point-to-multipoint” transmission…??).

I will be grateful if someone could tell me where I went wrong and suggest some solution.

many thanks

Luciano

2

see the other posts here on baud rate errors and on the fact that in any such wireless system with packets, you need flow control. Either using CTS or XON/XOFF or just have the stream do pauses to preclude overrunning.

As to XBee topology: the sending radio addresses a packet to ANY other in-range XBee by setting DH/DL. Be sure to enable ACKs so there will be automatic retries on bit errors.

You can send one to many (broadcast) by using an all ones address, though there are no ACKs so error correction falls upon your app.

3

thank you for your reply:

“see the other posts here on baud rate errors”

baud rate error can be excluded in my case (see my post)

“and on the fact that in any such wireless system with packets, you need flow control. Either using CTS or XON/XOFF or just have the stream do pauses to preclude overrunning”.

I have read several previous posts but I could not find an explanation on how to perform this properly:

should it be done from the PIC controlling the XBEE, using some of the XBEE pin? or should it be done while programming the XBEE with X-CTU?

I think I have tried the latter (as I wrote in my previous post: I tried D7 = 1 but no success)

could you please give more precise details or point to a specific post that I may have missed?

"As to XBee topology: the sending radio addresses a packet to ANY other in-range XBee by setting DH/DL. Be sure to enable ACKs so there will be automatic retries on bit errors.

You can send one to many (broadcast) by using an all ones address, though there are no ACKs so error correction falls upon your app."

I think (?) the configuration I used was not “broadcast” but rather “point-to-multipoint”. as far as I understood it (?) broadcast is something different, and requires many re-transmission of packets between all units, so it does not seem suitable for streaming.

please correct me if I am wrong

Luciano

4

Dont feel bad, I just purchased 3 of these units and having same problem.

My problem is If i send say just 5~10 bytes (using the X-CTU terminal app), the end point will just stop transmitting information, moments later the lost information appears on my coordinator. But if i do it other way around i never loose any information.

My coordinator is hooked up to a usb explore board with all proper serial pins, but my spark fun exploer board only has the Din and Dout to a separate usb-serial converter.

I guess only work around is using the API mode :frowning:

Sean-

5

Broadcast means that YOU set the DH:DL registers to the broadcast address (All Ones, or hex FF).

Streaming from A to B is not normally done by broadcast.

Streaming from A to many must be done by broadcast or n separate transmissions for n destinations.

6

I noticed if i send a byte every second (like a keepalive) the delay goes away or is very minimal. My guess is the Xbee sleeps? I really really need to read the 60 page manual. But worst case, sending one keepalive byte every second is working just fine (for now).

7

whoismaha:
I noticed if i send a byte every second (like a keepalive) the delay goes away or is very minimal. My guess is the Xbee sleeps? I really really need to read the 60 page manual. But worst case, sending one keepalive byte every second is working just fine (for now).

XBee (series 1) sleeps only if you change the factory default (no sleep).