First off may I wish everyone here a very happy, healthy and prosperous new year - may the Force be with you all in 2023.
egarding my issue, it’s a bit of an odd one - I’ve just finished a Thrawn Hunter short hilt with Master chassis, and I’m getting crazy false clashes when I ignite. The config is basically the same as the long hilt which I finished a few weeks ago (just some differences with the accent LEDs) and that works fine.
Relevant specs are: Proffie 6.7. SA22C prop (one button). Volume 1700. (2 watt KR 24mm bass speaker). Clash threshold 3.9. Changing font makes no difference.
Ordinarily I’d tweak clash threshold and volume, but there a couple of weirdnesses in this case:
Even if I ignite the blade muted, it still false clashes like crazy - to the point where I can’t switch the blade off because the button press is constantly accompanying a clash so it goes into lockup mode. So it can’t be speaker vibrations causing it.
With the blade off, I should be able to enter the volume menu by holding the button and doing a clash. But no matter how hard I clout the hilt, I can’t initiate that clash with the blade unlit.
The chassis is currently supported on the wires and not glued (as I always want to iron out wrinkes before I glue stuff), but I tried securing it to the chassis with tape really securely and it made no difference.
I’ve just tried reloading the config (minus a couple of presets to make room for serial diagnostic commands) with volume set at 200. I also disabled the spinning motor for the crystal chamber in case that was causing the problem.
Unfortunately no change. I tried powering from battery while connected to USB but it’s still clashing like crazy despite the hilt being absolutely still.
Do you have another saber you can try same config with? If the same config works fine in another saber I think it’s safe to say there’s an issue with the board.
My guess is that you have a broken motion chip on this board.
There are a few things we can do to see what it’s doing, but if the motion chip is broken, then it (or the whole board) has to be replaced.
Things to try:
Remove DISABLE_DIAGNOSTIC_COMMANDS from your config file.
Add ENABLE_DEVELOPER_COMMANDS to your config file.
Re-program
Now you can use a few commands that will show you what the motion chip is doing. these commands are:
dumpfusor: This command will dump the contents of the fusor, which will show all the values produced by the motion chip for the last 20ms or so.
monitor clash: This will print continous output about about clash data. It should show you approximately what is going on.
You’ll probably want to post the output here to see what we can tell from the output.
OK, I’ve done dumpfusor and monitor clash in 6.7 and these are the results:
However before that I tried the same config in 5.9, and bizarrely that didn’t exhibit the clash problem. Yet the serial data above from 6.7 does show the motion chip going crazy (assuming I read it right). However the audio in 5.9 was terrible - crackly and nasty. Config volume was only 1000, and even when I went down on the menu (which did seem to work in 5.9) it was still awful even when whisper quiet. I suspect the audio was bad in 6.7 too, but with so many clashes all on top of each other it’s kind of hard to tell.
So the gyro data looks weird.
But I don’t see anything wrong with the accelerometer data.
In 6.x, clashes are checked by checking if | accel - down | > threshold (and I think that was the case in 5.x too.)
The accel data looks fine, but it might be that one value in a few thousand is bizarre, causing a clash. That would be hard to see with monitor clash. dumpfusor might be able to catch it, but you would need to run it lots of times.
The other possibility is that the down vector goes crazy because the accelerometer data is off. The down vector seems reasonable in the serial output though: down={0.14, 0.08, 1.03}
Thanks Prof.
Although I’m not quite sure where that leaves us.
Are we saying that the gyro is broken, even though (if I’ve read it right) it shouldn’t actually affect clashes?
I’m guessing the gyro doesn’t affect sound quality either, so that must be a separate issue? (I’ll try swapping the speaker but it’s tricky on this particular install).
Just trying to figure out where to go from here.
It might be.
The gyro affects the “down” value. If the gyro says the saber rotated 1 degree, then the “down” vector is rotated 1 degree in the other direction so that it still points down. Bad gyro values could make the down vector point in a direction which isn’t actually down, and then the clash algorithm would produce false clashes.
OK, I just downloaded a clean 6.7 OS and tried inserting that code as you said. This is what it looks like in Prop_Base, including the two ‘if’ lines you mentioned:
In file included from /Users/chrisandlindsey/Desktop/ProffieOS_6.7/ProffieOS/props/saber_sa22c_buttons.h:123,
from /Users/chrisandlindsey/Desktop/ProffieOS_6.7/ProffieOS/config/padawan_thrawn_short_v10.h:69,
from /Users/chrisandlindsey/Desktop/ProffieOS_6.7/ProffieOS/ProffieOS.ino:567:
/Users/chrisandlindsey/Desktop/ProffieOS_6.7/ProffieOS/props/prop_base.h: In member function 'virtual void PropBase::DoAccel(const Vec3&, bool)':
/Users/chrisandlindsey/Desktop/ProffieOS_6.7/ProffieOS/props/prop_base.h:726:36: error: 'class Fusor' has no member named 'gyro_clash_value'
726 | << " gyro: " << fusor.gyro_clash_value()
| ^~~~~~~~~~~~~~~~
exit status 1
Error compiling for board Proffieboard V2.
OK I did that and it all worked.
But most bizarrely, everything now works perfectly!
I confess I’m a bit confused. I can only think that my 6.7 folder must have got corrupted somehow, as downloading a new copy from the Proffie website seems to have sorted it - both in terms of false clashes and bad audio. Yet all I did originally was duplicate the entire folder from the long hilt install (which was all up and running and working perfectly) and tweak the config for the accents.
I’m so sorry for what seems to have been a wild goose chase.
