abp hangs on RXMODE_SINGLE

[Okamensky]

Hello,

I am making an Atmega328p+GPS+BMP180 node using RFM95 module.

The MCU is put to deep sleep for 5 minutes in

case EV_TXCOMPLETE:

and after deep sleep I update the ticks

LMIC.bands[BAND_MILLI].avail = os_getTime(); LMIC.bands[BAND_CENTI].avail = os_getTime(); LMIC.bands[BAND_DECI].avail = os_getTime();

The whole system works, but sometimes it gets stuck after printing

Exiting deep sleep. 479562853: engineUpdate, opmode=0x908 479562936: Uplink data pending 479563132: Considering band 0, which is available at 479562848 479567227: Considering band 3, which is available at 0 479570810: No channel found in band 3 479573272: Considering band 0, which is available at 479562848 479577376: No channel found in band 0 479579837: Considering band 1, which is available at 479562849 479583941: Airtime available at 479562849 (channel duty limit) 479588026: Ready for uplink 479590866: Updating info for TX at 479562935, airtime will be 4816. Setting available time for band 1 to 3858169856 479597477: TXMODE, freq=868100000, len=36, SF=7, BW=125, CR=4/5, IH=0 479597459: engineUpdate, opmode=0x888 479599929: irq: dio: 0x0 flags: 0x8 479602280: Scheduled job 0x593, cb 0xdd0 ASAP 479605260: Running job 0x593, cb 0xdd0, deadline 0 479608585: Scheduled job 0x593, cb 0xbf9 at 479656158 479656162: Running job 0x593, cb 0xbf9, deadline 479656158 479656361: RXMODE_SINGLE, freq=868100000, SF=7, BW=125, CR=4/5, IH=0

to the Serial output. Sometimes it happens after 180 cycles, 80 or even 10...

My pin configuration is as follows:

const lmic_pinmap lmic_pins = { .nss = 10, .rxtx = LMIC_UNUSED_PIN, .rst = LMIC_UNUSED_PIN, .dio = {2, 6, LMIC_UNUSED_PIN}, };

I also changed the clock error:

LMIC_setClockError(MAX_CLOCK_ERROR * 10 / 100);

Do you have any idea why this might be happening? I am using a single channel ESP32 gateway at home and have put lmic to single channel. But I have had this problem even when I tested it with all channels and regular gateways in my city.

[cstratton]

Probably the fact that the receive has timed out (or succeeded) is not being detected. This is supposed to be detected via state of the DIO pins, such that interrupts could theoretically be used.

But LMiC typically doesn't actually use interrupts, but merely poll the pin states in the function that should enable them, which gets called over and over from a typically busy looping scheduler.

There are a few likely causes of failure:

• Settings of the LoRa chip getting corrupted so that the RX attempt does not happen or more likely such that the DIO bits are no longer driven at completion, for example due to rare glitches on the SPI.

• MCU pin states getting mixed up such that they no longer read the DIOs, perhaps as a result of entering/exiting a sleep mode, especially a wakeup from sleep mode that might be implemented as something very nearly a "reset"

• Other logic bugs.

I'd consider making the polling of the IO's print out state DIO state, and perhaps even poll relevant flag registers via SPI. You could also add logic to give up after a maximum plausible time and re-configure the radio. Or simply configure the radio from scratch every time you wake up to transmit (sleeping in between transmit and the RX windows is of relatively little value compared to the complexity - most MCU's don't consume that much power running for a second or two every few minutes, but in an extreme case doing so might be worth the trouble, only after everything else works well)