One way to solve the debate on a cap before or after the diode is to eliminate the diode with small signal pfet, like a bsp250 for reverse polarity protection. This board has plenty of room for it.
More debate on where the cap should be? Then here is fellow BLF member who has experienced similar problem that I have seen, only it is well documented in this thread My Medusa. Because different people have different experiences then board layout and component selection could be to blame?
The relevant original post describing why the driver wasn’t working and the fix:
…and it didn’t work. Well it did, but as soon as I screwed the battery pack in it just started flashing. I tried different batteries and sometimes it worked, whils other times it’d just go back to flashing. It drove me nuts! Spent 2 days trouble shooting:
I swapped out the MCU
I tried every battery I owned
I rewired the switch several times
I removed and re-soldered the contact plate several times
Sanded the contact plate down just in case it was a contact issue
I swore. A lot.
I eventually figured out that the driver did not like fully charged batteries, but worked fine when the cells were at their nominal voltage (~3.7V). I eventually emailed tterev3 with my issue and he suggested that the current drain was so high on fully charged cells that it was pulling the voltage too low and resetting the MCU constantly, hence why it worked on more depleted cells and not on fresh cells. The fix was to add a small capacitor between VIN and GND after the reverse polarity diode. In my original circuit I had it placed before the diode. Annoyingly enough this is the first time I’ve ever done that trick and normally place my caps right on the VIN pin of the MCU!
I happened to have already added a small pad for the GND connection very close the VIN pin of the MCU (for programming the PIC) so I soldered straight to that. Lucky!
Now it functions exactly as described here, just with a MUCH brighter white.
So let the debate continue.
P.S. having pads for a cap across the momentary switch inputs would be a plus. Software can handle a switch press several different ways, but mostly polling and interrupts. With interrupts it is nice to have the cap there for debouncing, it just gives you more options and save a further revision.