Testing Needed - AUDIO_CLASH_SUPPRESSION_LEVEL

Nothing that I’m aware of.
I could see settling or cable movement causing changes in sensitivity though.

So… I’m experiencing these phantom clashes also, which at first I thought was related to the speaker like this thread mentions… However, I’m wondering if it might not be speaker related, but hardware related.

Here’s my test scenario setup:

  • Two 2.2 boards
  • Same OS 6.7
  • Same config
  • No battery in

The test itself

  1. Plug in the cable
  2. Open Serial Monitor
  3. Let board sit idle (meaning “blade off”, so no sound is even playing)

Test Results

1. Phantom clash board and Serial Monitor Output

Serial Monitor Output: I get clash event logging all the time

11:18:06.876 -> EVENT: Clash millis=172003
11:18:07.230 -> EVENT: Clash millis=172386
11:18:07.548 -> EVENT: Clash millis=172675

2. Test bench board, no serial monitor output since no clash event logging unless actual clash happens

Conclusions

Based on my test results, my conclusion is that it might be a board defect. I will be ordering some more boards soon-ish for installations, so definitely will be testing more.

I’ve lost track of which board was from what source, but I’m fairly certain the one that has phantom clashes, is a “newer” board, meaning I acquired it within the last year. My test bench board, I may have acquired it before the chip shortage began. I have 17 other 2.2 boards on OS 6.7 with no phantom clashes. Only this one.

I hope this is helpful/useful for someone.

It is useful, if for nothing more than cross comparison. I’m gonna go re-check my Tesku board equipped Bendu hilt.

Does monitor clash say anything interesting?
Normally the three values should be something like 0,0,1 when the board is sitting still.
(You might need to remove DISABLE_DIAGNOSTIC_COMMANDS from your config file to use monitor clash in the serial monitor.)

Serial monitor output for monitor clash

12:07:37.005 -> EVENT: Clash millis=123744
12:07:37.041 -> ACCEL: {0.05, 1.01, -0.10}
12:07:37.114 -> EVENT: Clash millis=123852
12:07:37.262 -> ACCEL: {0.05, 1.00, -0.10}
12:07:37.470 -> ACCEL: {0.05, 1.00, -0.10}
12:07:37.503 -> EVENT: Clash millis=124219
12:07:37.644 -> ACCEL: {0.06, 1.00, -0.10}
12:07:37.819 -> EVENT: Clash millis=124563
12:07:37.854 -> ACCEL: {0.05, 1.00, -0.10}
12:07:37.999 -> EVENT: Clash millis=124727
12:07:38.070 -> ACCEL: {0.05, 1.00, -0.09}

I will need your help @profezzorn about what’s “interesting” :smile:

It’s weird, because the ACCEL values are reasonable and stable.
A clash should only occur if ACCEL - DOWN is big.
Is there a global.ini and/or global.tmp on your sd card? What do they say the clash threshold is?

It is very weird! Clash threshold is 0

clash_threshold=0.00

In my reported test, I literally used the same sd card to try to reduce the test variables.

I just thought of another test that I could do to try to validate my conclusion, so I will report back when I have an opportunity: Run OS 5.x on both boards

ProffieOS 5.x doesn’t have dynamic clash thresholds, so either your global.ini file is a remnant from another saber, OR, it’s not actually running 5.x…

So where are we with the whole OS6 clash threshold issue? I still feel this is a very widespread problem, but got swept under the rug for now. At least for me, I still cant seem to find the right settings for clash threshold or suppression level. And I’ve been adjusting and tweaking for weeks now…on a few multiple sabers.

Its either I get false clashes, …or I have to set it so it suppresses it, but then it takes brute force hit near the chasis/hilt in order to trigger a normal clash.

I was finally able to get the free time to set up and run the clash recorder. This is using Proffie’s master branch, up to commit 5de73a894938ce2f71e6478ec9cc5059151a687a (yesterday). What I tried doing was recording 3 true clashes by turning the volume down to 10% and hitting the saber. Then, I recorded 3 false clashes by maxing out the volume and triggering the false clashes by using blaster blocks. I’m not sure why 7 files were created instead of 6.

I can’t post .CSV files, so here’s a Drive link.

Another thing to note is that after updating to the master’s latest, I noticed that I received the improvements to the false clash rate regardless of whether I set the accel range back to 4; I was able to set it back to 16 and had the same improved (but not fixed) behavior. Also confirmed that switching back to Sabertrio’s fork reintroduced the high levels of false clashes, and reconfirmed that setting the accel range to 4 with Sabertrio’s fork resulted in the improved false clash rate.

Sabertrio wants me to send in my saber for warranty service, so I will be doing that soon. I hope this has been helpful!

Did you try lowering your volume?
If you cut your volume in half do you still get false clashes?

Have you tried better supporting or insulating the board from the speaker?

If you go back through this thread there are other suggestions in addition to CLASH_THRESHOLD_G and AUDIO_CLASH_SUPRESSION_LEVEL to try, including the recent suggestions from profezzorn.

Last I remember was that we had some very odd results with changing the accelerometer ranges. For some reason, restricting the range in software did not work the same as restricting the range on the device, which would indicate that the device itself is producing weird values when we set the range to 16g.

I’ve added CSV to the list of extension that can be attached.
I will take a look at the things you recorded when I have a chance.

That’s weird, because I don’t think I’ve done anything that would change clashes on the master. Makes me wonder if maybe there is something simpler going on here, like maybe I’m using data at the same time that DMA is writing to that data? Time to review the code again I guess.

Im also getting the clash issue on an Sabermach Saber (basically an 89 Sabers) Kenobi. interestingly I though it was a shorting issue as when screwing the pommel on the clashes are really bad and the chassis I have has the metal surround … I increased my clash threshold to 3.5 (the original was 2.5 when I got it) and its better … also got the audio suppression at 25 and its definitely better but still there … I think its a case of tweaking but its slightly irksome that it goes off randomly … also some fonts seem worse than others (I have 4) which doesn’t seem to make a ton of sense but I guess that might be to do with the wav files not being levelled?

This thread’s a bit outdated now, there have been multiple additions/changes including new clash detection that are now part of pre-alpha OS7.x. You’ll want to get the current version of Master from github to test.

Different fonts and or specific sounds can absolutely have different results if it’s volume/speaker vibrations that are causing false clashes. I would test the new pre-Alpha master and read through here for all of the settings available to tweak (including just lowering the volume if you’re pushing the speaker too hard).

thanks for this … I’ll give that a whirl and see what happens … much appreciated for the reply …

might be tomorrow before I get a chance but I’ll do that … and report back

sorry one last thing … I did reign back the volume as it happens from 2100 to 1900 … again it was set originally at 2000 but it was horrendously loud and that original config it came with was super simple.

Not sure how to do a post on here. I’ve been using the test for clashes because my saber was horrible. This addition is AMAZING! I can now have my clashes on 1.0 with the sound at max and I no longer get false clashes or ignitions. I can tap my blade ever so slightly to cause a clash. I absolutely love it!

Clash detection on 1.0, Suppression at 10, font 1 notch below max.

1 Like

Before the test prop. My saber had to be around half volume with clash detection 7. Which made it hard for any thrusts, stabs, or clashes.

Great to hear, profezzorn also updated the clash detection code in the pre-Alpha so it should perform much better overall.