Takes hours for any data to appear on TTN (ABP)

Not sure what I am doing wrong, I tried many different sketches from 3rd parties on 2 different Arduino UNOs, but I always get the same problem; it takes hours before I get any data at all to show on TTN. I use ABP. When data appears it never stops, and every emission is working fine.
I tried OTAA as well, and with it I can at least see some action, but it also takes a very long time to join.
I have at least 3 gateways in the vicinity, none of them are mine.

This what I see all the time:

13:41:35.451 -> 70273: engineUpdate, opmode=0x808
13:41:35.485 -> 70858: TXMODE, freq=868100000, len=30, SF=7, BW=125, CR=4/5, IH=0
13:41:35.553 -> Packet queued
13:41:35.553 -> LMIC.freq:868100000
13:41:35.586 -> Receive data:
13:41:36.394 -> 128741: RXMODE_SINGLE, freq=868100000, SF=7, BW=125, CR=4/5, IH=0, rxsyms=255
13:41:37.040 -> 167529: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0, rxsyms=255
13:41:38.097 -> 232024: 10
13:41:38.097 -> EV_TXCOMPLETE (includes waiting for RX windows)

Did you see https://www.thethingsnetwork.org/docs/lorawan/security.html#frame-counters?

(You can disable that for testing.)

Wow… Thanks a lot. Could have gone a really long time before finding out about this…
Will test soon.

Any tip for the very long delay to be able to join using OTAA?

Could well be essentially the same problem, only with re-use of the join nonce. In that case you would not see join accepts being generated until the node tries a join nonce it has not previously used.

Or it could be a node with flaky receive window timing, such that is usually fails to catch the downlink packet. In that case you would see join attempts being generated, the node would just be missing them.

Or you could have one of the notorious single-channel non-gateways, in which case most of the packets transmitted by your node would be getting lost (but it doesn’t sound like that, given you describe that it keeps working once it starts to)

By the way, what happens if using ABP my node sends a communication that is not picked up by any gateway? Will the frame counter fall out of step?

Forward skips are expected and allowed.

It’s backwards ones and repeats that are rejected.

Ultimately the frame counter is 32 bits, with only the lower 16 bits transmitted, but all 32 covered by the cryptographic checksum. Practically that means there’s a range of gap where guessing if a jump in count incremented the high bits might be necessary, and then the guess (or guesses) are checked with the checksum. So ultimately skipping millions or billions of counts forward would fail but realistic forward skips from being out of range for a while at permissible packet rates are handled.

Actually anything above 16k will fail.