Sorry to revive this thread, but I have a hilt where the buttons are very close to the board, and clicking them is sometimes giving false clashes.
My question is to the prof - do the bits of code you referenced above in Prop Base (1710 IgnoreClash and 282 ClashTimeout) apply to ALL button clicks (Main and Aux) or just selected clicks from one of the buttons?
Also what does the number on ClashTimeout refer to? is it milliseconds? If so, 3 seems very short - it feels like something more like 20 or 50 would be more realistic.
Just been experimenting and I’m not sure if those mods are actually inverted. The video shows what I mean.
The setup in the video is that prop_base is modified thus:
282 clash_timeout_ = 15;
and
1708 IgnoreClash(250); // ignore clashes to prevent buttons from causing clashes
The config has clashes as yellow and blaster blocks as white. But as you can see, the clashes are pretty instant with aux button clicks, but the blaster blocks appear delayed.
Unfortunately it’s hard to hook up serial monitor in this build because I need to lift the board up slightly to get the USB in, and obviously the board will be subject to completely different types of vibration when resting on its wires compared to how it would be when secured in the chassis.
Really just sharing in case it’s useful. I can probably ramp up clash sensitivity as a workaround (it’s currently at 3.9), but I don’t want to make it too hard to get clashes unless I really have to.
The unit of both of these numbers is milliseconds.
3ms is generally enough for the “clash_timeout_”, because at that time, the click has already happened, it was just picked up by the accelerometer first, so we need a couple of milliseconds for the button code to detect it. 15 ms is still pretty fast, so it would be nearly instant.
The 50ms is to deal with vibrations after the click, which can take some time to go away. Making this 250ms does not actually delay anything, it just creates more time when no clashes will register.
I think this might be a “saved click” thing. Basically we wait a little bit before triggering a “saved” event to allow for double-clicks.
1 Like
Ah OK. Yes, could be. So looks like I need to do a little more experimenting and fine tuning. I might also try that don’t use gyro for clash define. It also occurs that I can’t see a down side to really racking those numbers up - like clash timeout 200ms and IgnoreClash 500ms. If you’re pressing buttons - whether it be for blaster blocks or to access things like colour menus, you’re not going to want a clash realistically for a full second at least. You could probably go to 1000ms for both to no ill effect.
Anyway I’ll do some more experimenting when I get home today and will report back.
OK, quick update:
After various experiments, it turned out that using the PROFFIEOS_DONT_USE_GYRO_FOR_CLASH define completely solved the problem without the need for any modifications to prop_base. It also allowed a sensible clash sensitivity of 3.9 which made for comfortable clashes with no false ones.
It seems this define is a useful catch all for any install where false clashes emanate from close to the board. You’ll remember I also had the same false clash issue with the Desert Wanderer Master chassis due to the rotating plasma gate motor being close to the board, creating crazy false clashes. I’ve now done three of those and used the above define successfully on all of them.
Definitely a useful one to have in the toolbox.
1 Like
