Clash detection was changed in OS6 to allow the strength of the Clash to be used for a number of features, then it was improved upon in OS7 with more options to fine tune. It’s not the same clash detection as OS5. It’s not “unknown” it’s very much known. @profezzorn can explain in more detail. But personally I have several sabers that had zero changes needed between OS5, 6 and 7 and a couple that needed small changes from 5 to 6 but none from 6 to 7 and one or two that needed small changes from 5 to 7. As we’ve improved and expanded the features the code has changed but how that impacted each individual saber has differed quite a bit. The main variable that I’ve seen through all the discussions, troubleshooting, etc. is the saber itself, with some having no real chnge in behavior and others have very different behavior, as a result some hilts need a lot of fine tuning and other do not.
Understood. thank you for your explanation.
There are long discussions about clash issues on this board if you want to read them…
ProffieOS 5.9 has a clash algorithm that doesn’t really work if you go over a clash threshold of 3. However, lots of people still found that values all the way up to 4 ended up working well for them. I just don’t know how, because the algorithm runs in some some weird edge cases, and I’m not sure how those edge cases “help”, but it kind of seems like it does???
Anyways, ProffieOS 6 upped the limit to 15 and increased the speed and smoothness of the clash detection algorithm. Unfortunately, that meant that the edge cases that somehow helped people went away, and for some people this made it difficult to find a clash threshold that works.
To try to help and fix this, AUDIO_CLASH_SUPPRESSION_LEVEL was added, which dynamically adjusts the clash threshold based on the volume. It’s not a perfect fix, but it helps.
In ProffieOS 7, we also re-worked the clash algorithm to use both the accelerometer AND the gyroscope. In most cases this produces a more robust clash detection which is less sensitive to speaker-induced noise. However, for some reason, this does not work for some people, and the new algorithm ends up doing exactly the opposite of what it’s supposed to do: Real clashes are suppressed, while noise is amplified…
So, now we have defines for threshold, audio suppression, motion read speed, motion range, and whether to use the old or the new algorithm. By using a bunch of these it’s possible to get back to exactly the same algorithm that was used in 5.9, you just have to set the speed to 800, range to 4g , disable audio suppression and using the accelerometer for clashes, simple, right?
@profezzorn
Edit: Is below what you’re referring to? I can add to POD and my config helper tool, just want to double check. These defines would “revert” clash detection to pre-OS6, correct?
Would this impact ClashImpactF<> or other Clash Strength functions to your knowledge?
#define AUDIO_CLASH_SUPPRESSION_LEVEL 1
#define PROFFIEOS_MOTION_FREQUENCY 800
#define PROFFIEOS_ACCELEROMETER_RANGE 4
#define PROFFIEOS_DONT_USE_GYRO_FOR_CLASH
Yes, this is what I’m referring to.
However, three out of four of these defines are considered experimental and should remain undocumented in my opinion. I consider these defines “escape hatches” for some of the improvements that we’ve made, but once they are documented, we’re stuck with supporting them basically forever.
Although maybe PROFFIEOS_DONT_USE_GYRO_FOR_CLASH should be documented. There seem to be a small group of people who need it.
The frequency and range ones are basically unproven. There are people who claim that it helps, but we don’t know why, and the results seems to be a bit random. Telling people to use defines that tend not to help leads to cargo-cult behavior, so let’s try to avoid that.
Ok, makes sense why I couldn’t find then. I’ll direct clash issues here for troubleshooting.
Adding in these 4 defines with those exact settings seems to work well. I kept my Volume at 2200 and lowered the Clash-Threshold to 3.0 and it was very responsive. Also was laying down the saber on the bed/floor (not held in hand) and got no false clashes at all.
Great, but why?
Well if you have the time and energy, figuring out which combinations of these four defines actually matter might be interesting and helpful.
Roger Roger. I’ll do so mid next week when I’m back home with my sabers
@profezzorn How would you go about this since it never hurts to learn more, right?
Maybe start out with undefining each in different combinations to see if it’s a quick diagnostic?
From there if that shows nothing drop the used values down (excluding volume and clash to isolate what works and does not work with the new defines) in different ways to see just when things act up again. *Ideally using serial monitor most of the time if reasonable.
It’s just four defines, so just remove one at a time until it stops working?
When it stops working, but the last define back, try again to make sure it’s not a fluke, then move on to the next define.
OK, doing some testing on Defines, and because the false clashes were most apparent when laying the saber down on the floor/bed and just doing a normal push button ignition…this is also how i tested each scenario:
The best defines that triggers NO False clashes at all AND feels responsive like back in the OS5.9 days:
#define VOLUME 2100
#define CLASH_THRESHOLD_G 2.9
#define AUDIO_CLASH_SUPPRESSION_LEVEL 1
#define PROFFIEOS_MOTION_FREQUENCY 800
#define PROFFIEOS_ACCELEROMETER_RANGE 4
#define PROFFIEOS_DONT_USE_GYRO_FOR_CLASH
Then i tried this:
#define CLASH_THRESHOLD_G 2.9
#define AUDIO_CLASH_SUPPRESSION_LEVEL 1
//#define PROFFIEOS_MOTION_FREQUENCY 800
#define PROFFIEOS_ACCELEROMETER_RANGE 4
#define PROFFIEOS_DONT_USE_GYRO_FOR_CLASH
Removing the OS_Motion_frequency800 triggers false clashes GALORE. I couldn’t’ve ignite the saber without it false clashing every time.
then i tried this:
#define CLASH_THRESHOLD_G 2.9
#define AUDIO_CLASH_SUPPRESSION_LEVEL 1
#define PROFFIEOS_MOTION_FREQUENCY 800
//#define PROFFIEOS_ACCELEROMETER_RANGE 4
#define PROFFIEOS_DONT_USE_GYRO_FOR_CLASH
Putting OS_Motion_frequency800 back in, and removing the PROFFIEOS_ACCELEROMETER_RANGE 4 seemed to not do anything, it was a good and didnt trigger any false clashes at all.
And then i tried this:
#define CLASH_THRESHOLD_G 2.9
#define AUDIO_CLASH_SUPPRESSION_LEVEL 1
#define PROFFIEOS_MOTION_FREQUENCY 800
#define PROFFIEOS_ACCELEROMETER_RANGE 4
//#define PROFFIEOS_DONT_USE_GYRO_FOR_CLASH
Removing Gyro_For_Clash didnt do anything and was good, no false clashes at all.
So it seems the culprit may be around the Motion_Frequency?
Very interesting, thank you for trying that.
It makes me wonder if the sort of built-in filter you get from doing a lower frequency of motion events is what’s helping here, or if there is something about the motion sensor itself that works better at lower frequencies.
I have one more test that can maybe tell us that if you’re up for it.
You would need to remove the frequency define again, but then go into common/fuse.h and change this line:
to 800
It should have a similar effect as changing the frequency…
OK commented out Motion-Freq in the define, and edited the clash_filter_hz to 800 in fuse.h
//#define PROFFIEOS_MOTION_FREQUENCY 800
#define PROFFIEOS_ACCELEROMETER_RANGE 4
#define PROFFIEOS_DONT_USE_GYRO_FOR_CLASH
Results:
Sill got false clashes…however they were not as intense as like when simply removing the motion_freq in the define by iteself. These false clashes happened every other ignite, and smacking the saber sometimes triggered 2 clashes back to back.
So what if you use the frequency define and nothing else?
ok so i put the fuse.h back to 'static const int clash_filter_hz = 1600;
and edited the Defines in the config:
#define CLASH_THRESHOLD_G 2.9
//#define AUDIO_CLASH_SUPPRESSION_LEVEL 1
#define PROFFIEOS_MOTION_FREQUENCY 800
//#define PROFFIEOS_ACCELEROMETER_RANGE 4
//#define PROFFIEOS_DONT_USE_GYRO_FOR_CLASH
and sure enough…NO false clashes at all! I tried my best to make it false clash, but not a single one. And the saber still felt very responsive with the ‘hitting the saber to trigger a clash’.
So it seems that false clashes are tied to Motion_Frequency
Which is more than a little weird.
There must be something in the motion sensor itself that works better at 800 Hz than at 1600 Hz.
If this happens for more than one person, then I’m going to change the frequency back to 800Hz in ProffieOS 8.x
Thanks for providing clear feedback on what works and what doesn’t. Still don’t know exactly why some of these things are happening, but at least in your case, we have narrowed down the possibilities to one specific setting, which is great.
Roger Roger …