Atmel Lightweight Mesh stack

Go To Last Post
566 posts / 0 new

Pages

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

Has there been any updated libary for all extra features?

Or do I simple follow the RF230 to RF 233 application notes?

Thanks

Regards

DJ

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

No, there has not been an update. You will have to define new registers in the header file for the radio and then initialize them in PHY_Init().

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

If I follow the pdf doc on Atmels site , would that be good enough for this app or do I need to any thing extra.

When initializing them, is that only if it’s a new reg and not a replacement reg with a new address.

I will start on this tomorrow.

Thanks

Regards

DJ

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

Registers with the same names will have the same addresses. You just need to add the new ones.

I would just use datasheet - go over the register list and add any registers that are extra compared to what you have for 230 (or better yet, 231).

But if don't have a battery operated device or you are satisfied with the way your current devices works, it might not worth the trouble adding 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

Thanks

I do have a battery device.

So these new extra reg are they a replacment of old ones how would I know where to call them

Thanks

Regards

DJ

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

They are static initializations, you just read the description in the datasheet and set the values you like in PHY_Init().

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 will have spend some time looking at some the datasheet of both RF230 and RF233. See what new feature can be used with new regs

I believe these are shown as

 _REG

in the stack?

Would I be correct in saying that no change is necessary if I want the performance of RF233 to be like Rf230, even for power? Most I might need is the extra power, reduced power and maybe on chip security.

Bit confused do I need to follow the migration steps for lightweight.

But I have noticed that some of the changes are already included.

For example on RF230

“TRX_CMD_FORCE_PLL_ON”

is already included in at86rf230.h even though the chipset does not use it

I have added

PREP_DEEP_SLEEP

in list as well now. But do I need to modify anything for RF233 to sleep .

On the migration notes, It mentions

TRX_STATUS_RX_ON_NOCLK

, it seems that Lightweight does not use this even though its defined in project.

I thinking the migration notes menstions alot which are not used by this lightweight stack

Thank You

Thanks

Regards

DJ

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

As I said already, LwMesh uses a very small subset of all features. That's why drivers for 230 work for 233 without any changes. Header files for the transceivers include all registers and definitions, even if they are not used out of the box. This is done so that users could use them in their program without defining anything.

Migration note you are reading is not specific to LwMesh, of course, so it mentions everything.

You should not use DEEP_SLEEP mode, unless you plan to restore all registers on each wake up. You should look at Reduced Power Consumption Modes and associated registers.

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

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

Thanks.

I had a look at the datasheets and could not see an new feature that I would need. I think hardware security if enabled would be the same as it currently programed.

I also checked power during sleep mode and its 40uA as before with 230.

So am I missing anything if I was to leave the code driver as it is, as I do not really need anything more?

Thanks

Regards

DJ

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

You won't loose anything compared to 230, that's for sure.

230 had no HW security, so your current project is not using it, and if it works for you, then you can keep 230 for now. You can always switch later when 233 is officially supported.

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 can use software security for now.

But is there alot of changes to make HW security work. More then just enabling some regs.

Thanks

Thanks

Regards

DJ

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

You can use RF231 PHY as a reference, or just take entire RF231 PHY and use it instead.

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

Yeah I will give that a go thanks.

I was told software secuity is more secure as SPI data lines can be probed and possible to read security key at power up.

Is this true?

My aim to aviod an fake device(counter fit units) join my network or my device join other networks.

Thanks

Regards

DJ

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

Security key is transferred over SPI on each encryption, not only on power-up, so yes, HW security over SPI is way less secure than SW 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

I installed the WSN Monitor from the BitCloud_XMEGA_1_14_0\Evaluation Tools folder.
Can I use this also for Lightweight Mesh WSNDemo application.
If yes what protocol do i have do select (in the installation folder WSNMonitor\protocol) when i want to connect in the file->connect tab and what IP do i have to type in for TCP/IP?

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

You can use it with LwMesh, just leave protocol at its default value. You don't need to type an IP, because you don't have any IP connected devices.

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

To give each Cord a Unique 16-bit address in WSN what would be better.

Use less signiicant bytes from UID chip or use random calcultor?

Thanks

Regards

DJ

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

If UIDs are sequential, then least significant bytes will be better.

But in any case, some sort of address conflict resolution will be required.

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,

Well I need somthing for network address. In case two cords are close to one another.

At the moment cord is assigning address for nodes and routers, its got a simple increment for every new device.

Thanks

Regards

DJ

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

If they have different PAN ID, then there is no problem with address conflict.

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!

I find LWmesh also have the APP Timer with callback function like BitCoud, and removing it will bring trouble. What can I do to make the whole process fast to 8ms?

In another way, I wonder LWmesh1.1.1 can run ritht on the AVRstudio5.1.208 or not.

My hardware is not contained in the demo, what should be noted when I build a project based on the demo?

without professional basis, I can't make it easy.

Thank for your help!

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

You need to initiate sending straight from the appDataConf() callback. Instead of going into the APP_STATE_SENDING_DONE state, you must go into the APP_STATE_SEND state. You might need other changes.

All the project files are created and tested with AtmelStudio 6.1. You really should update from AS5.

A brief description of the porting process - uou need to pick the closets matching processor, search for all mentions of this processor in the source code, header files and project files and replace them with your target processor. After that you will need to address any hardware differences those two might have.

It will not be easy, you will have to spend time and learn how to do this. There is absolutely nothing I (or anyone else) can do about 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:
Correct, you don't need a coordinator in LwMesh.

How can the PC receive the data?

#if APP_ADDR == 0
  #define APP_CAPTION     "Coordinator"
  #define APP_NODE_TYPE   0
  #define APP_COORDINATOR 1
#elif APP_ADDR < 0x8000
  #define APP_CAPTION     "Router"
  #define APP_NODE_TYPE   1
  #define APP_ROUTER      1
#else
  #define APP_CAPTION     "End Device"
  #define APP_NODE_TYPE   2
  #define APP_ENDDEVICE   1
#endif

Which kind of node is the "Coordinator" here ?[/code]

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

Don't mix the stack and a particular application. Stack itself has nothing to do with the PC.

This application mimics the behavior of its counterpart from BitCloud, so it uses terms from ZigBee, so WSNMonitor could understand it. From the stack point of view it is a regular routing node.

Feel free to rename it to something else, for example, PC_GATEWAY. It won't change 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

I can use one routing node connected with PC to collect data from other node then send them to PC, and in the program named it as coordinator or else then arrange its special task, right?
Or I can programming differently for different nodes instead of one which must choose node type?

Last Edited: Sat. Dec 21, 2013 - 07:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't understand your question.

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

Sorry... Before I think the coordinator is used to collect data and send data to PC. In fact, the function of sending data to PC can be programmed for the special node, right?

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

Any device can send data to PC, even in BitCloud. It is just convenient to assign a device with a well known address (0) a gateway role. Coordinator is a "special" node in this sense.

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

Now I know that, thank you for your patient explain. :)

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

I installed the WSN_Monitor from the BitCloud_XMEGA_1_14_0\Evaluation Tools\WSNDemo (WSN Monitor) folder.
When i click connect in the WSNMonitor Application I can't choose any other Connenction then TCP/IP and i don't know where to find the standard Protocol configuration folder.
Both entries are empty now.
What do I have to do to get the WSNMonitor running with the Atmel Lightweight Mesh-WSNDemo on the 256A3BU-board with is connected with a UART-Sniffer on J4 header and powered by the USB-Port?
Only the UART-Sniffer has a Com-Port(COM7) assigned.

Attachment(s): 

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

Don't select TCP/IP, you need to work with COM ports. If by "UART sniffer" you mean some sort of UART to USB converter, then it will be the only port you will see, and that's the port you need to use.

USB connector on the board is connected to the real USB peripheral and will only work with appropriate USB stack on the device side, which is not a part of the LwMesh.

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 dropdown menu there should be an option for COM port. I don't know why it is not there, it might be a W8 problem. WSNMonitor relies on a java library to interact with COM ports, which might not be available on W8. I'm just guessing here.

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
Is it normal, that I don't have access to TRX24 registers via JTAG? (Other registers are available) I can't run even empty template from Lightweight Mesh, cos it runs away in SYS_Init(). :(

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

TRX registers become available after this peripheral is enabled. I don't think it is related to the issue you are seeing.

So what exactly runs away?

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 goes like this:

SYS_Init() -> 
   (...) ->
   PHY_Init(); -> 
      TRXPR_REG_s.trxrst = 1; -> 
      phyTrxSetState(TRX_CMD_TRX_OFF) ->
           TRX_STATE_REG = TRX_CMD_FORCE_TRX_OFF

And runs away.
I use my own boards (based on Atmega128RFA1), and everything else works fine. I have access to I/O and Timer registers and I can edit them via JTAG, but I don't have access to TRX24 registers.

I have three boards and on each there is the same problem.

Board is as simple as it can be. Decoupling capacitors, balun, antenna and 3 diodes with resistors. Just to test wireless connections.

I've double checked if there is a dedicated pin to supply transceiver's voltage, but there isn't.

Fuses are:
Extended 0xFE
HIGH 0x9D
LOW 0xC2

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

You do have 16 MHz crystal, right? Without it radio will 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

It wasn't soldered at one side :/ I'm so embarrassed now. I've checked almost everything, except that.
Thak you. You've just made my day !

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

The actual clock and interupt configurations are:
#elif F_CPU == 32000000
OSC.PLLCTRL = OSC_PLLSRC_RC2M_gc | OSC_PLLFAC4_bm;
OSC.CTRL |= OSC_PLLEN_bm;
while (0 == (OSC.STATUS & OSC_PLLRDY_bm));

CONFIGURATION_CHANGE_PROTECTION;
CLK.CTRL = CLK_SCLKSEL2_bm;

PMIC.CTRL = PMIC_HILVLEN_bm | PMIC_LOLVLEN_bm | PMIC_RREN_bm;
SYS_EnableInterrupts();

Do i can run USB in low speed mode with adding some code? (USB at 6MHz?)
Or do i can change the OSC to 32MHz and run then the USB in high speed mode 48MHz? Like the USB-Example does with udc drivers.
Do i need then other interupts activated? Like irq_initialize_vectors();
cpu_irq_enable();

In an other project i using:
#define CONFIG_USBCLK_SOURCE USBCLK_SRC_RCOSC
#define CONFIG_OSC_RC32_CAL 48000000UL
#define CONFIG_OSC_AUTOCAL_RC32MHZ_REF_OSC OSC_ID_USBSOF

#define CONFIG_SYSCLK_SOURCE SYSCLK_SRC_RC32MHZ
#define CONFIG_SYSCLK_PSADIV SYSCLK_PSADIV_2
#define CONFIG_SYSCLK_PSBCDIV SYSCLK_PSBCDIV_1_1

and

sysclk_init();
board_init();
pmic_init();
gfx_mono_init();

udc_start();
irq_initialize_vectors();
cpu_irq_enable();

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

This code start 2MHz RC oscillator and multiplies it by 16 to get 32 MHz operating frequency.

To get USB working you need to use 32 MHz RC oscillator (calibrated to 48 MHz). It can be done independently from this code.

But USB is a complex system, so you probably will have less problems if you integrate LwMesh into your existing project and let your existing system select the MCU clock. Simply don't use LwMesh HAL_Init() and call your *_init() functions instead.

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

Will Atmel Lightweight Mesh also work with 32 MHz RC oscillator? Or does the Protocol needs 2 MHz somewhere in the code?
For what stands SYS_EnableInterrupts();?
Is it the same as rq_initialize_vectors(); and/or cpu_irq_enable(); ?

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

Network stack itself does not care what clock source is used. The only place where it matters is HAL - to control timer intervals and UART baudrates.

SYS_EnableInterrupts(); on this platform is just asm("sei");

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 was wondering where this
appState = APP_STATE_WAIT_CONF;
take me in the WSNDemo code. Because this state is not being specified in the App_TaskHandler(void) functiomn. I know this is for confirmation purpose but can you explain me how this works?

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

Just an empty state, so nothing is executed while application is waiting.

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 how long does it wait? and after each waiting period it goes to next state in the APP_task Handler()? I mean if appState = APP_STATE_WAIT_CONF; is being called in APP_STATE_SEND state, after some time it goes to the state following to it, which is APP_STATE_SENDING_DONE right?

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

It stays in this state until confirmation handler (appNwkDataReq.confirm) for the request is called.

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 i am adding new state, that must be specified in appDataConf() function, which in your demo code is APP_STATE_SENDING_DONE.

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

That very much depends on what state you are adding and what 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

I am adding state to send sensor data, which is my whole purpose of making new state. It consist of collecting ADC data and giving it to the array variable and sending it across radio and getting confirmation.
btw is it necessary to have confirmation ?

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

Well, application already sends data, why not just extend its payload with the data you want?

Yes, it is necessary. Until confirmation is received memory for the request belongs to the stack.

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

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

I have a few deRFusb-23E06 on my desk...
I wonder if somebody run LightweightMesh on it.
( It is not listed within supported board list, but AT86RF231 is... )

Thanks.

Pages