Just trying to figure out what’s going on. Is this standard behavior for the LMIC code to connect to TTN?
There are many reasons a join could fail:
- re-using an already used join nonce, causing the server to silently reject the join attempt. LMiC in particular likes to grab a single random number (which in many people’s situations comes from a bad algorithm) and if it fails, then count linearly rather than re-randomize. So for example, if your RNG always returns the same thing (oops) it will take longer and longer on each run before you get a join success. LoRaWAN nodes are really supposed to save the join nonce (or session details including frame count) across boots, trivial firmware changes, etc - but most people’s installs don’t.
- poor RF situation between the node and gateway
- on-air contention with other users or other radio services
- node firmware not turning on the radio at exactly the right time to receive replies
- mismatched channel configuration or other regional settings (note TTN EU868 has a non-standard RX2, but sometimes concludes you didn’t implement that and starts using the standard one…)
It’s a lot easier to debug this kind of thing if you control the only gateway that could potentially be used. Then you can see if there’s gateway traffic, and you can see if the server sends a reply.
For timing issues, while you can blip a GPIO at the end of transmit and start of receive and measure with a scope, it can be even more effective if you trigger a scope on a GPIO blipped at the start of receive, and put the other probe on the gateway card’s transmit LED.
If you don’t have a scope a cheapie USB logic analyzer works too (at least for cleanly digital signals, might not work for tapping out LED drive), and actually makes it easier to untangle what happened in long experiments.
Is there any way to reduce the time for the TXSTART (and JOIN) event to succeed?
If you do LoRaWAN the way it was intended, then joins are a very rare thing so that’s not supposed to be as much of an issue as it is being for you. But that would require saving the result across power cycles and even trivial firmware changes.