Not receiving packets when using CAD

[Bartvelp]

Hoi Maarten,

When using the CAD function to autodetect spreading factor I am not receiving any packets. CAD seems to detect the transmission sometimes. I am transmitting a packet every 12 seconds, alternating between SF7 and SF10.

See log below:

Sat 07-11-2020 22:08:43- SCAN:: I=CDDONE CDDETD , F=0, SF=7, E=0, S=RX , eT=2182, dT=2203
--
Sat 07-11-2020 22:08:43- SCAN:: I=CDDONE CDDETD , F=0, SF=7, E=0, S=RX , eT=2218, dT=2242
Sat 07-11-2020 22:08:43- SCAN:: I=CDDONE CDDETD , F=0, SF=7, E=0, S=RX , eT=42018677, dT=2792
Sat 07-11-2020 22:08:38- v PULL_ACK:: token=44897, size=4, IP=52.169.76.203, port=1700, protocol=2
Sat 07-11-2020 22:08:38- ^ PULL_DATA:: token=44897, len=12
Sat 07-11-2020 22:08:22- v PULL_ACK:: token=55626, size=4, IP=52.169.76.203, port=1700, protocol=2
Sat 07-11-2020 22:08:22- ^ PULL_DATA:: token=55626, len=12
Sat 07-11-2020 22:08:06- v PULL_ACK:: token=51101, size=4, IP=52.169.76.203, port=1700, protocol=2
Sat 07-11-2020 22:08:06- ^ PULL_DATA:: token=51101, len=12
Sat 07-11-2020 22:08:01- CAD:: I=CDDONE CDDETD , F=0, SF=9, E=0, S=CAD , eT=15567, dT=7619
Sat 07-11-2020 22:08:01- CAD:: I=CDDONE CDDETD , F=0, SF=10, E=0, S=CAD , eT=30090, dT=14921
Sat 07-11-2020 22:08:00- CAD:: I=CDDONE CDDETD , F=0, SF=10, E=0, S=CAD , eT=29933, dT=14776
Sat 07-11-2020 22:08:00- CAD:: I=CDDONE CDDETD , F=0, SF=10, E=0, S=CAD , eT=29934, dT=14891
Sat 07-11-2020 22:08:00- CAD:: I=CDDONE CDDETD , F=0, SF=10, E=0, S=CAD , eT=12084497, dT=15212
Sat 07-11-2020 22:07:50- v PULL_ACK:: token=14663, size=4, IP=52.169.76.203, port=1700, protocol=2
Sat 07-11-2020 22:07:50- ^ PULL_DATA:: token=14663, len=12
Sat 07-11-2020 22:07:48- SCAN:: I=CDDONE CDDETD , F=0, SF=7, E=0, S=RX , eT=2183, dT=2204
Sat 07-11-2020 22:07:48- SCAN:: I=CDDONE CDDETD , F=0, SF=7, E=0, S=RX , eT=42071556, dT=2685
Sat 07-11-2020 22:07:34- v PULL_ACK:: token=18296, size=4, IP=52.169.76.203, port=1700, protocol=2
Sat 07-11-2020 22:07:34- ^ PULL_DATA:: token=18296, len=12

As can be seen in the log, I sometimes get a CDDONE line but no packets. When using a hardcoded SF, receiving works just fine. These are my compilation settings:

[env:Gateway_21]
platform = espressif8266
board = d1_mini
board_build.mcu = esp8266
board_build.f_cpu = 80000000L
build_flags =
  -D _PIN_OUT=2
  -D _WIFIMANAGER=0
  -D _SPIFFS_FORMAT=1
  -D _CHANNEL=0
  -D _REPEATER=0
  -D _OLED=0
  -D _DUSB=1
  -D _PROFILER=1
  -D _STAT_LOG=1
  -D _STRICT_1CH=2
  -D _LOCALSERVER=1
framework = arduino
board_build.flash_mode = dio
upload_speed = 921600
upload_port = COM5
monitor_speed = 115200

I am using an ESP8266 with RFM95W with the connections made using dupont wires.

These are the logs in TTN, note the framecounter (uneven = SF7, even SF10):

Any ideas what might cause this? Great working project BTW, could use some refactoring I think but it has a lot of nice features. Lmk if you need anymore info.

[platenspeler]

Hi Bart,

Sorry for reacting late, but lots of other interrupts. ? Why are you using board_build.flash_mode = dio and not qio? ? Are you indeed using a comresult board (_PIN_MODE==2) or are you using a standard Halard board. The comresult is "better" but you might miss the CAD.

Maarten

[Bartvelp]

Hi Maarten,

No problem, this is just open source, not free support. I was having some issues flashing the bin that's why I changed it to dio, but I don't think that is related. I am not using a Halard board, or comresult board. I soldered the rfm95w to a esp8266 breakout and connected GPIO wires directly between the Nodemcu and the rfm95w, and this is the pinout in _PIN_MODE==2. I have only wired DIO0 and DIO1, and I am not sure DIO2 is also needed, but this page says it isn't https://things4u.github.io/Projects/SingleChannelGateway/UserGuide/2_Installation.html

I just tried using a different module with the RFM95W DIO0 and DIO1 wired to GPIO15 using a diode, so very similar to Hallards board, and I am getting the same issue.

[hisnameishb]

What I read from the doc: CAD mode is not very sensitive. You have to adjust the threshold for the RSSI, then it maybe works better. The value of -40 is imo too high, most of the packets I receive are around -90 ... -110 (packet RSSI).

Imo this threshold idea is not very practical and the whole CAD functionality is more or less worthless at least for LoRaWAN. I did some experiments with CAD mode on my own pure LoRa projects (not LoRaWAN-based) and its usesless here too. It works better if you have very long preambles, the LoraWAN preambles are way to short to dectect something for shure with it. If preambles are long enogh there is enough time to test all SFs and dont miss the payload.

Best ist to check each channel 24h with SF7, next day with 9. Thats what most nodes use, SF higher than 9 is rarely used. I never recived such a LoRaWAN Packet with SF > 9. Most nodes send at a specific time. The Gateway should remember after it received something successfull the time and the channel+sf and switch the next period at this time to this channel with same settings, a kind of adaptive freq. hopping for each node. In the "free time" it should scan again.