Any XEDE Converts??????? Some questions....
#1
Evolving Member
Thread Starter
iTrader: (4)
Join Date: Oct 2003
Posts: 108
Likes: 0
Received 0 Likes
on
0 Posts
Any XEDE Converts??????? Some questions....
Hey All,
I was wondering if there are any ECU+ users that have also used the Vishnu XEDE piggyback system. If there are, how do the two compare? Any regrets..?
Also, I have the following questions:
1. Does the ECU+ allow advancing of the timing without the dreaded PO300 MIL light?
2. Does only having three load variables (Low, Med, High, WOT) limit the capabilities of the unit. Also, what determines the load variable.....for instance what is the scaling? How does it compensate for a larger turbo (higher maf readings)?
3. Now the unit also monitors OBDII Cel codes.....is it always hooked up to the OBDII port or is it spliced into the communication lines to the ECU?
4. Are the "solenoid" outputs capable of PWM output for boost control. Is that something that could be implemented by the end user?
5. Has anyone used the ECU+ for a 30R turbo combination? What were the results? Do you have software produced power curves?
6. What are everyones results with injector scaling with larger injectors? Are 780 cc/min injectors possible?
I really think this could be a great system, but I just have some reservations due to the lack of resolution and possible PO300 codes. I just want a system that works and does not seem to be cobbled together.
HiVoltEVO8
I was wondering if there are any ECU+ users that have also used the Vishnu XEDE piggyback system. If there are, how do the two compare? Any regrets..?
Also, I have the following questions:
1. Does the ECU+ allow advancing of the timing without the dreaded PO300 MIL light?
2. Does only having three load variables (Low, Med, High, WOT) limit the capabilities of the unit. Also, what determines the load variable.....for instance what is the scaling? How does it compensate for a larger turbo (higher maf readings)?
3. Now the unit also monitors OBDII Cel codes.....is it always hooked up to the OBDII port or is it spliced into the communication lines to the ECU?
4. Are the "solenoid" outputs capable of PWM output for boost control. Is that something that could be implemented by the end user?
5. Has anyone used the ECU+ for a 30R turbo combination? What were the results? Do you have software produced power curves?
6. What are everyones results with injector scaling with larger injectors? Are 780 cc/min injectors possible?
I really think this could be a great system, but I just have some reservations due to the lack of resolution and possible PO300 codes. I just want a system that works and does not seem to be cobbled together.
HiVoltEVO8
#2
Evolving Member
iTrader: (14)
Originally Posted by HiVoltEVO8
Hey All,
1. Does the ECU+ allow advancing of the timing without the dreaded PO300 MIL light?
2. Does only having three load variables (Low, Med, High, WOT) limit the capabilities of the unit. Also, what determines the load variable.....for instance what is the scaling? How does it compensate for a larger turbo (higher maf readings)?
3. Now the unit also monitors OBDII Cel codes.....is it always hooked up to the OBDII port or is it spliced into the communication lines to the ECU?
4. Are the "solenoid" outputs capable of PWM output for boost control. Is that something that could be implemented by the end user?
6. What are everyones results with injector scaling with larger injectors? Are 780 cc/min injectors possible?
Tom
#3
Evolving Member
Thread Starter
iTrader: (4)
Join Date: Oct 2003
Posts: 108
Likes: 0
Received 0 Likes
on
0 Posts
Tom,
Thanks for all your responses.
You mention that this information was covered in the users manual, but when I downloaded the software to take a look at it, the manual was dated 2004 and I did not seem to cover some of these questions. Do you have a link to a more recent manual. If so, I may be able to avoid some foolish questions.
Also, I realize that you are a one man show and you are pressed for time. I am an electrical engineer myself with extensive knowledge of embedded control systems. I would love the opportunity to assist you in your development efforts. It would give me a chance to combine two of my favorite activities, embedded control systems and cars If you decide to take me up on the offer, please send me a PM
Gordon
Thanks for all your responses.
You mention that this information was covered in the users manual, but when I downloaded the software to take a look at it, the manual was dated 2004 and I did not seem to cover some of these questions. Do you have a link to a more recent manual. If so, I may be able to avoid some foolish questions.
Also, I realize that you are a one man show and you are pressed for time. I am an electrical engineer myself with extensive knowledge of embedded control systems. I would love the opportunity to assist you in your development efforts. It would give me a chance to combine two of my favorite activities, embedded control systems and cars If you decide to take me up on the offer, please send me a PM
Gordon
#4
Evolving Member
iTrader: (14)
Originally Posted by HiVoltEVO8
You mention that this information was covered in the users manual, but when I downloaded the software to take a look at it, the manual was dated 2004 and I did not seem to cover some of these questions. Do you have a link to a more recent manual. If so, I may be able to avoid some foolish questions.
There's two sets of software on the web site. The one dated a week ago is the one you want. Take another look.
Also, I realize that you are a one man show and you are pressed for time. I am an electrical engineer myself with extensive knowledge of embedded control systems. I would love the opportunity to assist you in your development efforts. It would give me a chance to combine two of my favorite activities, embedded control systems and cars If you decide to take me up on the offer, please send me a PM
Yea, I would be interested in some ideas for development. The ECU+ is a completely home-grown system; for example, the software for the main DSP chip is written in assembler, and I wrote the assembler. As such, it's quite a steep curve to even learn about how to program it. That, coupled with the fact that I want to keep the source code to myself, means that I don't want coding help. But if you have some algorithm knowledge - sign me up! Boost control in particular is something I haven't tackled yet, so if you're interested, consider the general problem of closed loop boost control using a MAP sensor, where the input is the MAP sensor and the output is a PWM of whatever frequency and duty cycle will get the job done. Some things to consider are what algorithm to use, what frequency of PWM drives the BCS, and how to avoid spikes for a range of turbo sizes. If you have any thoughts on these, I'm all ears.
Tom
#5
Evolving Member
iTrader: (3)
Originally Posted by HiVoltEVO8
Also, I realize that you are a one man show and you are pressed for time. I am an electrical engineer myself with extensive knowledge of embedded control systems. I would love the opportunity to assist you in your development efforts. It would give me a chance to combine two of my favorite activities, embedded control systems and cars If you decide to take me up on the offer, please send me a PM
#6
Evolving Member
iTrader: (3)
Originally Posted by tlcoll1
But if you have some algorithm knowledge - sign me up! Boost control in particular is something I haven't tackled yet, so if you're interested, consider the general problem of closed loop boost control using a MAP sensor, where the input is the MAP sensor and the output is a PWM of whatever frequency and duty cycle will get the job done. Some things to consider are what algorithm to use, what frequency of PWM drives the BCS, and how to avoid spikes for a range of turbo sizes. If you have any thoughts on these, I'm all ears.
#7
Evolving Member
iTrader: (14)
Matz -
The DSP is a TI fixed-point chip (http://focus.ti.com/docs/prod/folder...20lf2406a.html - same as used in the Segway http://www.segway.com/ ), and yea, it does have a number of captures and PWM outputs. I put 'em to good use, as the ECU+ DSP is 90-something percent idle at maximum workload.
About the solenoids - it's a good question. I'd hope that the different ones wouldn't be much different as far as response times go, but I don't know for sure yet.
Tom
The DSP is a TI fixed-point chip (http://focus.ti.com/docs/prod/folder...20lf2406a.html - same as used in the Segway http://www.segway.com/ ), and yea, it does have a number of captures and PWM outputs. I put 'em to good use, as the ECU+ DSP is 90-something percent idle at maximum workload.
About the solenoids - it's a good question. I'd hope that the different ones wouldn't be much different as far as response times go, but I don't know for sure yet.
Tom
Last edited by tlcoll1; Dec 28, 2005 at 10:34 AM.
Trending Topics
#8
Evolving Member
iTrader: (3)
Originally Posted by tlcoll1
Matz -
The DSP is a TI fixed-point chip (http://focus.ti.com/docs/prod/folder...20lf2406a.html - same as used in the Segway http://www.segway.com/ ), and yea, it does have a number of captures and PWM outputs. I put 'em to good use, as the ECU+ DSP is 90-something percent idle at maximum workload.
About the solenoids - it's a good question. I'd hope that the different ones wouldn't be much different as far as response times go, but I don't know for sure yet.
Tom
The DSP is a TI fixed-point chip (http://focus.ti.com/docs/prod/folder...20lf2406a.html - same as used in the Segway http://www.segway.com/ ), and yea, it does have a number of captures and PWM outputs. I put 'em to good use, as the ECU+ DSP is 90-something percent idle at maximum workload.
About the solenoids - it's a good question. I'd hope that the different ones wouldn't be much different as far as response times go, but I don't know for sure yet.
Tom
I know HiVolt has dibs on helping out, but I could probably test algorithms here.. I have an air hookup on my desk at the office, and access to pressure regulators so it would be easy to just manually change the pressure and see how the control algorithm does with the BCS. Of course, I'll need to find a BCS cheap somewhere, and get other aftermarket ones.
#9
Evolving Member
Thread Starter
iTrader: (4)
Join Date: Oct 2003
Posts: 108
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by tlcoll1
Gordon -
There's two sets of software on the web site. The one dated a week ago is the one you want. Take another look.
Man you gotta be careful with that - that's exactly the kind of thinking that made me build the ECU+ in my spare time. Now my spare time is zero!
Yea, I would be interested in some ideas for development. The ECU+ is a completely home-grown system; for example, the software for the main DSP chip is written in assembler, and I wrote the assembler. As such, it's quite a steep curve to even learn about how to program it. That, coupled with the fact that I want to keep the source code to myself, means that I don't want coding help. But if you have some algorithm knowledge - sign me up! Boost control in particular is something I haven't tackled yet, so if you're interested, consider the general problem of closed loop boost control using a MAP sensor, where the input is the MAP sensor and the output is a PWM of whatever frequency and duty cycle will get the job done. Some things to consider are what algorithm to use, what frequency of PWM drives the BCS, and how to avoid spikes for a range of turbo sizes. If you have any thoughts on these, I'm all ears.
Tom
There's two sets of software on the web site. The one dated a week ago is the one you want. Take another look.
Man you gotta be careful with that - that's exactly the kind of thinking that made me build the ECU+ in my spare time. Now my spare time is zero!
Yea, I would be interested in some ideas for development. The ECU+ is a completely home-grown system; for example, the software for the main DSP chip is written in assembler, and I wrote the assembler. As such, it's quite a steep curve to even learn about how to program it. That, coupled with the fact that I want to keep the source code to myself, means that I don't want coding help. But if you have some algorithm knowledge - sign me up! Boost control in particular is something I haven't tackled yet, so if you're interested, consider the general problem of closed loop boost control using a MAP sensor, where the input is the MAP sensor and the output is a PWM of whatever frequency and duty cycle will get the job done. Some things to consider are what algorithm to use, what frequency of PWM drives the BCS, and how to avoid spikes for a range of turbo sizes. If you have any thoughts on these, I'm all ears.
Tom
I have been thinking about your boost control problem. This all depends on how much horsepower (pun intended) your processor has. However, you have more parameters than just MAP that you can use and "intelligently" control the boost. More importantly, you can monitor other things (knock, AFR, etc.) and cut the boost. You want your algorythm to be code and processor efficient. In order to do this most efficiently and handle the widest selection of turbos, I would implement the following variables:
Pressure setpoint (psia)
Base duty cycles at idle, LOW, MED, HIGH and WOT
TPS setpoint (duty cycle will be 100% below this point) allows fast ramp up
Your algorythm would them implement discrete PID control to vary the duty cycle around the base duty cycle (+/- 10%) to maintain the prescribed pressure set point. The control could then be made to be pretty agressive since it will act like feed forward control.
If you make the parameters visible in the program, the PID output could be viewed like a fuel trim to allow the user to choose a base duty cycle that has the PID output set at 0% (like fuel trims). You may even be able to just get away using P control, which is insanely easy to implement.
I recommend the velocity form of the PID algorythm represented by:
u(t) = u(t-1) + Kc(e(t) - e(t-1)) + ( (Kc*Ts)/ Ti)*e(t) + ((Kc*Td)/Ts)*(e(t)-2*e(t-1)+e(t-2))
where u(t) is current control output
e(t) is current error
Kc is constant gain
Ts is sampling period in seconds
Ti is integral period in seconds
Td is derivative period in seconds
This algorythm is very efficient since it will require very little ram to implement since it only requires the last two error inputs and the last output to implement). I recommend a sampling period of 40-200 milliseconds (only some experimentation will tell). Maybe it would be beneficial to make sampling period variable for larger turbos since boost can come up fast.
Well, this is as much thought as I have put into it thus far. let me know if this makes sense or not. Please free to PM me if you have any questions.
#10
Evolving Member
iTrader: (3)
Originally Posted by HiVoltEVO8
I have been thinking about your boost control problem. This all depends on how much horsepower (pun intended) your processor has. However, you have more parameters than just MAP that you can use and "intelligently" control the boost. More importantly, you can monitor other things (knock, AFR, etc.) and cut the boost. You want your algorythm to be code and processor efficient. In order to do this most efficiently and handle the widest selection of turbos, I would implement the following variables:
Pressure setpoint (psia)
Base duty cycles at idle, LOW, MED, HIGH and WOT
TPS setpoint (duty cycle will be 100% below this point) allows fast ramp up
Your algorythm would them implement discrete PID control to vary the duty cycle around the base duty cycle (+/- 10%) to maintain the prescribed pressure set point. The control could then be made to be pretty agressive since it will act like feed forward control.
If you make the parameters visible in the program, the PID output could be viewed like a fuel trim to allow the user to choose a base duty cycle that has the PID output set at 0% (like fuel trims). You may even be able to just get away using P control, which is insanely easy to implement.
I recommend the velocity form of the PID algorythm represented by:
u(t) = u(t-1) + Kc(e(t) - e(t-1)) + ( (Kc*Ts)/ Ti)*e(t) + ((Kc*Td)/Ts)*(e(t)-2*e(t-1)+e(t-2))
where u(t) is current control output
e(t) is current error
Kc is constant gain
Ts is sampling period in seconds
Ti is integral period in seconds
Td is derivative period in seconds
This algorythm is very efficient since it will require very little ram to implement since it only requires the last two error inputs and the last output to implement). I recommend a sampling period of 40-200 milliseconds (only some experimentation will tell). Maybe it would be beneficial to make sampling period variable for larger turbos since boost can come up fast.
Well, this is as much thought as I have put into it thus far. let me know if this makes sense or not. Please free to PM me if you have any questions.
Pressure setpoint (psia)
Base duty cycles at idle, LOW, MED, HIGH and WOT
TPS setpoint (duty cycle will be 100% below this point) allows fast ramp up
Your algorythm would them implement discrete PID control to vary the duty cycle around the base duty cycle (+/- 10%) to maintain the prescribed pressure set point. The control could then be made to be pretty agressive since it will act like feed forward control.
If you make the parameters visible in the program, the PID output could be viewed like a fuel trim to allow the user to choose a base duty cycle that has the PID output set at 0% (like fuel trims). You may even be able to just get away using P control, which is insanely easy to implement.
I recommend the velocity form of the PID algorythm represented by:
u(t) = u(t-1) + Kc(e(t) - e(t-1)) + ( (Kc*Ts)/ Ti)*e(t) + ((Kc*Td)/Ts)*(e(t)-2*e(t-1)+e(t-2))
where u(t) is current control output
e(t) is current error
Kc is constant gain
Ts is sampling period in seconds
Ti is integral period in seconds
Td is derivative period in seconds
This algorythm is very efficient since it will require very little ram to implement since it only requires the last two error inputs and the last output to implement). I recommend a sampling period of 40-200 milliseconds (only some experimentation will tell). Maybe it would be beneficial to make sampling period variable for larger turbos since boost can come up fast.
Well, this is as much thought as I have put into it thus far. let me know if this makes sense or not. Please free to PM me if you have any questions.
This may be a dumb question, but why would you want to control the BSC by monitoring knock and AFR? The stock ECU already pulls timing when it detects knocking. Also, in general, don't people tune with the ECU+ while remaining conscious of the AFR, thus making that unnecessary? And when the AFR goes up, this raises combustion temps, which causes detonation, which leads back to my first question about the ECU pulling timing anyway.
#11
Evolving Member
Thread Starter
iTrader: (4)
Join Date: Oct 2003
Posts: 108
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Matz
Wow. I hope you don't mind if I ask questions later on about your algorithms. I am embarrassed because I took controls courses in my undergrad and grad work, but have 0 practical experience. However, the basic algorithm that you typed above makes sense. Working on ECU+ related items would be a great way to revisit my previous subjects.
This may be a dumb question, but why would you want to control the BSC by monitoring knock and AFR? The stock ECU already pulls timing when it detects knocking. Also, in general, don't people tune with the ECU+ while remaining conscious of the AFR, thus making that unnecessary? And when the AFR goes up, this raises combustion temps, which causes detonation, which leads back to my first question about the ECU pulling timing anyway.
This may be a dumb question, but why would you want to control the BSC by monitoring knock and AFR? The stock ECU already pulls timing when it detects knocking. Also, in general, don't people tune with the ECU+ while remaining conscious of the AFR, thus making that unnecessary? And when the AFR goes up, this raises combustion temps, which causes detonation, which leads back to my first question about the ECU pulling timing anyway.
I really wish that I could take credit for the suggested PID algorythm. However, it is derived from classical control in continuous domain and applying the z-transform to get it to the discrete domain. I bet if you googled "discrete PID" you would run into it or another form of it. I would be happy to answer any questions that you may have.
I realize that incorporating knock and AFR may seem counter-intuitive when implementing simple boost control. However, I am thinking more towards the future when water/alcohol injection may be implemented. If this is implemented now, all of the code would be relevant later. A failure in the injection system would immediately cut boost, add fuel and retard timing. Sounds like utopia to me.
Of course, I am just offering ideas. I would love to write code, but I certainly understand why Tom wants to keep that all to his-self. Although, I really believe that an open source piggyback controller would be unbelievable. Can you imagine what would be possible if we had 1,000 people working on improving a product rather than one? No offense, Tom...........Just daydreaming of a Linux-like engine management Hey, it may even free up some time for you. LOL!
#12
Evolving Member
Thread Starter
iTrader: (4)
Join Date: Oct 2003
Posts: 108
Likes: 0
Received 0 Likes
on
0 Posts
I realize that this thread has gotten a little off subject, but I would love to find out if anyone has used XEDE and ECU+ and find out their opinions on the differences between them (good and bad).
#14
Evolved Member
iTrader: (66)
Originally Posted by HiVoltEVO8
I realize that this thread has gotten a little off subject, but I would love to find out if anyone has used XEDE and ECU+ and find out their opinions on the differences between them (good and bad).
I am using the XEDE.....but I like to reconsider my options every once in awhile.
I can post what I like and dislike about it and then some ECU+ folks and counter if you'd like. I think most piggybacks are going to be fairly comparable.
I am coming from the 2G Eclipse scene. On my DSM I was using www.DSMLINK.com which in my mind was the ultimate in control. With the DSMLink you actually programmed the ECU and not a piggyback controller. By controlling the ECU you could change you injector size, inj deadtime, read dutycycles, read knock, control redline settings, LC and NLTS, ect.
When moving to the EVO I found that my options were limited for a solution like DSMLink. I picked up a used XEDE for fairly cheap. I've been using the XEDE for about a year now. My biggest complaint is that the provided "tune files" are provided for a specific upgrade path. This means if you make a few mods outside of the Vishnu upgrade path you are on your own for tune. EXAMPLE: They do not provide a "tune file = map" for cams without cam gears. If you stick some 272's in your car and you dont have thier cam gears they you will need find a way to tune the car yourself. This isn't that unusual but we all know that these companies do many dyno tunes on many different EVO's and I'm sure they could provide us with a rather large database of maps for various stages of modification.
Safely tuning without a wideband and pocketlogger is tricky because you cannot directly read overall engine timing or knock. When you lean out your AFR the XEDE has no idea what your actual engine timing is. It has no way to tell if you are knocking. It is unaware if you are getting 20 psi or 24psi of boost. Sure it controls the BCS but every EVO's boost will be different especially as the seasons change. I have to keep my BCS at a max of 85% in the winter otherwise I'm way over 22psi.
There are a few things that I like about the XEDE. First its very easy to make changes to the tune. I am pretty much done modding the car but I do drive it year round and in many different load conditions. Therefore, I have a road race map, drag race pump gas map, drag race 104 octane map, and I've even made a road trip economy map.
I also like that they have stutterbox launch control and no lift to shift but it doesn't function like I feel it should. Basically it uses only the upper clutch saftey switch and I feel it should use a speed sensor input as well.
If I find a replacement that can read ignition timing and knock and provide LC/NLTS, I would more than likely ditch the XEDE for it.
Personally I feel the only real solution would be having access to the ECU and OBD-II info and directly making changes to the ECU.
#15
Evolving Member
iTrader: (14)
Originally Posted by Jeff_Jeske
I also like that they have stutterbox launch control and no lift to shift but it doesn't function like I feel it should. Basically it uses only the upper clutch saftey switch and I feel it should use a speed sensor input as well.
If I find a replacement that can read ignition timing and knock and provide LC/NLTS, I would more than likely ditch the XEDE for it.
Tom