Lopy4 433MHz

  • Hi,

    How can I change my Lopy4 to work on 433Mhz. When I run command:

    C:\Program Files (x86)\Pycom\Pycom Firmware Update>pycom-fwtool-cli.exe -p COM4 lpwan

    My output is:
    Running in PIC mode
    SMAC: 70B3D54997FB6121
    SID: 004D367E
    PAC: 5C044BFB32BC008E

    Then I try to change in EU433
    C:\Program Files (x86)\Pycom\Pycom Firmware Update>pycom-fwtool-cli.exe -p COM4 lpwan --region EU433

    the output is:
    Invalid LoRa region EU433 must be one of: EU868 US915 AS923 AU915

    BR Mladen

  • @bed Thanks. I did not make my second pass through modlora.c yet and compare it with the LORaWAN specs. In my first run I had the impression, that also the existing code has some 'shortcuts'.
    B.T.W.: I tried OTAA join on Wednesday, and besides the inherent timing problem of the nanogateway it works. Since in general downlink worked, that was to be expected.

  • @robert-hh Hi Robert,

    I had a quick look at the code diffs and it makes sense to me (nothing bad stuck out). I'll pull it in the next couple of days to look at it in full context and report back any issues.

    It all looks pretty straight forward -- add in the region file, add manual add/remove of channels, and other sanity checks. Looks great so far.


  • @bed @Mladen I tested now LoraWan with Loriot, and both uplink and downlink work. I did not try OTAA join yet. The old problem with inconsistent timing of downlink messages at the nanogateway still remains. It is recommended to select the RX2 response window at the Loriot device setting. With that, OTAA join should work too. TTN has no support for EU433.

    The modified code is at this repository and branch: https://github.com/robert-hh/pycom-micropython-sigfox/tree/eu433. It still requires a second review pass. I'll do that in a few days, when the changes made are not so obvious to me any more, forcing me to reconsider them.

  • @robert-hh That's really promising -- thanks for checking that out.

  • @mladen I now have a LoPy4 and made a first test. Using region EU868 and just setting the frequency to 433 MHz creates a 433 MHz carrier at the proper antenna output of the LoPy4. I'll continue my testing.

  • @mladen Sorry, I could not test that. It's only supported with a LoPy4, which I do not own. I just have LoPy's ans FiPy's. I did not consider that before, even if it was obvious (!).

  • THX for replys, I will try next week

  • @bed OK. I will not have time for that before the weekend.

  • @robert-hh That would be useful -- try the EU433 values on a transmit and see if there is transmission on the correct antenna. I saw some of your other posts w.r.t. the receive windows being out of alignment and that setup looked awesome.

    I'm not at the point of using EU433 yet, but knowing if the current firmware could be used for those frequencies would be useful.

  • @bed I did not look into the details yet. i could give it simply a try and look, which output is used, if any.

  • Hi @robert-hh - I'm fuzzy about how the lf vs. hf antenna switch works - I hoped that it would just work :)

    From my reading of the Semtech SX1276 datasheet, it seems that there are two RF sections, one for the lf and one for the hf:


    I figured (hoped) that the pycom U.FL connectors went to the two different sections and that the Semtech chip then used the correct section depending on the frequency that was written into it's registers.

    But, again, I've only use the hf side for AU915 and AS923, so I don't know if this is true or not. It would make things easier - just hook up an antenna to the correct U.FL connector for which band you are using, and that's it. But it could be wishful thinking.

  • @bed I considered that, but did not find an answer yet on how the switch of the antenna connector happens. I have to look into the driver code, if that is done by the drive upon selecting the frequency range.
    Besides that, clearly supporting the region EU433 seems not the largest change of the code.

  • @robert-hh - Thanks, really good point.

    I hadn't looked that deeply. As you say, the specs for EU433 are very similar to EU866, though the default channel frequencies are different. Still that should be easy to fix up by removing the defaults and adding in new defaults.

    So we know that we CAN'T use something like this:

     lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.EU433, ....) 

    But it looks like we can use:

     LoRa(mode=LoRa.LORAWAN, region=LoRa.EU866)

    Followed by removing the 3 default channels (0, 1, 2) and adding them back in manually. Except in the documentation, it says:

    On the 868MHz band the channels 0 to 2 cannot be removed, they can only be replaced by other channels using the lora.add_channel method. 

    So, it looks like the pseudo-code to use EU433, ON A LOPY-4 is:

    # Using EU433, but have to select region EU866 on the LOPY-4 to access EU433
    # Put any other arguments into this call that you need
    LoRa(mode=LoRa.LORAWAN, region=LoRa.EU866)
    # Replace the three default channels:
    lora.add_channel(index=0, frequency=433175000, dr_min=0, dr_max=5)
    lora.add_channel(index=1, frequency=433375000, dr_min=0, dr_max=5)
    lora.add_channel(index=2, frequency=433575000, dr_min=0, dr_max=5)

    It looks like this is a work-around until the actual region parameter handling is hooked up. @Mladen I would love to know if this actually works in the field.

  • @mladen The code seems inconsistent. The settings and QSTR for EU433 are not included, but using EU868, you can set the frequency to as low as 410 MHz. (esp32/mods/modlora.c, line 1143 ff)

            case LORAMAC_REGION_EU868:
                    #if defined(LOPY4)
                        if (frequency < 410000000 || frequency > 870000000) {
                        if (frequency < 863000000 || frequency > 870000000) {
                            goto freq_error;

    Besides the frequencies, the spec for EU433 and EU868 seem very similar.

  • @mladen Have you tried just adding the EU433 setting when you setup LoRa in your code? The device-level setting (in the firmware update tool) is just a default anyway...

  • Actual LoPy4 specification on the WEB site says:


    According to this EU433 must be working!

  • From what I could tell from looking at the code, the front ends to the update tool, and the python interfaces to the LoRaWAN stack only support a subset of regions:

    (from pycom-micropython-sigfox/esp32/mods/modlora.c)

    static void lora_validate_region (LoRaMacRegion_t region) {
        if (region != LORAMAC_REGION_AS923 && region != LORAMAC_REGION_AU915
            && region != LORAMAC_REGION_EU868 && region != LORAMAC_REGION_US915) {
                nlr_raise(mp_obj_new_exception_msg_varg(&mp_type_ValueError, "invalid region %d", region));

    The regions are supported in the main LoRaWAN stack, but it doesn't look like the support has trickled through to the pycom code yet.

    I wonder if anyone from pycom could tell us where EU433 is on the priority list?


Hello World?

Pylife on Kickstarter - November 2018

Back Us On Kickstarter >

Pycom on Twitter