Fett263
September 14, 2022, 4:09pm
8
Would need a bunch of info, start in this thread:
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?
You can also hook up to Serial Monitor to see “when” clash triggers. It might give a clue. Most likely cause is speaker vibrations from out.wav. If adjusting CLASH_THRESHOLD_G and VOLUME don’t work, look to above thread.