Account for lag between TX IRQ and processing when opening RX windows

[avillacis]

Previous to this commit, the timers that opened and closed the RX windows for LoRaWAN packet reception started counting from the instant the RX-Done callback was invoked. This fails to account for any significant lag between the IRQ reception and the next call to Radio.IrqProcess(), which actually invokes the callbacks. For sketches performing lots of work between the call to lmh_join() and the next loop execution, this will frequently result in missed reception windows. Fix by recording the timestamp at IRQ time, then calculating the IRQ processing lag, and subtracting this lag from the times the RX windows are opened.

Intended to fix #32

[beegee-tokyo]

Your Pull Request would break backward compatibility, so I will not merge this.

I am working on a solution to take out Radio.IrqProcess() from the main application (your code) and handle it in the background without the users code being even able to block it. Testing will be done this coming week and I hope I can release a new version soon.

[avillacis]

Your Pull Request would break backward compatibility, so I will not merge this.

Is the problem just with adding a parameter to the TxDone callback? Or with the whole concept of recording the timestamp of the last IRQ? If the first, what about adding a new function to report the recorded timestamp instead of passing it as a parameter? Would this be acceptable?

Alternatively, there could be a callback-processing task that is signaled from IRQ context, instead of just setting an activity flag. However this would require paying attention to concurrency and locking between the main task and the callback-processing task.

[beegee-tokyo]

Second solution is what I am testing this week. Background task, wake up directly from HW IRQ signal.