Provide meta-data from simulator to routers

[paidforby]

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 ?

[simplymathematics]

Hello. I don't mean to intrude, but I'm working on similar data from libremap.net to measure quality of service across the libremesh network. I am quite fond of y'all at sudomesh and I'm following disaster radio closely.

RSSI and SNR are physical quantities based largely on distance and locally measured noise floor values as well as the shape and angle of the antennas. Here is some background info on the model. RSSI is implemented differently by different chips. Sometimes it's a log scale. Other times it is reported as a percentage. However, those scales vary widely between manufacturers and you might have to do some calibration on your hardware to get an actual dB figure for your background noise. That figure will more-or-less be the same across a given city. The SNR (or signal-to-noise ratio) is a function of the power at a given distance from the transmitter and the background noise level. If you need any help, let me know.

To get reasonable values, you'll have to test locally. Luckily, Lora won't have the same background noise problems as wifi and performs significantly better in non line of sight circumstances. The approximations for RSSI and SNR assume line of sight.

[paidforby]

Thanks for the input @simplymathematics I haven't looked closely at the values returned by the LoRa transceiver (via LoRa library https://github.com/sandeepmistry/arduino-LoRa/blob/master/API.md#packet-rssi ). We definitely need to do more real world testing to generate realistic values.

As a temporary solution, I'm going to generate random RSSI and SNR values in the C code, since, right now, that's all simulator is doing. On the actual hardware these randomly generated values can be replaced with the LoRa library function calls.

[simplymathematics]

I'll have to pick up one of the LoRa boards you're using.

The SNR and noise floor are related as explained above. This source(pdf) explains the tech specs a bit more. The worst case is -20 dB (this means that lora can detect signal 20dB below the noise floor), but obviously signal will effect bandwidth. There's a chart on page 5 with the trade-off. Those charts are very much simulated and real-data would be awesome. . The noise due to interference along a given link is easily calculated by comparing the theoretical path loss (calculator below) and a measured value. For example, if your theoretical value is 4 and the measured is 1, your interference noise value is 3. I cannot find any data on reasonable values for this in the wild (perhaps because lora isn't widely adopted by anyone).

This one shows how to calculate SNR from actual/theoretical bandwidth, which is probably what the chip is doing (dunno what output looks like). Page 22 talks about the link budget and shows the sensitivity for a given link.

If you assume your average link should be >1kb/s , you'll need your path loss to be less than 132dB (often given a '-' to denote loss). If you play with the calculator below, you'll see why a uniformly distributed random number isn't going to reflect the real world at all. Because of the magic of logarithms, a rand(0,132) would drastically skew the results towards the positive.

Using this calculator, we can see potential links (excluding any environmental noise indicated by the gap between the path loss and measured noise). We can see that the setup documented here can reach about 370 meters with a LoRa SF =10 modulation and .976kbps data rate. This is far more likely than two people meshing within the same building. However, the random uniform distribution you suggest would say there as many connections at 1 meter as there are a 2 meters, and so on. In actuality, you are far more likely to be within 300 meters of one of these than 30. If you want to simulate path loss models, then you should randomize locations and apply the model accordingly. You'll have some cool .js code for future link budgets and a far more realistic model.

If I knew .js I'd just do it for you. 😉

I might be being a little selfish here because I would love a realistic network simulator that can run in a browser. I just don't know anything about browsers.

[simplymathematics]

https://github.com/bcopeland/wmediumd

[paidforby]

Metadata is successfully being shared between node.js and the routers/base.c after these commits, 45099fbc8b781a2372691a2b5eae5fb073ca1f6eand 2ce88d7 related to a lot of discussion in #6 (comment). We have yet to represent RSSI and SNR realistically, but that is currently outside the scope of this issue. I also don't think using RSSI and SNR as metrics is a great idea, since they may vary wildly. If anything, they will be related to packet loss closely enough, that we can just monitor packet loss as an indicator of these values.

[simplymathematics]

if they vary wildly your throughput will too. I'd have to see more research to suggest packet loss is a strong enough indicator by itself. With RSSI, SNR, and Channel, you get a full picture of the physical layer, allowing you to calculate bandwidth at any one moment. Packet loss will only indicate if a connection is congested or not. Maybe that is good enough, but your simulator will not be able to simulate bandwidth. Because LoRa is such a low bit rate, it would see to me that you'd want to know network capacity in advance, not just congestion information. For example, if we have a hypothetical node at 10m and one at 100m, the packet loss data will not indicate the loss of network capacity. You'll certainly have more packet loss at 100m than 10m, but nowhere the 99% of -signal- loss. Additionally, the longer distance also means a lower modulation scheme which transmits fewer symbols per second than a noisy signal. If you were going to read the dropped packet counter from /proc/net/dev, then a low modulation scheme would necessarily generate fewer errors because it's moving much, much less data. However, you'd want to know that this network segment has a much lower capacity than the packet drop rate alone would indicate.