8000 Issue with non-blocking LoRa socket since 1.10.0.b1 · Issue #102 · pycom/pycom-micropython-sigfox · GitHub
[go: up one dir, main page]
Skip to content
This repository was archived by the owner on Sep 16, 2024. It is now read-only.

Issue with non-blocking LoRa socket since 1.10.0.b1 #102

Closed
dmartauz opened this issue Nov 20, 2017 · 11 comments
Closed

Issue with non-blocking LoRa socket since 1.10.0.b1 #102

dmartauz opened this issue Nov 20, 2017 · 11 comments

Comments

@dmartauz
Copy link

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
Copy link
ep1cman commented Nov 27, 2017

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

@dmartauz
Copy link
Author

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
Copy link
ep1cman commented Nov 27, 2017

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
Copy link
g0hww commented Dec 8, 2017 •
edited
Loading

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
Copy link

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

@g0hww
Copy link
g0hww commented Dec 8, 2017

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

@jmarcelino
Copy link
jmarcelino commented Dec 8, 2017 •
edited
Loading

@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
Copy link
g0hww commented Dec 8, 2017

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
Copy link
g0hww commented Dec 8, 2017 •
edited
Loading

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
Copy link
g0hww commented Jan 10, 2018

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
Copy link
danspndl commented Sep 3, 2018

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!

@danspndl danspndl closed this as completed Sep 3, 2018
peter-pycom added a commit that referenced this issue Feb 28, 2020
@peter-pycom
Fix double build frozen (#102)
5c818cb 
* fix double building of frozen Mpy

the second build after a first (clean) build would rebuild the frozen Mpy.

echo ${CURR_TS} > ${BUILD_TIMESTAMP}
that doesn't work if the dir doesn't exist!
amotl pushed a commit to daq-tools/pycom-micropython that referenced this issue Mar 6, 2020
@peter-pycom @amotl
Fix double build frozen (pycom#102)
aae2981 
* fix double building of frozen Mpy

the second build after a first (clean) build would rebuild the frozen Mpy.

echo ${CURR_TS} > ${BUILD_TIMESTAMP}
that doesn't work if the dir doesn't exist!
X-Ryl669 pushed a commit to X-Ryl669/pycom-micropython-sigfox that referenced this issue May 12, 2023
@peter-pycom
Fix double build frozen (pycom#102)
9aea6cc 
* fix double building of frozen Mpy

the second build after a first (clean) build would rebuild the frozen Mpy.

echo ${CURR_TS} > ${BUILD_TIMESTAMP}
that doesn't work if the dir doesn't exist!
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@g0hww @jmarcelino @danspndl @ep1cman @danicampora @dmartauz
0