saber ON and PROFFIEOS_ACCELEROMETER_RANGE set to 4
VARIANCE=0.04440007, 0.00061527, 0.00475658 STDDEV=0.21071324, 0.02480465, 0.06896793
VARIANCE=0.01818230, 0.00062531, 0.00760430 STDDEV=0.13484177, 0.02500618, 0.08720262
VARIANCE=0.04470127, 0.00114506, 0.00788829 STDDEV=0.21142675, 0.03383876, 0.08881605
saber ON and PROFFIEOS_ACCELEROMETER_RANGE set to 4, with set_volume 0
VARIANCE=0.00000241, 0.00000083, 0.00000181 STDDEV=0.00155384, 0.00091005, 0.00134423
VARIANCE=0.00000265, 0.00000128, 0.00000733 STDDEV=0.00162641, 0.00113134, 0.00270707
VARIANCE=0.00000464, -0.00000013, 0.00000397 STDDEV=0.00215338, 0.00000000, 0.00199130
This is quite interesting.
First of all, it definitely shows that the noise is much higher when the sound is on.
Second, it shows that the sound noise is primarily in the X direction. (The X axis is aligned with the blade normally.)
This suggests that the X axis might need more filtering than Y and Z, and that maybe the AUDIO_CLASH_SUPPRESSION_LEVEL should somehow focus on the X axisâŚ
This would coincide with speaker cone movement, no? (Assuming the speaker is mounted typically facing the pommel, as opposed to angled or 90 shooting out the side of the grip in something like an Ahsoka Katana @BK_Saber ?)
Itâs that sensitive.
Its a traditional saber with the speaker facing out towards the pommel
So Iâm assuming a big reason this is so difficult to nail down is likely due to all the variables involved in each sabers physical construction as well as the software side of things correct?
Stuff like hilt type, chassis type, chassis fit, board location and orientation in the chassis, speaker type, speaker location, etc.
Then the stuff like font type, volume setting,
And finally all the code stuffâŚ
Thatâs a lot of stuff lol.
So my question is, what would you all consider to be the most valuable information for us to be providing to help work this issue out?
From my POV, the first question is whether youâre experiencing false clashes in OS6.7 that you didnât on previous versions or not.
I have not been able to recreate on any of my 12 sabers, besides maybe increasing CLASH_THRESHOLD_G by maybe 0.5 on a few.
If you are experiencing false clashes in OS6.7 that you didnât in OS5 or earlier then you can run some of the recent tests profezzorn posted.
If youâre not, then not sure if testing would be needed or not. From what I have seen (and havenât been able to recreate) thus far the issue is definitely saber specific; hilt, chassis, proximity of sound board to speaker, volume, font, resonance, stability of the chassis within the hilt and probably a bunch of other physical factors are causing the board to detect more vibration/acceleration from sounds than before. The more recent posts show that the it âappearsâ to be tied to the ACCELEROMOTOR_RANGE changing from 4 to 16, but only on specific sabers. So I think it needs to be tested out on the sabers that have the issue to narrow down.
If you have experienced then more help testing is probably good, but if your saber isnât youâre probably in the same boat many of us are in not actually being able to recreate to effectively test.
Ok good to know. I only have one Proffie saber so far, that Iâm just finishing up, so I donât have any experience with any of the older OS versions.
My false clash encounters were not as extreme as some have experienced and happened mostly early in my build.
Saber is a Korbanth OWK4 with a Goth 3d eco removable chassis. My learning saber, first build.
A few things I noticedâŚ
When I was still testing and removing the chassis frequently, The frequency of false clashes was at its highest. The press fit of the board into the chassis was not all that tight, but I wasnât ready to bust out the E6000 because I was still popping the board up regularly. I ran a few loops of 1/4inch art tape around the chassis and over the top of the micro USB housing, to hold the board down. It also kinda shimmed the chassis a bit resulting in less wobble.
Dramatic reduction in false clashes ensued.
After I was finished with the install and testing, I glued the board in and used the chassis set screw on the saber to tighten the fit and also tightened the rattling and loose D-ring and it resolved the issue entirely.
During this, my clash threshold was at 4.
However clashes were a little harder than I liked to trigger from blade slaps, being a thin neck with a pixel stick show blade. I set the threshold to 3 and it worked great. Sweetspot achieved⌠No flase clashes, just the right amount of force to triggerâŚ
Until I put a Smugglers Outpost Elite 28mm speaker in, and cranked the volume to 2500. I can now feel the air moving and pulsing from my saber. This led to occasional but predictable/repeatable breakthrough clashes. Some fonts, worse than others. The heavy bass events and dark side styles mostly.
All issues now resolved by setting clash threshold to 3.5.
So in my case, it was definitely vibration and volume related it appears. Never had issues with clashes occurring from spirited saber swinging.
Just wanted to add that to the knowledge base.
For me personally, I noticed it right away when upgrading from 5.9 to 6.0. And it was happening to all my sabersâŚeven the elâ cheapo LGT ones with little 24mm speakers, all the way up to the better/louder sabers with 28mmâs.
Which makes me to believe the sensitivity was altered in the OS starting at 6.0 and up.
*If it would help Iâm happy to loan you one of my Flagships to use as a test bed for this since honestly as of a couple months ago I am slammed at work. This way you would have a practical example to fine tune as best possible and it may speed this all up.
I donât know if this info will be of help, âŚ
But it seems HOW you are trying to trigger a clash matters now in OS6+. And what I mean is, it depends on how you are hitting your saberâŚand against what type of material matters now.
Example: When you set the Clash Threshold high enough to no longer trigger false clashes (lets say set to 3.8 - 4), trying to trigger a normal clash by hitting your hilt/blade with your hand takes massive force of a hit to trigger one. BUTâŚif you hit your saber blade against another saber blade, or a surface that is HARD (like a wooden chair leg), getting a normal clash to trigger is quite easy at these settings.
So I think âvibrationsâ does have some sort of play in all this, and how long/short the impact vibrations ring out (time) defines a clash maybe?
MaybeâŚjust rambling at this point.
Thatâs kind of weird, because it sort should be the other way aroundâŚ
Older versions of ProffieOS (<= 3.x) used to simply compare the last accelerometer values with the next one and if the change was high enough, a clash was triggered. Doing it that way means that the frequency of measurements matters a lot. The more often you read from the accelerometer, the less chance of getting a large value.
Since I wrote fusor.h however, clashes are triggered if |accelerometer - down | is larger than some value. Since down should normally only depend on how youâre holding the saber, and not change very fast, the speed of sampling shouldnât matter that much. (And, earlier in this thread, we tried that, and it did seem like it didnât matter that much.)
Although, now that I type this, it occurs to me that | accelerometer - down | really ought to be integrated over time. A short sharp whack and a longer, softer whack really wonât produce the same values, but they would produce roughly the same âarea under the graphâ⌠Maybe this will lead to a new and better clash detection formula?
Is there a good clash threshold # to use to not get false clashes? I just upgraded to OS 6 and used my usual clash threshold (2.2) from previously OSâŚand am getting false clashes on every ignite and blaster block now. I tried to also up the threshold to get it to stop, and now i can barley get it to clash at all without slamming it hard and almost breaking the blade
Sounds like you already know the answer, because you already tried increasing the value.
You could try getting latest proffieOS from github and add this define and see if that helps:
#define PROFFIEOS_ACCELEROMETER_RANGE 4
I tried that and it DOES seem to help. I now set my threshold back down to 2.2 and it stopped the random clash sounds. Once i go higher than this the random clash sounds start to come back. But at 2.2 it is still very hard to get it to trigger a normal intentional clash by hitting the saber. I have to smack the blade or hit with my hand like 4 to 5 times really hard for it to trigger 1 clash. I think im gonna roll back to the 5.9 system i was on and wait this out.
Not gonna lie, im still in that same boat where downloading the main OS from github and using
#define PROFFIEOS_ACCELEROMETER_RANGE 4
does seem to limit/omit false clashes considerably. But now the new problem is (or same issue actually), it takes a considerable amount of force of a hit to trigger a ânormalâ clash now (with your hand). IMOâŚthe newly added define of âClash Suppression Levelâ really doesnât do much other than make it even more harder to trigger normal clashes, lol. Adding the Accelerometer range value seems to be the best and easiest remedy thus farâŚbut it still doesnt fully resolve the issue and bring us back to normalcy like in the olâ OS-5.9 days
Did you define AUDIO_CLASH_SUPPRESION_LEVEL in your config?
If not, it defaults to 10. You can set it to 1 and it should have no impact on clash detection.
#define AUDIO_CLASH_SUPPRESSION_LEVEL 1
Yes, back in the day before trying the GitHub fork and using âAccelerometer_range 4, 8, or 12â âŚI went this route first and tried many different value combinations between Suppression Level and Clash ThresholdâŚand gave up cause while again it may solve the issue of eliminating the false clashes, once you hit that point where you found the magic number(s) where the false-clashes are goneâŚit just now makes it extremely harder to hit your saber to try and trigger a normal clash.
Ill say it again, and againâŚsomething is not right with OS6.0 and above. Something is not stable anymore. I feel it in my bones.
I meant in the current master, when you tested did you set AUDIO_CLASH_SUPPRESSION_LEVEL to 1?
I still have never had or been able to replicate the issues youâre having so Iâm not much help. Maybe @profezzorn has some insight. To my knowldge, if you use these 2 defines together in current master youâve essentially returned to OS5-ish.
#define PROFFIEOS_ACCELEROMETER_RANGE 4
#define AUDIO_CLASH_SUPPRESSION_LEVEL 1
I did tons of testing (see this thread above, lol). I think it really comes down to if Profezzorn has had the time to look over all the data I gave from testing, and If he looked down the path of:
"This suggests that the X axis might need more filtering than Y and Z, and that maybe the AUDIO_CLASH_SUPPRESSION_LEVEL should somehow focus on the X axisâŚ"
âAlthough, now that I type this, it occurs to me that accelerometer-down really ought to be integrated over time. A short sharp whack and a longer, softer whack really wonât produce the same values, but they would produce roughly the same âarea under the graphâ⌠Maybe this will lead to a new and better clash detection formula?â
So it sounded like we went down a path where we may have found a culprit of what âcouldâ be causing itâŚits just a matter of now analyzing it and âwhat can we do about it.â.
ButâŚit sounds like this false-clashes issue is happening to many people, but not many people are willing to go through all this extensive testing to give more concrete data to see if its the âsame culprit issueâ for all users⌠or not.