I don’t understand why the following observations would cause the issue you’re seeing, but a few things seem weird:
For The Things Network, the last line is wrong, as RX2 should use SF9, not SF12. As this is an ABP node, you’ll need to ensure the correct network settings are programmed into your node. (For OTAA, LMiC should be using the correct settings as received in the OTAA Join Accept message.) At least, the following seems to be missing, maybe more:
Also, you’ve disabled 5 of the 8 channels in your code, so the duty cycle limits will kick in sooner than you think. Like BoRRoZ wrote: increase the time between transmissions. Or better yet: enable the other channels?
The above does not explain why the node halts after around 200 uplinks. Which version of LMiC are you using?
The following might indicate LMiC is running into some overflow of the timer variables, as the “available at” is lower than the current timestamp in the following? By itself a delay is not a problem, but indeed 2,148,918,405 is a lot larger than 348,957,730, so that’s a long delay, but is that why you think the following is an error?
Maybe the above might be explained by something like the following:
Be sure to read all of Adafruit Feather 32u4 LoRa - long transmission time after deep sleep to see if something applies to your code while in deep sleep.
Your code is already using timer0_overflow_count += 8 * 64 * clockCyclesPerMicrosecond()
after the sleep, but that lacks any documentation as for what that should achieve. Any more details?
As an aside, the timestamps in the log seem okay. Like this:
…tells you that 347,334,226 - 347,136,201 = 198,025 equals about 3.2 seconds. And then this:
…shows that 348,916,902 - 347,334,226 = 1,582,676 equals 25.7 seconds. And indeed 1,582,676 / 198,025 = 8 times as long as those first 3.2 seconds, so that seems to match the human readable timestamps. But still, one does not know if the LMiC internals know about the deep sleep?
Finally, probably unrelated:
I wonder what the unit is above. The following defines 4 times 2 bytes of data:
struct {
unsigned short high_axy;
unsigned short high_ayz;
unsigned short high_axz;
unsigned short battery_percentage;
} mydata;
…which in SF7 would take about 57 milliseconds. Are you indeed receiving 8 bytes when all is fine?