Real-time energy measurement through ZigBee Pro, problems with latency

XBee & XBee Gateway XBee - Zigbee
1

Hi,

I’ve been using Digi products for a while. More specifically, I’m using a ConnectPortX2 to “bridge” requests and responses from a local server (connected to the ConnectPort through an ethernet link) to different kind of meters/sensors (who receive and send data through XBee RS485/RS232 End Devices). When using two to three sensors, this method would work perfectly, we could have data from the sensors at each minute. However, when installing larger networks (sensors must relay through up to 4 wall routers before “talking” to the ConnectPort) or networks with more devices (10-20 meters), the ConnectPort becomes unreliable (times out, looses communication with an end device that worked well before making the network larger, etc.). I’ve tried to configure the ConnectPort for Many-to-one routing (this made it worse…). I also tried to modify the python program used to talk to the end nodes. I’ve run out of options… What am I doing wrong? Is the problem more likely to be related with my python script (if yes, I’ll post in the python section), or is it related to the way ZigBee works?

2

Are the 485 units really “End-Device” firmware?

if so, then the SN/SP of your X2 and ALL of the routers need to be increased to handle the expected request cycle.

Talking once per minute to 20 meters should be a no-brainer, as long as you skew the polls to be serial and not try to talk to 20 at the exact same instant.

If the “End Device?” question is true, then I can explain more.

3

Hi Lynn, thanks for the response.

First of all, yes they are “End-Device” firmware. We also started to buy RS485 Converters with “router” firmware and we will continue buying the router firmware converters as I think they are better for our usage (am I right?). However, I must continue to work with the End-device converters that are already installed since we cannot have access to all of them easily. So how should the SN/SP be configured?

For the skewing part, I recently developed a new python script that incorporated multi-threading so that many devices could be polled in “parallel” (instead of blocking on one device until timeout occurs). Is this a bad idea? I also must admit that, when a device cannot be reached, the server script will poll the ConnectPort endlessly until it receives an answer. Should I also change this? How much time should I wait before retrying to poll a device when it is not responding?

I also have one last question, I’ve experienced situations were the end devices times out after receiving a request (eg. request A), receives another request (request B) and sends back a response corresponding to the first request (eg response A instead of response B). Is there a way to empty the serial buffer from an end device or to make it timeout to avoid such mix-ups?

I hope that’s not too many questions. Once again thanks for your time.

Marion

4

Are the End-Devices fully awake? or do they sleep? Are you using AT or API modes?

End-Devices are not part of the Mesh. In fact, no one can talk to them directly. When they wake, they query one and only one ‘parent’ for pending messages. So they pull requests and push responses via the parent.

So the parent reserves several full sized buffers for every associated child - a dedcated resource lost. So the parent uses SN/SP to decide when the child has left/died/been replaced. By default this some short time like 320 msec, so a parent flushes the child away in less than a second of inactivity. If they sleep that is. If they are awake I think they are active every 100msec by default.

This might NOT be the problem, but it worth trying.

SN/SP settings I commonly use are SP=0x07D0 (which represents 20 seconds), then SN of 0x03 for 1 minute, 0x0F for 5 minutes, 0x2D for 15 minutes and 0xB4 for 1 hour. The only downside to using larger Sn/Sp in routers (meaning the X4 and other routers) is when you DO remove an end-device, it takes longer for the parent to free up the old resource.

Talking in parallel to 3 or 4 devices shouldn’t be a problem. trying to talk to 20 at the same instant would be a problem first because it congests the RF channel (bunches up messages), but also because an X4 won’t like running 20 threads at the same time.

My own designs I tend to decouple the request/response as much as possible. So I send a request and do NOT wait for the response. At some time in the future I see a response, which (if the protocol permits) I just treat as a magic unsolicated answer. I suppose you are using AT-transparent mode, which complicates multi-slave behavior.

With API mode, one could for example send a request to slave #1, then 100msec later send one to #2 and so on to all 20. At some point you’d have potentially 20 responses each tagged with the MAC address of the slave (in API mode). so the single task then just sorts the responses to match them up to the appariproate slave.

With AT mode, the most you can do is raise the baud rate (to reduce the serial shift time), plus keep the RO setting low. The Xbee shouldn’t really buffer data very long, but i don’t think there is a way to (for example) tell the Xbee to discard what it has, and that won’t be very useful because either 1) the buffer is complete and within msecs it will be sent, or 2) the serial devcie is still sending data and just flushing 1/2 of the message won’t stop the slave from finishing the response.