Atmel Lightweight Mesh stack

Last post
517 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Atmel® Lightweight Mesh software Stack is an easy to use proprietary low power wireless mesh network protocol. It has been designed to address the needs of a wide range of wireless connectivity applications, including:

    - Remote control
    - Alarms and security
    - Automatic Meter Reading (AMR)
    - Home and commercial building automation
    - Toys and educational equipment
The Lightweight Mesh software stack is designed to work with all Atmel IEEE® 802.15.4 transceivers and SoCs. Currently the stack works with AVR®- and ARM®-based MCUs, but given its extreme portability and low resource requirements, it can be run on almost any Atmel MCU.

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/LIGHTWEIGHT_MESH.aspx

PS: Please ask application development questions in separate threads. This thread is for LwMesh itself and its operation.

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:
Atme® Lightweight Mesh software Stack is an easy to use proprietary low power wireless mesh network protocol. It has been designed to address the needs of a wide range of wireless connectivity applications, including:
    - Remote control
    - Alarms and security
    - Automatic Meter Reading (AMR)
    - Home and commercial building automation
    - Toys and educational equipment
The Lightweight Mesh software stack is designed to work with all Atmel IEEE® 802.15.4 transceivers and SoCs. Currently the stack works with AVR®-based MCUs, but given its extreme portability and low resource requirements, it can be run on almost any Atmel MCU.

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/LIGHTWEIGHT_MESH.aspx


Thanks Alex
I look forward to testing this :)

_________________________________

www.proficnc.com
_________________________________
Go Aussie Go!!!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

THis looks interesting. I like to know more about this:

1) I've been meaning (for a long time) to ask here about "a map of the terrain" re wireless protocol stacks etc. E.g. ZigBit. Where does this Lightweight Mesh fit in?

2) I have a few Ravens lying around. Played with'em a few years ago, but now they're collecting dust. W/o digging out all the Raven specs, and then digging into the specs of what Lightweight Mesh supports - do those two marry well?

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1. LwMesh uses IEEE 802.15.4 physical frames, but it does not follow IEEE 802.15.4 MAC specification, so it is "worse" than the real MAC in this sense. But LwMesh implements mesh routing, so it is "better" than plain MAC in that respect.

Basically it covers 90% of the requests I see on a daily basis from people who try to use BitCloud for what it was not designed to be used for. Unfortunately some people really need ZigBee, so they have to deal with bloated technologies.

2. There is no direct Raven (RF230+ATmega1284) support. But there is support for ZigBit, which is RF230+ATmega1281. ATmega1281 is virtually the same as ATmega1284. All you have to do is redefine IO pins and IRQ handler.

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As a bonus LwMesh includes sample applications that can be easily understood by humans :)

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, so you're saying that with a little bit of tinkering I could get the stuff running on the Ravens. I'll start reading the documents then. Not in a hurry. Not likely to get a round to actually trying it until Christmas or some such.

Re the "does not follow IEEE 802.15.4 MAC specification": If I have other 2.4 GHz apps nearby (not talking about some WLAN but "simple" home automation stuff), will the co-exist peacefully?

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They will co-exist to the same extent as two different 15.4 networks, like ZigBee and WirelessHART, for example. LwMesh uses standard MAC header (to facilitate hardware frame filtering), but does not respond to the command frames. So if LwMesh happen to decode into something meaningful, then it might cause problems. The same way if ZigBee frame decodes into proper WirelessHART frame it might cause problems. Why there is no "payload protocol ID" field in the MAC header is beyond my understanding.

In practice, with security enabled, both networks will just look like noise to each other and nothing bad will happen.

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BTW, Alex: Are you aware that both the links on the LwMesh page at www.atmel.com (that you link to in your announcement) ultimately contain exactly the same thing (a directory tree with the root "LwMesh", both being of equal total size, and both containing the exact same files AFAICT)?

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, there is also no links to the stack from a main wireless products page. I've been told it is in the process of being fixed :)

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What I'd like to see is the commercialization of the IEEE 802.15.5 mesh protocol, used with 802.15.4. Truly open, unlike ZigBee or ISA100.11a, and the numerous chip-specific proprietary mesh protocols for 802.15.4.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is nothing chip specific in LwMesh, but it is a tool to sell chips. If you feel like sponsoring development of a really open and independend stack, I'm sure there are people who will do it.

ZigBee is an open standard, but it is bloated to the point where implementation takes 10-15 man*years, so no hobby takers.

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, Alex for your efforts to release this new stack.
I reviewed the docs, looking for SPI support. My applic. is to connect devices via SPI like GPS(@10 Hz), & etc. to my zigbit A2 module.
Your advice is appreciated.
Thanks!

Asking a better question, is the beginning of learning.
**********************
New Hardware Hackers SIG in San Diego, CA Meets 2nd. Tuesday, more info www.Spincraft.com
***********************

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is no support for any peripherals. This is a wireless communication stack. You don't expect SPI support from TCP/IP stack, do you?

Take the datasheet for atmega1281 and read how to program USART module in SPI mode.

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, I understand.

// Put your application code here

From a memory viewpoint, what is the footprint of this stack?

Thanks

Asking a better question, is the beginning of learning.
**********************
New Hardware Hackers SIG in San Diego, CA Meets 2nd. Tuesday, more info www.Spincraft.com
***********************

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here are few numbers

size:
   text    data     bss     dec     hex filename
   3960       0     322    4282    10ba Debug/Template.elf
   3960       0     322    4282    10ba (TOTALS)

and

size:
   text    data     bss     dec     hex filename
   7764      12    1456    9232    2410 Debug/WSNDemo.elf
   7764      12    1456    9232    2410 (TOTALS)

This is a size of the stack + application code. In case of template application there is no code, but not all functions from the stack are used as well. So stack itself is somewhere in between.

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
From a memory viewpoint, what is the footprint of this stack?

From the very first post in this thread:
Quote:
Small footprint (less than 8kB of Flash and 4kB of RAM for a typical application)

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

silly me, sorry (:?)

Asking a better question, is the beginning of learning.
**********************
New Hardware Hackers SIG in San Diego, CA Meets 2nd. Tuesday, more info www.Spincraft.com
***********************

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thats great! i recently start playing with AVR+Wireless
and also join this forum

thanks Alex

From Idea To Invention

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there any possiblity to use LwMesh examples on Arduino plaform??

From Idea To Invention

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It should be possible to run them on ATMega32 with minor modifications, but not inside Arduino environment.

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

LwMesh might be a good topic for the Atmel Tech. on Tour series. What is the possibility of that happening?

Asking a better question, is the beginning of learning.
**********************
New Hardware Hackers SIG in San Diego, CA Meets 2nd. Tuesday, more info www.Spincraft.com
***********************

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is always a possibility, but I have not heard of any active preparations.

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alex, does LW mesh relies on any patents?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not to my knowledge.

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for the quick response, I had the same impression but I just want to ask. For sure it would be stated somewhere in the document or in the source code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alex:
There is any performance or benchmark tests for lwmesh?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What kind of benchmarks? It performs the way I would expect it to on a normal applications. I have not tried to push it to the limits - I'm not a big fan of pushing stuff to the limits and I've never seen actual requests to do so.

PS: But no, there are no formal benchmarks, because it is hard to benchmark wireless stack. It is mostly limited by the medium, not by the software.

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In the release notes it looks like only the 2.4GHz ZigBits are supported. Will lwmesh work with 900MHz zigbits?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are no projects for ZigBit 900, but it is very easy to make it work by changing projects for ZigBee 2.4 GHz to include rf212 PHY.

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What about the power consumption? Can all the node oparate with battery? Can all the nodes go to sleep mode?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, you can. Non-routing nodes are designed for this reason. You can have routing nodes sleeping as well, but it is application responsibility to keep track of when nodes sleep and when not so that network stays operational and no nodes required for routing are asleep.

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
It should be possible to run them on ATMega32 with minor modifications, but not inside Arduino environment.

Just out of interest, why do you think it is not possible to port LwMesh to arduino environment?

They both use a form of cooperative multitasking, so in theory it should be possible to write a C++ wrapper class for the LwMesh C code. Then replace HAL with Arduino calls for uart/spi etc?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If amount of work required is fine with you, then it is possible to run LwMesh on Arduino.

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It looks like each node needs to have a unique 16 bit address. Is there any way to auto assign addresses or is it the responsibility of the application to ensure unique addresses via special programming, switches, etc? Is there any way to take advantage of a Maxim DS2411 chip that automatically provides a unique 64 bit address?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Application should take care of address assignment, there are no mechanism defined by the stack. Depending on the complexity of your application it might be as simple as assigning a random number.Just make sure it is truly random, otherwise all devices will pick the same address. Using UID chip value to seed random number generator is one way of doing this.

Another way is to simply take lowest 15 bits of the UID value and assign it to the address.

If your application is complex and you need to make sure that there are no conflicts, you'll have to implement some kind of centralized database and make one device assign addresses to everyone else.

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In uracoli we use a technique for address assignment, that uses
the last 16 Byte of the bootloader section to store information like addresses, default channel, default pan id. The memory at the end of the bootloader is a more secure place then the eeprom, unless you flash with an external programmer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there any way to detect address conflicts? Will the stack deliver a message to the application layer if the source address matches the destination address?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a test application that is working fine without security. After I enable AES security my receive data handler is still called, but now the NWK_DataInd_t.size is 4 bytes larger than expected and NWK_DataInd_t.data contains random values. Do I need to call some stack functions to explicitly encode and decode packets?. I enabled AES security on my RF212 using

#define NWK_ENABLE_SECURITY
#define SYS_SECURITY_MODE 0
NWK_SetSecurityKey("TestSecurityKey0")
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not sure if you're still checking this thread, dcraw, but here's my answer to your question.

I am somewhat new to the LwMesh stack, so would appreciate it if someone else (AlexRu) comments if I am wrong.

I believe the four extra bytes are the MIC (Message Integrity Code). See section 4.1 on p. 9 of AVR 2130 for a reference to the optional MIC. It is optional in the sense that it is only there if encryption is enabled.

I am not sure how to decode the MIC, or even if we are supposed to. Is it some sort of checksum that we can unroll to verify the message was received intact?

“Science is not consensus. Science is numbers.”

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dcraw101 wrote:
Is there any way to detect address conflicts? Will the stack deliver a message to the application layer if the source address matches the destination address?
For some reason I did not receive notification for this question even tough I'm watching this thread.

There is no way to detect conflicts using only the stack itself. If conflicts are possible, then you need to include some unique value (UID) in the message and check pair (UID, Addr) on the application level.

Messages addressed to self will not be delivered.

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dcraw101 wrote:
but now the NWK_DataInd_t.size is 4 bytes larger than expected and NWK_DataInd_t.data contains random values.
This is a bug. Message Integrity Code (MIC) is checked by the stack and should be stripped from the message before indication.

As a workaround, just ignore last 4 bytes of encrypted messages.

dcraw101 wrote:
I enabled AES security on my RF212 using

#define NWK_ENABLE_SECURITY
#define SYS_SECURITY_MODE 0
NWK_SetSecurityKey("TestSecurityKey0")

This should be enough.

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hobbss wrote:
I am not sure how to decode the MIC, or even if we are supposed to.
It is not to be interpreted by user, stack checks it automatically.

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Alex, I just downloaded the March version of the Lightweight Mesh Software Stack v1.0.1.
I have been playing around with the STK-600-Atmega128RFA1 and Bitcloud but manipulating the GPIO is very cumbersome and slow (ADC, IRQ's etc...)
My first impression is that the mentioned ready to use binaries to start testing are not in the zip file.
Am I missing some other download that I should be aware of?
Thanks,

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah, they are not there. The truth is, I forgot to put them into v1.0.0 and only noticed this when I was preparing v1.0.1. And since nobody asked for them all that time, I decided not to include them this time.

It is very easy and straightforward to compile them from the project,

Kudos for reading the document though :)

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll do that. I was just afraid I could be missing something else.
Thanks for your incredible quick response :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi again.
Quick question, do you have any document or set of building recommendations that would help me mix LwMesh with your ASF 3.7.3 lib using AS 6.1 and STK600-AtMega128RFA1?
Thanks,

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The easiest way is to create an ASF project, then add all LwMesh files and definitions. It is a bit messy, but it works, I've tried.

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, I'll try it that way. I want to take advantage of all the HAL stack already built into ASF, especially ADC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Alex,
I have a few questions about the LwMesh. I was under the impression that I would be able to just program the boards with the Peer2Peer solution provided, and just change a few parameters to achieve a wireless UART configuration. After testing this, it is proving to be more difficult. I have tested two atmega128rfa1 dev. boards with attached incoming RX and TX lines. It seemed communication was not correctly made, and I tried programming a few different ways:
within config.h:
-one board is coordinator, other is router
-one board is coordinator, other is end point
-both coordinators
-differing PanIDs for the devices
-same PanIDs for the devices
-set HAL_UART_RX_FIFO_SIZE and TX to 1, to hopefully just send the data as it is received
within haluart.c:
-set 2 stop bits
within fuse settings:
-0xFE,0x9D,0xC2 (Extended,High,Low)
-0xFE,0x91,0xE2 (Extended,High,Low)

Sorry to overload you with information, but I figure I'm better off giving as much detail possible. Sorry I have no experience with networking, and am still familiarizing myself with micro controllers. Do you think LwMesh is a good choice for our UART to Zigbee needs?

Thank you for any help you may provide!

Edit: Also, I just noticed there is a newer version of the LwMesh (1.0.1). I will have to test that in the next few days, because I have been using 1.0.0.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All you need to start with P2P application is set APP_ADDR to 0 for the first device and to 1 for the second. Don't change anything else and it should work as you would expect it to. Once you get it working, you may start tweaking parameters to better suit your needs.

I don't remember numerical fuse setting off the top of my head, correct ones should be in the documentation. Basically you need to make sure that devices runs at 8 MHz internal RC oscillator and CKDIV8 is disabled.

LwMesh is not ZigBee, so if you need ZigBee connectivity, then it is not a right choice. If proprietary wireless protocol works for you, then LwMesh might be a solution you are looking for.

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you very much for the speedy reply Alex! I will have to debug our boards a little more to make sure all components are working as expected, and test it out some more. I will report back if there are still issues or questions.

Pages