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.
So I’ve been experiencing false clashes fairly regularly on my S3 hilt, but it wasn’t enough to even complain about until I made this “Army of Darkness” font. But that font (chaninsaw ignitions) makes them happen ALL THE TIME. I tried bringing down the volume on the ignition .wav files and I lowered the volume on the saber and it seems to help. I also made sure the board was secure in the chassis (it wasn’t). Another weird thing: it does it when I first fire up the saber, but messing around and running through the fonts seems to clear it up quite a bit.
I could barely get through this thread without a migraine, so I doubt I could be much help with testing—thank you guys for being the smart ones. Just weird how this one font really did it so much worse than all my others.
Have you tested the current version of the master on github (as it stands today) using the 2 defines together? You said setting the PROFFIEOS_ACCELEROMETER_RANGE to 4 helped with false clashes but it was hard to trigger so I asked if you set the AUDIO_CLASH_SUPPRESSION_LEVEL to 1 in the current version and test?
If you tested the accelerometer range without lowering the clash suppression to 1 you didn’t get a complete test. Your config above had the AUDIO_CLASH_SUPPRESSION_LEVEL commented out, so you only tested “half”. I suggest getting the current version and adding the two above defines and then testing. When too much time passes between testing and resolution it gets really hard to keep up (at least for me).
I don’t know about “many people” - thus far I think I have more Proffieboard sabers than the total number of people I’ve seen report this issue. I’m sure it can get sorted out BUT since I cannot replicate on any of my sabers it’s really up to the people who have the problem to fully help or there’s not much we can do.
I’ve been pondering how to possibly handle integration in the clash routine. The idea there was that it’s really kind of the “area under the graph” that matters, not just the size of the spike.
Interestingly, the math for integration looks suspiciously similar to the math for a low-pass filter. (And conversely, the math for derivation looks suspiciously similar to the math for a high-pass filter…)
The problem is that all of this is complicated, involves more parameters, and I don’t really like algorithms that require a lot of tuning, so I’m experimenting a bit before I implement anything.
Interestingly, I also recently found out that changes in gyroscope readings can also be used to detect clashes. At first I was thinking that it makes perfect sense, especially for clashes near the tip of the blade. After all, a hit near the tip is likely to cause a change in swing speed. I’ve been studying the data though, and it doesn’t look like that’s what is actually happening. In fact, there are some significant changes in the X gyroscope reading, which would be rotation around the blade. Clashes wouldn’t really cause rotations around the blade, but that’s what the reading says. Of course, the gyroscopic sensor is a vibrating element, so maybe the clash messes with it?
Anyways, I’m experimenting with it, hopefully the result will be a better clash detector some time soon.
Download the newest from GitHub and tried these parameters:
#ifdef CONFIG_TOP
#include "proffieboard_v2_config.h"
#define NUM_BLADES 1
#define NUM_BUTTONS 2
#define VOLUME 2700
const unsigned int maxLedsPerStrip = 144;
#define CLASH_THRESHOLD_G 3.7
#define ENABLE_AUDIO
#define ENABLE_MOTION
#define ENABLE_WS2811
#define ENABLE_SD
#define IDLE_OFF_TIME 60*5*1000
#define MOTION_TIMEOUT 60 * 15 * 1000
#define DISABLE_DIAGNOSTIC_COMMANDS
#define ENABLE_SPINS
#define NO_REPEAT_RANDOM
#define FILTER_CUTOFF_FREQUENCY 60
#define FILTER_ORDER 8
#define PROFFIEOS_ACCELEROMETER_RANGE 4
//#define ENABLE_DEVELOPER_COMMANDS
#define AUDIO_CLASH_SUPPRESSION_LEVEL 1
#define KILL_OLD_PLAYERS
#endif
#ifdef CONFIG_PROP
#include "../props/saber_fett263_buttons.h"
#endif
#ifdef CONFIG_PRESETS
Preset presets[] = {
OK now we are getting somewhere! This surprisingly worked well! I only had one instance of a false clash while swinging around for about 2min. I’m sure If I up the clash_threshold to maybe 3.8 it may do the trick. But at these settings it FEELS good and responsive again.
Cool, good to hear.
Well, after playing around a bit…yup, sure enough false clashes are back at the same settings above, and then after raising clash_threshold to 3.9, …still get em’. If i raise this any higher, ill be back in the “it takes to hard of a slap to trigger a clash now” territory. Its kinda like when I said way long back “Just when you thought it was fixed…it randomly comes back like a ghost in the machine”
However…im noticing a pattern. The false clashes mostly seem to happen when the saber is pointed at an downward angle. If i ignite the saber upright, or do blaster blocks and normal clashes when its upright, they don’t seem to happen (false clashes). But when the saber is pointed downward …they happen.