Atmel Lightweight Mesh stack

Go To Last Post
566 posts / 0 new
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.

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. Oct 16, 2015 - 12:21 AM
  • 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?

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

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

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

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

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

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

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)?

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 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 :)

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

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

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

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

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

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

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.

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

Alex, does LW mesh relies on any patents?

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

Not to my knowledge.

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

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

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.

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

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

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

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

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.

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

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.

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

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.

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, 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 :)

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

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

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

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

Hi, Alex!
I'm trying to port our project to the lightweight stack.
But after examining Your sources I found out that there is no code in PHY part for managing TX_POWER for RFA1/RFR2.
I add code by myself, but I have one question:
Can I change TX_POWER at any time or only at time when there is no transmition... In the documentation nothing mentioned about this...
By default TX_POWER = 3dBm, but it is too much for our controller because we use LNA and its output power is 20 dBm with gain 20 dB...

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

You need to follow the same pattern as for the other parameters. Add a PHY_REQ_* flag, field in PhyIb_t and hangle the request in phyHandleSetRequests(). This will automatically make sure that the radio is in the correct state.

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!
Is it nesessary for You to get such patches of stack code?

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

Not really, at some point I'll add that code myself.

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 again Alex!
I now have peer2peer successfully running as a wireless UART, but am running into a slight inconvenience. The data seems to transmit in bursts. When downloading a file over the configuration, it is not a smooth fast download. It will quickly fill varying blocks, maybe 3-9% at a time, but then it pauses for around a second or more sometimes before doing the next block. I assume this is controlled by the HAL_UART_RX_FIFO_SIZE and TX values. I tried changing them to lower values, but that sometimes causes timeout errors.

Are these the right parameters I should be changing to solve this problem?
Is there any way to transmit the data as it is being received? (so basically just send byte by byte)

Thank you very much for any help you may provide!

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

One second delay is probably a missed ACKs and retries. You might decrease ack wait time in config.h, but you won't get totally smooth flow, sometimes frames get lost.

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

Although, I see that P2P does not use ACKs, so I have no idea where those delays come from. APP_FLUSH_TIMER_INTERVAL should be maximum buffering 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

Thank you for the speedy replies again!
I have tried a few different possibilities, but to no avail.
Am I correct in thinking that HAL_UART_RX_FIFO_SIZE in the config applies to the buffer to be filled before wireless transmission? For example, if I wanted a byte by byte transmission, sending each byte as it is received; I should just set both of these values to 1?

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

HAL_UART_RX_FIFO_SIZE is a very temporary buffer, it will rarely have more that 1-2 bytes. Data to be sent is stored in appUartBuffer, but it is flushed every APP_FLUSH_TIMER_INTERVAL ms.

If you want byte by byte transmission, then you'll have to change APP_BUFFER_SIZE, but it will make things much worse, it takes about 3-7 ms to send a frame, it will only be able to handle single key strokes.

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

Hm, OK. Thank you very much for your patience and help! I may have to see if I can figure out what is causing this. Again, thanks for the help!

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

I have a problem with the LightWeight Mesh stack hanging, please see this post for details:

http://www.avrfreaks.net/index.p...

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

Hi, Alex!
Last two weeks I tried to make OTA service working, but with no success...
I fall back to Your WSNDemo, but... nothing...
I tried many things. Made modifications in PHY level, reverse engeneer PHY part of bitcoud stack (by the way, phySetState there doesn't uses FORCE_TRX_OFF state. It issues FORCE_PLL_ON, and according to the documentation this will improve performance of the channel), and so on... But nothing helps...
But the last day, I found in NWK level that data request made from Ind callback is places in NWK frames queue before the ACK frame, and though is sent BEFORE ACK frame...
I.e.: Server sent START_UPGRADE packet and is waiting for ACK, but receive START_UPGRADE_RESP packet, which is filtered put, as state of OTAUs sever is not yet OTA_SERVER_STATE_WAIT_START_RESP...
I think, that code of TX state machine is to be modified. ACK frames must be processed first...

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

Hi Alex,

I found a weird behavior of the stack and don’t know what causes it. I guess it is related to the routing. Let’s have one sender and one receiver. The sender sends a packet (127B) every 100ms, no LwMesh ACK is requested. Everything goes well at this point.

However, when I interrupt a power source for the sender very shortly (300ms, say), the sender starts sending broadcasts - searching for the route to the receiver but the receiver stops react always for the same time (3 sec.). During this 3 sec. time receiver doesn’t answer by LwMesh ACK. How may I avoid it please?

Full size capture at http://goo.gl/2e3J1

Attachment(s): 

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

sleepy_warmcat wrote:
I tried to make OTA service working, but with no success...
What have you tried apart from very low level modifications? OTA should work as is, so the problem is not in the low level code. So can you describe step by step what have you tried?

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

vladacr wrote:
How may I avoid it please?

It is duplicate rejection table at work, your sequence numbers are reset back to 0 and receiver thinks that it receives duplicates. Change NWK_DUPLICATE_REJECTION_TTL to a lower value, so records expire faster.

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

Oh! I tried so many things, that I don't remember all of them...
But problem was very simple... NWK_MAX_ENDPOINTS_AMOUNT wasn't defined in config.h of OTAUServerDemo... :-)
But with modifications mentioned in previous post...

static inline void phyTrxSetState(uint8_t state)
{
  if (TRX_STATUS_PLL_ON != TRX_STATUS_REG_s.trxStatus)
  {
    TRX_STATE_REG = TRX_CMD_FORCE_PLL_ON;
    while (TRX_STATUS_PLL_ON != TRX_STATUS_REG_s.trxStatus);
  }
  if (state != TRX_CMD_PLL_ON && state != TRX_CMD_FORCE_PLL_ON)
  {
    TRX_STATE_REG = state;
    while (state != TRX_STATUS_REG_s.trxStatus);
  }
}

Of course, in that case we need to define timer with expiration time ~5min to initiate transition to TRX_OFF state
for recalibration to take place (according to documentation)
But I thing that it’s worth the cost as transition time from TRX_OFF state to TX_ARET_ON or RX_AACK_ON takes 110 us, but from PLL_ON to them only 1 us
and

    case PHY_STATE_RX_IND:
    {
      --- cut ---
      PHY_DataInd(&ind);

      while (TRX_STATUS_PLL_ON != TRX_STATUS_REG_s.trxStatus);
      CSMA_SEED_1_REG_s.aackSetPd = 1;
      TRX_CTRL_2_REG_s.rxSafeMode = 0;
      TRX_CTRL_2_REG_s.rxSafeMode = 1;
      phySetRxState();
      phyState = PHY_STATE_IDLE;
    } break;

CSMA_SEED_1_REG_s.aackSetPd = 1;
there is from Bitcloud stack
TRX_CTRL_2_REG_s.rxSafeMode = 0;
TRX_CTRL_2_REG_s.rxSafeMode = 1;
From documentation... to release buffer and to set protection again...
In addition in PHY_Init I add
HAL_RfRxTxIndicatorOn()
which is defined in halPhy()

void HAL_RfRxTxIndicatorOn(void)
{
#ifdef HAL_RF_RX_TX_INDICATOR
  PHY_RxTxSwitcherOn();
#endif
}

and PHY_RxTxSwitcherOn()
in phy.c

void PHY_RxTxSwitcherOn(void)
{
        TRX_CTRL_1_REG_s.paExtEn = 1;
}

and modification in nwkTxTaskHandler to force SERVICE_ENDPOINT frames to send first.
I can send it to You if needed...

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

alexru wrote:
It is duplicate rejection table at work, your sequence numbers are reset back to 0 and receiver thinks that it receives duplicates. Change NWK_DUPLICATE_REJECTION_TTL to a lower value, so records expire faster.
Thank you very much for fast response Alex!
You are right that lower value helps, but I am still not sure about proper behavior or I am just missing something.

I enclosing shorten capture, where you can see that another broadcast (searching for a route) occurs after 7 sec. and even though NWK_DUPLICATE_REJECTION_TTL is set to default 3000ms receiver still suppress it. NWK_DUPLICATE_REJECTION_TABLE_SIZE is 10. Packets are sended every 60ms.

Moreover, even if there was only one Broadcast (seq.1) at the beginning the receiver later suppressing 48 other Broadcasts (seq.2 - 49) at this case.

Full size capture at: http://goo.gl/rBvCO

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

sleepy_warmcat wrote:
Oh! I tried so many things, that I don't remember all of them...

110 us is very small value compared to frame transmission time and other code executing. Do you really need this optimization?

I don't have time right now to go over the code, especially with modification. Have you tried to run stock code? Does it work?

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

vladacr wrote:
I enclosing shorten capture, where you can see that another broadcast (searching for a route) occurs after 7 sec. and even though NWK_DUPLICATE_REJECTION_TTL is set to default 3000ms receiver still suppress it. NWK_DUPLICATE_REJECTION_TABLE_SIZE is 10. Packets are sended every 60ms.

Duplicate Rejection Table is not only for broadcasts, it is applied to all frames to prevent loops. In this case Seq=1 is lower than Seq=125 that receiving device remembers, so it rejects the request.

In theory when your counter will reach 126 (within 3 second time) that frame will be received.

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,

I got the WSNDemo ported to work on a new project using ASF in AS 6.1 with STK-600. I am trying to use the ASF driver/service for the UART so I took out all of LwMesh UART code and place the ASF.
My problem is that there must be some collision with the clock handling of ASF because if I run the initialization nothing works, and if I just skip the "sysclk_init()" LwMesh works perfectly but of course the UART output is garbled (I am using usart_serial_putchar() instead of HAL_UartWriteByte())
The init function is like this:
void sysclk_init(void)
{
#if !MEGA_XX_UN0 && !MEGA_XX_UN1
uint8_t *reg = (uint8_t *)&(POWER_REG_ADD);
uint8_t i;
/* Turn off all peripheral clocks that can be turned off. */
for (i = 0; i < NUMBER_OF_POWER_REG; i++) {
*(reg++) = 0xFF;
}
#endif
#if !MEGA_UNSPECIFIED && !MEGA_XX
/* Set up system clock prescalers if different from defaults */
if ((CONFIG_SYSCLK_PSDIV != SYSCLK_PSDIV_8) ||
(SYSCLK_PSDIV_8 != CLKPR)) {
sysclk_set_prescalers(CONFIG_SYSCLK_PSDIV);
}
#endif
}
Could you please point me into what could be colliding?

Thanks,

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

Update:

I changed CONFIG_SYSCLK_PSDIV to SYSCLK_PSDIV_1 and commented the part about turning peripheral clocks off (I did not understand what it has to do with power regulators) and it worked. The funny part is that the function sysclk_set_prescalers(psdiv) does not take into account the sent parameter. It always sets the divider to whatever CONFIG_SYSCLK_PSDIV is set to.

Thanks,

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

alexru wrote:
In this case Seq=1 is lower than Seq=125 that receiving device remembers, so it rejects the request.
I've got it now. So it means that the size of Rejection table is related to the number of nodes in my range.

However, there are still cases when the last received packet was e.g. Seq= 136 and the receiver does answer the following broadcast with Seq=1. But according to your reply 1 < 136. Capture here http://goo.gl/adBg2

BTW: Dont you know, Alex, what value of Duplicate Rejection TTL uses BitCloud? I'd like to compare these two systems in practise.

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

vladacr wrote:
I've got it now. So it means that the size of Rejection table is related to the number of nodes in my range.
Yes, sort of. If they all are expected to sent at about the same time.

vladacr wrote:
However, there are still cases when the last received packet was e.g. Seq= 136 and the receiver does answer the following broadcast with Seq=1.
That is because 136 > 128 :). There is tricky signed integer arithmetic used to define what sequence numbers are just rollover (255->0) and what is actual difference. If you want to know what exactly happens, have a look at nwkRxRejectDuplicate() in nwkRx.c.

vladacr wrote:
BTW: Dont you know, Alex, what value of Duplicate Rejection TTL uses BitCloud? I'd like to compare these two systems in practise.
BitCloud uses different methods for rejecting duplicate broadcasts and unicasts.

For broadcasts it is calculated using a lot of parameters, but for 2.4 GHz range and default network depth it comes to around 500 ms.

For unicasts there is no timeout, records just don't expire. But you don't normally notice it, because if you power of the device it actively rejoins (possibly with a different address), which creates a new record with seq=0.

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 Alex,
Now I am trying to setup Lightweight Mesh with RS-485 (Half Duplex). I am using an RS-485 breakout board to achieve this, but it must be triggered to let it know when to transmit or receive. I believe I must use a TXc (transmit complete) interrupt, to trigger from transmit back to receive. I do not know where I would put the other trigger, or if this will even work with how the Lightweight Mesh is setup. Any help would be greatly appreciated.
Thanks!

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

I've never worked with RS-485, but I'm assuming that you need to look at halUart.c file.

LwMesh is a wireless communications stack, it really has nothing to do with serial interfaces.

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

sofakingdom wrote:
Hello Alex,
Now I am trying to setup Lightweight Mesh with RS-485 (Half Duplex). I am using an RS-485 breakout board to achieve this, but it must be triggered to let it know when to transmit or receive. I believe I must use a TXc (transmit complete) interrupt, to trigger from transmit back to receive. I do not know where I would put the other trigger, or if this will even work with how the Lightweight Mesh is setup. Any help would be greatly appreciated.
Thanks!

Hey, I am also using RS-485 in my project with LightWeight Mesh. I would recommend to copy the UART library source used by LightWeight Mesh and modify that to make the flow control work with your RS485 driver.

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

Alex, I have a new issue with the LightWeight Mesh stack getting stuck again, just my luck :-). It is quite random, but it can run fine for a few thousand packet transmissions, then it gets stuck in the while loop of the function:

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

The state is 22 (TRX_CMD_RX_AACK_ON), and I believe the function is being originally called via phySetRxState() in the state PHY_STATE_RX_IND of PHY_TaskHandler().

I have no idea what the problem is, I tried atomically protecting that section of code because TRX_STATUS_REG_s is being modified in an ISR, but it did not help. Any insight would be appreciated.

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

Going through the stack, it's not clear where the variable TRX_STATUS_REG_s is being assigned? It's used in conditional statements in a few places, but I can't find where it's assigned any values, is it memory mapped?

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

You should check what is the value of TRX_STATUS_REG_s.trxStatus when it gets stuck.

TRX_STATUS_REG_s is a memory mapped register defined in atmega128rfa1.h.

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, TRX_STATUS_REG_s.trxStatus is set to 9 (TRX_STATUS_PLL_ON?) when it's stuck in the while loop.

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

What frequency your MCU is running at?

I'd start from checking that FORCE_TRX_OFF has finished:

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); 

If it does not, I don't even know what to do. This is the first time I'm seeing something 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

Thanks Alex. The frequency is 8 MHz, I'm running off the internal RC clock for the CPU. One thing to note is that I have several ISRs running in addition to the stack, Timer1, Timer3 and UART0/1 TX and RX. There are a lot of instances in code where I block interrupts (for short durations). Also, the ISR for Timer 3 takes about 500 uS to complete and is called every 2 ms, so significant CPU time is dedicated to it.

I will look into the FORCE_TRX_OFF issue and get back to you.

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

I don't think any of the ISRs should matter for this particular code, transceiver operates in its own clock domain and it is never blocked by anything CPU does. T3 ISR might affect overall radio performance, but in a form of lost frames, not hanging up.

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

That makes sense. I'm wondering if my application code is causing this, but as you say, you've never seen this problem before. What's interesting is I'm running a similar application code for the RF on my "master" LightWeight Mesh node, and it has no issues. I'm also debugging a very simple network, just one master and the slave that's hanging. Could noise issues on the transceiver clock be responsible for something like this? I'm not too familiar with how the PLL works.

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

alexru wrote:
What frequency your MCU is running at?

I'd start from checking that FORCE_TRX_OFF has finished:

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); 

If it does not, I don't even know what to do. This is the first time I'm seeing something like this.

Hi Alex, I added this code to check FORCE_TRX_OFF, the problem still persists and is getting stuck.

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

In what place? On the first check or on the second one?

16 MHz clock might be a problem here, since only radio uses it by default, the rest of the system will appear to work fine.

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 hangs in the same spot, the second check.

Can you clarify what you mean by the 16 MHz clock? Are you saying if there are noise issues on that clock the system will appear to run fine even if the RF part has issues. I will try running the MCU clock off the transceiver clock and see how it performs.

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

Hi Alex, I switched the CPU clock to run off the transceiver clock, and I tried a different PCB for the device getting stuck.

The problem still persists, it transmits several hundred packets successfully, then gets stuck while waiting for state 22.

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

Something is wrong here. Your code confirms that it was in PLL_OFF and then it is in PLL_ON while waiting for AACK_ON. I'd check if any of the interrupt routines is writing something to the memory locations it is not supposed to.

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

Alex, in this ISR in the stack:

ISR(TRX24_RX_END_vect)
{
TRX_STATE_REG = TRX_CMD_PLL_ON; // Don't wait for this to complete
phyRxRssi = (int8_t)PHY_ED_LEVEL_REG;
phyRxSize = TST_RX_LENGTH_REG;
phyState = PHY_STATE_RX_IND;
}

The state is set to TRX_CMD_PLL_ON. Isn't there a possibility that this interrupt changes the state while in the phyTrxSetState(uint8_t state) function is running (waiting in while loop)? The state is being modified in both the regular stack code and in the ISR without any protection between the two from what I can see.

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

It looks like there is a problem. But in your case state is set to TRX_CMD_RX_AACK_ON, which means that radio is currently in a state where it can't receive data.

But I see where things might go wrong here. I'll look at it closer.

Can you describe your application, or even give complete source so I could reproduce this on my side?

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

And also, you are confirming that radio is in TRX_OFF state, where it can't receive anything.

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, here is a fix I have for now, it seems to be working but I need to run the test over the course of several hours to make sure it's completely stable:


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 = TRX_CMD_PLL_ON;
  while (TRX_STATUS_PLL_ON != TRX_STATUS_REG_s.trxStatus);
 
  SREG &= ~(1 << 7);
  TRX_STATE_REG = state;
  while (state != TRX_STATUS_REG_s.trxStatus);
  SREG |= (1 << 7);
}

What I think may be happening is that because I have some CPU-intesive ISRs, things get backed up and the Trasceiver RX/TX ISRs may fire late (they are lowest priority after all). This may create a condition where TRX_CMD_PLL_ON even after TRX_OFF state. But on a more fundamental level, registers changed in the stack code and the ISR should be protected from each other.

I can send you my application code, just let me know how, you can e-mail me at gregor.simeonov@ardapower.com.

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

This "solution" is just a temporary hack, but it seems to do the trick.

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

There is no reason to transition through PLL_ON state. This code will do the same, but better:

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

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

TRX_CMD_FORCE_TRX_OFF is the brute force way. Keep in mind that any ongoing transmit or receive actions are canceled immediately. Normal state changes are queued, that means
ongoing transactions are finished and after that the new
state is entered.

Depending on the transceiver (e.g. RF230) a transition over PLL_ON is necessarry before entering RX_AACK_ON or TX_ARET_ON.

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

Hi!

For those who don't know Atmel made some changes to ATZB-A24-UFLB module.

Does anyone know if this module is going to be supported by Lightweight Mesh?

Regards !

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

What changes you are talking about?

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:
What changes you are talking about?

I'm thinking about hardware changes, new PA (March 2013).

This module hasn't changed (hardware) for at least 4-5 years(6/2009).

I don't have any samples of this new modules, so how do these change(s) affect considering BitCloud ?

And question from previous post:

xtal_88 wrote:
is this module going to be supported by Lightweight Mesh?

Thnx Alex !

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

PA is just from a different manufacturer, but they all have the same interface. BitCloud will work on it as is.

In LwMesh it is easier to enable PA manually in PHY_Init() than wait for a release that will support 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

alexru wrote:

In LwMesh it is easier to enable PA manually in PHY_Init() than wait for a release that will support it.

I had a look at module and PA datasheet:

http://www.atmel.com/Images/doc4...
http://www.skyworksinc.com/Produ...

It seems that I have to satisfy table 8. on p. 6 of PA datasheet with CPS, CSD, CTX and n_FEM_SLP(P_C.1 of uC) pins.

Looking at modules datasheet - Internal schematics p. 15:

PA SE2431:

-CPS (21 pin): is allways 1("High") since it is connected to RF_3V

-CSD (20 pin): is logical output from OR gate(U5, NC7SZ32FHX ) -> CTX | n_FEM_SLP

-CTX (24 pin): I'm not sure about this signal (AT86RF230 and BC847PN are involved)

Only thing left (from side of uC which I can control) is n_FEM_SLP pin P_C.1 of uC.

I've digged through BitCloud and found in gpio.h :

#ifdef _HAL_USE_AMPLIFIER_
  // the macros for the manipulation sleep power amplifier
  HAL_ASSIGN_PIN(POW_AMPLF_SLP, C, 1);
#endif

In halSleep.c :

void halPowerOn(const uint8_t wakeupSource)
{
  halSleepControl.wakeupStation = HAL_ACTIVE_MODE;
  halSleepControl.wakeupSource = wakeupSource;

  if (INTERNAL_RC == halGetClockSource())
  {
    GPIO_RF_SLP_TR_clr();
  }
  else
  {
    GPIO_RF_SLP_TR_make_in();
    TCCR2A &= ~((1 << COM2A1) | (1 << COM2A0)); // no compare
    while (ASSR & HAL_ASSR_FLAGS);
  }
  GPIO_RF_SLP_TR_make_out();

#ifdef _HAL_USE_AMPLIFIER_
  // set one on pin. Enable power amplifier.
  GPIO_POW_AMPLF_SLP_set();
#endif

  halPostTask4(HAL_WAKEUP);
}
void halPowerOff(void)
{
  if (HAL_ACTIVE_MODE == halSleepControl.wakeupStation)
    return;  // it is a too late to sleep.

  // stop application timer clock
  halStopAppClock(); // will be shutdown
  if (0ul == halTimeStartOfSleep)
  { // start of sleep procedure
    // save time of stopping of the application timer
    halTimeStartOfSleep = halGetTimeOfSleepTimer();
  }

  /* Shut down a transceiver. This shouldn't be repeated during the MCU
     sleep cycle - halPowerOff can be called periodically. */
  if (HAL_SLEEP_STATE_CONTINUE_SLEEP != halSleepControl.sleepState)
  {
#ifdef _HAL_USE_AMPLIFIER_
    // set zero on pin. Disable power amplifier.
    GPIO_POW_AMPLF_SLP_clr();
#endif

....

So I have to do something similar like this in LW Mesh :

1. PA enabled by default
2. for sleeping nodes - turn OFF PA when going to sleep
3. for sleeping nodes - turn ON PA when waking up

1. PA enabled by default

In phy.c (LW Mesh) I add :

HAL_GPIO_PIN(POW_AMPLF_SLP,C, 1);

void PHY_Init(void)
{
  HAL_PhyReset();
  
  HAL_GPIO_POW_AMPLF_SLP_out();		// make out

  HAL_GPIO_POW_AMPLF_SLP_set();		// turn ON PA	


  phyWriteRegister(TRX_STATE_REG, TRX_CMD_TRX_OFF);
  while (TRX_STATUS_TRX_OFF != (phyReadRegister(TRX_STATUS_REG) & TRX_STATUS_TRX_STATUS_MASK));

  phyWriteRegister(PHY_TX_PWR_REG, (1 << 7)/*TX_AUTO_CRC_ON*/ | 0/* +3 dBm */);

  phyWriteRegister(IRQ_MASK_REG, 0x00);
  phyReadRegister(IRQ_STATUS_REG);
  phyWriteRegister(IRQ_MASK_REG, TRX_END_MASK);

  phyIb.request = PHY_REQ_NONE;
  phyIb.rx = false;
  phyState = PHY_STATE_IDLE;
}

2. for sleeping nodes - turn OFF PA when going to sleep

In phy.c I add :

void PHY_Sleep(void)
{
  HAL_GPIO_POW_AMPLF_SLP_clr();		// turn OFF PA	

  phyTrxSetState(TRX_CMD_TRX_OFF);
  HAL_PhySlpTrSet();
  phyState = PHY_STATE_SLEEP;
}

3. for sleeping nodes - turn ON PA when waking up
In phy.c I add :

void PHY_Wakeup(void)
{
  HAL_GPIO_POW_AMPLF_SLP_set();		// turn ON PA

  HAL_PhySlpTrClear();
  phySetRxState();
  phyState = PHY_STATE_IDLE;
}

So is this the way how it is supposed to be done or am I doing it wrong?

Thank you Alex !

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

Wow. This is messed up. So at86rf230 has no digital outputs to control PA/LNA, so detector on D1 switches between PA/LNA mode based on the fact that radio actually transmits something. So yeah, there is no registers in the radio that you must control, switching just happens automatically.

From what I see your code seems to be perfectly correct.

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,

I think I have found a mistake in "Developer-Guide" as in chapter 4.1.1 and the Figure 4-2 is missing description of third bit (Link Local).

As far I found out, the stack use it only for limiting of broadcast propagation. In other words it is just a user's option to limit broadcasts. Am I right?

Thanks

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

Yes, it was added in the final stages of development and was not documented. It will be documented in the next version that should come out 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

Hi !

I have few random questions about LW Mesh.

1. What is the size of message? Is it?

#define NWK_MAX_PAYLOAD_SIZE            (127 - 16/*NwkFrameHeader_t*/ - 2/*crc*/)
#define NWK_MAX_SECURED_PAYLOAD_SIZE    (127 - 16/*NwkFrameHeader_t*/ - 2/*crc*/ - 4/*mic*/)

2. For turning on security, is this all I have to do ?

In config.h :

//#define NWK_ENABLE_SECURITY                     
//#define SYS_SECURITY_MODE             1   // use XTEA mode    

Somewhere in code :

NWK_SetSecurityKey(...);

3. In LW Mesh stack is something written in EEPROM ?

4. In LW Mesh developers guide I don't see anything talking about power/signal strength. I'm using ATZB-A24-UFLB module so I would like to know how to set power/signal strength to desired value ?

5. What does this function do?

PHY_SetRxState(true);

It's name suggests that it sets RF part/chip in RECEIVE STATE.

Do I have to allways use this function ?

What if I put:

PHY_SetRxState(false);

What happens?

Thank you !

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

xtal_88 wrote:
1. What is the size of message? Is it?

#define NWK_MAX_PAYLOAD_SIZE            (127 - 16/*NwkFrameHeader_t*/ - 2/*crc*/)
#define NWK_MAX_SECURED_PAYLOAD_SIZE    (127 - 16/*NwkFrameHeader_t*/ - 2/*crc*/ - 4/*mic*/)

The first one for not secured messages and the second one for secured.

xtal_88 wrote:
2. For turning on security, is this all I have to do ?
In config.h :

//#define NWK_ENABLE_SECURITY                     
//#define SYS_SECURITY_MODE             1   // use XTEA mode    

Somewhere in code :

NWK_SetSecurityKey(...);

You need to uncomment #defines, but otherwise, yes, that is all you need to do.

xtal_88 wrote:
3. In LW Mesh stack is something written in EEPROM ?
No, it is a wireless communication stack.

xtal_88 wrote:
4. In LW Mesh developers guide I don't see anything talking about power/signal strength. I'm using ATZB-A24-UFLB module so I would like to know how to set power/signal strength to desired value ?
In the released SDK, by manually extending PHY API or manually setting desired power in PHY_Init(). In the upcoming release there is PHY_SetTxPower() function.

xtal_88 wrote:
5. What does this function do?
Puts transceiver into TRX_OFF state. It can be useful for battery powered devices that need to perform some calculations before sending the data and don't care about being on the network. For example it can be sleeping device that needs some time to read sensor value before sending it to network.

In general, set it permanently to true. Radio is disabled during sleep automatically, so you don't need to control it manually. I know that current WSNDemo does it, but it is not necessary and it was removed for the upcoming 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

Addition: for security you also need to request it: "nwkDataReq.options = NWK_OPT_ENABLE_SECURITY;".

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 for answers !

Again I have few questions to ask:

1. Can I use following function:

PHY_SetRxState(false);

on routing nodes to disable their routing function for some time for testing purposes?

My goal is to find out how to place nodes to achieve redundant paths. By using this function I would like to find out how good is link(LQI and RSSI) to some end device when I turn OFF TX on R1 and after that turn OFF TX on R2.

 
           -------- R1 -------           
          /                   \
COORDINATOR                    ED1
          \                   /
           -------- R2 -------

2. Does it make sence to let's say build network topology on routing records?
Like comparing BitCloud with LW Mesh, in BitCloud there is

ZDO_GetNeibTable()

There is nothing similar in LW Mesh.

3. In network I have moving nodes and e.g. one moving node is present in one part of network(in reach of "COORDINATOR") and other nodes in that part of network have this node in their routing table. Now
moving node moves to other part of network(NOT in reach of "COORDINATOR" ) and other nodes in that part don't have it in their routing table.

What happens if I send data to this moving node from COORDINATOR ?

Message is stuck in part of network which has moving node in it's routing table records?

It's more question about routing algorithm, hope you understand what I'm trying to ask.

4. Is in LW Mesh implemented CSMA/CA algorithm, because I would like to send a BROADCAST messages and I await responces form nodes?

5. Do I have to manually disable NWK_OPT_ACK_REQUEST when I send BROADCAT message or it is disabled dy default because of broadcast address 0xFFFF?

Thank you once again!

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

xtal_88 wrote:
1. Can I use following function:

PHY_SetRxState(false);

on routing nodes to disable their routing function for some time for testing purposes?


Yes, you can.

xtal_88 wrote:
2. Does it make sence to let's say build network topology on routing records?
Like comparing BitCloud with LW Mesh, in BitCloud there is

ZDO_GetNeibTable()

There is nothing similar in LW Mesh.

There is no direct analog of neighbor table, because it is not needed by the stack, but there is routing table, which currently can be reached with some hacking of the code and will be accessible though the API in the next version.

But correct way of achieving the same functionality (and even better) is to write some application code to do this. In BitCloud neighbor table is built based on the Link Status messages routers send every 15 seconds. You should do the same - send a local broadcast message very 15 seconds (or however often you like tbales to be updated) and receive this message on the other nodes and build tables based on the received info.

xtal_88 wrote:
What happens if I send data to this moving node from COORDINATOR ?
Few delivery attempts will be made (see NWK_ROUTE_DEFAULT_SCORE) and the route will be re-discovered.

xtal_88 wrote:
4. Is in LW Mesh implemented CSMA/CA algorithm, because I would like to send a BROADCAST messages and I await responces form nodes?
LwMesh uses CSMA/CA. But depending on how many nodes do you have in one place you might want to delay responses by a random time from the application.

xtal_88 wrote:
5. Do I have to manually disable NWK_OPT_ACK_REQUEST when I send BROADCAT message or it is disabled dy default because of broadcast address 0xFFFF?
Yes, you do. It might work if you don't, but it is not guaranteed to be this way in future version.

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

Few questions came to my mind:

1. In LW Mesh datasheet is stated that:

An application running Lightweight Mesh is responsible for:

Advanced network operation scenarios (sleeping routers, parent-child relationship, data delivery to the sleeping nodes, etc)

So there is no POLLING mechanism like in BitCloud.

Is there going to be something slimiar to POLLING technique in future releases of LW Mesh since in new release there is API for neighbor/routing table?

When sending BROADCAST message there are NO retries(deliveries to sleeping NODEs), which nodes are awake they receive BROADCAST and send it further(in case or routers) and that's it ?

2. Suppose I have situation like this :

   -------- R1 -------	
  /                   \ 
C                      ED1 
  \                   /
   -------- R2 -------

C sends message to ED1 and on ED1 I look at LQI and RSSI of the received frame.

How can I know if message came through R1 or R2 ?

Do I have to disable routing on e.g. R1 with

PHY_SetRxState(false); 

and that way I know that message to ED1 was delivered through R2 or there is some other way?

3. Can I use stack functions(in comment) like this (in int main()):

int main(void)
{
	SYS_Init();
	HAL_UartInit(38400);
	
	
	//HAL_GPIO_LED_set();
	//HAL_GPIO_DEFAULT_read();

	//Timer.interval = 3000;
	//Timer.mode = SYS_TIMER_INTERVAL_MODE;
	//Timer.handler = TimerHandler;
	//SYS_TimerStart(&Timer);	

	while (1)
	{
		SYS_TaskHandler();
		  
		HAL_UartTaskHandler(); 
		  
		APP_TaskHandler();
	}
}

Functions(commented) are used before while(1) loop which is main thing in app?

Thank you !

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

1. No, there won't be anything like this. There is API for the routing table, but polling is not needed for maintaining the routing table. In fact this API is already there from the first release, it is just not public. Polling can be implemented on the application layer and hence it will not be in the stack.

Yes, there is no retries, whoever was listening at a time will receive a message, others will miss it.

2. There is no way to know how the frame was received. If you need to test something, then disable one of the routers. Disabling a receiver is one way of doing it.

3. For provided functions it is fine and it should be fine for majority of APIs, but I can not guarantee that it will work for everything..

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,
I am facing another weird situation. I have tried many scenarios including two simultaneous sending nodes and one receiver - gateway. Packets are sent with no delay - after the previous was successfully sent out.
Each test was successfully done except the case when

appDataReq.options = NWK_OPT_ENABLE_SECURITY | NWK_OPT_ACK_REQUEST

. After receiving say 200 or 400 packets the gateway stuck on while loop in the function HAL_PhySpiWriteByteInline in halPhy.h waiting for the SPIF flag. No matter how big the message was (I have tried 1 to 105 B data payload). I am using IRIS motes (ATmega1281+RF230).

Do you know how to avoid this state please?

PS: Link to download software stack v1.1.0 doesn’t work.

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

This looks like a hardware problem. Can you trace where exactly in the code HAL_PhySpiWriteByteInline() that gets locked is located?

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:
This looks like a hardware problem.

I have tried today another module (Zigbit) and it behaves in the same way.

Quote:
Can you trace where exactly in the code HAL_PhySpiWriteByteInline() that gets locked is located?

As the problem occures after a few hundered of packets it is hard to follow debugging. I have tried to place Tracepoint to get the caller but there are too many calls and the program couldn't run normally. Can you suggest me the way to debug this please?

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

You can try to get the address of the place where it loops and match it to the code later using avr-objdump.

Or AS will probably show where it is locates right in the disassembly window. Just look at the surrounding functions.

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

LwMesh version 1.1.0 is now public. Among other improvements it includes support for AODV routing and multicast messaging.

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!

I'm using ATZB-A24-UFLR and ATZB-A24-UFLB(when they'll be available on market).

I have question about PHY_SetTxPower() function.

This function takes only one parameter and that is uint8_t txPower.

Datasheet of AT86rf230 p. 59-60 says about txPower and it's values, so it can be 0x00-0x0F.

Datasheet of ATZB-A24-UFLB p. 8 says:

USA
Register Value Power Register Setting [dBm] Output Power [dBm] (at antenna feed) 
11 -5.2 +20 
12 -7.2 +18 
13 -9.2 +16 
14 -12.2 +12 
15 -17.2 +7 

European Union
15 -17.2 +7 

Are only these values allowed for ATZB-A24-UFLB ?

What about old ATZB-A24-UFLR ?

Can I set txPower = 0x00 ?

Regards !

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

According to this table amplifier gives +25 dB, so if you set 0, you should get +28 dBm output, that is almost a legal limit, and distortions are probably way too high for this thing to work.

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!

Quote:
What about old ATZB-A24-UFLR ?

Some time ago, I tried to measure output power of ATZB-A24-UFLR modules and this was the results (I set up a very simple testbed and I measured only one module):

Register_Value Output_Power(dBm at Antenna Feed)
0x0F 10.1
0x0E 13.3
0x0D 15.1
0x0C 16.5
0x0B 17.1
0x0A 17.9
0x09 18.5
0x08 19.0
0x07 19.3
0x06 19.6
0x05 19.8
0x04 19.8
0x03 20.1
0x02 20.1
0x01 20.2
0x00 20.5

Acording to this thread:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=117362&highlight=amplifier
it could be possible to disable the module's amplifier and get less output power, but, after many attemps, I didn´t manage to disable it...

Regards,

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

Yes, this looks about right. Because of distortion, all energy goes to higher harmonics, breaking FCC rules.

It is possible to disable the amplifier in case of BitCloud - just use non-amp version of the stack. It is harder to do dynamically.

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 !

Today I received ATZB-A24_UFLB new modules.

I currently working on old ones, ATZB-A24_UFLR.

Here (2nd post):

http://www.avrfreaks.net/index.p...

discussion was about how to enable PA on LW Mesh on old module (it's about pin c1 of uC).

This whole time I was experimenting with nodes on my desk (0.5m distance) and everything's OK.

But when I put one node on wall (to be door sensor, 3m away) it doesn't work.
Seems to me that PA is not properly turned ON or something else is wrong.

I don't have internal schematics of old ATZB-A24_UFLR module. Whole discussion mentioned above was based on schematics of new modeule.

I don't know if something else needs to be done to enable PA on old module on LW Mesh and how it is supposed to be done correctly.

Basicaly my questions again are:

How to enable PA on LW Mesh on ATZB-A24_UFLR and ATZB-A24_UFLB module ?

Thank you !

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

Your code still looks correct. Try to set TX power to a value from the recommended range. Or just set minimum (0x0f) - it still should be better that non-amplified module.

Combination of public ATZB-A24_UFLB schematic and BitCloud code that was written for ATZB-A24_UFLR tells me that they use exact same design, so modules should be compatible (and I would be surprised if they were 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

Hi Alex !

I haven't made any progress yet.

I uploaded BitCloud version which worked OK and thing is the same (communication doesn't work more then 1m).

I've removed setting PC.1 form phy.c and set it on application level, in main() actually, like this:

HAL_GPIO_PIN(POW_AMPLF_SLP,C, 1);

int main(void)
{
		
	HAL_GPIO_POW_AMPLF_SLP_out();      // make out
	HAL_GPIO_POW_AMPLF_SLP_set();      // turn ON PA
	
	
	SYS_Init();
	HAL_UartInit(38400);

	while (1)
	{
		SYS_TaskHandler();
		  
		HAL_UartTaskHandler(); 
		  
		APP_TaskHandler();
	}
}

I haven't cleared this pin, so PA should be turned ON all the time. Everything is the same.

I also tried to put PHY_SetTxPower(0x0F); as you suggested, nothing changed.

I don't know if PC.1 is OK. How can I check that ?

You said that PA switches from TX to RX state and vice versa automatically, so all I have to do is set PC.1 and that's it, right?

Thank you once again !

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

Yes, at this point I'd start checking your entire design for noise and other sources of interference. Also check your antenna connection. PC1 is the right pin, that's what BitCloud does and that's what schematic says.

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 kind of antenna do you use?

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:
Yes, at this point I'd start checking your entire design for noise and other sources of interference. Also check your antenna connection. PC1 is the right pin, that's what BitCloud does and that's what schematic says.

OK, I'll do that.

alexru wrote:
What kind of antenna do you use?

I use 5.5 dBi antenna, something like this:
http://uk.rs-online.com/web/p/wi...|cav

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

Hi Alex!

First of all, thanks for your inestimable assistance.

alexru wrote:
It is possible to disable the amplifier in case of BitCloud - just use non-amp version of the stack. It is harder to do dynamically.

Finally I had time to go to the lab and make a test using the non-amp version of BitCloud on an ATZB-A24-UFLR module, but without any success. Again, I measured an output power at antenna feed between 10 and 20 dBm.

I tried to enable/disable PA and LNA through PORTC1, as you said in other thread (and such as the BitCloud stack does), but I didn't see any change in the output power.

Regards,

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

Hi xtal_88!

xtal_88 wrote:
I use 5.5 dBi antenna, something like this:

Although it might seem a platitude, did you check U.FL/SMA cable polarity againts antenna polarity (female/female)? At 0.5 m modules can communicate through the U.FL connector (without antenna).

In my case, I don´t manage to *disable* the amplification of the ATZB-A24-UFLR modules, it is always on.

Regards,

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

Thanks Alexru and rober !

Problem solved.

Pigtail on my Router didn't have connection and Coordinator's PA doesn't work.

I don't know why PA doesn't work, at first I didn't enabled PA, and everything worked OK(but only on short distances), maybe this could be the reason?

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

I don't understand your description of what does/did not work.

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 don't understand your description of what does/did not work.

OK, sorry for bad description.

2 nodes are involved C and R(on both PC.1 is set).

Pigtail on R didn't have connection, so I had only module without antenna.

With sniffer(RSSI value, if I can relay on that) I found out that signal form C is very low/weak, so I suppose PA or/and AT86RF230 is not OK.

I can receive signal on C from R, but I don't receive signal on R form C.

----------------------------

Now I have new module ATZB-A24-UFLB which is now C.

Everything works now : this new C and old R(with new pigtail of course, PC.1 set of course).

----------------------------

At first I used C(ATZB-A24-UFLR and did not set PC.1, so without PA) and was experimenting with RBC-128-RFA1 and it was OK on short distance.

Maybe something went wrong because I didn't turn ON PA during this experimenting.

More or less that's it. Hope you understand me better now.

Thnx, Alex !

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

It looks like a hardware issue, maybe module was damaged somehow.

Anyway, I'm glad it works 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

Hi Alex,

I am still facing the problem with stucking on HAL_PhySpiWriteByteInline function as posted a month ago.

vladacr wrote:
I have tried many scenarios including two simultaneous sending nodes and one receiver - gateway. Packets are sent with no delay - after the previous was successfully sent out.
Each test was successfully done except the case when
appDataReq.options = NWK_OPT_ENABLE_SECURITY | NWK_OPT_ACK_REQUEST

. After receiving say 200 or 400 packets the gateway stuck on while loop in the function HAL_PhySpiWriteByteInline in halPhy.h waiting for the SPIF flag. No matter how big the message was (I have tried 1 to 105 B data payload). I am using IRIS motes (ATmega1281+RF230).

Do you have any suggestions how to solve it?

Here is a print of disassembly view:
http://goo.gl/lMsRCj

Thank you.

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

It is impossible to tell anything from this screenshot. You need to set this bit manually in the debugger, to let this function exit and see where it is called from. I need to know what stack is doing when this happens and that function is called from multiple places.

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,

I have been playing with the ATZB-24-A2 module. I have used it on a breakout board from Scott Schmit at Digikey. I used it with the LWM stack. I followed your video, “How to Develop Custom Applications Using the Light Weight Mesh”. It works great, thank you for posting it.
I have more of a hardware background so I have some basic questions regarding the code. I changed your code to transmit data for multiple sensors by just changing multiple bits in the uint8 variable you are sending. What would you recommend doing if I wanted to expend this to multiple units and more data? Would you recommend sending multiple 8 bit words, Should I come up with some sort of packet structure?
I would also like to be able to talk to the controller from other devices via a network. I was looking at your application note, AT03755 about a low cost gateway. It seems that sending characters versus other kind of variables (like an array or a structure) would make the application work over the network better, it would make it more portable.

BR

Arpad

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

arpadthetall wrote:
I changed your code to transmit data for multiple sensors by just changing multiple bits in the uint8 variable you are sending. What would you recommend doing if I wanted to expend this to multiple units and more data?
Just add more variables of any types you like to the same structure. You have 109 bytes that can fit into one frame.

arpadthetall wrote:
It seems that sending characters versus other kind of variables (like an array or a structure) would make the application work over the network better, it would make it more portable.
In that application note I used ASCII characters for Ethernet communication, because protocol was designed to be unified and there is a plan to run embedded web-server, so requests will be coming via HTTP, which only supports text. Wireless protocol is still binary.

Text-based protocols are a pain to decode and encode, binary is much easier, so if there is no limitation, I'd pick binary.

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 (spasibo) for the quick response. Five star service.

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

Hi Alex,

I have recently started using Lightweight Mesh stack and am facing some problems. I would really appreciate some help. My scenario is:

I have 2 ATMEGA256RFR2 Xplained Pro Boards.

I am trying to Broadcast messages. Both the boards are Broadcasting successfully.

I don't require any routing or security.

My scenario would further include other nodes that would also be broadcasting a frame including some random value.

I am using RSSI value to measure how close the nodes are but I guess it's not an accurate method. Any suggestions on this would be really helpful.

The problem is that after sometime they suddenly stop broadcasting. I have a counter for the number of frames received and it goes to a few thousands and then stops.

I checked the debugger and it was stuck in the below section:

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);
}

I changed it as you said in your post:

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

The problem is still there. However the code doesn't stop in the above section it keeps on running normally but the following callback is never called :

static bool appDataInd(NWK_DataInd_t *ind)
{
	frameCounter++;
	ltoa(frameCounter , count,	10);
	for (i=0; i

Here is how I am sending the frame:

static void appSendMessage(uint8_t state)
{
	appMessage.buttonState = state;	
	appNwkDataReq.dstAddr = NWK_BROADCAST_ADDR;
	appNwkDataReq.dstEndpoint = APP_ENDPOINT;
	appNwkDataReq.srcEndpoint = APP_ENDPOINT;
	appNwkDataReq.data = (uint8_t *)&appMessage;
	appNwkDataReq.size = sizeof(appMessage);
	appNwkDataReq.confirm = appDataConf;
	NWK_DataReq(&appNwkDataReq);
	appState = APP_STATE_WAIT_CONF;
}

And config.h :

#define APP_ADDR             boot_signature_byte_get(1)
#define APP_PANID            NWK_BROADCAST_PANID
#define APP_ENDPOINT         1
#define APP_CHANNEL	     0x0f

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

#define NWK_BUFFERS_AMOUNT                  10
#define NWK_DUPLICATE_REJECTION_TABLE_SIZE  50
#define NWK_DUPLICATE_REJECTION_TTL         2000 // ms
#define NWK_ROUTE_TABLE_SIZE                100
#define NWK_ROUTE_DEFAULT_SCORE             3
#define NWK_ACK_WAIT_TIME                   1000 // ms
#define NWK_GROUPS_AMOUNT                   3
#define NWK_ROUTE_DISCOVERY_TABLE_SIZE      5
#define NWK_ROUTE_DISCOVERY_TIMEOUT         1000 //ms

As you can see It's pretty simple and straightforward, I don't get why does is stops broadcasting :(

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

Where do you call appSendMessage() from? Are you sure it can not be called the second time before appDataConf() is called for the first request?

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

appSendMessage() is always called after appDataConf()

Here's the relevant code:

switch (appState)
  {
	  case APP_STATE_INITIAL:
	  {
		NWK_SetAddr(APP_ADDR);
		NWK_SetPanId(APP_PANID);
		PHY_SetChannel(APP_CHANNEL);
		PHY_SetRxState(true);	
             NWK_OpenEndpoint(APP_ENDPOINT,appDataInd); 
		appState = APP_STATE_IDLE;		
	  } break;

	  case APP_STATE_IDLE:
	  {
		appSendMessage(appButtonState);
	  } break;

	  case APP_STATE_WAIT_CONF:
	  break;
	 
  }

and appDataConf()...

static void appDataConf(NWK_DataReq_t *req)
{
	appState = APP_STATE_IDLE;
	(void)req;
}
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In this case I'd run it under the debugger and look at each buffer state in the nwkFrameFrames variable (located in nwkFrame.c). This might tell more.

Also, try to find out where it loops.

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 a simple LwMesh program that uses a poll/response application layer. A non-routing master node continuously polls 10 remote routing nodes (some remote nodes might be too far away to directly communicate with the master). When the remote node receives a poll it sends a response back to the master. My question is should I add some delay at the application layer on the master node between receiving a response and sending out the next poll. Do I need to have a bit of "dead air time" to prevent collisions between the master's next poll and any re-transmissions from the routing nodes? If I do need this dead air time what value should I use and should I add dead air time on the remote node between receiving a poll and sending back a response?

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

There is no specific reason why you would need a delay between the polls. But if your application allows longer poll intervals, I'd add the delay, just to reduce potential interference for other networks. Again, it is not required, just a way to be nice to others.

There is no need for delay between the request and response, it won't help anything.

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 for a node or router to choose which network to join if more then one exist on a chanel.

I just downloaded the stack, is there more information on the other examples apart from wsn?

Where and how can I modify the a 1281 project so that a 1284P can work?

Thanks

Regards

DJ

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

There is not joining or network discovery in the stack itself. You tell it which PAN ID to use and how you know it is up to you.

Network discovery will be implemented as an application service, but it is currently under development, so it won't be out for sometime.

Applications are very simple, just read though them.

Getting started guide talks about what HAL files are required for what platform. You will need to create your own HAL for m1284p and change MCU type in the project settings.

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

So does that mean when switch on a device, your in the network?

I noticed that even nodes can send message directly to another node, without even a router or cord as it was in bitcloud.

Then what is the purpose Router, is nodes can sleep while routers can't?

Once I get my RF230 to work with M1284P, am I correct I can switch to RF231 with easy?

Thanks

Regards

DJ

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

djoshi wrote:
So does that mean when switch on a device, your in the network?
Yes. You set PAN ID, address, channel, security key.

djoshi wrote:
I noticed that even nodes can send message directly to another node, without even a router or cord as it was in bitcloud.
Correct, you don't need a coordinator in LwMesh.

djoshi wrote:
Then what is the purpose Router, is nodes can sleep while routers can't?
Non-routing nodes are never selected as a next hop for routing purpose. They may sleep, or may stay awake, stack won't care either way.

djoshi wrote:
Once I get my RF230 to work with M1284P, am I correct I can switch to RF231 with easy?
Yes, just switch PHYs.

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 see some WSN examples in the docs but not on the other examples

Thanks

Regards

DJ

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

There is no documentation for all applications. Most of them are self-explanatory.

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

Well I think I will stick to WSN, as bitcloud use this so my other application should notice no difference, plus I can use WSN a debug tool as well.

Thanks Alex.

Thanks

Regards

DJ

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

Where can i find out any available functions, is there a certain help file?

For example If I want to leave the network and re join the network on another nework, so where would I find out to leave the current network?

And is there also a libary for I2C,or timers, or do we create it ?

Thanks

Regards

DJ

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

You don't leave the network. Just set another network parameters and you are done.

There are application timers, but there is no library for any peripherals - this is just a wireless 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

Great So I can jump from one network to another on the fly?

Are the timers still based on 32.768Khz

Adding Peripherals are no problem.

Thanks

Regards

DJ

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

Yes, you can.

Timers are based on the system clock source - RC-oscillator or external crystal. The same way as in BitCloud.

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

Bitcloud also used 32Khz.

Can I just run on 8Mhz or 1Mhz?

Thanks

Regards

DJ

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

BitCloud system time can run on 32 kHz, but application timers are always run from the system clock.

Yes, you can.

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 about this stacks system time? Can I do without 32Khz in bom. I do not need accurate timing for my application

Thanks

Regards

DJ

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

There is no system time in LwMesh. You only need 32 kHz crystal if you have sleeping devices or you need to calibrate your main oscillator for serial interfaces. Otherwise you don't need it at all.

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

Thank You

In that case I will still keep 32 Khz, as uart is required and waking up from sleep is also required?

I have download the stack and I am starting to look into it.

I got some questions...

1. As nodes can talk directly to one another, what difference do they have compared to routers? It seems from page 4 diagram in Developers guide that they can also pass on message as a router would?

2. If a node is sleeping, and a message is sent to that node. Would that just be a failed message OR does it get buffered on transmitting node or Router?

3. To make a 1284P project do I copy and paste the 1281 folder in the hal folder and make all the nessary changes in all files or just a particular file?

4. Am I correct that in the WSNDEMO folder  astudio you have multiple projects, each represent a different platform but the C files for main application is the same? Therefore you can jump from one platform to another with its own individual project file, with your same C code ?

5. My boards do not have an external flash. Is it possible to make a simple code small enough to sit in the bootloader that does a peer to peer firmware update for a node.

Thanks

Thanks

Regards

DJ

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

djoshi wrote:
1. As nodes can talk directly to one another, what difference do they have compared to routers? It seems from page 4 diagram in Developers guide that they can also pass on message as a router would?
Non-routing nodes are never selected as an intermediate node in the longer route. Non-routing flag is a hint to the stack that node might disappear. This is useful for sleeping nodes, but can be used in many more applications. For example mobile terminal that does not sleep, but moves around.

djoshi wrote:
2. If a node is sleeping, and a message is sent to that node. Would that just be a failed message OR does it get buffered on transmitting node or Router?
It will be failed message. Routers have no idea how to buffer anything, they don't keep track of their "children" and a device after wake up would not know who to ask for its data.

djoshi wrote:
3. To make a 1284P project do I copy and paste the 1281 folder in the hal folder and make all the nessary changes in all files or just a particular file?
Copy entire folder and make changes in all relevant places.

djoshi wrote:
4. Am I correct that in the WSNDEMO folder  astudio you have multiple projects, each represent a different platform but the C files for main application is the same? Therefore you can jump from one platform to another with its own individual project file, with your same C code ?
Correct. If you create projects for your application the same way. By default Atmel Studio wants to copy all files to the project folder. But there is a way to make a link instead of the copy in the "Add file" dialog.

djoshi wrote:
5. My boards do not have an external flash. Is it possible to make a simple code small enough to sit in the bootloader that does a peer to peer firmware update for a node.
It might be possible, but usual solution is to receive the image into second half of the flash, and then just do a switch when entire image is received. This is how standard LwMesh OTA process works.

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:
Non-routing nodes are never selected as an intermediate node in the longer route. Non-routing flag is a hint to the stack that node might disappear. This is useful for sleeping nodes, but can be used in many more applications. For example mobile terminal that does not sleep, but moves around.

What would be seen as a longer path?

So if somthing moves around but does not sleep, then would the node just pass on the message?

So am I correct first choice is given to router and then nodes providing they do no sleep.

Thanks

Regards

DJ

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

Please explain, what would I need to do if I wanted to make project from ATMEGA 1284P +RF230, just like all the other projects and then 1284 +rf233.This is in regards to Studio 6 setup?

Just noticed there is a soloution file along with project.

Dj

Thanks

Regards

DJ

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

djoshi wrote:
What would be seen as a longer path?
For example route (0)-(1)-(2). Non-routing node will never be in a position (1) because it can not be relied upon to pass messages from (0) to (2).

djoshi wrote:
So if somthing moves around but does not sleep, then would the node just pass on the message?
If contacted directly, it will, but it is not likely to happen, since other nodes will avoid sending messages though non-routing nodes. But broadcasts, for example, will be passed.

djoshi wrote:
So am I correct first choice is given to router and then nodes providing they do no sleep.
There is no first or second choice. Routing node, when it has to add a next hop address in the routing table, looks at the address. If it is a non-routing node, then it won't add the record and will wait for a routing node. If there is no routing nodes to support this route, then it will be re-discovered each time a message has to be sent.

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

djoshi wrote:
Please explain, what would I need to do if I wanted to make project from ATMEGA 1284P +RF230, just like all the other projects and then 1284 +rf233.This is in regards to Studio 6 setup?
You don't need to do anything special with Studio. Just open a project you like and replace all links to 1281 with links to 1284. Do the same for the radio.

djoshi wrote:
Just noticed there is a soloution file along with project.
Solution is just a simple file that links to all projects. In this case there is only one project.

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, think I understood. A non routing node must be directly connected to a node in terms of RF signal for it to send data.
If for some reason it can not directly connect, then router is nessary even though another can connect to both the TX and RX ing nodes.

So in short I could setup two nodes to talk to one another and if routers do have exist also the base unit presuming RF signal is not strong enough for direct connection.

I have also read routers can sleep? But wouldent they miss out fowarding messages?

Thanks

Regards

DJ

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

Non-routing node can send data, entire can be made out of non-routing nodes. It is just there will be no recorded routes, each new message will cause a new route discovery.

If routing node will go to sleep, it will loose frames, obviously. But you can have a network of sleeping routers that wake up from time to time, communicate data, and go to sleep. If all devices are asleep, then there is no one to miss frames from.

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:
Non-routing node can send data, entire can be made out of non-routing nodes. It is just there will be no recorded routes, each new message will cause a new route discovery.

So does this mean non-routing nodes can forward messages, but it would start the discovery process every time?

Thanks

Regards

DJ

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

Well in regards to sleeping, you could do a sync once in while among all nodes and routers and transmit a message the setups a sleep period while all nodes are fully awake . And then setup router to wake up few seconds before the nodes.

Thanks

Regards

DJ

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

djoshi wrote:
So does this mean non-routing nodes can forward messages, but it would start the discovery process every time?
Exactly.

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

djoshi wrote:
Well in regards to sleeping, you could do a sync once in while among all nodes and routers and transmit a message the setups a sleep period while all nodes are fully awake . And then setup router to wake up few seconds before the nodes.
And that is the intended use.

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

So if a node goes through discovery every time and message transmision is not frequent e.g 3 msg every min, then am I correct in saying I would not be much of a problem.

I can understand of applications where a continous transmission occurs might have timing issues

Thanks

Regards

DJ

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

Technically it is not a problem, but I would not intentionally design application 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

Ok...

I am now going to start working on the project file.

I have copied the project file
ZigBit_ATmega1281_Rf230 and renamed it ATmega1284_Rf230

Under Solution I see a Hal foler.

Under That I see Atmega1281, how do I get that the point to the newly created Atmega1284 folder?

There is also a new folder called drivers, what is this?

Thanks

Regards

DJ

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

djoshi wrote:
Under That I see Atmega1281, how do I get that the point to the newly created Atmega1284 folder?
First you need to create copies of the relevant files in the filesystem (renamed accordingly).

Then you need to change paths in the project. There are two ways of doing this:
1. "Official", but also longer and error-prone. In AS solution explorer remove links to the old files and add links to the new files.
2. Fast. Just open project file with a text editor and do search and replace of MCU and RF name. Project file is just an XML. Make sure that it is not open in AS at the moment of editing.

djoshi wrote:
There is also a new folder called drivers, what is this?
Drivers are not essential for normal stack operation, but a useful for the applications. If you don't need functionality provided by drivers, then you don't have to port them.

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

Let me give option 2 a go

When you say copy the relavant files you mean just copy the whole folder and rename it. In this case it will be 1284, should I be doing any more files or folders.

Now In the project file I will replace all 1281 refernce with 1284?

Thanks

Regards

DJ

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

Now the files in driver folder are missing in soloution explorer .

Thanks

Regards

DJ

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

Yes, copy entire folder and replace 1281 with 1284 in the projects.

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

djoshi wrote:
Now the files in driver folder are missing in soloution explorer .
Then you did something wrong. If files are present on the drive and paths in the projects are not changed (except for 1281 -> 1284), then it all should work.

Another option - just run with 1281 and change MCU in the project settings. It should work as well.

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, I just noticed the driver folder inside the hal folder, so I made a copy of the 1281 folder inside an renamed it 1284.

I then did a compile and I I go PORT E errors, As there is not PORT E's in ATMEG1284, so I changed it PORT A for now.

And it seems to remove the errors.

I now get

Unknown HAL

I think somewhere I need to introduce HAL_ATMEGA1284 ?

Thanks

Regards

DJ

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

Go to the error source. It will be obvious.

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

Yes I see why it happens,

Do I comment it out ? or do I need to add a HAL_ATMEGA1284 reference some where.

Where is the HAL_ATMEGA1281 been specified?

Thanks

Regards

DJ

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

Just add another #ifdef section by analogy. HAL_ATMEGA1281 (and 1284 now) comes from the project settings, which you have changed when you were editing XML 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

Ok I got it working, HAL_ATMEGA1281 is renamed HAL_atmega1284.

I am now getting all the reg error, so I guess its time to look for the equailant reg from ATMEGA1284 datasheet.

Thanks

Regards

DJ

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

You need to preserve the case when replacing stuff in the project XML.

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

Yes, I am going through the files and seeing where I need to make the change.

Just out of curiosity why is that when you change from RF230 to RF231 with 1281, the internal REG of 1281 also change.

#if defined(PLATFORM_ZIGBIT)
  EICRB |= (1 << ISC51) | (1 << ISC50);
  EIMSK |= (1 << INT5);
#elif defined(PLATFORM_RCB231)
  EICRA |= (1 << ISC01) | (1 << ISC00);
  EIMSK |= (1 << INT0);

Thanks

Regards

DJ

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

RCB and ZigBit have radio connected to different pins. You will have to rewrite this code for your platform as well.

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

This is due to the PCB layout of each platforms, but my layout will be the same for RF230 and RF231,RF233 so once set, i guess i don't have to change this part when i try another IC?

Thanks

Regards

DJ

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

Well, here we see support for two different radios on two different platforms. In your case you'll have to write code once.

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

No problem, when I swap my RF I can just edit the files with in the project?

Looking this piece of code, its reflects that pin is connected to a external INT, but on the Raven boards I don't see any external INT.

Thanks

Regards

DJ

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

On Raven it is connected to PD6, which can be a Pin Change interrupt or Input Capture interrupt. Look at how it is done in BitCloud. You will have to do more work yourself, otherwise it is me doing everything.

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

Its a IRQ on the RAVAN(1284) its going to PIN PD6 PCINT30, so its a pin change, so when ever it changes this interupt will fire rather then just rising edge.

Thanks

Regards

DJ

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

Filter out failing edges in the software, what's the problem?

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, thank I will have a look

Thanks

Regards

DJ

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

Yes, I see how Raven interupt is set as input capture and then I see how the input capture has a edge setup.

It looks simple, let me give it a go , step by step and then get back to you with my results?

Thanks

Regards

DJ

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

I have made all changes, but seems when I debug I can not get into APP_TASKHandler().

I am always stuck at

INLINE uint8_t HAL_PhySpiWriteByteInline(uint8_t value)
{
  SPDR = value;
  while (!(SPSR & (1 << SPIF)));
  return SPDR;
}

When I click on the pause.

Thanks

Regards

DJ

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

Do you really get stuck in this function and can't get out if you single step? Not likely. Most likely you are stuck in some code that polls the radio over SPI, which means that you might have the wrong settings for the radio connection.

PS: Please delete duplicate messages yourself, or fix your internet connection.

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

Got it working.

I edited

HAL_UART_CHANNEL       0

inside halUart.c and set it to 1.

I have now set it to 0 as I say a HAL_UART_CHANNEL define in config.h

Thanks

Regards

DJ

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

I want to give each node a unique ID dynamically, previously I had a 64-bit UID from EEPROM? I see that a MAC address is no longer needed, is 16-bit the only ID that seperates each node?

I use to use the same MAC address as the CORD as the network ID, so every Cord had its own network, can the same be achived with this stack?

Thanks

Regards

DJ

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

Yes, all you need is 16-bit address. If you want to have dynamic allocation, then you will have to implement it yourself. Next version of the stack will include application service that implements dynamic allocation, but it will require 64-bit UIDs to work.

There is no extended network addresses, only 16-bit PAN ID. Again, it is either static, or you have to implement dynamic allocation yourself.

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