Atmel Lightweight Mesh stack

Go To Last Post
566 posts / 0 new

Pages

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

Quote:
There is no such feature in BitCloud. Two nodes having the same short address is an error in the network that will be resolved as soon as detected.

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

If I remember correctly, you could not even join a network without an extended PANID.

And if two network had the same address for nodes and cords, but two different Expanid id both would work side by side correctly.

I will give what you say also a go..

Thanks

Regards

DJ

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

Two different networks can have devices with the same addresses. But there is no way to communicate with both of them from a device in one of the networks. On a physical and MAC level PANs are differentiated by their short PAN ID (16 bits). Extended PAN ID is added by the network layer and a short PAN ID is selected randomly to be unique.

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 understand that,

But in bitcloud I am sure i could have two networks with the same short panid, but two different exPanid. And both would work independently side by side.

Am I missing something...

Did Bitcloud assign a different panid for every network with same short address and compare it to the extended address in the start up sequence? maybe?

To avoid confusion, i think I will just added a GUI options where I can assign a short address and frequency.

Thanks

Regards

DJ

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

djoshi wrote:
But in bitcloud I am sure i could have two networks with the same short panid, but two different exPanid. And both would work independently side by side.
That is impossible. According to the spec that sityation constitutes "PAN ID conflict" and has to be resolved. That is unless you specifically force stack into this situation, but it is no longer ZigBee.

djoshi wrote:
Did Bitcloud assign a different panid for every network with same short address and compare it to the extended address in the start up sequence? maybe?
What addresses are you talking about? On startup stack scans for all available networks. If it is a coordinator, it then selects a unique short PAN ID. Starting from this point a PAN exists with ExtPANID==coord's IEEE address and a unique short PAN ID.

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, understood now

There is start up short address sequence function which assigns a short network address.

Thanks

Thanks

Regards

DJ

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

Hi Alex and everyone,
I am starting learning this protocol stack. So accept my apology if I ask very basic questions.

1. I want to implement a simple network consisting of one coordinator, one router and an end device. Is it necessary to have the same packet structure as in WSNDemo? Like this:

ypedef struct PACK AppMessage_t
{
  uint8_t     messageType;
  uint8_t     nodeType;
  uint64_t    extAddr;
  uint16_t    shortAddr;
  uint32_t    softVersion;
  uint32_t    channelMask;
  uint16_t    panId;
  uint8_t     workingChannel;
  uint16_t    parentShortAddr;
  uint8_t     lqi;
  int8_t      rssi;
//..
} AppMessage_t;

2. If that structure is not necessary, is it possible for the packet to be routed from the end device to the coordinator without this part of the code?

static void appSendData(void)
{
#ifdef NWK_ENABLE_ROUTING
  appMsg.parentShortAddr = NWK_RouteNextHop(0, 0);
#else
  appMsg.parentShortAddr = 0;
#endif
//..
}

3. In peer2peer example, if I modify the code by enabling routing in config.h, i.e. using

#define NWK_ENABLE_ROUTING

and give the coordinator, router and end device correct addresses. Will the routing happen automatically without additional code?

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

JWM2005 wrote:
1. I want to implement a simple network consisting of one coordinator, one router and an end device. Is it necessary to have the same packet structure as in WSNDemo?
No, not at all. This structure is application-specific. And you should know this since you've looked at other applications, and they don't have this structure.

JWM2005 wrote:
2. If that structure is not necessary, is it possible for the packet to be routed from the end device to the coordinator without this part of the code?
Yes, this code just populates report structure with some information from the stack. It has nothing to do with actual routing.

JWM2005 wrote:
3. In peer2peer example, if I modify the code by enabling routing in config.h, i.e. using

#define NWK_ENABLE_ROUTING

and give the coordinator, router and end device correct addresses. Will the routing happen automatically without additional code?

There is no C, R and ED in Peer2Peer. C, R and ED are only applicable to WSNDemo and even there they re because it simulates legacy ZigBee application.

In P2P device with address 0 sends data to device with address 1. If you add another device, with address 2, this device will act as a router, if needed.

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

Quote:

If you add another device, with address 2, this device will act as a router, if needed.

So does it mean the routing device is not restricted to the address range? As long as device 0 can not contact device 1 directly, it can route the packet to any device within the communication range? Is that right?

Thanks again.

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

JWM2005 wrote:
So does it mean the routing device is not restricted to the address range?
What do you mean here?

If there is no direct path between 0 and 1, any other router in the network will route the data.

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

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

What I meant was, as in developer guide, in order for the device to route a packet, it must have an address less than 0x8000. I think it is now clear.

One last question. Is there any way I can access the content of the routed packet at the routing node? Or at least to know that the router is now forwarding the packet? It seems

 static bool appDataInd(NWK_DataInd_t *ind) 

is not executed when the router is forwarding the packet.

Thanks again for your support.

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

Hi Alex

Sorry, but got another question in relation to a possible issue with two nodes with same short address.

For examples

-A Cord device send a message a node.

The wrong node receives the message first before the correct one and send a confirmation ack.

Now the second and correct node get the message, and also send a ACK confirmation.

But how does the Cord see this message?

Does this ack also invoke the confirmation interrupt function?

Thanks

Regards

DJ

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

No, only the first ACK will be used and the second one will be ignored.

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

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

How would you insure that you have no conflicts with maybe your neighbours network for example. I guess you could do a broadcast message searching for any available network, but if nodes are sleeping then this will not be very successful, unless there is node acting as the “Cord” or Router.

I am not sure if this would work for me …but this what I am planning to do as a work around to this issue so I can avoid having all my messages as broadcasts and changing large amounts of my code.

1)I am thinking adding an extra 64-bit variable in the data structure for the message, it will be called the ExtendedPanID, this would be the same UID as the Cord. Therefore in theory no two networks would have this identically.

2)Whenever a node joins a particular network it will be given this ExtendedPanID. And when a message is TX from any device this number is also included in the message body.

3)Then when any device receives a message before analysing the message to execute any command it first checks this EXtendedPanID if it matches.
-If it matches it preforms what it needs to do.

-if it does NOT match then this would mean a WRONG network For that Node ” Conflict in short network addr”. But this can also mean the RIGHT node has also got the message Or the RIGHT node is asleep .

Now as the wrong node has also got a copy of the message how can we avoid sending any ACK message? But as you have already said that this cannot be done,

I am thinking… The ACK can be delayed by maybe few seconds, within the message inbox function.

Therefore the correct NODE send its ACK first.

And if the correct NODE is a SLEEP or not even there and therefore CAN not send the first ACK, then as the Wrong node that has a delay before it send its ACK then Original message TX node will time out of waiting for the ACK reply.

If this can work it would mean in the worst case the correct node reply ACK packet would be accepted, as the delayed ACK would also be discarded.

Would this work?

Thanks

Regards

DJ

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

djoshi wrote:
How would you insure that you have no conflicts with maybe your neighbours network for example.
It will have different PAN ID. Selecting a random PAN ID is usually enough of protection, if you don't have 100's of networks nearby, of course.

djoshi wrote:
Would this work?
You are solving a problem that does not really exist.

If there is a high change that there will be a PAN ID conflict, then you need to invent a method for resolving this conflict and not change your ACK behavior.

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 some questions

1. What happened with OTA in new release of LWMesh?

2. Do you know any way to calculate the approximate maximum propagation time of the frame over the network by the number of nodes to calculate NWK_ACK_WAIT_TIME?

Thanks for your time

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

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

ariandres wrote:
1. What happened with OTA in new release of LWMesh?
It was removed in anticipation of a better implementation. The better one did not happen in time. The old implementation should work with thew new stack.

ariandres wrote:
2. Do you know any way to calculate the approximate maximum propagation time of the frame over the network by the number of nodes to calculate NWK_ACK_WAIT_TIME?
As a rule of thumb, I use a number 10 ms per hop. For an ACK wait time you need to double that, of course.

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

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

I am trying to simulate a network with multiple nodes. The part I am simulating is how my application on the PC will handle multiple nodes in the database.

I would like to call multiple times.

appSendMessage((uint8_t *)&appMsg, sizeof(appMsg));

But it seems like it only TX messages for only two sets of nodes.

Ideally I would like to place that function in a for loop and call it 100 times and then see 100 nodes appear on my PC database. But this seems not work like that.

Am I missing something important?

Thanks

Regards

DJ

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

This function puts bytes into a buffer and exits, so you are limited by the size of this buffer. Use a timer and send multiple requests giving enough time to a previous one.

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 got it working with the timer.

I can send bytes to the wsn PC program or XMEGA and I have no issues.

No I would like to send bytes from my XMEGA to the AVR with Lightweight Stack.

I can see all bytes being outputted from the XMEGA using my PC with serial port monitoring software.

But when AVR receives the bytes it seems that some bytes are distorted and sometimes some are missing.

I am using the following function

void HAL_UartBytesReceived(uint16_t bytes)
{

uint16_t i;
 
  for ( i = 0; i < bytes; i++)
  {
	tft_cmd[message_uart_counter]=HAL_UartReadByte();
	message_uart_counter++;
  }
  
  if (message_uart_counter > my_uart_buffer_limit)
     {
		 message_uart_counter = 0;
	 }
  
}

Am I doing any wrong?

Or I need to check?

If I am correct the all bitcloud use to calibrate the internal oscillator with reference to the 32khz. I do not see that happening in this stack. But the output of UART seems to be working well.

Thanks

Regards

DJ

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

Just added a 10ms delay on the XMEGA between every byte being sent, seems the lightwight stack gets all bytes correctly.

I would have thought common baud rate would be sufficient.

Thanks

Regards

DJ

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

Some delay might be required between the bytes, because a byte has to be placed into a FIFO buffer, but 10 ms seems to be hugely excessive.

What buffer sizes do you have for UART FIFOs on LwMesh 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

Buffer is 30 bytes.

I have reduces delays to 1ms.

I am not sure if this done by stack or do I need to do it...

How do I insure that all message sent at the same time to a node are recived. Is there some form of buffering?

Thanks

Regards

DJ

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

djoshi wrote:
I have reduces delays to 1ms.
I am not sure if this done by stack or do I need to do it...

UART driver is not part of the stack, it is just a demo driver, not necessarily the most optimal one for all applications. It is hard to say exactly why bytes are lost without debugging and fully understanding what gets lost and how.

djoshi wrote:
How do I insure that all message sent at the same time to a node are recived. Is there some form of buffering?
That depends on the definition of "the same time".

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

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

Hi Alex,

regarding the NWK_OPT_ACK_REQUEST,

I set the appTimerInterval to 1000ms that request data from each node each time. the node receives the request will send a data pkt back.

I'd like to reduce traffic in the network, If I disable NWK_OPT_ACK_REQUEST, does it affect the routing mechanism? because there is two coordinators in the same environment, does it cause interference if NWK_OPT_ACK_REQUEST is disabled?

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

NWK_OPT_ACK_REQUEST does not affect routing in any way.

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 the retry mechanism has to be implemented on the application level? If I resend the same frame (from appDataConf with e.g no_ack or phy_busy status) would it be detected as duplicate on the coordinator?

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

If it is a new frame, it won't be detected as a duplicate. Why should it be?

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

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

How can we make sure the pkt reach its coordinator and not get lost?

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

Use acknowledgments and check status in the confirmation.

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 coordinator that has PA and the nodes do not, if the routing mechanism initiated by the coordinator, a node will record a direct route because pkt can be send directly from the coordinator but not from the nodes back to the coordinator (has to go through some hops). A similar problem can happen with LNA on coordinator that it would record direct route to the node but it won't be able to send data directly to the node.

Could this be a problem?

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

As you said resend the frame will be consider as a new frame, then we could get a duplicate data if the ack is lost, how do we avoid that?

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

No, there should be no problems with this configuration. But in general it does not make sense to have asymmetrical PA/LNA, because they are not improving anything. If you need to go two hops in one direction, you might as well go two hops in the other and save on the hardware cost and complexity.

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

You're correct, the hardware was targeted for point to point system but as now we use Mesh, it won't be much advantageous. Many thanks Alex.

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

srapvn wrote:
As you said resend the frame will be consider as a new frame, then we could get a duplicate data if the ack is lost, how do we avoid that?
Include counters on the application level, for example. Or make your application protocol intolerant to duplicates.

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,

If a frame is sent with NWK_OPT_BROADCAST_PANID, would it be routed and hopped to the destination node, regardless of the PANIDs of routers & destination node?

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

No, it will 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

What about broadcast message on the same PAN?

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

They will be delivered to all nodes on the PAN.

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 there a way for a coordinator in a fixed PANID tell a node (in unknown PAN to join its PAN), given that they need some hops to get to each other, and the routing nodes in between are already on the same PAN?

I think of the routing nodes to rebroadcast the message from the coordinator on the broadcast PANID, but would it create too many traffic in the air if there are 100 nodes and all of them rebroadcast the message to the broadcast PANID?

It might cause infinite loop without a mechanism to avoid duplication.

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

One of possible ways:
1. Node in the first PAN sends a broadcast inter-PAN message (it will not be re-broadcasted). This message must contain all necessary information on how to reach destination node and what to tell it.
2. Any (all actually) node receiving this message will send it directly to the destination node.
3. Destination node will take action.

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

intermediate nodes also do not know the PANID of the destination node. They would have to rebroadcast the message again. So we have to implement some mechanism to avoid duplication in the vicinity of the intermediate nodes?

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

If you know the PAN ID, then include it in the original message as well, so only nodes form the same PAN will route the message. Otherwise, I don't understand what do you need.

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

Got few questions in regards to boot loader on the this stack.

If I am correct there is an over the air bootloader already done, so we can use it. But If I am correct this is done on application memory sector and not on the boot sector?

My main device unit acts like as a Cord, it is also connected to an XMEGA, is it possible to TX uart bytes and re flash the Cord via the XMEGA? Like the over the air function can I do this while in application sector?

I cannot manage to find the point in the light weight stack where the internal XTAL is being calibrated. Can you advise me which file this will be in? I aware this must be done as the UART is working without a external friendly crystal.

Thanks

Regards

DJ

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

djoshi wrote:
If I am correct there is an over the air bootloader already done, so we can use it. But If I am correct this is done on application memory sector and not on the boot sector?
Bootloader is not part of the stack, it is just there as an example. It was removed in the last versions.

It is impossible to update bootloader section in AVR using anything but JTAG.

djoshi wrote:
My main device unit acts like as a Cord, it is also connected to an XMEGA, is it possible to TX uart bytes and re flash the Cord via the XMEGA? Like the over the air function can I do this while in application sector?
This sounds like a regular serial bootloader. LwMesh bootloader could do that while it was there. It was using Xmodem protocol, which is probably no the best choice for MCU-to-MCU update.

djoshi wrote:
I cannot manage to find the point in the light weight stack where the internal XTAL is being calibrated.
It is not calibrated anywhere.

LwMesh is a networking stack, everything else there is just an example, they don't have to be optimal, they don't have to work all the time. In this case I'm assuming that MCU is calibrated enough 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

I am using version 1.1.1. I am happy with this version, is there any doc how to enable this bootloader and use it.

I can understand JTAG is required, I meant to ask do I need to run a bootloader in boot sector as the over the air updater sounds like it happening in the application area.

I think I will implement a XTAL calibration function, as this was there in Bitcloud. It gives bit more insurebilty to the UART, as I am not using an external XTAL. What is suprising is that UART works with accuracy, not seen any problem.

Thanks

Regards

DJ

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

No, there is no instruction. You will have to figure out a lot on your own.
Short version of the process:
1. Compile bootloader for your platform.
2. Program it into the part.
3. Compile application with OTA support (APP_ENABLE_OTA).
4. Program that into the part without erasing it first, so both bootloader and application are programed.

Alternatively you can use Xmodem protocol to upload the image via a serial port. To do that you will have to define a pin that is used to enter into the bootloader mode. See BOOT_PORT, BOOT_PIN, BOOT_INDEX defines.

5. Compile OTAServerDemo and program it into another part that will act as an OTA server.
6. Use tools/otaServerDemo.py to communicate to the server and upload the image over the air.

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 will look into that ,

My cord will be done via a uart with xmega, but other nodes will have to be done over the air.

Thanks

Regards

DJ

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

Step 1, my bootloader. Am I correct in saying that it reads the updated flash in certain part from application area?

Thanks

Regards

DJ

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

What do you mean "my bootloader"?

LwMesh bootloader contains two critical functions - write_page and switch. write_page writes a page of data to any location, switch copies second half of the flash into the first half of the flash.

OTA code instructs bootloader to put the received image to the second half of the flash. After image is received, application tells bootloader to switch images.

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

Seems bootloader is done no need for me to do one

Is the switch done in the bootsector?

So this boorloader is it a seperate project?

Thanks

Regards

DJ

Pages