Will the UTEC ever have the ability to run an adjustable ECU offset timing advance like the Xede? It would seem to me that having the choice of absolute or offset would be ideal. I like the idea of having the choice of open loop fueling also(UTEC beta), which allows you to bypass fuel cut without a ECU reflash (XedeFlash).

Currently the UTEC's integration with the Tuner Pro (wideband O2), and logging seem to be the features that set it apart at the moment. I know the Xede will have this integrated down the road, and I'm wondering if the UTEC will ever be able to log at 100Hz (like the Xede) when it currently only logs at 5Hz?

Other feature I like on the UTEC is that because it is serial telnet based I can used my macintosh to access it, and write application software to display things as I wish. I know the future versions of the Xede will provide displays and tuning tools, but unless chiptorque makes XMap opensource I probably would not be able to write an application myself (I enjoy tinkering with such things, and trying to avoid any Micro$oft OS). Also I love the DTEC Gameboy gauge displays!

 

You like the DTEC, huh? Blingster.

 

What can I say, I like toys, afterall the Evo is a toy and seeing how I like computers and have played my share of Nintendo in years past it seems more my style to have LCD gauges made out of GameBoys. Anyway it seems logical to have a built in gauge/monitoring/tuning interface like DTEC as an option. I wouldn't say I'm a blingbling person, just a little of a computer geek.

 

Very interesting reading thanks this has been a great thread to which I was actually able to learn something and not just watch a fight occur.
Big props to Everyone involved!

 

I know...I was just diggin' ya in the ribs a bit.
-chris

 

Yep, this is turning out to be a great knowledge exchange and this is the way these sorts of things SHOULD be talked about..

Every product has its merits and its fans, you'll never convince the diehard fans to change what they use, but it allows the people who are on the fence to choose which product best suits their needs..

Honestly, I couldn't afford to "Test" an XEDE.. But there were reasons I did choose the UTEC which were right for me, and may not be right for others. The Absolute control of timing, and the ability to control how knock is handled is something I consider advantageous. (additionally in the new firmware the Open Loop fueling)

Shiv, You aint kidding about the indirect affect on timing altering the MAF signal has, partly the reason I found the direct control of timing a desirable feature.

So, here's my list of things that I was looking for at the time I chose the UTEC (Admittedly I was already aware of the upcoming beta features when I bought the UTEC and my list reflects that)..

1) Retains OBD-II and (the UTEC) can be bypassed if needed
2) Multiple Maps
3) Non-Specific user interface, you can connect to it with ANY computer capable of serial communications.
4) Absolute Timing Control
5) Direct Fuel control
6) closed loop (Feedback) boost control
7) Injector Scaling
8) Eliminate fuel cut without a reflash
9) Set your own rev limit without a reflash
10) Configurable enrichment/timing features (temp based, knock based, etc..)
11) Car will run as stock without any base tuning
12) All factory ECU controlled features still work
13) Comprehensive data logging
14) Integration with a wideband O2 sensor (Tuner) (I'd like to see the EGT on there too)
15) I had sent e-mail early on the TurboXS (prior to the Evo UTEC even being made public) They gave me a list of features (that it had, and what was planned) and a comprehensive e-mail about its capabilities. After my purchase, they helped me with my development efforts for software, and quickly responded to any question I had.

Thats all I can think of for the moment (this was my legitimate list) and I was willing to wait for some of these features to be released..

To my knowledge the UTEC was the only product capable of doing all of these things..

I have to admit, I was looking into the XEDE early on, and I was a little put off by it at the time because it was not yet plug and play, it did not control boost, and I was not answered when I asked questions about features and other product queries. (Their understandably busy but it was a factor).. Don't get me wrong, I like the XEDE, but after comparing the features of the products I was considering

1) AEM EMS
2) Autronic
3) UTEC
4) XEDE

As you can see, only the UTEC met all of my criteria..

Lets keep this going, this is very very useful data for you guys..

 

I suppose it would be possible for them to add that feature.. I don't find it to be necessary though. (see my previous post)

I also would like to see a "Compressed data stream" so they can increase the data rate significantly.. Thats the one disadvantage of formatted "Serial output" thats human readable.. I'd also like to see a higher data rate used for the serial communications. Those really are trivial things for me though.

 

Hi Jack,
First, this is a great thread and I'd like to thank you for taking the time to participate. Now back to the the meat and potatoes...

Could you explain to me why you find having absolute control over timing more desireable and/or useful than controlling timing by putting offsets over a known timing table? I can't speak for everyone, but most people that I talk to are more comfortable with the thought of adding or subtracting timing over a stock value that establishing that they need "X degrees" of absolute timing at every RPM/Load point. Especially when the offset approach doesn't sacrifice any drivability or safety margin/adaptability.

Regards,
shiv

 

For me, it was the thought of "chasing a tune", that is, adding or subtracting timing from something that is not static is something that would have added to inconsistency in tuning, depending on where in the timing map you may end up in, the offsets you use may not be appropriate for your desired end result. I guess its really only an issue if your one of the poor souls who have very active knock sensor activity.

I do understand where your coming from when you say many people prefer to offset the timing. I already had made the effort to map a majority of the timing over 2 months before I attempted to create a timing map. Given the time, someone with a standalone could put the time and effort into making their car drive just as well as stock too...

Frankly, I agree, its easier to add or remove a degree of timing to make tuning easier, if you don't already know what the actual timing is. On the other side, your stacking a timing change on top of a potentially unknown value, so you could in turn make a bad situation worse (of course a bad timing choice in an absolute map can do the same damage, so its just a fundamental point..)

I do tune on the side of being fairly conservative, so I don't really push the threshold of creating ignition induced detonation. And I frequently leave portions of the MAP set to ECU since my car seems to have pretty aggressive timing on its own.

Like I said earlier, I do recognize the factory ECU's ability to do what it does well, but when I do choose to control it, I would prefer the absolute control over relative control.

 

I'll second the "compressed data stream" option. A faster sample rate would really make any application that logs data and produces power graphs much more accurate.

Although sending binary data would be easier and quicker ( from the Utec programmer's point of view - doesn't have to convert data into pretty format ASCII text ), I do wonder how much of an increase in sample rate would be got.

The Utec's current sample rate maybe actually limited by how much "spare time" the Utec processor has to service secondary tasks like this after it is done with it's "main function" of calculating fuel, iginition, boost maps etc, or by the sample and hold time of it's internal A to D convertors.

 

It seems like the sample rate of the utec is a factor of baud rate.. Its possible there are other underlying reasons, but at the guts of the unit is a pretty powerful embedded microprocessor.

 

I have no doubt that the WRX has such a pain in the *** system to try to get around when you modify the car. The pains they go through to get power out of them is proof enough of this.

But how do you know that the Evo does? Have you disassembled the code?

There was lots of speculation on what the DSM ECU did for knock, but until someone took the time to disassemble the code, and comment it, we really didn't understand what was going on.

There is only so much information you can get from observing from the outside.

 

At the moment I don't think the baud rate is the real limiting factor with regard to the UTEC's sample rate. At 19200 baud you can theoretically transmit 1920 bytes/sec. Derate this by 10% to allow for real world and you still have 1728 bytes /sec to play with.

When logging with the tuner attached in Shift-1 mode the utec sends 76 characters per line. Throw in 2 characters for line feed and carriage return and you have 78. Round that up to 80 and you can send ( 1728/80 ) 21.6 lines or "samples" per second.

The UTEC sends 5 samples or lines a second, so I think that even at 19200 baud it could send a lot more.

Also I think I read somewhere on the WRX forums that you can hold some key down and the "sample rate" increases - that is the UTEC sends more lines per second, but most of the data sent ( namely the analog data ) is just repeated at the regular rate of 5 samples a second.

 

Yeah.. I suppose that would make sense.. I think the sample rate was set static just as the baud rate was.. I'll have to ask someone at TurboXS for the skinny.. oh and I think the 2 possible baud rates were 9600 and 19.2k so I think it was designed to accomodate the slower of the two.. which makes sense..

 

At a baud rate of 19200 bits per second, given the length of a shift-1 record, the theoretical maximum logging rate is about 25 records per second. That's 5 times faster than it runs now. Correct? So it seems like it must be limited by available processor power. I sure wish they would increase it though, to at least double what it is now.

And the problem I have with absolute timing is that I was never able to get it to be perfectly smooth in all cases when transitioning from ECU timing to programmed timing. Yes, you can get it smooth most of the time, but that's not good enough for me. I don't EVER want to feel that "bump". I don't see how it's possible to make it smooth during all possible part-throttle transitions.

I second what that other guy said, the two features I would like to see most in the UTEC are an option for offset-based timing and a higher data logging rate. That would really make the UTEC the most versatile solution out there.