Set up channels for LoRaWAN EU 863-870MHz ABP

[bmarkus]

Using LoPy configured for EU 863-870MHz by default only the three mandatory channels 868.1, 868.3 and 868.5 MHz configured. Most networks are using the Semtech 8-channel frequency plan. For proper operation and network compatibility of the device it is necessary to add channels when you are using ABP join:

Multi SF channels required for ADR (Adaptive Data Rate). DR6 is useful for high speed data transmission close to the gateway when no reflections.

Semtech channel plan has an 50kbps FSK channel also, but it is not supported in the LoPy firmware.

[arneme]

@jcaron Thanks, forgot about that (since it is relatively new). The gateway is just a meter away from me (indoor).

[jcaron]

@arneme You definitely don't need to join again after each deep sleep. Make sure you use the nvram_save and nvram_restore methods, and you'll be able to keep your join status across deep sleep.

How far are you from the gateway? Are you (and the gateway) indoors or outdoors?

[arneme]

@bmarkus Hm, not sure if what I see is normal. I am observing that the OTAA takes several minutes (which certainly will drain power, especially if the modus operandi is to go into deepsleep and therefore have to do a new join every time the device wants to send something). The network server (TTN) receives the join request several times and sends ack to the gateway but for some reason it looks like that the gateway is unable to match the rx1 and rx2 receive windows up to 10-100 times (or even more) before it finally manages to get the ack through to the device. We have observed similar behaviour using the Semtech reference implementation of the network server and I am starting to wonder why it seems to be so hard to hit the receive windows on the LoPy. Is it the Multitech gateway or the LoPy´s fault? We have used the basic_packet_forwarder that comes with the Multitech when sending to the Semtech network server and the Kersing multiprotocol packet forwarder when sending to TTN and both configurations seems to have the same problem. By the way, ABP seems to work fine even without adding channels as you suggested.

[bmarkus]

@arneme OTAA takes longer time, it is normal. Network Servers usually send list of available channels to the devices, so it is expected to work.

[arneme]

Will this have implications for OTAA as well? We are experiencing that the LoPy uses a long time to join using OTAA. Could it be that the gateway tries to use a channel for the join ack that is not supported by the LoPy (by default)?