Issue with non-blocking LoRa socket since 1.10.0.b1

[dmartauz]

Since 1.10.0.b1 I having issues with receiving data through raw LoRa non-blocking socket within a while loop. In case the loop is interrupted the data can be received by socket.recv() entered through the REPL.

Simplified code of receiver:

import socket
from network import LoRa

lora = LoRa(mode=LoRa.LORA, frequency=864000000, tx_power=10, bandwidth=2, sf=10, coding_rate=1, rx_iq=True)
lora_sock = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
lora_sock.setblocking(False)

while True:
    recv_msg = lora_sock.recv(512)
    if len(recv_msg) > 0:
        print("Received msg: ", recv_msg)

Output with 1.10.1.b1:

ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff9028,len:8
load:0x3fff9030,len:1076
load:0x4009fa00,len:0
ho 12 tail 0 room 4
load:0x4009fa00,len:15344
entry 0x400a070c
Traceback (most recent call last):
  File "main.py", line 10, in <module>
KeyboardInterrupt:
MicroPython v1.8.6-839-g536c958c on 2017-11-15; LoPy with ESP32
Type "help()" for more information.
>>>
>>> lora_sock.recv(512)
b' \x03$\n\xc4\x00\x11\x0e\x193u\x06'
>>> lora_sock.recv(512)
b''
>>> lora_sock.recv(512)
b''
>>> os.uname()
(sysname='LoPy', nodename='LoPy', release='1.10.1.b1', version='v1.8.6-839-g536c958c on 2017-11-15', machine='LoPy with ESP32', lorawan='1.0.0')

Output with 1.9.2.b2:

ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff9010,len:12
ho 0 tail 12 room 4
load:0x3fff9020,len:388
load:0x40078000,len:11584
load:0x4009fb00,len:848
entry 0x4009fc9c
Received msg:  b' \x03$\n\xc4\x00\x11\x0e\x191/\x06'
Received msg:  b' \x03$\n\xc4\x00\x11\x0e\x192\xf9\x05'
Received msg:  b' \x03$\n\xc4\x00\x11\x0e\x1905\x06'
Traceback (most recent call last):
  File "main.py", line 10, in <module>
KeyboardInterrupt:
MicroPython v1.8.6-796-g489fafa0 on 2017-10-15; LoPy with ESP32
Type "help()" for more information.
>>> os.uname()
(sysname='LoPy', nodename='LoPy', release='1.9.2.b2', version='v1.8.6-796-g489fafa0 on 2017-10-15', machine='LoPy with ESP32', lorawan='1.0.0')

[ep1cman]

I have observed similar behaviour, adding a 50ms delay in the loop caused the code to start working again.

[dmartauz]

It can be considered as temporary workaround however that means 50ms of wasted time it could be doing something else :) In my case ModBus client and simple web server for gateway configuration are handled within the same loop.

[ep1cman]

Im not suggesting that as a final solution I'm just adding that a delay seems to make it work to help track down the issue.

[g0hww]

I've just experienced this issue. Today I upgraded my pair of LoPys to the latest firmware. Now one of them does not receive any LoRaRAW traffic from the other, when it is fitted to an Expansion Board 2. The other LoPy is on a PyTrack - it can receive OK. If I swap the LoPys, the receive problem remains on the Expansion Board 2. The LoPy on the PyTrack can always receive. I have no DeepSleep module fitted with the Exp.Brd2. I have used some SDR software that decodes the LORA frames and can confirm that it continues to decode frames from both LoPys.
It seems that the issue might depends on the base board in use.

(sysname='LoPy', nodename='LoPy', release='1.10.2.b1', version='v1.8.6-849-g0af003a4 on 2017-11-24', machine='LoPy withESP32', lorawan='1.0.0')

[danicampora]

@g0hww Do you have anything connected to the LoRa radio pins (P5, P6 and P7) on the expansion board?

[g0hww]

Nope. Out of curiosity, I removed all the jumpers but that had no unexpected effects, other than loss of the UART connection.

[jmarcelino]

@g0hww Can you explain what you mean "receive LoRaMAC traffic from the other"? LoRaMAC traffic is usually from node to a gateway, not between nodes. Is one configured as a Nano-gateway?

[g0hww]

Sorry, I meant LoraRAW (will edit)

    self.lora = LoRa(mode=LoRa.LORA, tx_power = config.tx_dbm,
                     bandwidth=LoRa.BW_125KHZ,
                     sf = 8, preamble=12, coding_rate=LoRa.CODING_4_7,
                     frequency=config.lora_freq)

[g0hww]

Odd. Its actually just started working now, though those LoPys have been on for an hour or so in this test run. The socket calls are all blocking and I'd added the 50ms delay in for good measure. That didn't seem to help earlier on. I've been fiddling with them for about 6 hours today and its the first time it has shown signs of reception. The only reason I've seen before for these little blighters not to be able to talk over LORA is when they stubbornly synchronise their beaconing intervals so that they clobber each other, but that definitely wasn't happening here. I know the channel is good, as I have an SDR monitor. UPDATE: reset by paper-clip restores the "failing to receive" state.

[g0hww]

I updated one of my LoPys to 1.13.0.b1 and that device was then able to reliably receive my LoRa traffic when fitted to the ExpBrd2. My other LoPy still on 1.10.2.b1 continued to suffer from the problem I described above when it was fitted to the ExpBrd2 prior to upgrading. After upgrading it to 1.13.0.b1 it started to receive LoRa traffic reliably too. The issue I described seems to be fixed now :)

[danspndl]

I think this has been resolved, so I'll close this issue. If you think otherwise, feel free to reopen it and add more details!