BlindAssassin111:
I was mainly wanting to just use the average time to get a ball park for the program so it knows that within parameters of time that I set via hard code and/or via the last shift time.
What's an average time worth ? My 1'st to 2'nd to ... shift times are slow when I'm going for groceries, driving past a cop. They're quite different when I'm at a drag strip. My downshift times are different when approaching a stoplight vs approaching Turn 1 at Limerock. So what "average" do you want ? How would that help (w/setting a debounce time) ?
FWIW your switches may already be electrically debounced. Or maybe there’s a better, less simple way than I’ve posted. In any case it’s a risk item to be attended to, somehow at some point in time.
The main reasons for knowing the average are:
-
Last year after competition the clutch lever broke off, meaning we had no way of slipping the clutch for launches, so we had to use the shifter to bypass this problem, when you hold the downshift paddle the clutch actuator will be disengaging the clutch and when you let go it dumps the clutch and you are now in first and should be moving if you were 75% + throttle. This way after that long period of holding the downshift paddle, the arduino doesn’t compare to that time and think that every shift is a bounce. By using the data from just playing with the system, we can set an upper limit for the comparison of the last shift, ie. if a shift is above the upper limit don’t use that value to compare later on and if above the lower limit set by us to also get rid of possible bounce it will just help with the entire system if need be.
-
It shows the judges that we tested the average time that both the driver and transmission shift at(we already have a pretty good estimate for the shift time of the transmission, this would allow us to get an average total shift/reaction time(with some error obviously).
I think we’re talking 2 different animals. I don’t think you’ve quite grasped the switch bounce problem as it pertains to counting the number of times a shift is commanded by the driver vs how it’s counted by a micro. Perhaps Google some more on switch bounce ???
The time it takes for the transmission to do a shift is not the issue I’m raising. That’s a different animal. And one I don’t think you can easily measure. All the micro knows is when the driver pushed some switch. How long it took the transmission to complete that command … well, just how would that be measured ?
Ok, so we are both missing the point of each others statements a bit…Ignore the last couple posts.
First, I understand what debounce is…I may have just misunderstood how you were wanting to implement this type of debounce.
Second,I was trying to say by the first main point that if I were to compare the value of a pulse, that may have been a bounce or a shift, to the previous shift time, then if I were to hold the switch for a minute, and you only compare to the last pulse then you will always count the future pulses as bounces, seeing as they will be a whole lot faster. So the whole point of the average time is to set a ceiling, given by a slow shift time that I will measure via testing, for the pulses that can be used to tell if a pulse was a bounce or not, does that make more sense? I was still planning on using the comparing of pulses to get only the shift pulse, I was just adding upon that by making sure that if a pulse is longer due to us having to hold the paddle for some reason, the code will not include that in the comparison in order to prevent it screwing itself up.
Third, ignore the statement about the shifting time altogether…you aren’t understanding what I am trying to mean and I can’t think of any other way to word it besides saying that design judges at comp. are engineers in the field that they are asking questions about, it would be a nice thing to be able to say that we tested the gear indicator to make sure that it is “protected” from debounce because we tested the system to make sure that it was by comparing previous shift times below a given max. If that doesn’t make sense then sorry…I don’t know what else to say.
I will start coding to show you that I know what you are getting at and to show you what I was getting at. I have never been the best with words so sometimes what I say makes no sense to others but to me it makes sense…
Okay just finished the code, been really busy so I just started 15 minutes ago… but I did something similar to what you said, just a hard coded reference minimum time because it is just easier and is less code to run. I have thought of another way to do a debounce similar to this but I think this is the best for right now.
/*#define FLIPDISPLAY*/
#include <AlphaNumeric_Driver.h>
#define NUMBER_OF_DISPLAYS 1
int SDIpin = 7;
int CLKpin = 6;
int LEpin = 5;
int OEpin = 4;
int Up = 2;
int Down = 3;
volatile int currentGear = 1;
volatile int minReaction = 40; //can be changed if this value cuts out any shifts and vice versa
volatile unsigned long currentTime = 0;
volatile unsigned long lastTime = 0;
alphaNumeric mydisplay(SDIpin, CLKpin, LEpin, OEpin, NUMBER_OF_DISPLAYS);
void setup()
{
Serial.begin(9200);
pinMode(Up, INPUT_PULLUP);
pinMode(Down, INPUT_PULLUP);
mydisplay.print(currentGear);
attachInterrupt(0, downShift, RISING);
attachInterrupt(1, upShift, RISING);
}
void loop()
{
}
void upShift()
{
currentTime = millis();
if ((currentTime - lastTime) >= minReaction)
{
if (currentGear <= 4 && currentGear >=1)
{
currentGear++;
mydisplay.print(currentGear);
}
else
mydisplay.print(currentGear);
}
if (currentTime > lastTime)
{
lastTime = currentTime;
}
}
void downShift()
{
currentTime = millis();
if ((currentTime - lastTime) >= minReaction)
{
if (currentGear >=2 && currentGear <=5)
{
currentGear--;
mydisplay.print(currentGear);
}
else
mydisplay.print(currentGear);
}
if (currentTime > lastTime)
{
lastTime = currentTime;
}
}
Looks like it should work !
But pre-test code is like a battle plan before the 1’st shot. And you know what they say about battle plans. :mrgreen: