Zigbee network setup for transmission from E(End module) to C(Coordinator) via R(non polling router)

xbeezigbee

I am trying to setup a cluster-tree with 3-4 xbee 865 (S8), with nodes configured as
1 – Coordinator (API mode)
1 – Standard Router (API mode)
1 – Non Routing Module

I want network to setup such that, Communication between the coordinator and the non-routing module always takes via standard router (even if the devices are kept in range.)

What steps must be carried out to setup such a network??
Should i configure the DH/DL of coordinator to SH/SL of router and DH/DL of router to SH/SL of module (point-to-point communication) and have a micro-controller at Standard router to process the data received from Coordinator and modify the API frames to route data to non-routing module?? in such a case, the reverse transmission (data from module to coordinator) will not be done without modifying DH/DL of both router and module.
Can such a network be setup without micro-controller, using xctu software
only?? what steps??
Should i use zigbee api frames or digimesh api frames??
How do i ensure that the data transfer between the coordinator (to and fro) is done via router only??? (as all 3 are in the range, my attempts have resulted to transmission of data between the coordinator and the module directly, bypassing the router).

Note: xbee 865 (S8) doesnt have MYID

Best Answer

xbee 865 (S8) modules run Digimesh protocol, which is a proprietary protocol. The above situation is not achievable using digimesh, as digimesh is a true mesh and nodes in range communicate directly with each other.

Related Solutions

Xbee series 2 – router or end device firmware

I don't think the router or end device firmware makes a difference. I always use the router firmware, since I have enough power available, and never had such delays as you are experiencing.

Are you maybe using them in an area with lots of interference?
Are you using broadcasts to send data? Broadcasts can cause an overload of the network that could easily create those delays and even more.
How big are the packets you are sending? An XBee packet has a relatively small size. If your data needs to be split, then any delays due to other factors will be multiplied.
Are your microcontrollers/data sources set to the same serial speed and parity etc. as the XBees?

As a first step I suggest to enable acknowledgements for the packets you send and see how many retries were needed (can be done in API mode). Then you'll know better what to exclude.

XBee API mode help

I don't think your checksum byte is correct.

Adding up all the bytes from after the length bytes to before the checksum byte gives me 0x604. 0xff - 0x04 = 0xfb

You should write a method to implement sending (and receiving too), e.g.

struct xBeePacket {
   unsigned int dest_address;
   unsigned char api_id;
   unsigned char frame_id;
   unsigned char options;
   unsigned char data[100];
   unsigned int length;
}

void send_message(xBeePacket* p)
{
   unsigned char checksum = 0;

   Serial.write(0x7E);
   Serial.write((byte)(length>>8));
   Serial.write((byte)(length & 0x00ff));

   Serial.write(p->api_id);  checksum += p->api_id;
   Serial.write(p->frame_id);  checksum += p->frame_id;

   Serial.write((byte)(p->dest_address >> 8));  
   checksum += (byte)(p->dest_address >> 8);
   Serial.write((byte)(p->dest_address & 0x00ff));  
   checksum += (byte)(p->dest_address & 0x00ff);

   Serial.write(p->options);  checksum += p->options;

   for (int i = 0; i < p->length; i++)
   {
       Serial.write(p->data[i]);  checksum += p->frame_id;
   }

   Serial.write(0xff - checksum);
}

Hoep this gets you started.

Related Topic