Baudrate of internal XBee module in ConnectPort X4 gateway

Hi guys, does anyone know what is the default baudrate settings of the internal XBee module in CPX4 gateway? I guess it is 9600bps just like the XBee module with default factory parameters.

Why I’m asking for this is I found the communication rate is not fast enough for our application. Considering the Gateway must use the API mode of XBee module, a simple message needs bundle of byes transmitted. Assume 50bytes for a message frame, we need 50ms under 9600bps for single direction (100ms for bi-direction if needs response). If in a large system contains 100 nodes, then scan 100 nodes will cost 100*100ms = 10seconds. That sounds not good for some control. Like my lighting control application. 10 seconds is not good enough.

Anyway, then I thought of whether we can change the baudrate to a higher value to improve this realtime performance. From the web interface, I founf the baudrate setting is disabled for gateway itself.

So…I want someone could tell me if we cannot change the internal baudrate or there is a way you know.

The X4-XBee link runs at 115kbps. If you install a ‘stock’ module at 9600 baud, the X4 automatically bumps the speed up to 115kbps.

You really have a 1-to-100 network, so if you’re not using Source-Routing, then your performance will be bad. How to use it? I don’t know - haven’t tackled that task yet. But without source routing, the packets re-invent a route every time they move. With source routing, the ‘mesh’ memorizes the last good route and keep reusing it until it fails.

Also, you may be seeing that the X4’s XBee is a bottleneck with a limited number of concurrent transactions it can manage (4?) - so an outgoing packet needs to be handed off to & ACK’d by another node before that buffer is available for a new transaction (signified by the return of the 0x8B Zb Transmit Status).

One possible solution - assuming your remote nodes are in API mode - is to consider using multiple “server” Xbee - for example the X4 as coordinator and a few X2 as routers. This would allow more packets to enter/leave the mesh, but would require more intelligent routing of the responses since they now have one of 2 or 3 possible destinations.