Wireless Network Simulator for LWMesh

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

  ---

  LwMesh_sim_port.zip
• #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:
  

  Code: [Select]

  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
  

  Code: [Select]

  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:
  

  Code: [Select]

  directory:
@gmkdir -p $(CONFIG)
while in the int_test makefile is set to:
  

  Code: [Select]

  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
  

  Code: [Select]

  #define APP_PEER_ADDR           24and the config file for the simulation is
  

  Code: [Select]

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

  Code: [Select]

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


  ---

  LwMesh_sim.zip
• #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
• Quote from: fgargiulo on 03 Apr, 2017 20:20

  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
  

  Code: [Select]

  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
• Quote from: 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.

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

  Quote from: fgargiulo on 05 Apr, 2017 18:55

  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.
  
  

  Quote from: fgargiulo on 05 Apr, 2017 18:55

  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.
  
  

  Quote from: fgargiulo on 05 Apr, 2017 18:55

  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.
  
  

  Quote from: fgargiulo on 05 Apr, 2017 18:55

  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
• Quote from: 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?

  
  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:
  
  

  Code: [Select]

  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.
  
  

  Quote from: fgargiulo on 11 Apr, 2017 17:11

  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
• Quote from: fgargiulo on 11 Apr, 2017 18:19

  (hope is the last one).

  It does not need to be, I don't mind answering questions. That's why I'm here
  
  

  Quote from: fgargiulo on 11 Apr, 2017 18:19

  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.