Conversation
This was slightly "riding" the brake output on my setup.
Similar to gearChanged() for the shifter, this saves the 'changed' return value from the update function so it can be retrieved later to see if any of the pedal positions have changed since the last call.
Matching the layout of the ShiftJoystick example, this only sends the Joystick USB packet if the pedals have actually changed position. This should avoid issues with the pedals "spamming" inputs and stealing a game's input priority even when they're constantly 0.
For checking whether a value is within the calibrated range.
Changing my mind on this. Going to tackle it in another way. This reverts commit 6c5ba50.
Fixes a bug where pedal state would not be detected until the pedals were moved for the first time. Also refactors the function name from "updatePedals" to "updateJoystick", as the pedal object is updated from within loop().
Instead of detecting simply if the ADC value changed, this now checks if the changed value is outside of the calibrated range (in the same direction it was previously). If so, the user-facing classes aren't going to care and can safely ignore the update. This was written specifically to solve an issue with the pedals, which don't need to send constant updates when they're at their resting position.
This allows the user to set independent 'start' and 'end' deadzones for their pedal serial calibration. The purpose is to prevent pedals from being slightly pressed in their resting position, and to prevent pedals from reaching their 100% "pressed" position at full extension. By default, this uses a 1% deadzone for the start of travel and a 2.5% deadzone for the end of travel. I'm trying to be conservative here, because the last thing I want is for a user to set a large deadzone and then be unable to compensate for it when using the pedals as an HID device. Still, I think a tiny bit of fuzzing is good and can compensate for noise at the input extremes.
Restores the old behavior of the example if set. Always nice to have an override.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
These changes make it so that pedal data in the
PedalsJoystickexample is only sent whenever the pedals actually move. The goal is to avoid spamming games with pedal input and grabbing focus away from other input devices like wheels or mice. The latter of which makes it really difficult to actually set up the pedals in certain games. This can be overridden with an option in the example to restore its previous behavior.Because of an underlying change to the
AnalogInputclass, all classes that use an ADC input will only report changes if the ADC input is within the calibration range (to avoid saying "data changed" when it's outside of the range we are reporting). TheHandbrakeclass is the one most noticeably affected.Pedal serial calibration now includes deadzone options for the start and end of the travel range. The former should reduce issues with pedals being always "on", the latter should reduce issues with being unable to get the pedal to 100%. Both are set at low values by default (1% and 2.5%, respectively). These only affect serial (conversational) calibration. Applied calibration is unmodified.
This also slightly adjusts the calibration of the Logitech pedals' brake, which was registering a constant low input during more thorough testing.