Routing table limitation?

Using Xbee ZB, are we still limited to 8 end devices per coordinator/router? If yes, is there any way of managing the routing table from the host connected to the Xbee module?

Thanks in advance,

Daniel.

Where do you have this information from ?

Is this really true ? What happens if I have a coordinator with 12 end devices ?

You can have 10 children per coordinator, 12 per router.

As for the second part of your question, I’m not sure what you’re asking here. What is the host, and if this is a PC is there some sort of software on it that can talk to an XBee? What type of XBee module (coordinator/router/end node)?

yes , while network is fixed. each end and router can know their parent. so you need plan manually.please refer Frame Type: 0x95

Also, keep in mind that with ZB firmware, you can set a router/coordinator to “forget” devices associated to it, also known as Child Poll Timeout.

This value will be 3 x (SP x SN), and is described in the current ZB OEM manual on page 71 at the following link:
http://ftp1.digi.com/support/documentation/90000976_C.pdf

The coordinator is a CPX. What are the limitations here ? Does the CPX hold an extended address table to increase the number of addressable childs to more than 10 ?

I ask this question because we are using a star topology and we are now observing delayed packet transactions (mostly from coordinator to end-device) and a degrade in overall performance and reliability (some nodes seem to block other if you are looking at a realtime trace logger on the cpx, packet got lost or are splitted up or trunced.) as we increased the number of end devices. Some devices are in sleep mode (30s period), some devices send periodically (every 1s about 30 chars).

The CP-X has no additional capabilities beyond that of a standard Coordinator as far as the number of children. One thing you might want to look into, once your CP-X has been updated to the new 2.8.4.7 EOS firmware, is many-to-one and source routing.

These can significantly reduce the amount of traffic on your PAN, and therefore reduce delays when packets have to wait on other packets to clear the queue.

These are valueable pieces of information. There is obviously the question, why the CP-X does not provide such mechanisms like an extended address table to increase the performance causes by the limited resource of the XBee modules.

There is another question concerning performance (the problem of a stalling transmission from the CP-X to an end-device or router): As I got information from the Digi Support Team that the socket.send() method is non-blocking and immediatelly transfering the data to the zigbee layer, we get no feedback whether the transmission was successful. So there seems to be a problem of buffer-flooding if we are sending data consecutively with no or too little delay (buffers may fill up).
So the question is: if I send data from the CPX to a sleeping end-device (30s) and promptly after that send data to a non-sleeping router (from the CP-X), will the transmission queue (buffer on the zigbee layer) be worked off in sequence ? I think there is some kind of hash/dictionary (nwadd -> descriptor for each end-device) implementation so that polling child requests are treated in the order of the arrived requests - how does the zigbee layer / XBee Module schedule the transmission to router / end-devices side-by-side ?

Message was edited by: bju

push
I now got feedback that a blocking socket and therefore error detection is possible. However this is not an efficient solution since socket usage is exclusive which means subsequent send attempts may wait for a long time.

I think my question concering transmission scheduling on the xbee is quiet interesting.