sudomesh / disaster-radio-simulator Goto Github PK

This is gonna be a quick one:

Do I need to intall this in some kind of arduino folder? I tried cloning it and compiling the firmware, but the Arduino.h could not be found. I have arduino installed, but I didn't clone the simulator in any of its directories.

Attempting to run simulator.js results in the error,

Error: Cannot find module './random.js'

Not sure if it's supposed to use random npm module, or if there is a random.js file @Juul forget to check in. Please help.

in latest commit 1500d5f retransmitting should occur after the learning phase is complete (assuming the network is well-constructed, i.e. it has some two-hop routes). Visually, it is difficult to tell when a packet is retransmitted because the retransmit gets triggered immediately after the initial transmit, such that the animations are out of sync. Additionally, it would be nice if the emoji for the retransmitted packet was the same as the emoji for the initial packet. Is this feasible @bennlich ? Right now, the data in the initial and retransmitted packets are identical, so you should be able to tie the emoji to the data in the packets.

can save to localstorage

@Juul is it possible to remove the LoRa airtime delay from the network setup (radio.js) and perform it in the router (firmware.c) instead, we'll need to port it eventually anyway. The delay makes it very difficult to predict when a packet will be transmitted by the send_packet function. At least we could add an option to disable it for testing.

Simple test router code, attempting to send_packet every 5s, results in:

[node 0] 319.02, 626.56 - range: 1724.03 | snr: 0.35
Nodes within range of node 0: 0
[node 0] transmitting packet: test packet 0 
[node 0 router] initialized
--- looping

[node 0 router] --- looping

[node 0 router] --- looping

[node 0 router] --- looping

[node 0] transmitting packet: test packet 1 test packet 2 t
[node 0 router] --- looping

[node 0 router] --- looping

[node 0 router] --- looping

[node 0 router] --- looping:

[node 0 router] --- looping

[node 0 router] --- looping

[node 0 router] --- looping

[node 0] transmitting packet: est packet 3 test packet 4 test packet 5 test packet 6 test packet 7 test packet 8 test packet 9 test packet 

We need the simulator to provide (at least) three items of meta-data to the routers,

• TxDone/RxDone interrupt to emulate DIO0 pin
• RSSI of received message
• SNR of received message
  The last two are need for metric calculations, they are accessible from the LoRa transceiver using the LoRa.packetRssi() and LoRa.packetSnr() functions. Not sure how to best to do something similar for the simulator. Any ideas where to start @Juul ?

Hi,

This is more a question than a issue.

When I follow the steps to compile the firmware, I see a compilation error.

I see the note about running it on Ubuntu 18.04. I have a 20.04, so I gave it a try.

I ran the prerequisite step, and the ./fetch_deps.sh. It went fine, no error.

When I do 'make firmware' I see the error below

./libs/backward-cpp/backward.hpp:211:10: fatal error: bfd.h: No such file or directory
  211 | #include <bfd.h>
      |          ^~~~~~~
compilation terminated.
make: *** [Makefile:26: firmware] Error 1

And then

/usr/bin/ld: cannot find -lboost_filesystem
/usr/bin/ld: cannot find -lboost_system
collect2: error: ld returned 1 exit status
make: *** [Makefile:26: firmware] Error 1

I installed additional dependencies to work around that in 20.04. You guys want a documentation MR for that ?

Long story short : On 20.04, to compile the binary for ./firmware you will need :

apt-get install binutils-dev
apt-get install libboost-filesystem-dev
sudo apt-get install libboost-filesystem-dev

I cloned the simulator and got it running but when I go to the visualizer I only see nodes, no links. This happens for any of the provided net_structures. No routing tables appear to have been populated, and messages do not travel between nodes, so it seems it's not a display issue. There really is no link.

Edit: Okay, I had one of my serial devices in the wrong spot. I CAN get messages out broadcast, it appears it's simply not populating routing tables and therefore not drawing links. Perhaps not an issue with the simulator but with the firmware. Or me.

just noticed that something is broken with the monitor node option, it prevents all nodes beside the node specified with monitorNode from transmitting. not sure what caused this change.

For unclear reasons, we are getting some unintended packet loss in the simulator. Occasionally, a node will receive a bad packet from a neighbor, which often looks something like this,

ttl: 10
length: 96
source: 160d579311b
destination: d088ffffffff
sequence: ff
type: �
data: 027286acaa7b445301e5c4f781d9a8a001fc859c7740de3401e194e785d2a042027eb2d1980b49800270d40647a8173603c427b7ee8c12d804d250c9ad46211604dcad7b6e3a293704e4be97fbc9ad6a
message type not found
88ffffffff. 25
sequence: ff
type: �
data: 027286acaa7b445301e5c4f781d9a8a001fc859c7740de3401e194e785d2a042027eb2d1980b49800270d40647a8173603c427b7ee8c12d804d250c9ad46211604dcad7b6e3a293704e4be97fbc9ad6a

It appears that the whole packet is being shifted to the right by 4 bytes, not sure why. My guess is that node.js is not blocking the receptions of packets correctly and multiple packets are occasionally be received simultaneously?

I wish there was a way to see if a packet reached its intended destination in the visualizer. Maybe we could have the intended recipient "light up" when it received a message addressed to it. I'm thinking the best way to do this is to bring the 6 byte addresses of the nodes into the visualizer (we'll want an option to display them anyway). We can probably get that address this by monitoring the packet.source during the hello phase and storing those values as a key-value pair with the node id number. Then when node X receives a packet it compares packet.destination with its stored address, and if it matches, node X "lights up", "does a jig", or otherwise indicates its excitement. Any ideas where to start with this @bennlich or any potential problems with my suggested solution?

been working a bit with @paidforby today and the firmware will occasionally crash with no useful info :-/

Maybe implementing some of these things will help debug: https://spin.atomicobject.com/2013/01/13/exceptions-stack-traces-c/

Maybe we should look at https://github.com/mwarning/MeshNetSimulator for visualization, it seems fairly fleshed out and very similar to what we are attempting to do. What do you think @Juul ?

I noticed that the hello messages don't get sent all at once, but the routing advertisements do get sent all at once. (After 30s, all nodes start firing at once.) Is this intentional? Or should we add:

_discoveryTimeout += wait;

to line 732 in firmware.c?