Originally Posted by
pgop2.0
This would be true in a "dumb"system that transmitted the signal directly to the noid. In modern markers this is not the case. The switch signals are sent to the board logic which determines when the noid signals are sent. The filtering you are referring to (software debounce) is a number in milliseconds that the software is programmed to ignore additional signals after the first. Typically it looks like this:
delay(200);
where 200 is a fixed value. Variable debounce is one of the possible explanations for what I'm seeing (but not the most likely one IMO. Variable debounce looks like this:
int debounce = 200;
//elsewhere in the code we would find something like this
if((millis() - lastTriggerPullMillis) < bounceLoweringThreshhold){
debounce = 50;
}
//elsewhere we would find the debounce statement:
delay(debounce);
In my hastily typed example the software is checking to see how recently the last full switch signal occurred and is lowering the variable integer used to debounce the switch. It would not be much more complicated than than that.
I have reason to believe that (at least in most cases) it is signal thresholding that is the culprit variable. This is irrelevant to the results. BPS second limits actually allow the manufacturers to be more flagrant. What they aught to do is disregard any switch pull that exceeded the cap. What they do instead is say:
if(ROF > 12.5)
ROF = 12.5;
Now the sound signature that used to be a tell tale sign of cheater modes just sounds like the marker firing at the capped rate.
If the "profesional" leagues were serious about enforcing 1 shot 1 pull and the rof cap, they would insist on markers using hardware debounce.