Atmel Lightweight Mesh stack

Go To Last Post
566 posts / 0 new

Pages

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

Ah, you also on a slow radio.

I would say random delay 0-80 seconds would help a lot. If your devices are assigned sequential addresses, then I would simply use device address as delay in seconds. This way they all will line up nicely.

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:
then I would simply use device address as delay in seconds. This way they all will line up nicely.

That's genius, I could avoid rand()

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

Hi Alex

Recently I had a problem where a particular Router node , a sleeping node and Coordinator Node, were just hanging in some loop , did not have debugger plugged so do not know where.

This was noticed after my area had a main power cut

My configuration is shown below,

“C” represents the node acting as the Coordinator. SN is the sleep node. And R as Router

Quote:
R1 --> R2--> C
SN1-->C

All nodes apart from R2 have a backup battery. R2 connects to the mains power via a DC power plug.

I am not sure if my theory would be correct, but please advise me on this…

If I am correct that on the application layer when you a message is being Tx, there are some intermediate message being sent before the actual message gets TXed e.g. routing message etc .

If during these intermediate a Router node passing a message was to lose its power, can it leave other nodes associated nodes hanging , as those nodes could be in some waiting state.

In my case if a messages was sent from R1 ->R2 -> C. And R2 was to lose power during intermediate message stage could it cause an issue to what I am experiencing?
A sleep node was also looped, maybe it’s also TX a message at the same time and was locked in some state as well.

Everything is working fine such issue, but wanted to know if my theory of the power loss could have caused this?

Thanks

Regards

DJ

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

I won't even read this unless you create another thread. This is a last warning.

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 won't even read this unless you create another thread. This is a last warning.

Ok this in regards to the same stack, but an ways i will create an new thread.

Thanks

Regards

DJ

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

Atmel has 3 or 4 stacks. It does not mean that there should be only 3 or 4 topics. Separate topics should be created for separate issues.

Also, quote from the first post of this topic:

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

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

ok,new post just created

Thanks

Regards

DJ

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

Hi !

 

In LW_Mesh,  channel and txpower, can they be changed on run-time(actually at any time) or they can only be set on start-up?

 

I use functions :

 

 PHY_SetChannel(channel);
PHY_SetTxPower(tx_power);

Thnak you !

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

Yes, they can be changed at any 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

I am running lightweight mesh on an AtmegaRFA1.  I have been trying to figure out why these devices occasionally hang and I finally caught one in the act.  It is stuck in the first while loop because the TRX_STATUS_REG never goes to TRX_STATUS_TRX_OFf (8).  It is always TRX_STATUS_PLL_ON (9).  Any ideas?

 

static inline void phyTrxSetState(uint8_t state)
{
  TRX_STATE_REG = TRX_CMD_FORCE_TRX_OFF;
  while (TRX_STATUS_TRX_OFF != TRX_STATUS_REG_s.trxStatus);

  TRX_STATE_REG = state;
  while (state != TRX_STATUS_REG_s.trxStatus);
}

 

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

mikewilt wrote:

I am running lightweight mesh on an AtmegaRFA1.  I have been trying to figure out why these devices occasionally hang and I finally caught one in the act.  It is stuck in the first while loop because the TRX_STATUS_REG never goes to TRX_STATUS_TRX_OFf (8).  It is always TRX_STATUS_PLL_ON (9).  Any ideas?

 

static inline void phyTrxSetState(uint8_t state)
{
  TRX_STATE_REG = TRX_CMD_FORCE_TRX_OFF;
  while (TRX_STATUS_TRX_OFF != TRX_STATUS_REG_s.trxStatus);

  TRX_STATE_REG = state;
  while (state != TRX_STATUS_REG_s.trxStatus);
}

 

On which state is it when it's stuck?

If it's on SLEEP state, it won't work.

 

By the way, shouldn't you have created a new thread?

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

I thought it would make sense to create a new thread but didn't see how.  This web site is different than the last time I used it.

 

It looks like this function is being called from the phy task manager and it is trying to force the transceiver to a particular state by first turning it off.  I also see an ISR that may set this register to PLL_ON.  My working theory is that the ISR ran between the line that turns it off and the line that waits for it to be off.  I am trying a version that protects this code as a critical region.

 

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

I've never seen this, but I've seen code like this:

do
{
  TRX_STATE_REG = TRX_CMD_FORCE_TRX_OFF;
} while (TRX_STATUS_TRX_OFF != TRX_STATUS_REG_s.trxStatus);

There might be a reason for this.

 

But again, I've never seen this happen before and I've never sen reports of anything like this.

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

It looks to me like that would work.  Even if an ISR changes the state or the hardware doesn't respond the first time it would keep poking until the transceiver reports being off.  I noticed that this particular function did not change at all in the latest lightweight stack release.  It looks like a hazard, and I caught it hanging there once, but it doesn't look like other people have had this problem.

 

 

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

By the way what is the max message payload size?

Thanks

Thanks

Regards

DJ

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

NWK_MAX_PAYLOAD_SIZE for not secured unicast and broadcast messages.

For multicast subtract NWK_MULTICAST_HEADER_SIZE.

For encrypted messages subtract NWK_SECURITY_MIC_SIZE.

 

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 alexru.

 

I played with ZigBit modules a couple of years ago, but found them a bit difficult to work with. Very good structure with callback functions etc, and really understandable. But difficult to start a project from the scratch, so someone should start a project, by editing WSNdemo or LowPower etc. There wasn't a template (blank project) to start with. Also what I didn't like was the fact that I had minor control of the code, I was writing code on application layer and everything else was hidden. I couldn't follow the code flow easilly. Finally those xml files or makefiles was a pain in the ***, because i was not familiar with GCC. My question is: from simplicity point of view, is LwMesh improved, compared to BitCloud?

 

Thanks.

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

OL_EL wrote:
My question is: from simplicity point of view, is LwMesh improved, compared to BitCloud?
Most of the things you mention are improved. But LwMesh and BitCloud are very different stacks, so you might find new problems.

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 all !

 

Can someone explain what is the difference between :

 

 NWK_NO_ACK_STATUS                       = 0x10

 

and

 

NWK_PHY_NO_ACK_STATUS                   = 0x21

 

 

Thank you !

 

 

 

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

xtal_88 wrote:
Can someone explain what is the difference between :

 

Repeat reply, the old one ended up in some forum black hole.

 

NWK_PHY_NO_ACK_STATUS means that the frame was not acknowledged on a hardware level by the first hop in the route. Essentially this means that the frame was not sent, except for rare cases when the frame is sent, but the ack was not received due to some interference.

 

NWK_NO_ACK_STATUS means that the frame was not acknowledged on a network level, meaning that the entire multi-hop transaction is failed.

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 already use this stack with the original zigbit modules.

 

We are designing a new product with the new ATZB-S1-256-3-0-U. Is there support directly for this module with V1.2.1 ?

 

If not what is involved in porting to support new module, as it has integrated micro and phy ?

 

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

I think that would make more sense as a new thread - with an appropriate title.

 

*Maybe so, but the split facility is broken, so until it is fixed it will have to stay here. Sorry. Ross*

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Mon. Feb 23, 2015 - 11:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But nothing to stop pat180269 creating a new thread, and providing a link to it form here...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just a quick question about CRC. It looks like the stack never checks to see if the CRC flag (RX_CRC_Valid) is set or not. Is there any reason the CRC isn't used to determine if a packet is valid or not? or am I just missing it in the code?

 

Thanks!

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

The stack is using the radio in a mode where broken frames will not be indicated, so no need to check CRC flag, it will always be true.

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

Last Edited: Fri. Feb 27, 2015 - 12:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

Have one (silly?) question about lightweigh mesh.

 

In case I only need to have a star network topology, is it a way to optimise the transmission (time and power consumption) for the emitter by setting/modyfing some option/parameter?

 

Tell me if this question is not clear enough!

 

Thanks!

 

BR

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

Just disable routing. No route discoveries will be performed and all devices will be assumed to be within direct link range.

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

Has anybody ported Atmel Lightweight Mesh protocol stack to any non-Atmel SOC?

alexru, whit who I am supposed to talk about licence-policy for porting Atmel Lightweight Mesh to non-Atmel platforms?

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

Licensing - see: https://www.avrfreaks.net/comment...

 

The licence specifically prohibits use on a non-Atmel MCU - so you could, in principle, use it on a non-Atmel radio but with an Atmel MCU...

 

But I would also be interested to know who to ask about these issues...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Alex,

 

You can send me the version 1.1.1 of lwmesh, I need to bootloader OTA and can not find it on the internet

thanks

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

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

akla wrote:
alexru, whit who I am supposed to talk about licence-policy for porting Atmel Lightweight Mesh to non-Atmel platforms?
I would create a support ticket. I think that as long as you are using Atmel radio you are OK, by I'm no lawyer.

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: 1

ariandres wrote:
You can send me the version 1.1.1 of lwmesh, I need to bootloader OTA and can not find it on the internet
  Attached.

Attachment(s): 

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 to all! I just stumbled upon the lightweight mesh stack and think this is exactly what I need for a good wireless serial connection. Unfortunaltely I developed the last years only with Bascom and only decided some weeks ago to change for C++ and Atmel Studio so sorry for asking beginners questions.

I loaded the Leightweight Mesh 1_2_1 and took the example Rcb231_ATmega_Rf231. My MUC is ATmega32 and my RF is ATRF231. As far as I understand things I have to adapt the hal layer which contains several includes and sources. The pin declarations however I found in iomxx0_1.h Is ist right that I only have to add the atmega32 to the declarations there? What other types of modification have to be done? I remembered reading that Alex mentioned the stack should run with minor changes on mega32.

Thanks a lot to point me in the right direction!

Olaf.
 

problems are not only just expected... they are welcome!

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

You really should not start learning C programming with LwMesh, you will waste a lot of time. Start from simpler projects.

 

You should not touch iomxx0_1.h. All you need to do is select the right MCU in the project settings and the right header file will be included automatically. Now you need to go into HAL and change definitions for your radio SPI and GPIO pins.

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, firstly thank you for sharing your precious time to answer questions and help out in this forum!!!

 

Surely you are right, I had only two small test projects written by myself before I went into copy/paste/edit .

Nevertheless I am used to "cold water jumps" and your hint was very helpful.

Will test it and work my way through it...

 

Thanks a lot from Portugal

 

Olaf.

problems are not only just expected... they are welcome!

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

Hi, I have a question about the stack:

 

After setting up an endpoint like so:

   NWK_OpenEndpoint(APP_ENDPOINT, appDataInd);

 

And after a packet comes in, this function is called:

    static bool appDataInd(NWK_DataInd_t *ind) 

 

Question:  is  *ind always the same memory address, always different, or neither?

Question:  when does *ind get freed?

 

What I'm getting at is that I want to create a queue or list of received packets, and I want to do this with the least number of malloc's and memcpy's.

 

Thanks a lot!

 

 

 

 

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

steve_at_odi wrote:
Question:  is  *ind always the same memory address, always different, or neither?
It is allocated on the stack, so it will be the same for the same program, but really unpredictable.

 

steve_at_odi wrote:
Question:  when does *ind get freed?
As soon as indication function returns. You need to get anything you want to save out before returning.

 

steve_at_odi wrote:
What I'm getting at is that I want to create a queue or list of received packets, and I want to do this with the least number of malloc's and memcpy's.
You can use static buffers, but you will have to copy the data.

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, you're the man Alex!

 

that was my guess, I saw that there was a NWK_DataInd_t allocated on the stack and then its address is passed to another function.  Never seen that before haha.

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

Split into separate thread. Please create separate threads for debugging issues.

Last Edited: Tue. Jun 16, 2015 - 12:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

I'm working at WSN demo application, I really don't understand how the software timers work, for example the appNetworkStatusTimer I use this configuration:

 

  appNetworkStatusTimer.interval =6; //  default 500 //
  appNetworkStatusTimer.mode = SYS_TIMER_PERIODIC_MODE;
  appNetworkStatusTimer.handler = appNetworkStatusTimerHandler;
  SYS_TimerStart(&appNetworkStatusTimer);

 

by the LWmesh protocol this means that every 6ms the timer handler is called right? but I don't understand how it counts, is it like an interrupt? Something is decremented like a timer counter?

Thanks a lot 

Hello everyone,

I'm an italian student and I'm working for my master work with the ATmega128RFA1 microcontroller. Hope you can help me and sorry for my english :)

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

Why not look line the source code then? Software timers run from a single hardware timer. By default hardware timer is set up with 10 ms interval, so all software timers have granularity of 10 ms.  So 6 ms interval will actually be 10 ms (or 0, the rounding is not guaranteed).

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 alexru,

I watched (better) the source code and it seems that all the timer intervals are decremented of 10 when setted. So setting timer with values under 10 or not-multiple of 10 has no sense right?

 

Hello everyone,

I'm an italian student and I'm working for my master work with the ATmega128RFA1 microcontroller. Hope you can help me and sorry for my english :)

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

That is correct. All events will happen on 10 ms boundaries, no matter what the timer interval is.

 

You can decrease 10 ms to 1 ms, for example, at the expense of higher CPU load, of course.

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 want to experiment with a very simple routing algorithm, and I am wondering if I can do this by only changing the NWK_RouteNextHop function to the following:

 

uint16_t NWK_RouteNextHop(uint16_t dst, uint8_t multicast)
{

    if( dst > nwkIb.addr )

       return nwkIb.addr + 1;

    else if( dst < nwkIb.addr )

       return nwkIb.addr - 1;

}

 

Do I have to create a static routing table or would this bypass the routing table, ie. the searching of the routing table?  Would this bypass the native route discovery that does the broadcast messages, sets up a reverse path, etc?

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

Yes, this will work and will route things along the line.

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

awneil wrote:
Licensing - see: https://www.avrfreaks.net/comment...

 

The licence specifically prohibits use on a non-Atmel MCU - so you could, in principle, use it on a non-Atmel radio but with an Atmel MCU...

 

More on licensing: https://www.avrfreaks.net/comment...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Alex, is it possible for a device to send a NWK_DataReq to a device's own address?  Like a HTTP request to localhost.

 

I have an a SAMD20 I2C slave, which takes all I2C packets  and simply passes the data into a NWK_DataReq_t and does NWK_DataReq().   The first byte of the I2C is used as destination address, the rest is payload.

This SAMD20 is  NWK_ADDR 0x0000

 

It's great, except when I want to send data to this particular device, NWK_ADDR 0x0000.  This is particularly critical for joining the first other device to the network.

Sure I could add more I2C code to recognize that the packet is to be processed and not put into a NWK_DataReq_t.  

But I would like to keep the I2C-to-NWK_DataReq module super simple.  So what I want to do is send an I2C packet with the first byte = 0x0000.  This would result in a NWK_DataReq_t with dstAddr = 0x0000;  Then I can get at the payload inside of a DataInd() callback.

 

At first this didn't work because there was nothing in the routing table, and 0x0000 was trying to broadcast for route discovery.  so I added this to nwkRouteInit()

    nwkRouteTable[0].dstAddr = 0;
    nwkRouteTable[0].fixed = 1;
    nwkRouteTable[0].nextHopAddr = 0;

 

But it still doesn't work; now, NWK_ADDR 0x0000 tries to send to 0x0000 4 times and gives up.  I can see that in these packets, MAC Src = MAC Dst = NWK Src = NWK Dst = 0x0000.  I tried setting the option NWK_OPT_ACK_REQUEST, still nothing.  The DataInd() is not getting called.

 

I'm stuck!  Any ideas?

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

No, there is absolutely no internal routing of any kind. The only frames that have a chance of being indicated to the application have to come from outside.

 

You can add this logic either on the application level (where it really belongs) or inside the stack.

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 may have found a serious security issue with v1.2.1 when using XTEA. The end result is that not all of the data is encrypted, and much data is sent plain-text. The issue is in SYS_EncryptReq(). "text" is a uint8_t, and so the call to xtea(&text[2], key) does not encrypt the last 64 bits of data as expected. The calls to swap around the text before this are also not working as intended. "text" must be typecast to a U32 to correct this issue.

 

This is a regression in v1.2.1 as v1.1.0 worked correctly.

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

timali wrote:
I may have found a serious security issue with v1.2.1 when using XTEA.
XTEA encryption should really be removed altogether. It was only added because RF230 has no AES module. But RF230 is not relevant any more.

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

Pages