It is winter and all. So I am not going to bug you to make changes to CAL for a while. Thank you for what you have done and I think you earned some Finnish christmas present
It is winter and all. So I am not going to bug you to make changes to CAL for a while. Thank you for what you have done and I think you earned some Finnish christmas present
Don't worry. Thanks, it would help atleast me to check if there are some resistors broken and more debug why CC behaves the way it behaves now.
Car is in warm garage so I can check what resistance values it gives. Besides it need new left balljoint before going back to road.
Ok, I can't really calculate the resistance values. But, I can easily calculate the CC line voltage for each button press. I'm not sure which value goes to each button either.
#1 - 0.41V
#2 - 1.56v
#3 - 3.14v
#4 - 5v
What's also not clear to me, even looking at the code, is how it interprets a double button press. Each button is momentary, and you would normally only press one at a time. But, what happens if you press any combination of 2 buttons? The resistance is then divided and the output voltage is different.
Also, I had the thought that cars without cruise control could use this analog channel for other purposes. Variable boost control, spark trim or fuel trim something like that.
I may actually convert my Daytona to SBECII electronics this winter. I really want to play with the 3D tables for my own car...
Probably well thought out resistance values that when "stacked" equal an invalid value.
Ian Adams Function>Form 1990 shadow scrapped, too rusty:( 1991 Spirit R/T Scrapped, parts sold:( 1989 Turbo Caravan Daily beater with built-[I]ish [/I]engine slowly evolving into weekend turbo beater.
I'd say Shackwrr's idea is logical, I'd also guess that the highest voltage would work safest as an "on"/"off" button, with the next highest voltage being one that would possibly command the actuator to engage. Lower voltages to disengage...
The picture I found of what looks to be a period correct button "bar" shows 3 buttons, and 4 Pins on the back... So I'm a bit unsure how we get 4 values, since we need one of those to be "power in". If one is power in, we are left with two buttons and three values... I suppose it's possible to have two resistors for each button, one that is "normally closed" and one "normally open", but that's four values/voltages... Although I suppose one button could not have a resistor in one position...
Just my SWAG:
#1 - 0.41V_____"Set"
#2 - 1.56v_____"Resume"
#3 - 3.14v_____"Accel"
#4 - 5v________"on/off", uses the 5V on (or 0 off) to signal the SBEC if cruise is desired or not, and possibly "coast".
I guess we could probe the wires in the loom coming off the column, if all else fails...
Mike
"The Constitution is not an instrument for the government to restrain the people, it is an instrument for the people to restrain the government - lest it come to dominate our lives and interests." - Patrick Henry
Bad laws are the worst sort of tyranny.
- Edmund Burke
Rob, what may work well for you is something that's been done in the past.
Use a switch crkt to divide 0 - 5v into two operating ranges to 'mux' two features into the CC crkt.
For example:
0 - 2.3v = fuel trim
2.7 - 5v = spark trim
The logic, in this case, makes the determination on which feature is being adjusted based on the voltage window being used and is also the reason for the small voltage hysteresis between the two.
It helps to filter the voltage steps to prevent rapid adjustment and in some cases I used closed throttle to inhibit adjustment during switch toggling.
The resolution is not too bad depending upon how you scale the look up table(s).
Hope this helps the project.
Yeah, that's a good idea.
Here's another (related) question that maybe you know the answer to: The CC mode wire goes into Pin23 on the SBECII. Pin 22 is TPS and Pin24 is the Crank Ref input. 22 and 24 are the same on the SBEC(I). So, does that mean that pin 23 on the SBEC(I) is an unused A2D line on the SBEC?
Update Posted 12/14/12 - Updated some code definitions, and many updates to the 3-bar +40 pre-built cal.
Thanks for posting this up. What is the preferred editor of choice for these T3 cals? Is there any specific version that is better than others? Which software is most friendly with your flashable SBEC's?
Hehe The liquor is best when you put it in the freezer for a while. You too have a Merry Christmas!
RT is back in action.
When using regular fuel CEL lights after 4k rpm in boost. Using premium knocking happens after 5.5krpm in boost. may be still bit too much timing in high rpms...?
Fuel consumption feels a bit high, but I am not sure is that from Zeitronix giving feed to ECU. In driving AFR is not bouncing like using directly narrow band. It just stays 14.7 or goes +-.2
Still having very strange CC. Both set and resume buttons works as set button. Most of the time when speed has been set after for a while car stars accelerating. I can push set/resume to stop accelerating but of course car deaccelerates then. I even noticed that if the CC is on and I have set speed and pressed brake pedal to drop CC off. Some times ECU decides that it needs to accelerate. This looks like some memory bank problem.. just a wild guess. Where the CC is taking the reference? How it know what is the speed. Is it reading speedsensor or engine rpm? Bit faulty speedsensor could cause something, but not over accelerating and same function for both buttons.
I know that CC in 92 is bit different but I could not find any problems from wiring etc.. with stock ECU no problems.
and for one detail about the MPG display. It still is a bit optimistic.. I'd like to have car that I can drive 60-80MPH and MPG is something like 40
OK, I'll take a look at the cruise control code again...
I think I know what the cruise control issue is. Eski - can you read the cal file off your SBEC and e-mail it to me? I want to compare it to the original; I think it's being corrupted. It's related to the engine stalling issue you had last year. Basically, the flash module cannot prevent being overwritten when the ECU tries to write to the uProcessors EEPROM and certain bytes in the flash module then become corrupted. I think in your case those bytes are in the cruise control routine. Which is why you get strange behavior.
If it is actually the cal being corrupted by EEPROM writes, then I think it can be fixed by enabling the SDP on the flash chip (which hasn't been done in the past). I'm going to test it this week. I'll post the results later...
Do you still need that I read flash from SBEC? I can do that.
Ok. Will do that.