The Long Range wifi mode

[brokenbrigde9000]

I wanted to try the long range wifi mode in Micropython but this is less obvious than I thought. I have found a handful of (somewhat vague) references to this functionality in Micropython and at this point I'm not sure if it even exists. I try to send a message between 2 ESP32 devices (dfrobot firebeetle).

I found this thread referring to these lines:

w0 = network.WLAN(network.STA_IF)
w0.config(protocol=network.MODE_LR)

which sort of make sense to me but at the same time setting protocol=network.MODE_LR does not seem to do anything for me. When called before .active(True) the code sometimes runs once, but then throws me a 'RuntimeError: Wifi Unknown Error 0x0102' even after a hard reset. When called after .active(True) everything runs fine, but definitely not in the long range mode given the regular wifi performance.

I'm running v1.14 (2021-02-02) .bin on both devices. Am I doing something wrong? Or does this functionality not exist yet?

Here is the code from my sending device:

import network
import espnow
import time

# A WLAN interface must be active to send()/recv()
sta = network.WLAN(network.STA_IF)  # Or network.AP_IF
sta.config(protocol=network.MODE_LR)
sta.active(True)

e = espnow.ESPNow()
e.active(True)
peer = b'\x10\x97\xbd\xdc\x12x'  # MAC address of peer's wifi interface
e.add_peer(peer)  # Must add_peer() before send()

e.send(peer, "Starting...")
for i in range(30):
    print('sending', i)
    e.send(peer, str(i) * 20, True)
    time.sleep(0.5)

e.send(peer, b'end')
print('finished transmission')

And here is the receiving end:

import network
import espnow

# A WLAN interface must be active to send()/recv()
sta = network.WLAN(network.STA_IF)
sta.config(protocol=network.MODE_LR)
sta.active(True)

e = espnow.ESPNow()
e.active(True)

print('start listening for data...')
while True:
    host, msg = e.recv()
    if msg:  # msg == None if timeout in recv()
        print(host, msg)
        peers = e.peers_table
        print('peer list', peers)


     if msg == b'end':
        break
print('finished receiving data')

[davefes]

A lot has happened to ESPNow since then. I had a go at LR mode with v1.17 or 1.18 and couldn't see any difference. Glenn has started a specific ESPNow thread. There is also a proper wifi.py script that handles all the issues around getting the right sequences.
https://github.com/glenn20/micropython-espnow-utils/blob/main/src/wifi.py

[davefes]

It was 1 year ago:
https://forum.micropython.org/viewtopic.php?f=5&t=12370&p=67124&hilit=ESPNow+LR#p67124
1-2dB increase and that could be due to environment changes as much as anything else. Where are the pm constants documented?

[peterhinch]

Is measuring RSSI actually relevant? It's possible that RSSI is determined by transmitter power, receiver sensitivity, and antenna gain. These parameters may not change in LR mode. Yet it might implement a modulation mode enabling the receiver to more efficiently extract data from noise. Does anyone know how LR mode (and, for that matter RSSI measurement) claims to work?

[brokenbrigde9000]

I figured comparing RSSI between 11B mode and LR mode would make sense, but my knowledge doesn't go that far. Perhaps it does not tell anything about the performance and I should stick to the real-world test (actual distance).

I have more ESP32 units in my collection, including a couple of Espressif ESP32-WROOM-32E. I have flashed micropython on them and ran the same experiment. These devices defeat the DFRobot units by a factor 3 in distance. I can walk away up to 35 meters until the ESPNow messages stop coming in.

When connecting to my home network router, they all seem to have similar performance when it comes to maximum range. I guess we got MODE_LR working, but I'm a bit disappointed in the actual range. Perhaps an open field actually allows for a couple hundred meters, but add 2 trees and a wall and the LR mode seems to barely beat a normal wifi mode.

[davefes]

The bottom line on the quality of a radio link, in my experience, was determined by iPERF testing. The amount of data you get through a radio channel at defined error-rates tells you quality.

Good summary on RSSI:
https://en.wikipedia.org/wiki/Received_signal_strength_indicator

Good point Peter. I would expect that reducing receiver bandwidth or whatever processing changes they make should allow you to get a defined QoS at a lower RSSI. Testing where a system falls-over is a rough indication of quality.

[brokenbrigde9000]

The bottom line on the quality of a radio link, in my experience, was determined by iPERF testing. The amount of data you get through a radio channel at defined error-rates tells you quality.

Thanks for the links. In my usecase, getting any data is pretty much good enough. If a sensor keeps blasting data is caught only once every 15 minutes at the 'gateway node', that would be fine.

I'm looking for several hundres of meters in range so I will probably resort to using Lora.

[davefes]

With common-variety WiFi whips at both ends, using ESPNow I typically get -73 to -76dBm at about 100 metres. Worst case -78dm, that is still a good 15dB of margin. I use LoRa for the longer links.

[glenn20]

I agree with @peterhinch here. I've had a lot of reports that LR_MODE doesn't make any difference to the RSSI values (but I wouldn't expect it to do so). The few reports that I have seen that demonstrate benefits of LR_MODE (not micropython examples) have shown a measured reduction in packet loss over distance. I think that will be the only convincing evidence for the benefits of LR_MODE.

Also - note that LR_MODE is not restricted to ESPNow usage. Espressif claims it can be used to improve long-range performance between any ESP32 devices. However, successful reports of the benefits are pretty few and far between.