Can anybody explain what happens in the device communication depicted in the picture below?
What causes this activation resending and resetting of the counter?
The device (Arduino Pro-mini and RFM95) is using the LMIC library and LowPower sleep.
The gateway (RAK831) data is depicted below:
All tips are welcome to get me on the right track 
The counter is reset on all OTAA joins.
Which LMIC library?
Is there any chance your device is resetting when it sleeps?
How close is it to your gateway?
MCCI LoRaWAN LMIC version 3.2.0.
Distance of device to gateway is more than 4 metres.
I will check if the device resets the counter while sleeping.
The join resets the counter.
It’s if the sleep is so sleepy it loses the join info - usually discovered by watching the serial port.
> 11:41:10.878 -> Starting
> 11:41:10.947 -> In do_send with bLED is 0
> 11:41:10.947 -> Packet queued
> 11:41:10.947 -> 2834: EV_JOINING
> 11:41:14.655 -> 235996: EV_TXSTART
> 11:41:19.849 -> 557947: EV_JOINED
> 11:41:19.849 -> netid: 19
> 11:41:19.849 -> devaddr: 26012689
> 11:41:19.849 -> AppSKey: 81-XXXX
> 11:41:19.849 -> NwkSKey: 13-XXXX
> 11:41:19.849 -> 559923: EV_TXSTART
> 11:41:21.998 -> 694629: EV_TXCOMPLETE (includes waiting for RX windows)
> 11:41:22.303 -> Going to sleep...
What would you suggest to debug the problem situation according to the displayed serial port logging above?
Nothing, because there’s only one cycle and I’d want to see what happens after it wakes up …
Electrons are free, please post as a block quote as I’ve altered the above, a longer log.
1 Like
15:00:30.402 → Starting
15:00:30.469 → Packet queued
15:00:30.469 → 2833: EV_JOINING
15:00:30.469 → LMIC.seqnoUp: 0
15:00:31.759 → 83270: EV_TXSTART
15:00:36.913 → 405215: EV_JOINED
15:00:36.913 → netid: 19
15:00:36.913 → devaddr: 26015ACF
15:00:36.913 → AppSKey: B9-XXXXX
15:00:36.913 → NwkSKey: D3-XXXXX
15:00:36.913 → LMIC.seqnoUp: 0
15:00:36.947 → 407224: EV_TXSTART
15:00:39.092 → 541929: EV_TXCOMPLETE (includes waiting for RX windows)
15:00:39.400 → Going to sleep…
15:02:05.483 → Awake again…
15:02:05.788 → LMIC.seqnoUp: 1
15:03:04.692 → 4293438: EV_TXSTART
15:03:04.692 → Packet queued
15:03:06.834 → 4428153: EV_TXCOMPLETE (includes waiting for RX windows)
15:03:07.139 → Going to sleep…
15:04:33.219 → Awake again…
15:04:33.493 → LMIC.seqnoUp: 2
15:05:32.421 → 8179671: EV_TXSTART
15:05:32.421 → Packet queued
15:05:34.565 → 8314550: EV_TXCOMPLETE (includes waiting for RX windows)
15:05:34.872 → Going to sleep…
15:07:00.924 → Awake again…
15:07:01.194 → LMIC.seqnoUp: 3
It seems that the counter is not reset by the device during sleep.
Might the problem be a timing issue?
That was never a question I asked, I said it was reset by the Join.
What was/is of interest is why it was rejoining. But it appears not to be in this transcript. Did anything else change?
For testing, can you reduce the size of the payload and send less often. A six byte payload can be sent every 149 seconds to stay within fair use policy. see https://avbentem.github.io/airtime-calculator/ttn/eu868/2 For testing, I have a push button so I can watch everything happening and not accidentally leave the thing banging away overnight (or a weekend)