search

gpstar81 / GPStar-proton-pack

GPStar Proton Pack and Neutrona Wand
https://www.gpstartechnologies.com
GNU General Public License v3.0
38 stars 9 forks source link

Mode switch button has odd behavior #263

Closed nomakewan closed 8 months ago

nomakewan commented 8 months ago

Okay, so I've been trying to fix this on my own for a bit now but have only managed to make the problem worse, so I think it's best to open this issue up to get more feedback. On my bench setup I've noticed that if I press the button on the end of my Hasbro wand just right, it can cause the menu to freak out as if I just pressed the button tens of times in a split second. At first blush this sounds like a classic debounce issue, except that increasing the debounce window in ezButton actually makes the problem even worse.

If the window is increased from 50ms (as it is now) to, say, 200ms, then what will happen is the switch will get significantly less responsive to touch, but the few times you do touch it and it works it actually has a higher chance of the exact same rapid-fire menu symptom occurring, almost as if the inputs were being buffered during the debounce window then "released" all at once.

Attached is a video of the symptom (with the default 50ms debounce):

https://github.com/gpstar81/GPStar-proton-pack/assets/11485516/49f1a38c-2e00-44c8-a543-e96cb5941d0a

Additionally here is a video from a user that I suspect is the same issue (rapidly switching vibration settings in the menu): GPStar FB Community Post

I noticed some 'odd' switch code in the wand and wonder if perhaps there was a method to the madness, and that writing conditionals with isPressed/isReleased in this way was done for exactly this reason. An example would be this code. Could this indeed be the case?

Thanks as always!

nomakewan commented 8 months ago

Okay, so I have a theory here now that I've done more testing, and it occured to me while fixing an issue with the vibration menu.

The "buffering" behavior seen here may be because the switch loop is not being properly called. If anything blocks the loop for the mode switch ezButton, it can in fact cause "buffering" to occur on the output. This would explain why I can never seen to get the menu system to rapid-fire when entering the menu, but can easily cause it when exiting the menu. Something in the menu system (or the menu exit function) may be blocking the loop.

I'm going to continue investigating.

EDIT: After thinking it over I have several things I'm going to try to diagnose this one, but unfortunately some real life obligations are going to get in the way this evening. Hopefully I'll be able to return to it in about 6 hours or so, but we'll see. Depends on how long said obligations run.

Absolute worst case the state transitions themselves can be "debounced" rather than the button polling, which will resolve these issues (but not fix whatever the underlying problem is). I'd still like to find the actual cause though.

EDIT 2: Was able to do one final test before leaving. This behavior is not just in the menu and is not limited to exiting the menu either. By lightly tapping the button as quickly as possible this "skipping" behavior happens in all situations (changing firing mode, entering menus, exiting menus, etc). I still intend to get to the bottom of it and have some debug ideas, but short term debouncing the state transitions is a viable solution. I'll get back to this as soon as I can.

nomakewan commented 8 months ago

I have returned and identified the problems. In fact this issue was three completely different problems that worked together to create a perfect storm of malfunctions regarding the menu system.

  1. We were polling the wrong edge of the barrel wing button. Due to how sensitive this button is, and since we only ever tap it to change modes or enter/exit menus, we should poll the falling edge instead of the rising edge. Changing the polling direction fixed the "machinegun" bug in the original video.

  2. The vibration settings options had delays in them, which put the ezButtons out of sync with reality. This caused the mode switch button to behave unexpectedly when attempting to change Neutrona Wand vibration settings.

  3. The checkWandAction() function, which handles the EEPROM menus, was being called above the check for the primary settings menu. This means successfully exiting the EEPROM menu would instantly drop into checking whether we should enter the non-EEPROM settings menu, and since it was within microseconds of checking for the button press, the button press check returned true still and dropped into the settings menu.

I am compiling these fixes into a PR now.

EDIT: Oh. I see there were some changes while I was gone. Hm.