HiVoltEVO8

iTrader: (4)

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

tlcoll1

iTrader: (14)

I can answer some of these. I know a little bit about it...

The ECU+ does generate a P0300 on some EVOs (usually the 2003's), but it's unrelated to advancing the timing. I'm working on this issue right now.

Low, medium and high load is based on MAS readings, and is configurable. WOT is based on throttle position (as you'd expect). Most people tune largely at WOT, but you can tune the other settings using the OBD-II fuel trim displays.

The latter. But that means that it's always connected to the stock ECU, and you can't plug another device into the OBD-II port unless you remove a jumper. This is all outlined in the user's manual for the ECU+.

Yes, and no, respectively. Closed-loop boost control is one of my next projects.

You'll generally find that the larger the injector, the better off you'll have by getting a reflash for that injector combination. Dynoflash Al has a $75 offer on the table for ECU+ customers that does the compensation and removes the rev limit. The same will be true for the XEDE or similar system. Vishnu, I think, sells a separate reflash specifically to work with the XEDE.

Tom

HiVoltEVO8

iTrader: (4)

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

tlcoll1

iTrader: (14)

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

Matz

iTrader: (3)

Hooo boy, you sound just like me. Except that I'm an ME with more software / Windows programming experience than ME experience. Unfortunately, I don't think Tom is willing to give up source for the windows app, either, so I don't think I can help in that area.

Matz

iTrader: (3)

What kind of DSP do you use? If that's proprietary info, please ignore my request. I have no DSP experience, but am interested... Do DSPs have input captures / output compares like many standard microcontrollers? Probably would be good to have different profiles for BCSs, since some people use stock, others use Forge, and the various solenoids probably have different "response times", which ultimately affects the duty cycle and frequency, right?

tlcoll1

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

Matz

iTrader: (3)

Cool! If you have PWM outputs, then you don't even need to use input captures and output compares. I assume you just stick a value in the PWM register and it does everything for you, like on a lot of micros these days.

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.

HiVoltEVO8

iTrader: (4)

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.

Matz

iTrader: (3)

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.

HiVoltEVO8

iTrader: (4)

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!

HiVoltEVO8

iTrader: (4)

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).

tlcoll1

iTrader: (14)

Gordon,

Thanks for the info! I have some questions, so I'll follow up in a bit with a PM so we don't clog up the forums with technical mumbo-jumbo.

Thanks again,
Tom

Jeff_Jeske

iTrader: (66)

What are you using now?

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.

tlcoll1

iTrader: (14)

Jeff - I'm working on LC/NLTS now (see https://www.evolutionm.net/forums/sh...d.php?t=177179) so if you could explain the deficiencies of the XEDE in this area, perhaps I could implement a better algorithm. Using the clutch switch and (probably) speed sensor is a given for NLTS - there's no obvious way to tell when to activate the shift rev limit unless you use the clutch switch. My current LC implementation uses only the speed sensor, and it's not clear whether or not adding the clutch switch to the LC mix might be good.

FYI, the current "silver box" ECU+ reads both timing and knock - always has. It also includes an OBD-II implementation to display fuel trims.

Tom