Help for my RS from the experts:)
May 31, 2010, 03:17 PM
#31
Interesting last few days. While my request in this thread I thought would be an odd one and a waste of time for some of you..............it would appear from the amount of people who asked me about it over this race weekend that the people watching this thread are 10 times what are posting in it! haha
I believe what I've requested is more sought after than any of us expected it to be.
Thanks again for those of you looking into it.
I believe what I've requested is more sought after than any of us expected it to be.
Thanks again for those of you looking into it.
May 31, 2010, 03:35 PM
#32
Interesting last few days. While my request in this thread I thought would be an odd one and a waste of time for some of you..............it would appear from the amount of people who asked me about it over this race weekend that the people watching this thread are 10 times what are posting in it! haha
I believe what I've requested is more sought after than any of us expected it to be.
Thanks again for those of you looking into it.
I believe what I've requested is more sought after than any of us expected it to be.
Thanks again for those of you looking into it.
Jun 1, 2010, 05:23 PM
#33
Curious if anyone knows anything about the variables I'm logging.
Discovered something interesting.
the value is zero when at idle but soon as you give it even a hint of throttle it goes to 4 when i did a small WOT pull i jumps to 6 and 7 showing bits 0 and 1 come on only at high load levels normal driving does not do this.
I'm wondering if what i've stumbled upon is really the fuel circuit itself where the pump gets more voltage at a certain load levels. Thoughts?
Also I'm trying to figure out a way of logging the variable while sending a mut command to simulate the ecu into actuating the fuel pressure solenoid so i can log variables and determine where its coming from. Any info would be nice here.
Discovered something interesting.
the value is zero when at idle but soon as you give it even a hint of throttle it goes to 4 when i did a small WOT pull i jumps to 6 and 7 showing bits 0 and 1 come on only at high load levels normal driving does not do this.
I'm wondering if what i've stumbled upon is really the fuel circuit itself where the pump gets more voltage at a certain load levels. Thoughts?
Also I'm trying to figure out a way of logging the variable while sending a mut command to simulate the ecu into actuating the fuel pressure solenoid so i can log variables and determine where its coming from. Any info would be nice here.
Jun 1, 2010, 06:37 PM
#34
Evolving Member
Join Date: Apr 2008
Location: Reading, PA
Posts: 265
Likes: 0
Received 0 Likes
on
0 Posts
0 - BF will be taken as a logged item.
C0 and greater will be taken as a Command.
Looking at the MUT Commands code is usually a good way to figure the solenoids out. Think the MUT Command changes the Actuator Flag Mask. Acamus has a couple posts on how the Actuator Flag Mask thingy works.
Edit - ( Commands C4 - D8 directly interface the Actuator Bit Mask Table [In H8s at least], so the MUT Command code isn't going to be easy way to find FPS either.)
I checked the FPS code in the H8s to see if there was a RPM or Load number you could search for. Unfortunately its not that simple, it looks at about 12 bit flags to decide if the FPS is on or off.
Jun 1, 2010, 09:50 PM
#35
Evolved Member
Join Date: Mar 2008
Location: Lattitude 48.38°, Longitude 17.58°, Altitude 146m = Slovakia, for common dude
Posts: 730
Likes: 0
Received 2 Likes
on
2 Posts
My shortcut would be logging A1-B6 while sending actuator command.
And then reverse eng the changing bit.
And then reverse eng the changing bit.
Code:
<DataListItem DataLog="Y" Color="" Display="A0" LogReference="A0" RequestID="A0" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="Y" Color="" Display="A1" LogReference="A1" RequestID="A1" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="Y" Color="" Display="A2" LogReference="A2" RequestID="A2" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="Y" Color="" Display="A3" LogReference="A3" RequestID="A3" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="Y" Color="" Display="A4" LogReference="A4" RequestID="A4" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="Y" Color="" Display="A5" LogReference="A5" RequestID="A5" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="Y" Color="" Display="A6" LogReference="A6" RequestID="A6" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="Y" Color="" Display="A7" LogReference="A7" RequestID="A7" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="y" Color="" Display="A8" LogReference="A8" RequestID="A8" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="Y" Color="" Display="A9" LogReference="A9" RequestID="A9" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="Y" Color="" Display="AA" LogReference="AA" RequestID="AA" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="Y" Color="" Display="AB" LogReference="AB" RequestID="AB" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="Y" Color="" Display="AC" LogReference="AC" RequestID="AC" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="Y" Color="" Display="AD" LogReference="AD" RequestID="AD" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="Y" Color="" Display="AE" LogReference="AE" RequestID="AE" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="Y" Color="" Display="AF" LogReference="AF" RequestID="AF" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="Y" Color="" Display="B0" LogReference="B0" RequestID="B0" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="Y" Color="" Display="B1" LogReference="B1" RequestID="B1" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="Y" Color="" Display="B2" LogReference="B2" RequestID="B2" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="Y" Color="" Display="B3" LogReference="B3" RequestID="B3" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="Y" Color="" Display="B4" LogReference="B4" RequestID="B4" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="Y" Color="" Display="B5" LogReference="B5" RequestID="B5" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="Y" Color="" Display="B6" LogReference="B6" RequestID="B6" Eval="x" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
Last edited by acamus; Jun 1, 2010 at 09:56 PM.
Jun 1, 2010, 10:39 PM
#36
The bits are reversed? Thats good to know.
The mut command d6 is supposed to be the fps which according to you in this post https://www.evolutionm.net/forums/7325298-post13.html is really mask 0x8.
I've found the test for 0x8 on mut_actuator_0
Jun 1, 2010, 11:13 PM
#37
Evolved Member
Join Date: Mar 2008
Location: Lattitude 48.38°, Longitude 17.58°, Altitude 146m = Slovakia, for common dude
Posts: 730
Likes: 0
Received 2 Likes
on
2 Posts
I have meant - reverse engineer the changing bit.
It is kind of black box testing, you do not have to disassemble that much and you have the bit.
It is kind of black box testing, you do not have to disassemble that much and you have the bit.
Jun 2, 2010, 06:06 PM
#39
Well thanks to accumus's suggestion i have the spot and bit where the FPS is.
its the PFDR (MUT AB) bit 2 or 0x4.
The setting happens in my 94170015 at 0xAF7E.
By the way since I seem to be the only one with time here should i intercept more of the actuators for stock vs windowed mode? Doesn't look like its going to exceedingly difficult to do. Seems at most the variables are only touched in a couple places.
I plan on just replacing them with dummy variables and handling the bit inter change in my own routine.
Which signals should I attempt intercept of, in other words what would be useful to us?
So far i'm thinking:
-Evap
-EGR
-FPS
-AC Fan
-Radiator Fan
Also a good note would be simply what conditions should we be shooting for?
TPS, RPM, Coolant Temp, etc
its the PFDR (MUT AB) bit 2 or 0x4.
The setting happens in my 94170015 at 0xAF7E.
By the way since I seem to be the only one with time here should i intercept more of the actuators for stock vs windowed mode? Doesn't look like its going to exceedingly difficult to do. Seems at most the variables are only touched in a couple places.
I plan on just replacing them with dummy variables and handling the bit inter change in my own routine.
Which signals should I attempt intercept of, in other words what would be useful to us?
So far i'm thinking:
-Evap
-EGR
-FPS
-AC Fan
-Radiator Fan
Also a good note would be simply what conditions should we be shooting for?
TPS, RPM, Coolant Temp, etc
Jun 2, 2010, 07:22 PM
#40
Some suggestions I have which you have probably already thought of but it's worth mentioning:
A minimum time delay between changing states
Hystersis for switching to prevent instablility of the control system at the thresholds
RPM, TPS, Load (and/or MAP), Coolant temp, vehicle speed
Also, the AC fan has two outputs, a low and a high speed.
A minimum time delay between changing states
Hystersis for switching to prevent instablility of the control system at the thresholds
RPM, TPS, Load (and/or MAP), Coolant temp, vehicle speed
Also, the AC fan has two outputs, a low and a high speed.
Jun 2, 2010, 07:34 PM
#41
Some suggestions I have which you have probably already thought of but it's worth mentioning:
A minimum time delay between changing states
Hystersis for switching to prevent instablility of the control system at the thresholds
RPM, TPS, Load (and/or MAP), Coolant temp, vehicle speed
Also, the AC fan has two outputs, a low and a high speed.
A minimum time delay between changing states
Hystersis for switching to prevent instablility of the control system at the thresholds
RPM, TPS, Load (and/or MAP), Coolant temp, vehicle speed
Also, the AC fan has two outputs, a low and a high speed.
This is probably a stupid question but Hysteresis is just an averaging of the variable right? I guess another way i could do it is just ignore changes for a certain number of cycles.
Anyways this sort of function is only valuable for direct inputs like map voltage right where the most glitches can happen. Slow moving variables like coolant temp and speed i shouldn't have to employ anything.
Jun 2, 2010, 11:01 PM
#42
Hysteresis creates a "dead" area where changes won't take place even though it is technically out of the range desired.
For example, let's say you do an RPM based window with a start point at 4500 and a stop point at 7500. As revs increase, it trips 4500 RPM and the window region is reached, activating the output. Any jitter though could cause the RPM signal to drop below 4500 and it would shut the output back off even though you don't really want it to.
What I am talking about would be a second condition where once the output is active it won't turn OFF until it goes below like 4200 RPM, giving a 300 RPM "dead" zone that is actually out side of the intended range. Any jitter now won't cause the output to shut off unless the engine speed drops more then the range you have allowed for. You would also do the same on the top, the output would initially turn off at 7500 but might not turn back on until the RPM goes below 7200 RPM.
You use hysteresis on a lot of stuff just to avoid bit toggling where you are right on the resolution threshold and the output wants to turn off and on because the input is floating around the trigger value. Say coolant temp with a threshold of 80C and the signal is fairly stable at 80C but bounces back and forth 1 bit. Giving it like5 C of dead area would keep relays from clicking and eventually burning up stuff.
The time delay is more for nitrous then anything, but it also has kind of a similar effect as introducing hysteresis requirements.
For example, let's say you do an RPM based window with a start point at 4500 and a stop point at 7500. As revs increase, it trips 4500 RPM and the window region is reached, activating the output. Any jitter though could cause the RPM signal to drop below 4500 and it would shut the output back off even though you don't really want it to.
What I am talking about would be a second condition where once the output is active it won't turn OFF until it goes below like 4200 RPM, giving a 300 RPM "dead" zone that is actually out side of the intended range. Any jitter now won't cause the output to shut off unless the engine speed drops more then the range you have allowed for. You would also do the same on the top, the output would initially turn off at 7500 but might not turn back on until the RPM goes below 7200 RPM.
You use hysteresis on a lot of stuff just to avoid bit toggling where you are right on the resolution threshold and the output wants to turn off and on because the input is floating around the trigger value. Say coolant temp with a threshold of 80C and the signal is fairly stable at 80C but bounces back and forth 1 bit. Giving it like5 C of dead area would keep relays from clicking and eventually burning up stuff.
The time delay is more for nitrous then anything, but it also has kind of a similar effect as introducing hysteresis requirements.
Jun 2, 2010, 11:44 PM
#44
Hysteresis creates a "dead" area where changes won't take place even though it is technically out of the range desired.
For example, let's say you do an RPM based window with a start point at 4500 and a stop point at 7500. As revs increase, it trips 4500 RPM and the window region is reached, activating the output. Any jitter though could cause the RPM signal to drop below 4500 and it would shut the output back off even though you don't really want it to.
What I am talking about would be a second condition where once the output is active it won't turn OFF until it goes below like 4200 RPM, giving a 300 RPM "dead" zone that is actually out side of the intended range. Any jitter now won't cause the output to shut off unless the engine speed drops more then the range you have allowed for. You would also do the same on the top, the output would initially turn off at 7500 but might not turn back on until the RPM goes below 7200 RPM.
You use hysteresis on a lot of stuff just to avoid bit toggling where you are right on the resolution threshold and the output wants to turn off and on because the input is floating around the trigger value. Say coolant temp with a threshold of 80C and the signal is fairly stable at 80C but bounces back and forth 1 bit. Giving it like5 C of dead area would keep relays from clicking and eventually burning up stuff.
The time delay is more for nitrous then anything, but it also has kind of a similar effect as introducing hysteresis requirements.
For example, let's say you do an RPM based window with a start point at 4500 and a stop point at 7500. As revs increase, it trips 4500 RPM and the window region is reached, activating the output. Any jitter though could cause the RPM signal to drop below 4500 and it would shut the output back off even though you don't really want it to.
What I am talking about would be a second condition where once the output is active it won't turn OFF until it goes below like 4200 RPM, giving a 300 RPM "dead" zone that is actually out side of the intended range. Any jitter now won't cause the output to shut off unless the engine speed drops more then the range you have allowed for. You would also do the same on the top, the output would initially turn off at 7500 but might not turn back on until the RPM goes below 7200 RPM.
You use hysteresis on a lot of stuff just to avoid bit toggling where you are right on the resolution threshold and the output wants to turn off and on because the input is floating around the trigger value. Say coolant temp with a threshold of 80C and the signal is fairly stable at 80C but bounces back and forth 1 bit. Giving it like5 C of dead area would keep relays from clicking and eventually burning up stuff.
The time delay is more for nitrous then anything, but it also has kind of a similar effect as introducing hysteresis requirements.
I'm planing on doing this in a couple sub routines should be fairly simple if they all act in the same manner.
Psuedo code isn't complete no matter :P
Psuedo code:
Code:
Void MainCodeLoop(void)
{
//Do Each mask one by one until done.
WindowCheck(stuff);
For each mask bit we touch according to the check bit location store
that mask into a resulting OR'ed super mask and then negate it giving
us the mask of all the bits we aren't going to touch.
Using a dummy variable we can place in the origional routines we can just
AND the currently negated mask to it giving us all the bits it would have set
except the ones we touched and OR that back into the checkbitlocation spot.
}
Boollean WindowCheck(SettingsLocation, RamVariable, Mask, CheckBitLocation)
{
//Assuming everyting is a double word
MinValue = @SettingsLocation;
MaxValue = @(SettingsLocation + 4);
Deviation = @(SettingsLocation + 8);
Reversed = @(SettingsLocation + 12);
//If the bit needs to be reversed we just negate the mask here
if(Reversed > 0)
Mask = Not(Mask);
//Check the state
if(CheckBitLocation & Mask > 0) //Means its activated to ON
{
if(CheckHyteresis(MinValue,MaxValue,RamLocation,Deviation))
ApplyBitMask(CheckBitLocation, Mask);
else
ApplyBitMask(CheckBitLocation, NegatedMask);
}
else
{
if(@Ramlocation >= MinValue && @RamLocation <= MaxValue)
ApplyBitMask(CheckbitLocation,Mask);
else
ApplyBitMask(CheckBitLocation,NegatedMask);
}
}
Boolean HysteresisCheck(MinValue,MaxValue,CurrentValue,Deviation)
{
if(CurrentValue + Deviation > MaxValue)
return true;
else if(CurrentValue - Deviation < MinValue)
return true;
else
return false;
}
Last edited by RoadSpike; Jun 2, 2010 at 11:47 PM.