Alter lora frequency without reset
-
Re: Changing LoRa parameters - Is necessary to restart device?
Please LopyTeam, lopy4 crashes if i change the frequency later in the program.
-
@Gijs said in Alter lora frequency without reset:
Also, setting a timeout does not alleviate the issue of the taken semaphore.
No, but on timeout the semaphore could be released too.
-
@robert-hh said in Alter lora frequency without reset:
If no timeout is given, when can the device be considered as failing the join. According to what I have seen, it will continue to send join requests until you stop it manually,
Indeed, however, I do not know of a way to to stop joining from python currently, only by hard-resetting the device. Also, setting a timeout does not alleviate the issue of the taken semaphore.
-
@Gijs said in Alter lora frequency without reset:
but we never return it if the LoRa is not joined
If no timeout is given, when can the device be considered as failing the join. According to what I have seen, it will continue to send join requests until you stop it manually,
-
After some more digging last night and this morning, I found the issue, and why sleeping sometimes solves the problem.
For the ones who are interested:
WexsemaphoreTake()
at the beginning of join, but we never return it if the LoRa is not joined, nor do we return the semaphore when the LoRa is re-initalized. Only when the LoRa radio goes to sleep or the LoRa is joined, wexsemaphoreReturn()
. I made a quick fix that always returns the semaphore when the LoRa is initalized (inlora_init_helper()
at the top).in
esp32/mods/modlora.c
:
around line 1100, we take the semaphore in the joining process
a bit above that, we have the Sleep and Wake commands that return the semaphore.
and around line 580, we give the semaphore once the LoRa has joined.In conclusion, all you need to do is add
xSemaphoreGive(xLoRaSigfoxSem);
at the top oflora_init_helper()
function. Now I feel like this is not the 'proper' solution, but it seem to work in the limited cases I tested..
-
@jcaron I know but i want to test some gateways and want to program the test on a single device so i can switch between frequencies. Its not for an actual product.
-
@momo232030 If I understand things correctly, you are trying to write code that will try to join on various frequencies, probably to get a single product that can work in any of those regions without manual configuration, right?
Remember that you are not allowed to do this. Transmitting on the 868 MHz band in the US or on the 915 MHz in Europe is in breach of regulations. This would automatically make your device not compliant with local regulations, and not allowed for sale. No FCC marking, no CE marking.
You must either provision devices separately for the different markets (i.e. pre-configure them), or provide a way for the user to specify which band to use, or have some means to auto-detect it (e.g. if it connects to Wi-Fi, using an IP-to-country geolocation DB or service, or if it includes a GPS chip, based on coordinates — there may be other options).
You most definitely don't want a device which, until it successfully joins, tries alternatively all those different bands.
Note in addition that the US band allows much higher power than what is allowed for most ISM bands in the EU region. You don't want to be caught with a device transmitting at full power on the 915 MHz band in Europe (it is used by mobile operators for 3G or 4G).
If you think "but mobiles phones do it", remember that they don't send anything first. They always scan passively for available networks, and will only transmit once they have identified a network. LoRa end devices transmit first (gateways don't send beacons or anything similar in the general case).
-
While looking through the source, it seems a task is created for sending Join messages and we never close it if the unit does not join (if
timeout=0
is specified).
(lines 1960-1980 ofmodlora.c
):// get the timeout int32_t timeout = INT32_MAX; if (args[3].u_obj != mp_const_none) { timeout = mp_obj_get_int(args[3].u_obj); } // send a join request message cmd_data.info.join.activation = activation; cmd_data.cmd = E_LORA_CMD_JOIN; lora_send_cmd(&cmd_data); <--this will change the lora_obj.joined variable if (timeout > 0) { <-- timeout = 0, so it falls through this conditional while (!lora_obj.joined && timeout >= 0) { mp_hal_delay_ms(LORA_JOIN_WAIT_MS); timeout -= LORA_JOIN_WAIT_MS; } if (timeout <= 0) { nlr_raise(mp_obj_new_exception_msg(&mp_type_TimeoutError, "timed out")); } } return mp_const_none;
Im not sure why
time.sleep(60)
helps here, but it seems to timeout the task and let us create a new LoRa object for a different region
-
@Gijs That gives a consistent behaviour here of failing join attempts. Which is expected here.
What kind of timeout applies?
-
I had a chat with @momo232030 and it seems
time.sleep(60)
between the region switch did the trick. I know it has to be 30 seconds at least, did not really optimise it
-
@momo232030 However, if it fails the first join, it will print the text "second join", but then it will freeze. It does not even set the rgbled.
-
@momo232030 Yes. I do. And also the device joins at the first attempt for EU868. Does your device joins at the first run?
-
@Gijs @robert-hh
do you reachprint("second join")
on line 42import ubinascii import pycom import socket import time from network import LoRa # Colors off = 0x000000 red = 0x7f0000 green = 0x007f00 blue = 0x00007f # Turn off hearbeat LED pycom.heartbeat(False) print("start 868") # Initialize LoRaWAN radio lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.EU868) dev_eui = ubinascii.unhexlify('AAAAAAAAAAAAA868') app_eui = ubinascii.unhexlify('70B3D57ED003039C') app_key = ubinascii.unhexlify('2B7E151628AED2A6ABF7158809CF4F3C') lora.join(activation=LoRa.OTAA, auth=(dev_eui, app_eui, app_key), timeout=0) count = 0 while not lora.has_joined(): time.sleep(2.5) print('Not yet joined...({})'.format(count)) count += 1 if count > 5: break; if lora.has_joined(): print("joined 868") print("start 915") # Initialize LoRaWAN radio lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.US915) # Set network keys dev_eui = ubinascii.unhexlify('AAAAAAAAAAAAA915') app_eui = ubinascii.unhexlify('70B3D57ED003039C') app_key = ubinascii.unhexlify('2B7E151628AED2A6ABF7158809CF4F3C') #CRASHES AT THE NEXT LINE lora.join(activation=LoRa.OTAA, auth=(dev_eui, app_eui, app_key), timeout=0) print("second join") pycom.rgbled(0x1f0000) # Loop until joined while not lora.has_joined(): print('Not OTAA joined yet...') pycom.rgbled(0x1f0000) time.sleep(0.1) pycom.rgbled(off) time.sleep(2.4) print('OTAA Joined') pycom.rgbled(0x00001f) # create a LoRa socket s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) # set the LoRaWAN data rate s.setsockopt(socket.SOL_LORA, socket.SO_DR, 3) # make the socket non-blocking s.setblocking(False) # send some data s.send(bytes([0x01, 0x02, 0x03])) # get any data received... data = s.recv(64) print(data)
-
@Gijs The OP has a sample code here: https://github.com/pycom/pycom-micropython-sigfox/pull/474
But even with that sample code I do not get a crash. Obviously, the device does not join here at 915 MHz, since I'm in a EU868 region. But no crash so far.P.S.: I run my test devices without antenna, but with a 50 Ohm terminator instead, so they will not create too much interference. For test bench operation the stray radiation from the board and pigtail are still strong enough for testing at a level of about -60dB.
-
this is my code every time i switch to another region the lopy 4 the device freezes.
import ubinascii import pycom import socket import time from network import LoRa # Colors off = 0x000000 red = 0x7f0000 green = 0x007f00 blue = 0x00007f # Turn off hearbeat LED pycom.heartbeat(False) print("start 868") # Initialize LoRaWAN radio lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.EU868) dev_eui = ubinascii.unhexlify('AAAAAAAAAAAAA868') app_eui = ubinascii.unhexlify('70B3D57ED003039C') app_key = ubinascii.unhexlify('2B7E151628AED2A6ABF7158809CF4F3C') lora.join(activation=LoRa.OTAA, auth=(dev_eui, app_eui, app_key), timeout=0) count = 0 while not lora.has_joined(): time.sleep(2.5) print('Not yet joined...({})'.format(count)) count += 1 if count > 5: break; if lora.has_joined(): print("joined 868") print("start 915") # Initialize LoRaWAN radio lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.US915) for index in range(0, 7): lora.remove_channel(index) for index in range(16, 72): lora.remove_channel(index) lora.add_channel(8, frequency=903900000, dr_min=0, dr_max=3) lora.add_channel(9, frequency=904100000, dr_min=0, dr_max=3) lora.add_channel(10, frequency=904300000, dr_min=0, dr_max=3) lora.add_channel(11, frequency=904500000, dr_min=0, dr_max=3) lora.add_channel(12, frequency=904700000, dr_min=0, dr_max=3) lora.add_channel(13, frequency=904900000, dr_min=0, dr_max=3) lora.add_channel(14, frequency=905100000, dr_min=0, dr_max=3) lora.add_channel(15, frequency=905300000, dr_min=0, dr_max=3) lora.add_channel(65, frequency=904600000, dr_min=4, dr_max=4) # Set network keys dev_eui = ubinascii.unhexlify('AAAAAAAAAAAAA915') app_eui = ubinascii.unhexlify('70B3D57ED003039C') app_key = ubinascii.unhexlify('2B7E151628AED2A6ABF7158809CF4F3C') #CRASHES AT THE NEXT LINE lora.join(activation=LoRa.OTAA, auth=(dev_eui, app_eui, app_key), timeout=0) pycom.rgbled(0x1f0000) # Loop until joined while not lora.has_joined(): print('Not OTAA joined yet...') pycom.rgbled(0x1f0000) time.sleep(0.1) pycom.rgbled(off) time.sleep(2.4) print('OTAA Joined') pycom.rgbled(0x00001f) # create a LoRa socket s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) # set the LoRaWAN data rate s.setsockopt(socket.SOL_LORA, socket.SO_DR, 3) # make the socket non-blocking s.setblocking(False) # send some data s.send(bytes([0x01, 0x02, 0x03])) # get any data received... data = s.recv(64) print(data)
-
Im sorry, I sort of understand that the definition of the function issues a NOP in the ESP32, or it will crash (we need the function defined at least). then what does the PR have to do with this?
@momo232030 I cannot reproduce the module crashing after the
lora.join()
method multiple times, even after joining was successful and resetting the region. are you sure it is caused by that? Do you update the region before calling joinFrequency?Best,
Gijs
-
@Gijs lora.reset() will not solve the problem of this post, since on ESP rev1 devices like LoPy4 and Fipy lora.reset() is a NOP.
Code of the reset function:void SX1276Reset( void ) { if (micropy_lpwan_use_reset_pin) { // Set RESET pin to 0 GpioInit( &SX1276.Reset, RADIO_RESET, PIN_OUTPUT, PIN_PUSH_PULL, PIN_NO_PULL, 0 ); // Wait 2 ms DelayMs( 2 ); // Configure RESET as input GpioInit( &SX1276.Reset, RADIO_RESET, PIN_INPUT, PIN_PUSH_PULL, PIN_NO_PULL, 1 ); // Wait 6 ms DelayMs( 6 ); } else { DelayMs( 2 ); } }
Code in main.c that affects micropy_lpwan_use_reset_pin:
if (esp32_get_chip_rev() > 0) { micropy_hw_antenna_diversity_pin_num = MICROPY_SECOND_GEN_ANT_SELECT_PIN_NUM; micropy_lpwan_ncs_pin_index = 1; micropy_lpwan_ncs_pin_num = 18; micropy_lpwan_ncs_pin = &pin_GPIO18; micropy_lpwan_use_reset_pin = false; micropy_lpwan_dio_pin_index = 2; micropy_lpwan_dio_pin_num = 23; micropy_lpwan_dio_pin = &pin_GPIO23; } else { ..........
-
@momo232030 If time is of essence, you are also able to build your own firmware using the
lora.reset()
branch, as once the feature is merged, it will still not be directly included in a release. The instructions are listed on the GitHub repo
-
@momo232030 Please publish the device you are using, the firmware version, a minimal code that causes the crash and the crash dump.
-
sx1276-board.c, sx1276.h: Fix crash on calling lora.reset() #474
could somebody merge this please I really need the functionality