LoRa code organisation, extending to EU433



  • @Xykon @jmarcelino I have a question about the Lora code organisation. I started to extend the code for supporting EU433. While for raw LoRa and a LoPy4 this can be done by just specifying the proper frequency (like 433100000), for LoraWan this requires a little bit more work. The simple part is add a slot throughout esp/modlora.c for EU433 and tailoring application.mk. In most cases, the code for EU868 is a good template. Setting up a pair of node/gateway leads to a well known problem, caused by the single channel only support of the gateway.
    Using the trick of removing all channels but one does not help. The device still sends at the three default frequencies.
    Using add_channel to set all channels to the same frequency has no effect. A glance at the code revealed, that the function ChannelManualAdd is not supported in the file RegionEU433.c and Region.c. The same applies for CN470, CN779, KR920, IN865. Unfortunately add_channel accepts the parameter and silently ignores it. Changing RegionEU433.c is easy. Just add that missing RegionEU433ChannelManualAdd() function, which is the same as RegionEU433ChannelAdd() with a slightly different check for the frequency parameter.
    So my question is: should I change the regionEU433.c (and .h) file? My concern is, that this is part of the Semtech package, and Pycom prefers to keep Semtech and Pycom code sections separate.
    Although if I look at other places in Github where this package is used, RegionEU868ChannelManualAdd() does not exist.

    P.S.: I just have tested the uplink path up to the gateway. Downlink requires a proper service provider.



Pycom on Twitter