Os6.6 false clashes and stab sound and effects

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.

4 Likes

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.

1 Like

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.

There could be two reasons for this:

  1. Something is loose (like the speaker, or the chassis, or a wire) and when it falls in one direction, it makes contact with something and transmits vibrations from the speaker more.
  2. The math for the clash detector is basically | accel - down | > CLASH_THRESHOLD_G
    Both accel and down are vectors, so their directions matter.
    If the speaker is causing accel to have noise in a particular direction, then the direction of down will matter as well, because accel will max out at 4 with your current settings. Since | down | is approximately 1.0, this wouldn’t happen if PROFFIEOS_ACCELEROMETER_RANGE - CLASH_THRESHOLD_G > 1

Ok, so I checked in some new clash detection code on github.
It’s not very well tested, but here is what it does:

  1. Uses both accelerometer and gyro data to detect clashes. This may throw off stabs, and I have not had a chance to fix that yet.
  2. The accelerometer and gyro data is by default filtered down to 800Hz with a simple box filter.

All of this means that clashes now use 4 times more values, which I think means it should be more resilient against false clashes, but obviously we’ll have to see how that pans out…

Feel free to test it, I’ll be doing some of that myself tomorrow. :slight_smile:

1 Like

Did some tests on my primary test saber and even with CLASH_THRESHOLD_G down to 1.0 I could not trigger a clash no matter how hard I smacked either the hilt or blade. Not sure if this is only intended for sabers experiencing issues, I see you have a define to use old method so maybe this is only for troubled sabers?

Sounds like there are bugs then… Guess I should fix those huh?

Looks like I may have multiplied something by a million that shouldn’t have been multiplied by a million… fixed.
Also, I removed the 800Hz filter for now, it seemed to make clashing a fair amount harder, but we may want to experiment with putting it back as a way to combat speaker-induced clashes.

Confirmed, works as expected now on my test saber. I’ll try outa few more sabers as I have time and report back if I find anything off. Will need users with false clashes to test as well. Thanks.

Is there a later version of the OS other than v6.7??

Yes, but it’s in experimental pre-alpha stage, problems may occur and you have now been warned.

You can download it by going to github and select Code → Download ZIP.

After you unzip it, you will probably need to rename the directory from “ProffieOS-master” to just “ProffieOS”, otherwise Arduino will ask you to rename the ino file, and that will cause problems.

1 Like

Flashed latest master onto a few problematic sabers and the false clashes either went away or could be tuned reliably from either bumping up CLASH_THRESHOLD_G or lowering volume. The ones that needed further tuning were more prone to vibrations due to body/pommel design and were experiencing false clashes on OS 5.9 anyways.

On my daily driver which occasionally experience false clashes it went away completely with the same clash threshold (4.5).

Solved: Okay after adding these defines to my config I was able to set my CLASH_THRESHOLD_G from a 7.5 down to a normal 2.0 with no false clash or stab.
#define PROFFIEOS_ACCELEROMETER_RANGE 4
#define PROFFIEOS_MOTION_FREQUENCY 800
#define AUDIO_CLASH_SUPPRESION_LEVEL 1
#define FUSOR_VARIANCE
#define ENABLE_DEVELOPER_COMMANDS
Thanks for all you guys do :wink:

Was this parameter needed to solve your issue? I havent added this parameter to my config

What version of ProffieOS are you using?
If you have the time, I would very much like to know which of these defines are actually required to fix this problem and which ones are not, let me start:

#define FUSOR_VARIANCE
#define ENABLE_DEVELOPER_COMMANDS

These two defines don’t have any impact on the sensitivity, they just add commands for debugging what is going on in the fusor better, so you don’t actually need these.

#ifdef CONFIG_TOP
#include “proffieboard_v2_config.h”
#define NUM_BLADES 1
#define NUM_BUTTONS 2
#define VOLUME 2500
const unsigned int maxLedsPerStrip = 144;
#define CLASH_THRESHOLD_G 7.5
#define ENABLE_AUDIO
#define ENABLE_MOTION
#define ENABLE_WS2811
#define ENABLE_SD

#define ENABLE_SSD1306

#define SAVE_STATE
#define COLOR_CHANGE_DIRECT
// #define DISABLE_DIAGNOSTIC_COMMANDS
#define DISABLE_BASIC_PARSER_STYLES
#define NO_REPEAT_RANDOM
#define FETT263_MOTION_WAKE_POWER_BUTTON

#define FETT263_SWING_ON
#define FETT263_SWING_ON_SPEED 365
#define FETT263_TWIST_OFF
#define FETT263_LOCKUP_DELAY 300
#define MOTION_TIMEOUT 60 * 3 * 1000
#define IDLE_OFF_TIME 60 * 3 * 1000
#define FETT263_MULTI_PHASE
#define FETT263_EDIT_MODE_MENU
#define FETT263_BM_DISABLE_OFF_BUTTON
#define ENABLE_ALL_EDIT_OPTIONS
// #define FETT263_CLASH_STRENGTH_SOUND
#define FETT263_DUEL_MODE_SOUND
#define FETT263_MAX_CLASH 16
#define FETT263_BM_CLASH_DETECT 7
#define FETT263_SAY_BATTERY
#define FETT263_SAY_COLOR_LIST
#define FETT263_SAY_COLOR_LIST_CC
#define COLORWHEEL_ZOOM
#define FETT263_SAY_BATTERY_PERCENT
#define PROFFIEOS_ACCELEROMETER_RANGE 4
#define PROFFIEOS_MOTION_FREQUENCY 800
#define AUDIO_CLASH_SUPPRESION_LEVEL 1
#define FUSOR_VARIANCE
#define ENABLE_DEVELOPER_COMMANDS

I’ve just redownloaded the ProffieOS-master as was suggested and added these
defines#
AUDIO_CLASH_SUPPRESION_LEVEL 1
FUSOR_VARIANCE
ENABLE_DEVELOPER_COMMANDS
MOTION_FREQUENCY and set at 800
PROFFIEOS_ACCELEROMETER_RANGE
and set at 4
and for some reason using EDIT_MODE I’ve been able to reduce CLASH_THRESHOLD_G to 2.0
from 7.5 and get NO false clashes now
where as before I set it at 7.5 I was getting false clashes all the time but after adding those defines at 7.5 I couldn’t get a clash unless I tried VERY HARD

Ok, but if you remove one of the new defines at a time, when does the problem come back?