maybe a race condition!?

[imla]

in file IRsmallDecoder.h not sure but I think it is better to reverse the order of below lines!!

91 _irCopyingData=false; //an ATOMIC_BLOCK would be better, but it's not supported on many boards
92 _irDataAvailable=false;

[LuisMiCa]

Yes, there is an issue there, it's not critical but it creates the possibility of an undefined behavior:

A) If the Interrupt Service Routine interrupts right before the _irDataAvailable=false; while been triggered by the final bit of a valid IR signal, it will set _irDataAvailable to TRUE and, right after the end of the ISR, that variable will be set to FALSE. Effectively discarding that newly received signal and proceeding with the previously received signal.

B) If that interruption happens right after the _irDataAvailable=false;, it will change that variable to TRUE, signalling that there is already a new signal ready to be retrieved. The next time the dataAvailable() method is called, it will retrieve that new signal (if it wasn't already discarded by another signal).

The chances of getting any of these possibilities are very slim and the worst consequence is the discarding of signals. Something that may happen anyway if the duration of the main program loop is longer than the signal repetition period (more than 100ms in most cases).

So, by switching the order of the two lines you mentioned, the decoder behaviour will become more deterministic. I will make sure to include this change in the next update (I'm not sure when that will be).

Thank you for your suggestion