B-L072Z-LRWAN1, STM32CubeExpansion_LRWAN_V1.3.1, End Node application: 50% packet transmission failure to gateway

[JHCarter]

I am running the above mentioned board about 3 meters away from two gateways, a TTIG and a RAK7258. I made two modifications to the stock End Node application - I modified Commissioning.h with the EUI, etc. for one of the gateways (have tried both), and changed the preprocessor define from REGION_EU868 to REGION_US915.

I monitor packets on both gateways. After resetting the B-L072Z-LRWAN1 board, it will join whichever gateway I have it configured for, but it takes it anywhere from 2 to 6 attempts. After that the uplink packets appear intermittently on both gateway traces with RSSI values that vary wildly. For some packets, the RSSI is around -28, with an SNR of 8 to 14. These packets show up on both traces. Other packets either never show up, or show up on only one gateway with RSSI around -120 and SNR of -11. Most of the time I am missing 50% or more of the packets. Every once in a while things will straighten up and I receive 100% of the packets for hours.

So it appears that there is a problem with the B-L072Z-LRWAN1 hardware. Has anyone else seen behavior like this? Unfortunately I do not have access to a spectrum analyzer to look at exactly what is coming out.

[JHCarter]

OK, I think I have this figured out. The bottom line is that the current LoRaMac does not handle an environment where there is only an 8 channel gateway very well. The end node keeps sending uplink packets on random channels from 0 to 63 until it finally receives enough LinkADRReq messages to put together a valid channel mask. Sometimes sending 100 uplink packets is enough to get a channel mask but not always.

The fact that I had my end node so close to the gateway complicated things because the gateway was receiving valid packets on channels that were a harmonic of the channel that the end node used, resulting in the low RSSI values I was seeing.

I found a reference to a similar issue here: https://github.com/Lora-net/LoRaMac-node/issues/742 I also found that there was some code left in lora.c inside a #define HYBRID that referenced a US915 Hybrid mode that did what I wanted - defined a fixed channel mask up front. So for now that is what I am doing as my current environment only involves a single gateway on a private network.