Alter lora frequency without reset

[robert-hh]

@momo232030 Yes. I do. And also the device joins at the first attempt for EU868. Does your device joins at the first run?

[robert-hh]

@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.

[Gijs]

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

[robert-hh]

@Gijs That gives a consistent behaviour here of failing join attempts. Which is expected here.
What kind of timeout applies?

[Gijs]

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 of modlora.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

[jcaron]

@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).

[momo232030]

@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.

[Gijs]

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:
We xsemaphoreTake() 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, we xsemaphoreReturn(). I made a quick fix that always returns the semaphore when the LoRa is initalized (in lora_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 of lora_init_helper() function. Now I feel like this is not the 'proper' solution, but it seem to work in the limited cases I tested..

[robert-hh]

@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,

[Gijs]

@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.

[robert-hh]

@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.