No bugs this time (at least I don’t think so) but most likely something I’ve done (or not done).
The first concerns blade detect. I’ve not used blade detect much, so I’ve almost certainly done something silly, but it’s not doing what I thought it would.
Setup is thin-neck hilt with removable chassis with neopixel blade disc in the grenade section. The idea is I want the Proffie to know when the chassis is inside or outside the hilt.
I’ve setup two separate bladestyle arrays which are identical apart from the fact that the spinning motor is set to spin with the chassis out and set to not spin with the chassis in. Blade detect pin is wired to RX (pad 8) and defined in the config.
The Proffie is correctly registering chassis insertion or removal as it plays the bladein / bladeout wavs. But it doesn’t seem to flip to the opposite bladestyle arrays, as evidenced by the fact that the motor spins regardless of whether the chassis is inside or outside the hilt.
My guess is there’s some little step I haven’t done.
Config is below.
What have I missed?
The second issue concerns a spinning crystal chamber motor affecting the sound. If I have a blade preset with the motor spinning, I get all sorts of horrible artefacts - not so much false clashes (although there is some of that) but false swings. If I switch to the same preset and font without the spinning motor, it sounds fine? Video is below.
Battery is charged, have tried swapping SD card, file structure is optimized for fast SD access. I’ve tried it with and without the #define PROFFIEOS_DONT_USE_GYRO_FOR_CLASH line, and I would say it’s worse without it.
Anyone else known motors to upset things before? It’s wired positive to batt + with a 10 ohm resistor, and negative to an LED pad. I’m guessing the motor vibration is causing the board’s motion sensors to think they’re moving when they’re not (The motor is very close to the board). The question is what, if anything, can be done about it?
As always, any thoughts welcome.