ZigBeeMesh V/s DigiMesh

I do understand basic advantage of the DigiMesh interns of power saving n better network.
But I am confuse with some part.

There is no document mentioning how to setup networks using DigiMesh in detail (more infor. regarding auto association, network search, changing network, changing PANID or channel. etc) …

What if I want my end node to associate automatically or scan channels? Also I want router/coordinator to set random PANID.

As an example in ZigBee Mesh, end node can scan channel and find available network in surrounding. If end node do not know PANID then it can still search and associate.,…

I am looking for something similar to auto association.

If you can suggest something that can suits my requirements.

Thank you

Digimesh supports none of the things you wish. You must set a single channel (or hop-pattern) which matches on all nodes. DM nodes cannot scan for alternatves.

Also DM requires a single fixed PAN ID which matches in all nodes. DM does not have the PANID=0 trick of ZigBee to find alternative meshes.

I am not sure that Dm saves power - in fact since the nodes need to maintain accurate clocks while sleeping, plus all nodes need remain awake long enough to route & repeat packets for peers, the power usage can be considerably higher than Zigbee. DigiMesh’s main value is the ‘sleeping routers’ support, not low battery usage by sleepers.

ZigBee in contrast divides the world into 2 types of nodes - routers which need 100% full-time power and end-devices which sleep and can use a fraction of the power of a DM node because they can be ‘selfish’ and only power up for their own needs & do not help any other nodes.

Hi Lynnl,

Thank you for your reply.

Now things are more clear… I was wondering why there is no ZigBee Mesh network device on 900Mhz series? Are you planning to develop that in future?

It will be good opportunities for the people who are using ZigBee mesh and if they want to cover longer distance.
Pathik Shah

I don’t think Digi has any plans to do Zb on 900Mhz, in part because we use an ‘Ember’ stack for Zb but don’t have any Ember chips on any 900Mhz Xbee. So effort would be quite high.

Now, if you really want the ‘2 types of nodes - some fully awake & some very sleepy’, then there are more exotic settings for Digimesh. One could have full-time routers (for example living on power/light poles) running always and use the old SM=1 ‘pin-wake’ to obtain sleeping devices with very short wake times, which are forced to only link to the fully awake units. That is rather ZB-ish.


I want to make an network where one device is always ON and other devices are sleeping devices that can send data and sleep back.

I checked in few forums, I read that digiMesh can not go to sleep using Sleep_RQ (Ref. http://forums.digi.com/support/forum/viewthread_thread,317#1276 and http://forums.digi.com/support/forum/viewthread_thread,213#773)

I want to make use of SM=1 on all sleeping device using external uc, I can awake sleeping device, send data then sleep (using Sleep_RQ pin).

Let me know if you have any information about SM=1 in 900MHz digiMesh firmware.

I did not find a single note in datasheet about SM=1 not compatible in DigiMesh.

Thank you,

I believe DigiMesh fully supports SM=1, however DigiMesh doesn’t include a method like ZigBee for a second node to ‘buffer/hold’ packets for the sleeper.

I think the correct comment is “using SM=1” defeats the purpose of using DigiMesh at all. So the docs probably avoid that topic - it is a bit like explaining how to use your sports-car as a dump-truck :slight_smile: Problems multiple rapidly.

If you use SM=1, then:

  1. your device MUST be within radio-view of a fully awake node (SM=0) - otherwise it will wake and find no one to talk to!
  2. your device must remain awake long enough for a remote node to detect the message and return any response. Of course, some of your messages might not need a response.
  3. remote nodes will have no ability to send your node a packet when they wish - your only option is for them to wait for a message from your sleeper, then hope you can return a response fast enough to avoid the SM=1 node sleeping again.
  4. two nodes with SM=1 probably can never talk to each other.