-
Wireless Network Simulator for LWMesh
Posted by
fgargiulo
on 20 Mar, 2017 23:13
-
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 topic
http://community.atmel.com/forum/wireless-network-simulator
-
#1 Reply
Posted by
ataradov
on 20 Mar, 2017 23:40
-
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.
-
#2 Reply
Posted by
ataradov
on 20 Mar, 2017 23:46
-
Here is a full port that I used for tests. This one should work.
-
#3 Reply
Posted by
fgargiulo
on 21 Mar, 2017 00:05
-
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.
-
#4 Reply
Posted by
ataradov
on 21 Mar, 2017 00:12
-
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.
-
#5 Reply
Posted by
fgargiulo
on 21 Mar, 2017 12:13
-
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:
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/sec
Any 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.
-
#6 Reply
Posted by
ataradov
on 21 Mar, 2017 15:41
-
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.
-
#7 Reply
Posted by
fgargiulo
on 21 Mar, 2017 20:51
-
This is the error i get
process_begin: CreateProcess(NULL, gmkdir -p Debug, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [directory] Error 2
The only difference between both makefile is the line with the directory command. In PingPong makefile it is set to:
directory:
@gmkdir -p $(CONFIG)
while in the int_test makefile is set to:
directory:
@mkdir -p $(CONFIG)
I will try the example with the APP_PEER_ADDR defined and let you know if that works.
-
#8 Reply
Posted by
ataradov
on 21 Mar, 2017 21:00
-
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.
-
#9 Reply
Posted by
fgargiulo
on 21 Mar, 2017 21:03
-
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 24
#define APP_PEER_ADDR 24
and the config file for the simulation is
# 1x2 grid configuration
seed 123456
time 200000000
scale 1.0
# Name X Y ID Firmware
node R_0 -30.0 30.0 0 PingPong.bin
node R_24 0 30.0 24 PingPong.bin
# Name X Y Freq Sens Output
sniffer S_0 0.0 0.0 2405-2480 -100.0 sniffer.dcf
# Name X Y Freq Power On Off
#noise N_1 100.0 100.0 2405-2480 -10.0 2000000 1000000
Is this OK?
-
#10 Reply
Posted by
ataradov
on 21 Mar, 2017 23:04
-
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.
-
#11 Reply
Posted by
fgargiulo
on 22 Mar, 2017 11:50
-
Great. I'll be waiting for the new source files. Thanks a lot for you help Alex.
-
#12 Reply
Posted by
ataradov
on 25 Mar, 2017 03:38
-
I just pushed the update. The major difference - it works
It 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:
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()
-
#13 Reply
Posted by
fgargiulo
on 31 Mar, 2017 17:37
-
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.
-
#14 Reply
Posted by
fgargiulo
on 03 Apr, 2017 19:21
-
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.
-
#15 Reply
Posted by
ataradov
on 03 Apr, 2017 19:35
-
Did you use new LwMesh files attached to my latest post?
Yes, NetSim has changed, you need to build a new binary from GitHub.
-
#16 Reply
Posted by
fgargiulo
on 03 Apr, 2017 20:20
-
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?
-
#17 Reply
Posted by
ataradov
on 03 Apr, 2017 20:21
-
Do you think thats the origin of the problem?
Absolutely. All the changes were done there. LwMesh side had some minor clean-ups only.
-
#18 Reply
Posted by
fgargiulo
on 03 Apr, 2017 21:03
-
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.
-
#19 Reply
Posted by
fgargiulo
on 05 Apr, 2017 18:55
-
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 issue
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_STATUS
286074748 LOG R_12 appDataConf()
286075007 LOG R_12 RETRY: NWK_PHY_NO_ACK_STATUS
286088097 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.
-
#20 Reply
Posted by
ataradov
on 05 Apr, 2017 19:59
-
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.
There 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).
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.
So 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.
Is this NWK_PHY_NO_ACK_STATUS error related to the model used for the transceiver?
Well, yes, this status meant that node on the other end did not acknowledge the frame, or we did not receive that ACK.
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).
This has nothing to do with the size of the network. In this examples there are only two nodes talking at the same time.
As you can see, node 12 sends data to node 7 and fails, but node 7 signals the reception of first and second packet.
In 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.
-
#21 Reply
Posted by
fgargiulo
on 11 Apr, 2017 17:11
-
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.
-
#22 Reply
Posted by
ataradov
on 11 Apr, 2017 17:32
-
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?
That 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:
while (1)
{
// all task handlers
if (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 handled
You can automate some of that and look at NWK_Busy() as a sleep flag.
Is there any way of reducing this time?
/quote] The only real way is to introduce that sleep.
-
#23 Reply
Posted by
fgargiulo
on 11 Apr, 2017 18:19
-
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.
-
#24 Reply
Posted by
ataradov
on 11 Apr, 2017 18:26
-
(hope is the last one).
It does not need to be, I don't mind answering questions. That's why I'm here
This is because in real life there will be obstacles (buildings) between nodes that are not on the same axis
The 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.