M3post.com Transmission Testing Adventure

[lucid]

Originally Posted by footie

Not an electronic geek but could you not place a contact on to the back of the paddle and rig up a switch which when the paddle is flicked the two contact and create a circuit. No opening panels or messing with wiring. It mightn't give the exact point at when the signal from the paddle is sent from it's own wiring but it should be pretty close.

Just a thought.

Yes, that's what I suggested above. The issue would be calibration--making sure that it is activated when the paddle clicks. No way of calibrating with high accuracy without having access to the actual signal that is transmitted from the paddle, but it might still be good enough for long delays.

[swamp2]

^ Very difficult to impossible without extensive effort and additional equipment to calibrate any type of sensor (accelerometer, switch, etc.) used on an actual paddle. The paddle throw is a good 1/2" or so and the question becomes at what point during the paddle stroke does the electronic switch in the system actually send the shift signal? The lag measurements will be crap with this method and will contain extra systematic and random errors. Random because each pull from each driver will not be the same. As well each paddle has a different stroke and engagement point. For example the throw on the C63 AMG (not a car we wanted to test, but just for discussion sake) is really short compared to the M-DCT.

The BEST way would (as suggested previously) be to pop the transmission tunnel cover and intercept (i.e. clip on to) a wire used in the shifter in that region as opposed to the paddles in the column. Often these panels pop right off with no tools.

I know I keep repeating myself but we really need:

-Another donor at $100
-More cars.

Period.

[lucid]

I don't know to what extent these paddles provice tactile feedback when "clicked". That would be the only reference for calibration on a switch. The user would visually inspect the signal from the switch and decide if it was late or early depending on the tactile feedback he got--if there is feedback. But again, that would probably only be accurate to .2 seconds or so, and I am assuming that is on the order of the delay in many cases. On the other hand, an accelerometer might be able to pin the actual click down much better if there is tactile feedback--if there is a mechanical signature if you will--and might yield some useful information.

The probe idea will be the most accurate by far, but we should ask people if they are okay with opening up their steering columns so that we don't waste time with them if they are not.

Anyway, do you guys know how to locate the right wire apart from a trial and error approach? It might help to figure that out from documentation for different cars prior to the tests.

[TLud]

Originally Posted by lucid

Anyway, do you guys know how to locate the right wire apart from a trial and error approach? It might help to figure that out from documentation for different cars prior to the tests.

Apparently, wiring diagrams are available online (I'll look around), but it'll probably be relatively obvious once the steering column is opened up. Even if not, it'd be easy enough to figure it out with a multimeter.

[swamp2]

Originally Posted by lucid

but we should ask people if they are okay with opening up their steering columns so that we don't waste time with them if they are not.

Again, I'm 99% positive we can simply open the transmission tunnel and in most cased that will be simply via a snap off/snap on cover plate. The wire to clamp on to will be fairly simply located by trial and error and will be one coming right off the shifter that is on the tunnel. Of course volunteers will have to be let know exactly what is being planned. Surprises are not good for anyone.

[lucid]

Originally Posted by swamp2

Again, I'm 99% positive we can simply open the transmission tunnel and in most cased that will be simply via a snap off/snap on cover plate.

For some reason, I've been fixated on the steering column, and missed your reference to the tranmission tunnel. Yes, that should be easier to pop although if I had a $250k Ferrari, I'm not sure that I'd want some stranger, or myself, popping any kind of panel in my car as those things can snap if you pull the wrong way--not that we've been able to identify any Ferrari owners yet. Anyway, I guess we'll figure this stuff out as we go...

[T Bone]

Originally Posted by lucid

For some reason, I've been fixated on the steering column, and missed your reference to the tranmission tunnel. Yes, that should be easier to pop although if I had a $250k Ferrari, I'm not sure that I'd want some stranger, or myself, popping any kind of panel in my car as those things can snap if you pull the wrong way--not that we've been able to identify any Ferrari owners yet. Anyway, I guess we'll figure this stuff out as we go...

In the ideal world, we would have some OBD2 tool that would give the throttle position and a whole hose of other data.....

Anyone brave enough to develop such a thing? Or modify another OBD2 reader?

[TLud]

I have an OBDII tool (DashHawk) that measures both relative and absolute throttle position, among a host of other variables. It has data logging and charting capability, and I suppose it should work for this purpose.

Only problem is that it is semi-permanently mounted in the dash of my truck. I could take it out for short term use, but I don't think I'd want to mail it around the country.

[swamp2]

Getting a bit too far OT. Getting an OBD system to work for this task would be difficult and integrating it with the simple and fairly low cost system I have speced out herein would be really difficult. As well it would not add any information we are looking for. Again, keep it simple and as low cost as possible for the task at hand. For example throttle position is 100% irrelevant to these tests.

[T Bone]

Originally Posted by swamp2

Getting a bit too far OT. Getting an OBD system to work for this task would be difficult and integrating it with the simple and fairly low cost system I have speced out herein would be really difficult. As well it would not add any information we are looking for. Again, keep it simple and as low cost as possible for the task at hand. For example throttle position is 100% irrelevant to these tests.

Yes, it was OT, sorry but I would be interested in seeing what the throttle position is for downshift blips.

[kenwelch]

Originally Posted by swamp2

Getting a bit too far OT. Getting an OBD system to work for this task would be difficult and integrating it with the simple and fairly low cost system I have speced out herein would be really difficult. As well it would not add any information we are looking for. Again, keep it simple and as low cost as possible for the task at hand. For example throttle position is 100% irrelevant to these tests.

The problem with using OBD II scan tools and OBD data is that the data is processed data from the Powertrain Control Module (PCM or DME). The readings you get are not in real time and only what the PCM thinks is happening. Also the scan tool must process the information and then display the data. The delay would make coordinating live measurements to the processed data on the scan tool interesting.

Also there is another problem with using the connections in the “transmission tunnel” the M-DCT shifter is connected to a switch with a built-in control module. The M-Gear Selector Switch (M GWS) “consists of the selector lever with indicator, the housing with control module…..”. The M-Gear Selector Switch communicates through two networks.
“In addition to the PT-CAN connection; there is a LIN-bus connection built in to the M GWS for redundant communication with the M-DCT electronics”.

Interpreting the network signals from the M GWS will be a little more difficult than clamping on a low amp probe to wires in the center console (transmission tunnel).

[lucid]

I don't think throttle position is OT, especially given it should affect the delay. OBD info is problematic though. Calibration would be a serious problem, and Kenwalch is pointing out latency issues. It should be possible to use a simple position sensor of some kind to physically measure the throttle position and feed that to the DAQ along with the acceleration and shift command data. There might be a slight calibration issue in determining where WOT is exactly in the pedal, but the data would be interesting even if we can't get that right. I agree this is not a priority, but it should be fairly straightforward to implement.

[swamp2]

Originally Posted by kenwelch

Also there is another problem with using the connections in the “transmission tunnel” the M-DCT shifter is connected to a switch with a built-in control module. The M-Gear Selector Switch (M GWS) “consists of the selector lever with indicator, the housing with control module…..”. The M-Gear Selector Switch communicates through two networks.
“In addition to the PT-CAN connection; there is a LIN-bus connection built in to the M GWS for redundant communication with the M-DCT electronics”.

Interpreting the network signals from the M GWS will be a little more difficult than clamping on a low amp probe to wires in the center console (transmission tunnel).

Might be. Here is my speculation (actually stronger than speculation, it almost MUST be this way for any transmission whose lever initially or ultimately controls an electronic switch). When in manual mode (or likely automatic mode as well) and when not actually shifting the communication from the switches in the M-DCT shifter will NOT be transmitting any information, analog or digital, hence a "quiet" system. However, once the lever is activated at least one of the wires leaving the M GWS will "fire" for a very brief instant. It should be a spike rather than a step function change. If you have a good, sensitive milliamp current probe, you will be able to detect and capture this signal via the DAQ. Even if the signal is digital (which I doubt) the system is likely quiet then active for a brief instant when shifted and again the current probe should work.

Heck the redundant communication protocols makes things sound even easier. This leads me to believe we could get a useable signal from two alternate sources and through two different wires.

I know transmissions are one of your specialties so I welcome your input and advice. Perhaps you can even squeak some better information from some BMW contacts to make this part of the testing easier. We must have the shift signal synchronously in the data acquisition process along with the accelerations (and, obviously we have to do this on each car tested).

[swamp2]

Originally Posted by lucid

I don't think throttle position is OT, especially given it should affect the delay. OBD info is problematic though. Calibration would be a serious problem, and Kenwalch is pointing out latency issues. It should be possible to use a simple position sensor of some kind to physically measure the throttle position and feed that to the DAQ along with the acceleration and shift command data. There might be a slight calibration issue in determining where WOT is exactly in the pedal, but the data would be interesting even if we can't get that right. I agree this is not a priority, but it should be fairly straightforward to implement.

Not sure the point at all of throttle position. The idea is to get shift times and lag times and in the simplest terms to just get min and max values. We do not need to cover a complete smooth range of throttle positions. The idea here is not to map out some complexities of the TCU algorithms and how they work given various throttle inputs, just get the TIMES. Keep it simple. Part of the test plan would be multiple runs at roughly steady "light" "medium" and WO throttle conditions to simply cover the range. Of course in each vehicle those values would be a bit subjective. You could even make some simple spacer blocks to place under the gas pedal if you felt that throttle position was a huge factor (again I don't think it will be).

So again in a nutshell we want shift times and lag times, min and max, some basic Drivelogic mode sensitivity and throttle sensitivity, that is it. Adding a position sensor on the throttle involves another DAQ channel, another sensor like an LVDT, machined parts to mount the LVDT to the gas pedal, potential power supply and calibration issues for the LVDT, a much greater potential for safety problems from a stuck pedal, etc., etc., etc. Way too much work as well.

KISS - Keep It Simple Stupid. With of course absolutely no thoughts that those of you interested in throttle position are "stupid". This common phrase just captures my philosophy in testing. The "stupid" is more like something you say to yourself when things start getting to complex (and costly!).

[lucid]

Originally Posted by swamp2

Not sure the point at all of throttle position. The idea is to get shift times and lag times and in the simplest terms to just get min and max values. We do not need to cover a complete smooth range of throttle positions. The idea here is not to map out some complexities of the TCU algorithms and how they work given various throttle inputs, just get the TIMES. Keep it simple. Part of the test plan would be multiple runs at roughly steady "light" "medium" and WO throttle conditions to simply cover the range. Of course in each vehicle those values would be a bit subjective. You could even make some simple spacer blocks to place under the gas pedal if you felt that throttle position was a huge factor (again I don't think it will be).

So again in a nutshell we want shift times and lag times, min and max, some basic Drivelogic mode sensitivity and throttle sensitivity, that is it. Adding a position sensor on the throttle involves another DAQ channel, another sensor like an LVDT, machined parts to mount the LVDT to the gas pedal, potential power supply and calibration issues for the LVDT, a much greater potential for safety problems from a stuck pedal, etc., etc., etc. Way too much work as well.

KISS - Keep It Simple Stupid. With of course absolutely no thoughts that those of you interested in throttle position are "stupid". This common phrase just captures my philosophy in testing. The "stupid" is more like something you say to yourself when things start getting to complex (and costly!).

Swamp, you need to cool down here. I understand you have a certain impression of what "you" want to measure. That's fine, but it doesn't mean we can't engage in a discussion about what else might be interesting to measure. If someone wants to add another channel, why does that bother you so much as long as it does not interfere with the basic measurements we all agree on and are after? I appreciate hearing your perspective, but there is no need to act like a domain expert and lecture folks. The idea is to get a discussion going and obtain multiple perspectives.

You know as well as I do that the delay seems to be a function of throttle position. Even the actual shift time might be throttle position dependant. How will you consistently characterize "low" "medium" and "WOT" throttle inputs without any kind of objective reference? A wooden block sounds too crude to me (never mind potential safety issues with the block getting stuck somewhere unless you want to drill it into the floor panel). It would be much nicer if the actual throttle position was a part of the dataset. Plus, as I said ealier, I would like to use this setup on the track to log my own driving after we are done with this test, so I have other goals. I will pay for any additional costs associated with the potential position sensor.

You are exaggerating the potential issues with a position sensor on the throttle pedal. Regardless, the point is, even if it turns out to be a big deal, we can easily drop it, and nothing else would be affected. It wouldn't be on any kind of critical path. Just an added module.

I will try a few things with the setup I will borrow when I get back to Boston next week and let you guys know.

All, we still need one or two more people to finance this project by the way...

[footie]

I don't mean to be blunt, but this is the reason why I am staying out of this discussion and why at present I am not helping foot the bill. I appreciate what swamp is trying to do and I don't mean to offend here, but his pigheadedness on how his way is the only way just puts people off wanting to help or give an opinion on what is needed.

To me what Lucid is saying is correct, it is the throttle position which many believe to be the cause of the delay (myself included) among other things. I also understand the more requirements mean more time and ultimately money to get the job done.

Sorry for ranting on but on this one I am behind Lucid all the way.

P.S.

Could I suggest a list of objectives from the outcome of the test so that everyone know what you are looking to achieve and can give an opinion on something you might have overlooked. That way you win over the people you are looking the dosh from and they understand which kind of results to expect.

Could this not be carried out on a rolling road, it's ultimately safer for the public and no chance of getting a speeding ticket. Though I don't know if that a thing would affect the results.

[swamp2]

Originally Posted by lucid

Swamp, you need to cool down here. I understand you have a certain impression of what "you" want to measure. That's fine, but it doesn't mean we can't engage in a discussion about what else might be interesting to measure. If someone wants to add another channel, why does that bother you so much as long as it does not interfere with the basic measurements we all agree on and are after? I appreciate hearing your perspective, but there is no need to act like a domain expert and lecture folks. The idea is to get a discussion going and obtain multiple perspectives.

You know as well as I do that the delay seems to be a function of throttle position. Even the actual shift time might be throttle position dependant. How will you consistently characterize "low" "medium" and "WOT" throttle inputs without any kind of objective reference? A wooden block sounds too crude to me (never mind potential safety issues with the block getting stuck somewhere unless you want to drill it into the floor panel). It would be much nicer if the actual throttle position was a part of the dataset. Plus, as I said ealier, I would like to use this setup on the track to log my own driving after we are done with this test, so I have other goals. I will pay for any additional costs associated with the potential position sensor.

You are exaggerating the potential issues with a position sensor on the throttle pedal. Regardless, the point is, even if it turns out to be a big deal, we can easily drop it, and nothing else would be affected. It wouldn't be on any kind of critical path. Just an added module.

I will try a few things with the setup I will borrow when I get back to Boston next week and let you guys know.

All, we still need one or two more people to finance this project by the way...

Obviously I do feel strongly about it, otherwise I wouldn't post my opinion. I am not lecturing nor being hot headed. I would be more than happy to cool down if you pointed out how I am being not cool! Seriously.

Again THE central question is this: How do we obtain quality and accurate measurements of shift times and shift lags with minimal effort and minimum cost? In order to be good stewards of donated money you have to keep focused and as I said I very much believe the throttle position thing is an enormous distraction. I do not believe I have exaggerated the added complexity, difficulty, cost nor safety issues with adding a throttle position sensor. Furthermore, you really have to ask the question - what will it tell you? Will you monitor it while driving to standardize tests? Will you try a much more complex test plan to make every possible combination of throttle, rpm, Drivelogic mode, etc. then determine some dependencies or algorithm? We already know the basic answers about throttle position and its effect on shift lag! However, the issue is somewhat obfuscated by rpm. Is it just throttle position that provides a shorter lag or is it just rpm or some combination? Is our goal to determine this? I don't think so, not at all. Perhaps we should add another channel for rpm... perhaps one for brake pressure, fuel mixture, etc. ... I know, I know, a bit of argument ad absurdum but my point is valid.

I don't think this is at all what "I" want to measure. I said lets measure shift times. Later on during "thinking out load" I revisited the idea that lag is a key component of TOTAL shift time and most seemed to agree with that. Now we have drifted off to throttle position. If you can clearly define why we would want to do it, in what way it would shape a test plan and how it will further the knowledge about shift times I will certainly listen.

P.S. taping a wooden block below the gas pedal is completely safe, accurate and cheap.





P.S.S. Thanks for the vote of confidence footie. I'm sure you could organize the equipment and testing much better than me. I have been crystal clear about what kinds of results you can expect and have listed those previously. You can stop with the insults such as "pigheaded" when you sir seem to not be able to read.

[footie]

Originally Posted by swamp2

Thanks for the vote of confidence footie. I'm sure you could organize the equipment and testing much better than me. I have been crystal clear about what kinds of results you can expect and have listed those previously. You can stop with the insults such as "pigheaded" when you sir seem to not be able to read.

I have total confidence in your ability to get the job done but what I don't have confidence in is your ability to listen to what other people say and respect their opinion.

You are a person with a lot of intelligence but zero people skills. Maybe this is not require in your line of work but to ask people for money and then insult them at every opportunity is not the way to get the desired funding. You say you have listed the kind of results to expect but to Lucid, myself and others feel other things would need to be addressed as well to fully understand why the transmission is behaving the way it is in different occasions.

P.S.
I might have had disagreements with you on other subjects of the transmission but on the whole I was in agreement on the requirement for these tests to be done. As I said, it was not my intent to insult you, only to highlight the fact that the way you go about speaking to people leaves a lot to be desired, pigheadedness a word to describe your stubbornness to listen to other opinions, maybe in the States it's regarded as an insist but it was really not my intent.

P.S.S.

I hinted that the best and safest way to conduct the results were to carry them out on a rolling road, that way someone can be viewing the computer and relaying the requirements needed from the driver without needing to return to the same point. It's quicker and should allow for more results to be gathered on hopefully more cars.

[lucid]

Swamp, I think you already know the answer of the questions you asked. I already answered them in general terms. Nobody is suggesting we monitor brake pressure or fuel mixture. (What does brake pressure have to do with anything by the way?) We all seem to agree that throttle position and engine speed might have something to do with lag duration. Why is it so absurd to want to measure some reasonable subset of combinations of those (nobody said "all possible combinations" by the way, so please don't dramatize for effect there)? You are just being stubborn there. Maybe you don't think measuring those variables should be the "goal" of this exercise. Fine, I respect that. But that doesn't mean that other have to think like you do. Why is that so hard to accept?
I do see your point about trying to measure more variables will add cost and complexity. I offered two simple solutions to those concerns. I will pay for the position sensor if we feel like we really would like that data, and that measurement will in no way interfere with the basic lag and shift measurements (referred to as Intervals 1 and 2 earlier on this thread). So, even if it can't be performed for some reason, it won't break the test. If it happens, it will add some useful context that we can use to interpret the results.

There is nothing very complicated about measuring distance. We can even use a non-contact method. We just need to measure relative travel from no throttle input. As I've said earlier, determining WOT might be an issue, but we can estimate that by doing an initial series of calibration runs at different throttle positions until we fail to detect an increase in acceleration in 3rd gear on the highway. Yes, this would definitely add to the number of test runs we would be doing and increase the duration of the tests. But once we have a WOT position estimate and do 3 lag measurements at 3 different throttle inputs, we will be able to determine, with decent accuracy, the throttle inputs those 3 measurements were obtained at. So you can arrive at something in the lines of, in the M3, increasing throttle input from 55% to WOT resulted in a X% decrease in the lag, whereas in the GTR increasing throttle input from 45% to WOT resulted only in a Y% decrease in the lag. Or if the phenomenon is not continuous, which it most likely isn't, by doing more than 3 runs, we might be able to pinpoint the throttle input level at which a discrete effect is observed. We don't need to log rpms. We can simply start a set of tests at a specific rpm and vary the throttle position in the proceeding tests in that set. We can eyeball the rpm at which the shift is requested by using the tack. Would be accurate enough in higher gears IMO. You know all this. Why are you making me explain it?

Now, if your point is that that kind of more exhaustive approach is not in your thinking, and you are not interested enough to put in the necessary time to investigate throttle position effects, just say so, and I'll respect that. But please don't start telling me how experiments should or should not be run, and KISS and all that as those do not add anything to the discussion in my opinion.

As to cooling down: Please review this thread and look for words such as "wrong" and "period". Those are not so collaborative moves. They seem to be aimed at converging the discussion as opposed to letting it naturally diverge at an early stage. This could be because you already have a pretty clear conception of what needs to be done, which is fine. Then, do your own thing, and I'll be happy to learn from what you find out. But the thing is you have solicited participation, so it is natural that people will want to chime in and broaden the discussion before settling on something. If you are not open to that type of negotiation process, then maybe it is best not to call for participation.

[swamp2]

Originally Posted by footie

I have total confidence in your ability to get the job done

Thanks, very sincere...

Originally Posted by footie

You are a person with a lot of intelligence but zero people skills. Maybe this is not require in your line of work but to ask people for money and then insult them at every opportunity is not the way to get the desired funding.

Well not to digress too far, nor to boast, but my profession is people. It is sales and just for your information I have been the top performer in the entire world among a global sales force of nearly 100 in the most important way our sales folks are judged.

Originally Posted by footie

I hinted that the best and safest way to conduct the results were to carry them out on a rolling road, that way someone can be viewing the computer and relaying the requirements needed from the driver without needing to return to the same point. It's quicker and should allow for more results to be gathered on hopefully more cars.

Hmmm a good idea but not in line with getting quality data on a shoestring budget. As well we already know that testing is likely going to be required wherer the various cars are located, which means sending the test gear around. I guess you missed that?

[swamp2]

Originally Posted by lucid

Nobody is suggesting we monitor brake pressure or fuel mixture. (What does brake pressure have to do with anything by the way?)

As I said those were admittedly sort of an argument ad absurdum.

Originally Posted by lucid

We all seem to agree that throttle position and engine speed might have something to do with lag duration. Why is it so absurd to want to measure some reasonable subset of combinations of those (nobody said "all possible combinations" by the way, so please don't dramatize for effect there)? You are just being stubborn there. Maybe you don't think measuring those variables should be the "goal" of this exercise. Fine, I respect that. But that doesn't mean that other have to think like you do. Why is that so hard to accept?

Yes they are related. I just can not be convinced it should be a goal and that it is worth the added complexity and cost. I have never purported that folks need to think like me but I do believe I have made a very solid case to cover throttle and rpm effects in a simple and free fashion.

Originally Posted by lucid

I will pay for the position sensor if we feel like we really would like that data, and that measurement will in no way interfere with the basic lag and shift measurements (referred to as Intervals 1 and 2 earlier on this thread). So, even if it can't be performed for some reason, it won't break the test. If it happens, it will add some useful context that we can use to interpret the results.

And do you think this will be something you can and will get folks testing for the project without your supervision to install and get set up correctly on their gas pedal?

Originally Posted by lucid

There is nothing very complicated about measuring distance. We can even use a non-contact method. We just need to measure relative travel from no throttle input. As I've said earlier, determining WOT might be an issue, but we can estimate that by doing an initial series of calibration runs at different throttle positions until we fail to detect an increase in acceleration in 3rd gear on the highway. Yes, this would definitely add to the number of test runs we would be doing and increase the duration of the tests. But once we have a WOT position estimate and do 3 lag measurements at 3 different throttle inputs, we will be able to determine, with decent accuracy, the throttle inputs those 3 measurements were obtained at. So you can arrive at something in the lines of, in the M3, increasing throttle input from 55% to WOT resulted in a X% decrease in the lag, whereas in the GTR increasing throttle input from 45% to WOT resulted only in a Y% decrease in the lag. Or if the phenomenon is not continuous, which it most likely isn't, by doing more than 3 runs, we might be able to pinpoint the throttle input level at which a discrete effect is observed. We don't need to log rpms. We can simply start a set of tests at a specific rpm and vary the throttle position in the proceeding tests in that set. We can eyeball the rpm at which the shift is requested by using the tack. Would be accurate enough in higher gears IMO. You know all this. Why are you making me explain it?

Because you will get essentially the same information or at least upper and lower limits on it with no money and no real added complexity. Please don't minimize the power of bracketing various values.

Originally Posted by lucid

Now, if your point is that that kind of more exhaustive approach is not in your thinking, and you are not interested enough to put in the necessary time to investigate throttle position effects, just say so, and I'll respect that.

No it is not in my interest to do this nor do I think it serves the purpose of the original post - which is to determine shift times (with the added clarification of getting upper and lower bounds on them and similarly with the lag).

Originally Posted by lucid

But please don't start telling me how experiments should or should not be run, and KISS and all that as those do not add anything to the discussion in my opinion.

We can all have our opinions. But if we democratize the entire process, which has already begun, we will never make any progress.

Originally Posted by lucid

As to cooling down: Please review this thread and look for words such as "wrong" and "period". Those are not so collaborative moves. They seem to be aimed at converging the discussion as opposed to letting it naturally diverge at an early stage. This could be because you already have a pretty clear conception of what needs to be done, which is fine. Then, do your own thing, and I'll be happy to learn from what you find out. But the thing is you have solicited participation, so it is natural that people will want to chime in and broaden the discussion before settling on something. If you are not open to that type of negotiation process, then maybe it is best not to call for participation.

I stand by my use of those terms when I used them and do not see them at being hot headed, pigheaded or anything else. See comment above about democratization of a process that clearly needs a leader. Do we need to make a poll and see if measuring throttle position is a "must have", a "should have" or a "don't bother"? We don't have enough money right now to get all the gear we really need so how the heck can this even be on the table? Again this is based on the fact that the loaner equipment that you may be able to procure can not leave your immediate vicinity.

I suppose I am not being nice enough, open enough or whatever. But my style is clear, get it done, get it done with minimal cost and minimal complexity have quality data. That's it, period. Whoops sorry there goes another bad word...

[footie]

Originally Posted by swamp2

Thanks, very sincere...

Good, we finally got that one out of the way. I might add I never put myself forward as one to lead or conduct such a test, I neither have the skills or knowledge of the subject. I am a leader of people now-a-days so my skill in business and people management being self-employed with over 53 staff.

Originally Posted by swamp2

Well not to digress too far, nor to boast, but my profession is people. It is sales and just for your information I have been the top performer in the entire world among a global sales force of nearly 100 in the most important way our sales folks are judged.

I am glad to hear it, though I doubt you talk to those people the same way as you frequently talk to people on this site. Friendly banter is good fun and that is what I and TB have that going on but you do like to talk down to people at times, maybe not intentionally but that is the way it comes across. What sort of a mate would I be if I didn't highlight this fact to you.

Originally Posted by swamp2

Hmmm a good idea but not in line with getting quality data on a shoestring budget. As well we already know that testing is likely going to be required wherer the various cars are located, which means sending the test gear around. I guess you missed that?

Sorry I misunderstood, I took it the SolCal way the area where the tests were being conducted, mainly because of the rich pickings there and as you guys were into your dyno testing I just thought a friendly store would allow such a test to be carried out on the cheap. If the test gear is being sent to other locations then I totally agree that my idea would be out the window.