After performing a “breakoutectomy”, I was able to slim the code and allow it to build. With that, I could play with the gameframe a bit more 🙂
I now think I get a good sense of what’s going on, and the issue can be worked around in almost all the cases…. but it does not look like it is worth it for normal use (code would become bloated with checks that would take more space in the flash only to fix visual glitches in remote test mode, and the record mode is not really important for me … as long as I don’t lose the remote)
The issue is indeed caused by phantom codes being read by irrecv.decode(..). I changed the irReceiver() code to have a new value of ‘X’ for irCommand when the code is not recognized, which filters bad codes out.
The glitchiness in the remoteTest() code is due to the way you deal with ‘timeout’ of key presses, by simply waiting more than the typical delay between IR codes: but when you read an invalid code, you wait again 150ms before reading the next (which is the correct code still in the irrecv buffer somewhere). If the IR buffer is filled with random junk, you will need multiple reads to clear it, and at 150ms per read, this can take up to a few seconds of blinking when there is a lot of stuff there.
I tried changing the code logic with a timeout counter, and a delay of 10ms between reads, and it works almost in all cases… but it does not seem like its worth complicating the code for this.
I have *NO* idea, after reading and testing the code, why the crash test screen does not show these phantom codes (unless in rare cases where I have to spam key remote keys…), probably due to the timing?
Stupid idea: most of the code that produces random codes is almost always before/after refreshing the entire LED screen (which will flash), while the crash test screen does nothing to the screen (only writes to serial port).
Maayyyybe the LCD driver is interfering with the IR receiver somehow? (either on the data bus, electrically, or maybe even the light emitted by the LED would impact the receiver