Getting false swings on a board (leading to false swing activation on sa22c prop file).
KR Sabers board. Known good config. ProffieOS 5.9. Good cell charge. 100s of fault free installs under my belt.
Periodic swing activation whilst just sat still on the bench but more common when simply switching through presets … there’s (about one time in 5 or 6) a simultaneous ignition as you release the button after progressing to the next preset. The install is dead still on the bench.
Hmmm… I’ve already dropped from 2100 to 1800. Same components I always use for this kind of install, too. Will drop a touch more, but I did have a ghost ignition when just sat dead still and quiet on the bench, too (once).
I’ll give it a go in a few days. Re: versions, I rarely ‘early adopt’ and if anything prefer to stick with the stable prior version unless there’s a good reason. I install for a large(ish) dueling community here in NZ, so baselit RGB is the go-to install. All the new features tend to be for the NP crowd so there’s no real benefit in bumping up a version.
Looking from another angle, given that this is just one in a long run of installs using a tried and tested config, there’s not been any specification changes on the board that would have caused the issue, would there?
i.e. nothing has changed that moving to 6.7 would fix?
Not sure what you mean by “early adopt”, OS6.7 has been out and stable for a long time, in fact, OS7.x is just on the horizon.
There were a lot of updates for OS6, including gestures, so that’s why I recommended trying. I merged Sa22c’s prop with mine for OS6 so you’d just need to change your defines to match my prop, you can leave the rest of your config as is (OS6 is backwards compatible), although you will probably want to update styles down the line to OS6 to take advantage of all of the new features.
*I’m spitballing here but is this the same chassis and material you always use or different shell and chassis? Creep up on the clash setting by .25 increments and retest in action so you set the ini and tmp files. Let it sit for a few hours and pick it back up once the save files are created and retest. *Remember to disable SaveFiles for this.
Thing is … it has been working… nice and stable with no prior issues. I churn out 2-3 installs a week, issue free running 5.X.
Bumping up to 6.X is an option / obvious path, but as someone who does a lot of RGB baselit installs, I’ve found that testing of the RGB setups doesn’t get the love that the NP setups do, so I’m loathed to change for fear of having to deal with a bundle of new RGB specific bugs (especially if this is potentially a HW issue / niggle / niggle with my install that the meter hasn’t picked up).
Most important question would maybe be, were the new filters for gyro / accelerometer coded in response to fix an increasing trend that saw the issue more common on more recent boards when it wasn’t an issue on prior production runs? If so, moving to 6.x would be the obvious ‘go’, if not, is it just an issue specific to this board / install?
I’d also have to move from my current (stable) Arduino IDE config (compile errors on 6.7 due to the older library). …[muses] … I’ll fire up a VM [/muses]