Atmel Lightweight Mesh stack

Go To Last Post
566 posts / 0 new

Pages

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

The problem here is Cortex-M3 processor. There is no native support for it in the SDK.

However I did run LwMesh on Cortex-M3. In that case I just created an ASF project and added LwMesh files to it. It worked fine, but it is obviously more involved process.

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

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

Thanks for a speedy reply.
I'll start with simple - RCB128RFa1...
But eventually, I would like to make it run on deRFusb... Glad to hear that it is doable.

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

What is Tester application is about?
Does it allow to prepare the LM stack commands on PC and then to send them to LM mesh? In other words, does in some kind of UART<>LMesh gateway?

And how exactly the frame is serialized being sent over UART? ( Yes, I know it is possible to get from the state machine code... ;)) But may be there is a prepared doc somewhere ( and I just one download away...))?

Thanks.

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

ma5645 wrote:
What is Tester application is about?
Does it allow to prepare the LM stack commands on PC and then to send them to LM mesh? In other words, does in some kind of UART<>LMesh gateway?
Correct. It just exposes all stack APIs via serial port.

ma5645 wrote:
And how exactly the frame is serialized being sent over UART? ( Yes, I know it is possible to get from the state machine code... ;)) But may be there is a prepared doc somewhere ( and I just one download away...))?

There is no documentation for it. It is mostly an internal tool used in automated testing.

But it is very simple and very well illustrated by appUartSendCommand(). Frame is formatted like this: <1 byte start symbol = 0xa5> <2 bytes size> <2 bytes CRC>.

Commands and their structure is described in the commands.h file.

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

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

alexru wrote:
...Frame is formatted like this: <1 byte start symbol = 0xa5> <2 bytes size> <2 bytes CRC>.
....

Perfect, thanks!

Was it tried on any kind of 'usb stick hardware'? ( I know I asked before about deRFusb... ) But may be there is any other usb + atmel RF hardware around?

Michael.

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

Not that I know of. With new ZigBit USB stick out there might be something at some point in time, but not right now.

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

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

alexru wrote:
...I did run LwMesh on Cortex-M3. In that case I just created an ASF project and added LwMesh files to it. It worked fine, but it is obviously more involved process.

I started to work on 'porting' Lightweight Mesh to run on deRFusb23e06. The progress so far:
- It looks like I can create and compile the ASF project for studio 6.1. But that project is generated for sam3s_ek. I wonder what are the major differences between sam3s-ek and deRFusb23e06 hardware...
- Failed to find schematics for deRFusb23e06... ;( In attempt to understand the differences, I downloaded Bitcloud1_14 for Sam, and then bitcloud addon from Dresden Elektroniks... The intention was by looking on BSP & HALL code to figure out the proper board initialization... Probably, it will compensate the absence for schematics... But it is ' a long shot'...

- It looks like the low-level structure of the code is different between BitCloud and Lightweight Mesh:
in BitCloud, the board is actually 'described' within BSP and HAL code.
In LMesh, each board seems to be covered in HAL code. Also, it seems that the code structure is even more streamlined within HAL structure. It makes it easier (then BT code) to read and to follow. More difficult to compare. ;)
The fact that BitCloud still using Studio 4, while LMesh - 6.1 --- definitely adds fun to the exercise. ;)

The reason I wrote above -

a. May be somebody already went through the exercise, and would comment.
b. May be somebody can see a big 'obstacle' on that way.
c. May be somebody knows the source for schematics on deRFUSB23e06 board. Would be a great help!

All advice, help, suggestions -- would be highly appreciated!

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

ma5645 wrote:
- It looks like I can create and compile the ASF project for studio 6.1. But that project is generated for sam3s_ek. I wonder what are the major differences between sam3s-ek and deRFusb23e06 hardware...
Probably negligible, if you are not using board-specific stuff. But ASF always makes it hard to decouple it, so who knows.

ma5645 wrote:
- Failed to find schematics for deRFusb23e06... ;( In attempt to understand the differences, I downloaded Bitcloud1_14 for Sam, and then bitcloud addon from Dresden Elektroniks... The intention was by looking on BSP & HALL code to figure out the proper board initialization... Probably, it will compensate the absence for schematics... But it is ' a long shot'...
Technically all you need is pin locations for the transceiver. In BitCloud they all are localized in the HAL layer.

ma5645 wrote:
- It looks like the low-level structure of the code is different between BitCloud and Lightweight Mesh:
in BitCloud, the board is actually 'described' within BSP and HAL code.
In LMesh, each board seems to be covered in HAL code. Also, it seems that the code structure is even more streamlined within HAL structure. It makes it easier (then BT code) to read and to follow. More difficult to compare. ;)
The goal of LwMesh was not to include anything board-specific at all. It is not really possible, so there is some stuff that just has to be somewhere. And BSP never made any sense to me in a first place.

ma5645 wrote:
The fact that BitCloud still using Studio 4, while LMesh - 6.1 --- definitely adds fun to the exercise. ;)
There are projects for AS6.1 in BitCloud, but they still use the same external Makefile.

ma5645 wrote:
c. May be somebody knows the source for schematics on deRFUSB23e06 board. Would be a great help!
Ask DE support?

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

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

DE support was my first attempt.
Actually, they do provide the document, with tables for PIN allocation, etc. Together with their code -- it is enough to verify the PINs and connections. I just found it a bit less convenient then schematic. And in the past -- RCB128.... -- DE was providing both -- docs & schematics...

Looked more in ASF...
I wonder -- should I keep the ASF structure ( like they have the portion of files for CPU aka sam3s, then the particular board... aka ...-ek1) or, just make some init funciton based on BTCloud for Dresden and call it...
Looks like if ( when ?) I managed to finish it -- I'll be an expert... ;)

What would be the recommended debugger for the sam3s? ( Dragon served me well on Mega board... was practical...). Is it SAM-ICE for sam3s? Is there something even simpler?

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

ma5645 wrote:
I wonder -- should I keep the ASF structure ( like they have the portion of files for CPU aka sam3s, then the particular board... aka ...-ek1) or, just make some init funciton based on BTCloud for Dresden and call it...
That is up to you. For LwMesh to work you need to assign GPIO pins, provide SPI access functions and an interrupt handler.

ma5645 wrote:
What would be the recommended debugger for the sam3s? ( Dragon served me well on Mega board... was practical...). Is it SAM-ICE for sam3s? Is there something even simpler?
I've only used SAM-ICE, it works just fine, but I can't say how it compares to anything else.

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

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

Hi Alex.

Currently I have running LWMesh in modules ATZB-A24-U0 but these are out of the market, are there plans to implement LWMesh in modules ATZB-X0-256-3-0-C (ATxmega256A3U and AT86RF233)?, do you I recommend using BitCloud?.

thanks

ari@ari-K55A:~$ man woman
No manual entry for woman

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

No, don't use BitCloud.

There are plans to make a port, there is no concrete date. I will try to add support in the next release, which is supposed to be fairly soon.

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

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

Thanks, I appreciate it a lot

ari@ari-K55A:~$ man woman
No manual entry for woman

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

I can confirm that ATZB-X0 will be supported in the next release. I have it running on my desk right now. The port was very easy.

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

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

wonderful, I already ordered development kits

ari@ari-K55A:~$ man woman
No manual entry for woman

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

Am I understanding the recent posts correctly - that the new line of ZigBits (and specifically the ATZB-S1-256-3-0-C) will be supported directly with the next version of LwMesh?

Also, is there an ETA on when dynamic addressing will be released? I'm waiting on a host board to be printed (will arrive in a couple weeks), and I'd like to know if I should just try and roll my own or wait for the next LwMesh release.

Thanks!

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

S1 has an ATmega256RFR2 inside, there is nothing to support. Take any project for ATmega256RFR2 and just use it.
X0 will be supported out of the box.

No ETA, it is not a part of the next release.

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

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

Is it possible to use the random number generate with 64-bit a seed. This way, my main unit which gives all other device there short address can establish it own unique PANID to insure that there is no confusion with any of my other main units near by?

Thanks

Regards

DJ

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

It is physically impossible to uniquely compress a set of 64-bit numbers to a set of 16-bit numbers. If I understood the question correctly.

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

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

Hi Alex,

We tried to duplicate the Atmel AT03755: Android demo application to control IEEE 802.15.14 devices. The gateway is working (can see listed on the router). The gateway is an Xplained pro connected to a Wiznet 5200 Quickstart board, using your package SW with the ports modified. Also programmed the Xplained Pro board as a device (cannot test it yet).
However, we are having trouble compiling and building the Android application for the Atmel Gateway project. Setting up Apache Ant with SDK, JDK and all those little details proved to be a problem so far. We are trying to do an alternative way that would also be useful later.

We tried to send UDP message from a PC (and a raspberry Pi) instead of from Android, but not sure we have the addressing (or handshaking) and message format correct. Do you have an example ASCII string we can send to make sure our format is correct? Also do we have to modify the “preferred port” and “preferred IP” in the code if the Android isn’t there?

Finally, what is the best way to watch the debug messages from the gateway? We tried through the EDBG interface, but with no luck.

Thanks,

Arpad

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

In theory you need to send a single UDP message containing only one character - "+" from a PC. This will add your PC address to a list of clients. After that all events will be send as UDP messages.

Debug messages are available on UART0, which is available on the XPro extension connectors. If you want to use EDBG interface, then you need to change UART0 to UART1 in apps\Gateway\util\debug.c (not a single change, but all the registers).

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

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

I want to implement a automatic Method for building up a star network. My idea is to attach a button on all devices for network search and initialization.
I would use a Coordinator with APP_ADDR 0 and he broadcast all messages in his own APP_PANID. The Enddevices sends only to the coordinator appDataReq.dstAddr = 0;
Does LWMesh support a Method to send the APP_PANID from the Coordinator to all Enddevices? If yes how does that works and what do i need to write in the congig.h and in the main.c files?

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

There is no embedded method to do this.

There is a way to send messages with broadcast PAN ID - just specify NWK_OPT_BROADCAST_PAN_ID in the request parameters. This method can be used to exchange information until real parameters of the network are known.

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

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

How does this method works exactly (on coordinator- and on the enddevices-side) and do I have to send it only till network parameters a send or can i let the coordinator send it all the time (maybe some enddevice will connect to the network in the future and will need the PAN ID).

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

Approximate plan:
1. Device sends a broadcast PANID (BPANID) request to scan networks around.
2. Coordinator receives the request and sends a BPANID response.
3. Device received this response and sends BPANID request to get a real PAN ID and a network address.
4. Coordinator receives the request and sends a BPANID response. At this point Coordinator might check if device is allowed on the network, etc.
5. Device receives a response and starts using newly received PAN ID and address.

After that they can communicate as normal.

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

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

1. setting as options NWK_OPT_BROADCAST_PAN_ID on both Coordinator- and Enddevice-sides and do i need other configurations (like NWK_IND_OPT_BROADCAST_PAN_ID) somewhere?
3. In the config.h file from the Coordinator i set a PAN ID which will be send to the Enddevices. Do i set then NWK_SetPanId(0xffff); on the Enddevices side?
5. What Address are the Enddevices get from the Coordinator or do i specify it somewhere? Want to give the Enddevices APP_ADDR > 0x8000.

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

amais86 wrote:
1. setting as options NWK_OPT_BROADCAST_PAN_ID on both Coordinator- and Enddevice-sides and do i need other configurations (like NWK_IND_OPT_BROADCAST_PAN_ID) somewhere?
No, NWK_IND_OPT_BROADCAST_PAN_ID is an indication option used to inform the recipient that received data was received though a broadcast PAN ID.

amais86 wrote:
3. In the config.h file from the Coordinator i set a PAN ID which will be send to the Enddevices. Do i set then NWK_SetPanId(0xffff); on the Enddevices side?
It will not hurt.

amais86 wrote:
5. What Address are the Enddevices get from the Coordinator or do i specify it somewhere?
You don't specify, you write entire code for the address assignment.

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

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

Hi, I'm writing a proposal to use LwMesh for a project. Phase 1 is to demonstrate LwMesh running on Atmel demo boards. Does anyone have a feel for the time required for a reasonably skilled engineer to bring up a network? The customer requirements are forcing us to use the ATXMEGAB1-XPLD in conjunction with the AT86RF212 boards from the RZ600 kit. Any pitfalls with this configuration?

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

This HW configuration is supported out of the box. If you have the hardware ready, it will take less than 10 minutes to get the demo application running.

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

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

I have the folowing settings in my config.h file:

#define APP_FLUSH_TIMER_INTERVAL  20

#define HAL_UART_CHANNEL          1
#define HAL_UART_RX_FIFO_SIZE     200
#define HAL_UART_TX_FIFO_SIZE     200

#define NWK_BUFFERS_AMOUNT                  3
#define NWK_DUPLICATE_REJECTION_TABLE_SIZE  10
#define NWK_DUPLICATE_REJECTION_TTL         3000 // ms
#define NWK_ROUTE_TABLE_SIZE                100
#define NWK_ROUTE_DEFAULT_SCORE             3
#define NWK_ACK_WAIT_TIME                   1000 // ms

What Paramaters do i need and which ones can i scale down to minimize memory footprint.
I am using a 1-hop start-network and don't need routing , but maybe later security.
Longest UART_Message could have 32symbols. Should i set then HAL_UART_XX_FIFO_SIZE to 32?

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

Yes, you can reduce FIFO sizes. You can also reduce NWK_ROUTE_TABLE_SIZE to 2 or disable routing entirely.

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

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

Quote:
Yes, you can reduce FIFO sizes. You can also reduce NWK_ROUTE_TABLE_SIZE to 2 or disable routing entirely.

So i don't need

#define NWK_ROUTE_TABLE_SIZE                100 
#define NWK_ROUTE_DEFAULT_SCORE             3 

when routing is disabled or?

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

You may leave them as is, if routing is disabled, they won't be used.

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

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

What is the specific formula for calculating LQI and RSSI used on the AT86RF231 transceivers?

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

There is no formula. RSSI is quite literally a strength of the received signal (in dB above base level of -100 dBm).

LQI is just a number in the range 0-255 that is taken directly from the correlator output.

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

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

Hi

Am I correct to say that a APP_SECURITY_KEY is used after message has been received by a node in the network? Or would a message not get delivered to a node if its APP_SECURITY_KEY is not the same?

Thanks

Regards

DJ

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

Frame is delivered to a network layer. At that point encryption attempt is performed and if message integrity code does not match, then frame is disregarded.

Source node does not know if destination node knows correct key or not.

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

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

How do you insure a End Node does not route a message but only a node that is set a router does?

Thanks

Regards

DJ

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

Stack does not add a non-routing device as a next hop in the routing table. That's it.

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

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

I don't understand effects of

NWK_ENABLE_ROUTE_DISCOVERY

and

NWK_ENABLE_ROUTING

Thanks

Regards

DJ

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

NWK_ENABLE_ROUTING enables routing in general. Without it stack can only work in a direct mode.

NWK_ENABLE_ROUTE_DISCOVERY enables AODV route discovery algorithm, which replaces native route discovery algorithm. This option is meaningful only if NWK_ENABLE_ROUTING is enables.

The difference between the route discovery algorithms is described in the developers guide.

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

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

Hello,

I've upgraded to Studio 6.2 beta and ASF 3.15
LWMesh 2.0.0 is now included in ASF
What do I need to take into account when upgrading an existing project?

Thanks

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

I don't know why ASF version is v2.0.

Standalone version of the same stack will have a version v1.2.0. There are no major API changes, this is mostly a maintenance release.

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

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

Hi

Sorry for repeating the same questions again, I have just started re working on this issue.

I would like to introduce the same as Bitcloud, where a network transmission also depends on the Extended address(64-bit). Whereby if two nodes have same short address and pan id, only the node with the correct Extended address would receive the data.

Was this implemented on Bitcloud, very low level or somewhere high up?

For example there is two RX nodes and one node TX node.

Both RX nodes have the same NetPanID and Short address.

So if the TX node sends a message I presume both RX nodes will receive the data? Would this be correct?

But the first one to reply with an ACK will be the node that completes the communication?

If so can I can just place an IF statement stating if Extended address is the same then acknowledge the message.

But if Extended address is not the same , the if statement will insure that nothing happens on the top level, but must I do something at the lower transmission level.

For example if one node is at further distance then the other. If the wrong node gets the message first , what effect would it have on the right node getting a message and its ack message.

In short what I am trying to achieve is setting the wrong node to a mode as if it did not get any message at all.

Is it possible to do this?

E.g. If my node wants to join a network, via a node that acts like a cord. Can the cord just discard the message and ACT as if it did not get an message at all. So that if a cord with the correct Ext address is in range it the only node that does all the processing

Thanks

Regards

DJ

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

Hi Alex.
today on the website of Atmel saw LWmesh 1.2.0 was released with support for ATZB-X0-256-3-0-C, I will be testing this in the coming weeks.

I have a question, How many entries can I have in the routing table with 16K of RAM?

ari@ari-K55A:~$ man woman
No manual entry for woman

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

djoshi wrote:
I would like to introduce the same as Bitcloud, where a network transmission also depends on the Extended address(64-bit). Whereby if two nodes have same short address and pan id, only the node with the correct Extended address would receive the data.
There is no such feature in BitCloud. Two nodes having the same short address is an error in the network that will be resolved as soon as detected.

You can include extended address in the message payload and compare on receive. In this case I would send original message as a local broadcast, so you don't get HW acks from both devices at the same time.

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

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

ariandres wrote:
I have a question, How many entries can I have in the routing table with 16K of RAM?

Each entry in the routing table is 7 bytes. The rest depends on how much RAM you actually have left for the table. It is usually enough for any practical application.

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

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

Hi Alex,

read the new document
AVR2130: Lightweight Mesh Developer Guide

Lightweight should be support ATZB-X-233-xpro, am I right?
I really like the Xmega support 12bit AD, that is why.

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

LwMesh supports ATZB-X0-256-3-0-C and any board that is using this module, including ATZB-X-233-XPRO.

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

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

thank you Alex

Pages