mirror of
https://github.com/meshtastic/meshtastic.git
synced 2025-03-05 21:00:08 -08:00
formatting changes and add link back
This commit is contained in:
rcarteraz
parent
b2da414b05
commit
f7963b8019
|
|
@ -9,11 +9,12 @@ description: Discrete Event Simulator usage guide, simulating radio communicatio
|
|||
The discrete-event simulator mimics the radio section of the device software. It is currently based on Meshtastic 2.1.
|
||||
|
||||
## Usage
|
||||
|
||||
Please `git clone` or download this repository, navigate to the Meshtasticator folder (optionally create a virtual environment), and install the necessary requirements using:
|
||||
```pip install -r requirements.txt```
|
||||
`pip install -r requirements.txt`
|
||||
|
||||
To start one simulation with the default configurations, run:
|
||||
```python3 loraMesh.py [nr_nodes]```
|
||||
`python3 loraMesh.py [nr_nodes]`
|
||||
|
||||
If no argument is given, you first have to place the nodes on a plot. After you place a node, you can optionally set the node as a Router, change its hop limit, height (elevation), and antenna gain. These settings will automatically save when you place a new node or when you start the simulation.
|
||||
|
||||
|
|
@ -22,60 +23,68 @@ If no argument is given, you first have to place the nodes on a plot. After you
|
|||
If the number of nodes is given, it will randomly place nodes in the area. It ensures that each node can reach at least one other node. Furthermore, all nodes are placed at a configurable minimum distance (MINDIST) from each other.
|
||||
|
||||
If you placed the nodes yourself, after a simulation the number of nodes, their coordinates, and configuration are automatically saved, and you can rerun the scenario with:
|
||||
```python3 loraMesh.py --from-file```
|
||||
`python3 loraMesh.py --from-file`
|
||||
|
||||
If you want to change any of the configurations, adapt the file *out/nodeConfig.yaml* before running it with the above command.
|
||||
If you want to change any of the configurations, adapt the file _out/nodeConfig.yaml_ before running it with the above command.
|
||||
|
||||
For running multiple repetitions of simulations for a set of parameters, e.g., the number of nodes, run:
|
||||
```python3 batchSim.py```
|
||||
`python3 batchSim.py`
|
||||
|
||||
After the simulations are done, it plots relevant metrics obtained from the simulations. It saves these metrics in */out/report/* for analysis later on. See *plotExample.py* for an example Python script to plot the results.
|
||||
After the simulations are done, it plots relevant metrics obtained from the simulations. It saves these metrics in _/out/report/_ for analysis later on. See _plotExample.py_ for an example Python script to plot the results.
|
||||
|
||||
To simulate different parameters, you will have to change the *batchSim.py* script yourself.
|
||||
To simulate different parameters, you will have to change the _batchSim.py_ script yourself.
|
||||
|
||||
## Custom configurations
|
||||
Here we list some of the configurations, which you can change to model your scenario in */lib/config.py*. These apply to all nodes, except those that you configure per node when using the plot.
|
||||
|
||||
Here we list some of the configurations, which you can change to model your scenario in _/lib/config.py_. These apply to all nodes, except those that you configure per node when using the plot.
|
||||
|
||||
### Modem
|
||||
|
||||
The LoRa modem ([see Meshtastic radio settings](/docs/overview/radio-settings#predefined-channels)) that is used, as defined below:
|
||||
|
||||
| Modem | Name | Bandwidth (kHz) | Coding rate | Spreading Factor | Data rate (kbps) |
|
||||
|-------|-----------------|-----------------|-------------|------------------|------------------|
|
||||
| 0 | Short Fast | 250 | 4/8 | 7 | 6.8 |
|
||||
| 1 | Short Slow | 250 | 4/8 | 8 | 3.9 |
|
||||
| 2 | Mid Fast | 250 | 4/8 | 9 | 2.2 |
|
||||
| 3 | Mid Slow | 250 | 4/8 | 10 | 1.2 |
|
||||
| 4 | Long Fast | 250 | 4/8 | 11 | 0.67 |
|
||||
| 5 | Long Moderate | 125 | 4/8 | 11 | 0.335 |
|
||||
| 6 | Long Slow | 125 | 4/8 | 12 | 0.18 |
|
||||
| 7 | Very Long Slow | 62.5 | 4/8 | 12 | 0.09 |
|
||||
| Modem | Name | Bandwidth (kHz) | Coding rate | Spreading Factor | Data rate (kbps) |
|
||||
| ----- | -------------- | --------------- | ----------- | ---------------- | ---------------- |
|
||||
| 0 | Short Fast | 250 | 4/8 | 7 | 6.8 |
|
||||
| 1 | Short Slow | 250 | 4/8 | 8 | 3.9 |
|
||||
| 2 | Mid Fast | 250 | 4/8 | 9 | 2.2 |
|
||||
| 3 | Mid Slow | 250 | 4/8 | 10 | 1.2 |
|
||||
| 4 | Long Fast | 250 | 4/8 | 11 | 0.67 |
|
||||
| 5 | Long Moderate | 125 | 4/8 | 11 | 0.335 |
|
||||
| 6 | Long Slow | 125 | 4/8 | 12 | 0.18 |
|
||||
| 7 | Very Long Slow | 62.5 | 4/8 | 12 | 0.09 |
|
||||
|
||||
### Period
|
||||
|
||||
Mean period (in ms) with which the nodes generate a new message following an exponential distribution. For example, if you set it to 300s, each node will generate a message on average once every five minutes.
|
||||
|
||||
### Packet length
|
||||
|
||||
Payload size of each generated message in bytes. For a position packet, it will be around 40 bytes.
|
||||
|
||||
### Model
|
||||
|
||||
This feature refers to the path loss model, i.e., what the simulator uses to calculate how well a signal will propagate. Note that this is only a rough estimation of the physical environment and will not be 100% accurate, as it depends on a lot of factors. The implemented path loss models are:
|
||||
* ```0``` set the log-distance model
|
||||
* ```1``` set the Okumura-Hata for small and medium-size cities model
|
||||
* ```2``` set the Okumura-Hata for metropolitan areas
|
||||
* ```3``` set the Okumura-Hata for suburban environments
|
||||
* ```4``` set the Okumura-Hata for rural areas
|
||||
* ```5``` set the 3GPP for suburban macro-cell
|
||||
* ```6``` set the 3GPP for metropolitan macro-cell
|
||||
|
||||
- `0` set the log-distance model
|
||||
- `1` set the Okumura-Hata for small and medium-size cities model
|
||||
- `2` set the Okumura-Hata for metropolitan areas
|
||||
- `3` set the Okumura-Hata for suburban environments
|
||||
- `4` set the Okumura-Hata for rural areas
|
||||
- `5` set the 3GPP for suburban macro-cell
|
||||
- `6` set the 3GPP for metropolitan macro-cell
|
||||
|
||||
### Broadcasts or direct messages (DMs)
|
||||
By default, *DMs* is set to False, meaning it will send broadcast messages only. If you set it to True, each node will only send DMs to a random other node in the network.
|
||||
|
||||
By default, _DMs_ is set to False, meaning it will send broadcast messages only. If you set it to True, each node will only send DMs to a random other node in the network.
|
||||
|
||||
## Explanation
|
||||
|
||||
A discrete-event simulator jumps from event to event over time, where an event is a change in the state of the system. It is therefore well-suited for simulating communication networks.
|
||||
|
||||
For every node in the simulation, an instance is created that mimics the [Meshtastic logic](/docs/overview/mesh-algo). Each node runs three processes in parallel: *generateMessage*, *transmit*, and *receive*. The first creates an event by constructing a new message with a unique sequence number at a random time, taken from an exponential distribution. For now, each generated message is of the same payload size. The second and third processes model the actual transmitting and receiving behavior, respectively.
|
||||
For every node in the simulation, an instance is created that mimics the [Meshtastic logic](/docs/overview/mesh-algo). Each node runs three processes in parallel: _generateMessage_, _transmit_, and _receive_. The first creates an event by constructing a new message with a unique sequence number at a random time, taken from an exponential distribution. For now, each generated message is of the same payload size. The second and third processes model the actual transmitting and receiving behavior, respectively.
|
||||
|
||||
The model of the LoRa physical (PHY) layer is in */lib/phy.py*. Depending on the modem used, it calculates what the airtime of a packet is. The PHY layer uses a configurable path loss model to estimate whether nodes at a specific distance can sense each other's packets. Furthermore, it determines whether two packets collide, which depends on the frequency, spreading factor, received time, and received power of the two packets.
|
||||
The model of the LoRa physical (PHY) layer is in _/lib/phy.py_. Depending on the modem used, it calculates what the airtime of a packet is. The PHY layer uses a configurable path loss model to estimate whether nodes at a specific distance can sense each other's packets. Furthermore, it determines whether two packets collide, which depends on the frequency, spreading factor, received time, and received power of the two packets.
|
||||
|
||||
The routing behavior is implemented in each of the processes of the node. Inside *generateMessage*, reliable retransmissions are handled if no implicit acknowledgment is received. A MeshPacket (defined in */lib/packet.py*) is created to transfer the message. Note that there may be multiple packets created containing the same message, due to retransmissions and rebroadcasting. In *receive*, it is decided what to do on reception of a packet. A packet is flooded if its hop limit is not zero and no rebroadcast of this packet was heard before. In *transmit*, delays of the Medium Access Control (MAC) layer are called from */lib/mac.py*. The MAC uses a listen-before-talk mechanism, including introducing (random or SNR-based) delays before transmitting a packet. When a packet is ready to be transferred over the air, it is first checked whether in the meantime still no acknowledgment was received; otherwise, the transmission is canceled.
|
||||
The routing behavior is implemented in each of the processes of the node. Inside _generateMessage_, reliable retransmissions are handled if no implicit acknowledgment is received. A MeshPacket (defined in _/lib/packet.py_) is created to transfer the message. Note that there may be multiple packets created containing the same message, due to retransmissions and rebroadcasting. In _receive_, it is decided what to do on reception of a packet. A packet is flooded if its hop limit is not zero and no rebroadcast of this packet was heard before. In _transmit_, delays of the Medium Access Control (MAC) layer are called from _/lib/mac.py_. The MAC uses a listen-before-talk mechanism, including introducing (random or SNR-based) delays before transmitting a packet. When a packet is ready to be transferred over the air, it is first checked whether in the meantime still no acknowledgment was received; otherwise, the transmission is canceled.
|
||||
|
||||
The actual communication between processes of different nodes is handled by a BroadcastPipe of [Simpy](https://simpy.readthedocs.io/en/latest/examples/process_communication.html). This ensures that a packet transmitted by one node creates events (one at the start of a packet and one at the end) at the receiving nodes.
|
||||
|
|
@ -8,7 +8,7 @@ description: Overview of Meshtasticator simulator for evaluating performance and
|
|||
|
||||
import ReactPlayer from "react-player";
|
||||
|
||||
**Meshtasticator** is a discrete-event and interactive simulator that replicates the radio section of the device software. It helps evaluate the performance of various scenarios and the scalability of the protocol.
|
||||
**Meshtasticator** is a discrete-event and interactive simulator that replicates the radio section of the device software. It helps evaluate the performance of various scenarios and the scalability of the protocol. The **Meshtasticator** simulator can be found on [Github](https://github.com/meshtastic/meshtasticator).
|
||||
|
||||
## Discrete-Event Simulator
|
||||
|
||||
|
|
|
|||
|
|
@ -6,9 +6,7 @@ sidebar_position: 2
|
|||
description: Interactive Simulator usage guide for simulating multiple Meshtastic instances with TCP-based communication and configurable pathloss models.
|
||||
---
|
||||
|
||||
import ReactPlayer from "react-player";
|
||||
|
||||
The Python script `_interactiveSim.py_` uses the [Linux native application of Meshtastic](https://meshtastic.org/docs/software/linux-native) to simulate multiple instances of the device software. These instances communicate using TCP via the script, simulating the LoRa chip. The simulator forwards messages from the sender to all nodes within range, based on their simulated positions and the selected pathloss model (see [Pathloss Model](#pathloss-model)). **Note:** Packet collisions are not yet simulated.
|
||||
The Python script _`interactiveSim.py`_ uses the [Linux native application of Meshtastic](https://meshtastic.org/docs/software/linux-native) to simulate multiple instances of the device software. These instances communicate using TCP via the script, simulating the LoRa chip. The simulator forwards messages from the sender to all nodes within range, based on their simulated positions and the selected pathloss model (see [Pathloss Model](#pathloss-model)). **Note:** Packet collisions are not yet simulated.
|
||||
|
||||
## Usage
|
||||
|
||||
|
|
@ -82,7 +80,7 @@ Once the simulation starts, you can issue commands (or use a predefined [script]
|
|||
|
||||
## Usage with Script
|
||||
|
||||
Modify the `try` clause in `_interactiveSim.py_` to predefine messages. Run the simulator with the `-s` argument:
|
||||
Modify the `try` clause in _`interactiveSim.py`_ to predefine messages. Run the simulator with the `-s` argument:
|
||||
|
||||
```bash
|
||||
python3 interactiveSim.py 3 -s
|
||||
|
|
@ -106,7 +104,7 @@ python3 interactiveSim.py 3 -s
|
|||
Modify the `_out/nodeConfig.yaml_` file to adjust configurations before reloading.
|
||||
|
||||
3. **Using the Python CLI:**
|
||||
You can call functions from the Node class via `sim.getNodeById(<id>)` in `_interactiveSim.py_`. Example:
|
||||
You can call functions from the Node class via `sim.getNodeById(<id>)` in _`interactiveSim.py`_. Example:
|
||||
|
||||
```python
|
||||
node.setURL('<YOUR_URL>')
|
||||
|
|
|
|||
Loading…
Reference in a new issue