Setting LoPy frequency in LoRaWAN stack

[agotsis]

To my understanding, setting the frequency of LoPy in LoRaWAN mode is irrelevant, since the transceiver is supposed to change its frequency after every transmission attempt, right?

Then in the lorawan node example given in https://github.com/pycom/pycom-libraries/blob/master/examples/lorawan-nano-gateway/otaa_node.py i notice that only 3 channels are used and all are set to a single frequency. Is this setting relevant exclusively for the "join" procedure, or it is meaningful for data transmission as well?

In addition, when I am using a single-channel gateway (either the pycom's nanogateway or the single-channel packet forwarder for RPi/Dragino Shield), only a small part of transmitted messages seem to reach the gateway (no RX packet event is raised for the majority of transmissions). Is there a way to predict the exact rate of "lost" messages or the frequency hopping occurs in a random way?

Cheers!

[agotsis]

@jmarcelino Ok, I'll try with ABP as well and let you know. If this is the reason, then if i remove and re-set the channels after the join operation, wouldn't be "fixed"?

UPDATE: With ABP all seem fine. I also tried again with OTAA. I noticed that in the github code the non-default channels were actually removed after join, whereas in my code this did not happen. So, when I added this code after join OTAA did work fine as well.

Another remark: how do we know if we work with 3 or 8 channels?

Many thanks @jmarcelino for your help!

[jmarcelino]

@agotsis
Ok there can be many reasons, but would you be able to try ABP instead of OTAA?

If you can let me know if it improves the situation. I'll be actually playing a bit around single channel gateways this weekend. My current theory - may be completely wrong - is that when TTN configures (according to them) 5 extra channels during OTAA join these are still passed to the LoPy even though you've set it to just one channel initially.

[agotsis]

@jmarcelino Yes, this is the case, I have configured both the LoPy node and the nanogateway to the same frequency and spreading factor (7), but I lose a fair amount of packets (50-70%). These nodes are a few meters away, and no other node is transmitting. If there was another node interfering with my own, then shouldn't at least capture a LoRa.RX_PACKET_EVENT? (i am printing the events in the gateway prompt). However, no event is raised, and I could not figure out if the node radio is not transmitting or the gw radio is not listening...

[jmarcelino]

@agotsis
Yes if your node is programmed to use the one and same frequency (and spreading factor) as your single channel gateway then you shouldn't lose any packets.

*(of course barring practical issues like interference or clashes with other LoRa transmitters - for example if you have several LoPys sending on the same frequency you're bound to have more clashes than if the nodes are sending across 8 different channels)

It's true that single channel gateways do not comply with the official LoRaWAN specification.

Hope this helps.

[agotsis]

Thanks very much @jmarcelino for the comments.

A follow-up on this: if I configure all LoPy's channels (I am working in the EU_863_870 band) to the same frequency, then don't I "go against" the LoRaWAN stack concept? I mean that if I have a single-channel gateway configured at 868.1 MHz for example and a node where all 8 channels are set to 868.1 MHz, then does this mean that I lose no packet at all? I am a little bit confused.

[jmarcelino]

@agotsis
Single channel gateways can only listen on a single frequency so that code goes around the standard by forcing the LoPy node into using only one frequency. It's for the join and further communications.

If you don't force your nodes to use a single frequency then you have a 1/3 or 1/8 chance of having a single channel gateway pick up your message - it depends on your network band plan. This is in the EU region for others it's different.