Wireless Network Simulator for LWMesh - Page 1
Forum section: electronics / general

author: fgargiulo
author_rank: Contributor
timestamp: March 20, 2017, 11:13:18 pm
content: Hello,I've found a software for wireless network simulations with LWMesh and I'm really interested in using it for my own application. I was hoping to use this simulation software for testing some modifications to the stack and in order to understand the behaviour of the whole network with 1000 nodes.I started by compiling the PingPong example, but after a few debug lines, i keep getting an error of an unhandled write (Error: unhandled word write @ 0x480f4c0e = 0x00000008). I used the makefile inside the project folder and i added the missing files of the LWMesh directly from the source codes of Atmel Website (all files from network and system layer). Am i missing something? I would really appreciate the help of someone who has already used the software.The software i'm talking about can be found on this topichttp://community.atmel.com/forum/wireless-network-simulator

author: ataradov
author_rank: Super Contributor
timestamp: March 20, 2017, 11:40:51 pm
content: Something is wrong with the port for the simulator. Address 0x480f4c0e does not match any of the peripherals on the real device or virtual device.Can you describe your process of porting?I will try to find already ported application as an example.Also, simulation of 1000 nodes will be really-really slow.

author: ataradov
author_rank: Super Contributor
timestamp: March 20, 2017, 11:46:15 pm
content: Here is a full port that I used for tests. This one should work.

author: fgargiulo
author_rank: Contributor
timestamp: March 21, 2017, 12:05:08 am
content: Hello Alex,I first tried to compile the files inside " LwMesh_Sim.zip" using arm-none-eabi-gcc, but it failed because of some files missing. Then i realized that the files included inside the .zip where only the part that needed to be ported, and that the base application was missing (system and network). I guess it is because those files don't need any changes for using it with the simulation software. So i added the missing files that the make file couldn't find and it compiled succesfully. I used the files from "Lightweight Mesh Software Stack v1.2.1" that are in the Atmel website. I did not change anything from the main application (PingPong.c) or any other file in the original project. When i use the new .bin file i get the error i mentioned. Any suggestions? I'm sorry if there is something i'm doing wrong or that i've missed. Thanks again for your help.

author: ataradov
author_rank: Super Contributor
timestamp: March 21, 2017, 12:12:24 am
content: Try the project I attached to my second message.The reason I don't make full projects readily available is that I'm not sure if I can distribute Atmel code that way without violating the license.

author: fgargiulo
author_rank: Contributor
timestamp: March 21, 2017, 12:13:49 pm
content: Thanks for the new project. I've been able to compile the int_test project, but not the PingPong one using the attached makefile. If i use the makefile from int_test with PingPong it will compile succesfully. However, when i run the simulation using the PingPong.bin created from the PingPong folder, it frezees right after initializatation and i don't see any transmitted packets.This is what i get:Code:0 TRX R_0 started (-30.00, 30.00)0 TRX R_1 started (-10.00, 30.00)0 TRX R_2 started (10.00, 30.00)0 TRX R_3 started (30.00, 30.00)0 TRX R_4 started (-30.00, 10.00)0 TRX R_5 started (-10.00, 10.00)0 TRX R_6 started (10.00, 10.00)0 TRX R_7 started (30.00, 10.00)0 TRX R_8 started (-30.00, -10.00)0 TRX R_9 started (-10.00, -10.00)0 TRX R_10 started (10.00, -10.00)0 TRX R_11 started (30.00, -10.00)0 TRX R_12 started (-30.00, -30.00)0 TRX R_13 started (-10.00, -30.00)0 TRX R_14 started (10.00, -30.00)0 TRX R_15 started (30.00, -30.00)200000000 cycles in 44130 ms => 4532064 cycles/secAny idea why? Thanks again for all your help. Once i get this example to work, then i can make my own modifications without bothering you.

author: ataradov
author_rank: Super Contributor
timestamp: March 21, 2017, 03:41:13 pm
content: Makefile from Peer2Peer should work, so let's figure that out first. What errors do you get?The output you get looks correct, if devices just started and did not send anything.You need to set APP_NWK_SIZE equal to the size of the network. Although even with your config, device 0 should have sent something.It may be easier to start with configuration where APP_PEER_ADDR is defined, so you will only have 2 devices (0 and APP_PEER_ADDR) sending things to each other.

author: fgargiulo
author_rank: Contributor
timestamp: March 21, 2017, 08:51:07 pm
content: This is the error i getCode:process_begin: CreateProcess(NULL, gmkdir -p Debug, ...) failed.make (e=2): The system cannot find the file specified.make: ***  Error 2The only difference between both makefile is the line with the directory command. In PingPong makefile it is set to:Code:directory:@gmkdir -p $(CONFIG)while in the int_test makefile is set to:Code:directory:@mkdir -p $(CONFIG)I will try the example with the APP_PEER_ADDR defined and let you know if that works.

author: ataradov
author_rank: Super Contributor
timestamp: March 21, 2017, 09:00:38 pm
content: Yeah, that's insignificant.I'm traveling at the moment. I will try this stuff once I get a chance. I have not touched this simulator in a while. It was working when I left it.

author: fgargiulo
author_rank: Contributor
timestamp: March 21, 2017, 09:03:29 pm
content: Thanks, i would appreciate it.I just tried with the APP_PEER_ADDR defined but i get the same behavior as if there is no transmission from node 0. Peer address is set to 24Code:#define APP_PEER_ADDR 24and the config file for the simulation isCode:# 1x2 grid configurationseed123456time200000000scale1.0#NameXYIDFirmwarenodeR_0-30.030.00PingPong.binnodeR_24030.024PingPong.bin#NameXYFreqSensOutputsnifferS_00.00.02405-2480-100.0sniffer.dcf#NameXYFreqPowerOnOff#noiseN_1100.0100.02405-2480-10.020000001000000Is this OK?

author: ataradov
author_rank: Super Contributor
timestamp: March 21, 2017, 11:04:48 pm
content: Ok, I see a problem, but I will need some time to get things fixed. It will have to wait until this weekend, I will need to figure out what exactly went wrong. I think header file for the simulated SoC got mixed up with the one from an experimental version.You will have a working solution by the end of the week.On the other hand, I will add some other cool new features from that experimental version.

author: fgargiulo
author_rank: Contributor
timestamp: March 22, 2017, 11:50:28 am
content: Great. I'll be waiting for the new source files. Thanks a lot for you help Alex.

author: ataradov
author_rank: Super Contributor
timestamp: March 25, 2017, 03:38:38 am
content: I just pushed the update. The major difference - it worksIt includes better (but less tested) RF model. It also includes new logging capability. Now you can just do something like this 'SYS_CTRL_LOG = "test string 123" ' and the string will be sent to the simulation environment and printed on the console. Because of this change, I disabled debug output for TRX. You can enable it back in the utils.h, just set DEBUG_TRX back to 1.Another major change is support for interrupts and sleep. Now you can call "asm("wfi");" when application is waiting for the external event (a frame from other devices, or a timer event). Doing so will exclude this device from the simulation, which will speed up the whole thing quite a bit.I will make a simple example that takes advantage of this feature tomorrow. For now, I'm including another version of LwMesh port. When you run it, you should see the output that look like this:Code:20942 LOG R_11 --- main() ---21652 LOG R_9 --- main() ---74447 LOG R_15 --- main() ---106942 LOG R_8 --- main() ---136807 LOG R_0 --- main() ---139442 LOG R_1 --- main() ---140383 LOG R_0 appSendData()144327 LOG R_6 --- main() ---167202 LOG R_10 --- main() ---179337 LOG R_14 --- main() ---185237 LOG R_4 --- main() ---199692 LOG R_3 --- main() ---272212 LOG R_12 --- main() ---277732 LOG R_7 --- main() ---304702 LOG R_5 --- main() ---307712 LOG R_13 --- main() ---317747 LOG R_2 --- main() ---3144264 LOG R_11 appDataInd()3149412 LOG R_0 appDataConf()3242088 LOG R_11 appSendData()6249321 LOG R_12 appDataInd()6254516 LOG R_11 appDataConf()

author: fgargiulo
author_rank: Contributor
timestamp: March 31, 2017, 05:37:58 pm
content: I'm really grateful for all the help you've provided. Those new features you mention are really interesting. I'll be trying the new simulation software this weekend, so i'll let you know how it went.

author: fgargiulo
author_rank: Contributor
timestamp: April 03, 2017, 07:21:20 pm
content: Hi Alex. I've tried the new files without success. I get the same error of an unhandled word write. I had to change a line in the makefile from @gmkdir to @mkdir or otherwise it failed. Do you think this could be the problem? I'm also running the NetSim.exe from the original post i mention. Has it changed ever since? Thanks again for your help.

author: ataradov
author_rank: Super Contributor
timestamp: April 03, 2017, 07:35:23 pm
content: Did you use new LwMesh files attached to my latest post?Yes, NetSim has changed, you need to build a new binary from GitHub.

author: fgargiulo
author_rank: Contributor
timestamp: April 03, 2017, 08:20:00 pm
content: Yes, i used the LwMesh files from the latest post. I compiled the PingPong app and used the PinPong_4x4.cfg with the NetSim.exe. I'll try building the latest NetSim from GitHub. Do you think thats the origin of the problem?

author: ataradov
author_rank: Super Contributor
timestamp: April 03, 2017, 08:21:12 pm
content: Quote from: fgargiulo on April 03, 2017, 08:20:00 pmAbsolutely. All the changes were done there. LwMesh side had some minor clean-ups only.

author: fgargiulo
author_rank: Contributor
timestamp: April 03, 2017, 09:03:14 pm
content: Thanks Alex. It's working now. I'll start with my tests and let you know how they go. Your support has been really important for the development of this project. I'm really grateful for that.

author: fgargiulo
author_rank: Contributor
timestamp: April 05, 2017, 06:55:23 pm
content: Hello again. I was wondering if there is a way for setting the physical layer to work in the band of 902-928MHz, since our application uses a transceiver at 915MHz. This would let me set the distance between nodes as they'll be in real life.I've tried the default PingPong example and something has come across. Using the 4x4 config file with scale 1.0 everything seems to be working fine. But for scales of 4.0 and 5.0, sometimes transmition fails and the node has to retransmit the message. I've added some new logs in order to identify the error and it seems to be (at least most of the times) NWK_PHY_NO_ACK_STATUS. The destination node, however, receives all the packets (original and retransmitted), rejecting every packet but the first one one (or at least that's what i understand from the source code). Is this NWK_PHY_NO_ACK_STATUS error related to the model used for the transceiver? This worries me, because if it already happens with a network of 16 nodes it will be much worse with one of 250 nodes (or even 1000, which is our goal).Here is a piece of the log that shows the issueCode:282951055 LOG R_12 appDataInd()282965601 LOG R_3 appDataConf()283040686 LOG R_12 appSendData()286052770 LOG R_7 appDataInd()286056770 LOG R_12 appDataConf()286057029 LOG R_12 RETRY: NWK_PHY_NO_ACK_STATUS286074748 LOG R_12 appDataConf()286075007 LOG R_12 RETRY: NWK_PHY_NO_ACK_STATUS286088097 LOG R_7 appDataInd()286098983 LOG R_12 appDataConf()286146075 LOG R_7 appSendData()289152319 LOG R_14 appDataInd()289157212 LOG R_7 appDataConf()289247734 LOG R_14 appSendData()As you can see, node 12 sends data to node 7 and fails, but node 7 signals the reception of first and second packet.

author: ataradov
author_rank: Super Contributor
timestamp: April 05, 2017, 07:59:12 pm
content: Quote from: fgargiulo on April 05, 2017, 06:55:23 pmThere is no easy way. You wild have to adjust the air model in medium.c. You are better off just approximating sub-GHz behavior via slightly larger scale factor (probably in the range 2-5, depending on your real hardware).Quote from: fgargiulo on April 05, 2017, 06:55:23 pmSo that's 50 meter grid. And nodes 7 and 12 are 360 meters apart in this grid. They will obviously have some issues talking. That's exactly how it works in real life.Quote from: fgargiulo on April 05, 2017, 06:55:23 pmWell, yes, this status meant that node on the other end did not acknowledge the frame, or we did not receive that ACK.Quote from: fgargiulo on April 05, 2017, 06:55:23 pmThis has nothing to do with the size of the network. In this examples there are only two nodes talking at the same time.Quote from: fgargiulo on April 05, 2017, 06:55:23 pmIn this case application-level retry had to be performed as well. Basically 7 received the message, but could not send an ACK, or 12 could not receive that ACK (you can know more if you enable PHY debug messages). So 7 had to retry, and on a third attempt it all worked out. This is not uncommon scenario as distance between the nodes increases. There is probably more optimal route through some other nodes (not direct), and routing algorithm will probably figure that out eventually.All of this is normal, and absolutely reflects real life.Actually enable PHY debug messages, they are entertaining to watch.

author: fgargiulo
author_rank: Contributor
timestamp: April 11, 2017, 05:11:55 pm
content: Hey Alex. Could you explain me how the "asm("wfi")" directive works? My application waits for a periodic timer to send data, so it would be useful to exclude the corresponding node from the simulation until that timer expires. Where should i call the instruction to achieve that?I've been doing some simulations with a network of 100 nodes and it's working quite fine. The ratio between real time and simulation time is most of the times 3 to 1. I've done some simulations with different number of nodes, and my estimation is that for a network 1000 nodes (which is our goal) the ratio would be 60 to 1, which is a little high since it would take almost two and a half days for a one hour simulation time. Is there any way of reducing this time?Thanks again for your help.

author: ataradov
author_rank: Super Contributor
timestamp: April 11, 2017, 05:32:58 pm
content: Quote from: fgargiulo on April 11, 2017, 05:11:55 pmThat largely depends on your application overall design. Think about this instruction as a "sleep" instruction with wake up on any interrupt. So you would put it anywhere you would put a regular sleep in a real world.Keep in mind that application timers run on a fixed interval hardware timer, so it will generate interrupts on a periodic basis. So you need to do something like this:Code:while (1){// all task handlersif (sleep_flag)asm("wfi");}You need to set sleep_flag according to your application logic. Basically set it true before waiting on a timer, and set it to false when timer handler is called and application needs to do some work.This will wake up MCU periodically on a hardware timer, but it will go back to sleep as soon as timer interrupt is handledYou can automate some of that and look at NWK_Busy() as a sleep flag.Quote from: fgargiulo on April 11, 2017, 05:11:55 pm

author: fgargiulo
author_rank: Contributor
timestamp: April 11, 2017, 06:19:10 pm
content: Thanks Alex.I have another question (hope is the last one). I'd like to implement a grid network where nodes can communicate only with other nodes that are on the same axis (x or y). This is because in real life there will be obstacles (buildings) between nodes that are not on the same axis (remember it's aimed for a street lighting application). Is there a way of simulating this, either by using the .cfg file, noise sources or by modifying the simulation engine? I imagine though that the easiest way would be to filter this inside the firmware (maybe at network layer) by defining network address with some kind of pattern that represents the current position of the node (and hence the ones that it can communicate to). What do you think about it? Hope i've been clear enough.

author: ataradov
author_rank: Super Contributor
timestamp: April 11, 2017, 06:26:20 pm
content: Quote from: fgargiulo on April 11, 2017, 06:19:10 pmIt does not need to be, I don't mind answering questions. That's why I'm hereQuote from: fgargiulo on April 11, 2017, 06:19:10 pmThe real problem that buildings create is not attenuation, but multi-path propagation. And this is next to impossible to simulate.I would suggest assuming that there are no buildings for software debugging, and maybe just increase block size or decrease receiver sensitivity, so there is no physical link anyway.This is not 100% accurate physical simulation anyway. It is as close as software can practically get, but it is still mostly useful for debugging general algorithms, not specific scenarios and installations. You won't know how accurate this simulator is for your use case until you actually try with real devices.

author: fgargiulo
author_rank: Contributor
timestamp: April 12, 2017, 01:50:38 pm
content: Do you have any example where you use the sleep function? I'm having some trouble adding that functionality to my application. It seems that after calling asm("wfi"), no more code is executed (ever). I'm pretty sure i'm doing something wrong. Thanks.

author: ataradov
author_rank: Super Contributor
timestamp: April 12, 2017, 04:36:55 pm
content: Quote from: fgargiulo on April 12, 2017, 01:50:38 pmI will come up with one this weekend.Quote from: fgargiulo on April 12, 2017, 01:50:38 pmYou are probably not doing anything wrong. There is a problem with this implementation, actually.In a real core "wfi" will wake up if interrupt is enabled in the peripheral, even if it is disabled in the NVIC to actually call the interrupt handler.In this implementation, there is no NVIC, so interrupt handlers must be enabled, but they are not really needed in LwMesh.So I will need to add a simulated NVIC. To make it all work as in real system.I was also thinking about it, and it probably would not be too hard to add arbitrary signal attenuation between the nodes. This will let you specify the walls and buildings. It will work something like this. Assume you have 2 nodes in the configuration handler with IDs 0 and 1.You will specify additional attenuation value between the nodes:Code:att 0 1 1000att 1 0 1000This will create bidirectional attenuation of 1000 dBm (basically total block). You will have to manually identify nodes that should be connected, of course. This will probably be easier with some sort of config generation tool.

author: fgargiulo
author_rank: Contributor
timestamp: April 12, 2017, 07:21:30 pm
content: That's really awesome Alex. I'll start working on the config generation tool. I really appreciate your help.

author: ataradov
author_rank: Super Contributor
timestamp: April 14, 2017, 07:32:00 pm
content: Added both things. On my machine, I get about 10x increase in speed:Code:200000000 cycles in 7607 ms => 26291573 cycles/sec --- with wfi200000000 cycles in 74895 ms => 2670405 cycles/sec --- without wfiGet a new version from GitHub, and updated example attached. Format of the new path loss command:QuoteAnd as far as WFI goes, as you will see, I added this code to the main loop:Code:if (!NWK_Busy())asm("wfi");This makes sure that as long as stack has nothing to do, device sleeps, while waiting on interrupts. There are two sources of interrupts at the moment - the radio, and the timer. Timer interrupts every 10 ms to maintain software timers, and radio interrupts when frames are received and sent.This makes sure that stack is not blocked when it is busy processing the frames.But this does not really take into account application needs. In this case application is very simple, and it is not a problem, but more complex application may want to indicate that they are also busy doing useful things at the moment, ad node should not sleep.To indicate that application is busy, it must call NWK_Lock(), and when it is done it must call NWK_Unlock(). NWK_Lock() and NWK_Unlock() must come in symmetrical pairs, since one simply increments a counter, and another one decrements. Once counter is 0 - the stack is ready for sleep.

author: ataradov
author_rank: Super Contributor
timestamp: April 14, 2017, 07:34:12 pm
content: I only did very basic testing on all this, so please report any problems.

author: fgargiulo
author_rank: Contributor
timestamp: April 18, 2017, 12:57:35 pm
content: I've been testing the modifications and it all works awesome. The speed improvement and the new attenuation functionality lets me simulate lots of different environments. I'll let you know if i find any issues.So far so good I've been able to test a network of 240 nodes. I'd like to move to a network of more than 256 nodes, but I've seen that some variables of the stack are initialized as uint8_t, maybe limiting max number of nodes. Am i right?

author: ataradov
author_rank: Super Contributor
timestamp: April 18, 2017, 04:41:17 pm
content: The only thing that is really limited is routing table. It does make sense to just go and change all uint8_t in loops to int. This change was already done, but I never got to release that version of LwMesh.