Lightweight Mesh network size

Log in or register to post comments
Go To Last Post
10 posts / 0 new
Author
Message
hatem0216
hatem0216's picture
Level: New Member
Joined: Thu. Mar 7, 2013
Posts: 6 View posts
#1
Posted by hatem0216: Thu. Mar 14, 2013 - 07:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm working on a project that have about 200 sensors distributed within a bounded area, about 2km in diameter. Sensors transmit their data to a controller every 1 to 5 minutes. we want to connect those sensors wirelessly in a mesh topology. We decided to use ATRF212 900mhz modules because they perform better in forest. But I'm wondering which stack is better Bitcloud or Lightweight when it comes to large area coverage? I mean is there any limitation on the number of nodes?

Tags:

Wireless, General Wireless Discussions
Last Edited: Fri. Oct 16, 2015 - 12:22 AM
Top
Cybernetician
Cybernetician's picture
Level: Wannabe
Joined: Thu. Oct 4, 2012
Posts: 58 View posts
Posted by Cybernetician: Fri. Mar 15, 2013 - 02:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hatem0216 wrote:
Lightweight Mesh network size

And

hatem0216 wrote:
I mean is there any limitation on the number of nodes?

i think so most of them busy let me try.

May be it is helpful.

alexru wrote:
Features

The current implementation of the Lightweight Mesh protocol has the following features:
- Simplicity of configuration and use
- Up to 65535 nodes in one network (theoretical limit)
- Up to 65535 separate PANs on one channel
- Up to 15 independent application endpoints
- No dedicated node is required to start a network
- No periodic service traffic occupying bandwidth
- Two distinct types of nodes:

a. Routing (network address < 0x8000)
b. Non-routing (network address >= 0x8000)

- Once powered on node is ready to send and receive data; no special joining procedure is required
- Route discovery happens automatically if route to the destination is not known
- No child-parent relationship between the nodes
- Non-routing nodes can send and receive data to/from any other node (including non-routing nodes), but they will never be used for routing purposes
- Routing table is updated automatically based on the data from the received and transmitted frames
- Duplicate frames (broadcast or multipath unicast) are rejected
- Small footprint (less than 8kB of Flash and 4kB of RAM for a typical application)

http://www.atmel.com/tools/LIGHT...

reference: https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=125226

cheers

From Idea To Invention

Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Mon. Mar 18, 2013 - 04:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is no "embedded" limitation. The only limitation is available bandwidth and MCU performance.

200 sending every 5 minutes should be fine. Every minute is a bit harder, but still should work.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Top
hatem0216
hatem0216's picture
Level: New Member
Joined: Thu. Mar 7, 2013
Posts: 6 View posts
Posted by hatem0216: Mon. Mar 18, 2013 - 08:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks guys for your responses.

I have to mention that the "coordinator" (I mean a central node) has also to send some commands to the nodes.
My biggest concern here is about the latency caused by the route discovery mechanism.
I know that regardless of how many nodes there are in the network, each node needs only one entry in its routing table to communicate to the "coordinator".
But what if the "coordinator" needs to communicate to all those nodes in the ZigBee network?
The problem here is that the "coordinator" need to perform one route discovery for each destination device to establish a route.
And if the routing table on the "coordinator" is not capable of storing about 200 entries (the number of our sensors) this will cause route discoveries to occur more regularly. In this case we risk larger packet delays and poor network performance.

Is there any limitation on the routing table size?

alex: By "MCU performance" do you mean I have to worry about the RAM size on the "coordinator"?

Thanks
Hatem

Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Mon. Mar 18, 2013 - 08:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hatem0216 wrote:
But what if the "coordinator" needs to communicate to all those nodes in the ZigBee network?
Then it either needs to store all routing entries or discover routes from time to time.

With LwMesh you won't have problems storing routing tables. Each entry takes 7 bytes, so entire table for 200 nodes will take 1400 bytes.

With BitCloud route table entries are about the same size, may be a bit bigger, but then BitCloud takes much more RAM in other places, so 1400 bytes might be a problem.

hatem0216 wrote:
Is there any limitation on the routing table size?
The only limitation is amount of available RAM.

hatem0216 wrote:
alex: By "MCU performance" do you mean I have to worry about the RAM size on the "coordinator"?
Ability to process 200 frames every minute as well.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Top
hatem0216
hatem0216's picture
Level: New Member
Joined: Thu. Mar 7, 2013
Posts: 6 View posts
Posted by hatem0216: Mon. Mar 18, 2013 - 09:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see. Thanks for the in depth response. that's what I needed to know.
I'll start using the LwMesh.

Top
claudio01
claudio01's picture
Level: New Member
Joined: Fri. Jun 7, 2013
Posts: 3 View posts
Posted by claudio01: Tue. Sep 8, 2015 - 01:45 PM (Reply to #3)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear Alex

 

I'm new on Lightweight Mesh

 

Till today es use Telit NE50 Modules and mesh stack (based on Atmel xmega32A4 and SI4432)

I'm looking to migrate the SW stack to Lightweight Mesh in order to make the new routers and enpoint units with single Atmel chip (MCU and Radio)

 

1) The problem is our actual Gateways contains the mention module, so we will like to port Lightweight Mesh to a different radio, do you know if are examples on this issue?

 

2) What is the bandwidth that can be achieve with this stack?

      I have different requirements (not Low power required)

        a) AMI, read up to 500 meters (routers) every hour to the coordinator, and few configuration messages from coordinator to routers

        b) data transfer, where each router sends up to 2 messages per second of 46 bytes payload to a coordinator, here the topology is 1 coordinator and 5-20 routes maximum

 

3) Low power for battery operate units (routers),

        a) can a router be low power? what average power consumption could be achieve (xmega + AT86RF212 or similar HW), here we need to send 20 bytes packets 4 times an hour per router in the network, the LOW power Routers should be able to forward messages from distance units

 

 

thanks in advance

 

Claudio

Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Tue. Sep 15, 2015 - 07:05 AM (Reply to #7)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

claudio01 wrote:
1) The problem is our actual Gateways contains the mention module, so we will like to port Lightweight Mesh to a different radio, do you know if are examples on this issue?
That radio has completely different architecture. I have not worked with those radios, so I can't say if it is possible at all or not. It is not going to be trivial, that's for sure.

 

claudio01 wrote:
2) What is the bandwidth that can be achieve with this stack?
Depends on the performance of that radio and your driver.

 

claudio01 wrote:
3) Low power for battery operate units (routers)
Routers can't sleep without specifically designing your application to cope with sleeping routers. It is not easy for most application requiring true mesh.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Top
claudio01
claudio01's picture
Level: New Member
Joined: Fri. Jun 7, 2013
Posts: 3 View posts
Posted by claudio01: Wed. Sep 30, 2015 - 02:28 PM (Reply to #8)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear Alex

 

 

thanks for your response,

Now we are already sending and getting data, but without package handler,

 

 

We see that in the code you use the AT86RF212 the feature TRX_CMD_RX_AACK_ON, we need to make port the Listen before talk and the TX automatic Ack to a SW implementation. 

 

Do you have any example of implementing the RX_AACK by SW and also the channel energy detection to make listen before talk

 

 

thanks in advance

 

 

Claudio

Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Wed. Sep 30, 2015 - 03:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

There is PHY_EdReq() to do the channel scan,

 

Doing ACKs in the software is harder. They are very time sensitive, and LwMesh is not setup for time sensitive things like that. But in general, you just send and ACK frame as you would send any other fame, just format it according to the standard.

 

Also note that there is LBT bit in the radio registers settings, but I'm not sure if it will do what you want.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Top