That depends entirely on what is happening while waiting for the DIO pin to change, and how it is being monitored. If code were efficiently busy waiting on an I/O, that could actually potentially be faster than an interrupt as it wouldn’t incur the context switch latency (keeping the processor awake while waiting on the radio is a relatively small premium over the radio’s consumption). Or one could use a hardware timer capture input. But (at least with the exception of waking up from sleep) these distinctions are many times faster than actually required.
Typical actual issues are receiving too late, or actually receiving _too early__and as a result stopping the receiver before the preamble of the packet has been detected.
Causes tend to be things like user add-ons that conflict with the way LMiC’s scheduler works (ie, don’t add things in between transmit and receive, unless you know exactly how they will interact).
Or bugs in the software environment’s timekeeping - if you look at the issue tracker for the ESP32 Arduino core, they’ve had many difficulties there, in trying to come up with something that doesn’t break Arduino traditions and doesn’t suffer consistency issues from the dual-core nature of the ESP32. Another category here is using an uncalibrated RC oscillator, which may shift with temperature, etc.
Also the amount of time the receiver should check hasn’t always been calculated correctly. The SX127x chips specify this as a number of symbol periods, so the conversion between time allowance and the register value (which is split across 2 or 3 registers) depends on the spreading factor. If you start the radio a bit early because the clock might be slow, then you also have to widen the radio’s preamble detection window, in case the clock wasn’t wrong, or in case the clock was fast.
This is, without a doubt, a hard set of issues to debug - as I’ve said before, to investigate an issue its best to use hardware test equipment to look at the timing between transmit and receive. And it requires looking through the history of local customizations, LMiC repos, and any target-specific platform code like an Arduino port.
If someone wants an LMiC solution with a fighting chance of working, it’s not about which platforms or categories of platform to avoid - rather, it’s about picking only a board target that has a maintainer actively supporting and testing LMiC on it - and preferably doing so for the LoRaWAN regional parameters and TTN settings which will be needed.