I thought you guys might like to see how things are shaping up with the next version of TunerPro (RT in this case). I'm only 2 weeks in and still have a couple months to go, so who knows if the finished product will look like this, but at least you can see the vast improvement (hopefully)!

I'm focusing on making the whole process of tuning easier, faster, and more fun.

Enjoy!

M

 

Oh, and *no comments* on the BLM, please.

Tuning software developer = not much time to tune!

 

ALDL Dash I like it. will it be configurable so The user can choose which options show on the Aldl Dash

 

No way man. What purpose would that serve?

(of course... right clicking on a gauge allows you to select what to show in that position). And yes, there will be "bar" gauges to show temperature, TPS, etc.

And you may have noticed a toolbar? Each band is completely configurable. Hideable, re-sizeable, moveable.

 

Cool. Now how about away to make the ALDL Dash Undock and become a Full screen Seperate window. I know I am Very demanding the woman tells me this constantly lol

 

Yup. already done. Dash can be full screen.

 

Give me a minute I will think of something stupid that has no purpose in the program. lol hell or maybe it will be usefull

 

Looks real good!

/N.:hail: :hail:

 

Compared to the old days of when we had to carry proms to the car, barefoot, in the snow, it's already easier, faster, and more fun.

I'd given up on trying to get a *tunable* Dash. I've been wanting that for years. Now, I have to hold my breath, for it just to get here,

 

Help me tune and I can help you develop software. =) I do CSharp .NET everyday. Before that it was 6 years of C++.

 

Looks awesome so far. I am just getting into the last version you put out. Thanks again -John

 

I'm *extremely* excited about this upcoming release. It's a miracle for tuners. At the risk of sounding like a greedy pig, if you're interested in a "wish list", real pie-in-the-sky stuff, I might have a couple of items I've longed for for a while ...

Because I'm always fiddling with timing or fuel pressure or some-darn-thing-or-other, I'm constantly readjusting my BLMs (in a '747). I've longed for an "automatic" system that could adjust them on the fly for me, modifying the values of the table in realtime, with some indication of what cells have been changed - perhaps a display of the BLM table where all the cells start off, say, red (for un-calibrated) and turn green one at a time as they're updated as I drive around. When done with the "calibration cruise", I could tell the system "save calibration" and it would permanently change the .bin. It might look like this:



Something similar could be done with the timing curve, the software correlating detonation events to the timing curve cells, pulling out timing a degree at a time. More problematic than the BLM values, false knock and whatnot. Is there any reliable method of analyzing the pattern of detonation events to determine if it's really happening, or spurious signals? Hmm, interesting.

Also with regards to timing: is it possible to correlate timing in a given cell to torque in some way? I'm thinking of a scenario like this (assuming an empty road and plenty of time, and Really Gigantic MAP display): I put the software into "timing calibration" mode. I run the car up to, say, 20 mph in 5th, hit the "1st run" button, do a 40 MAP pull to 3600 RPM, hit the "run finished" button. The software has noted time spent in each cell in the timing table. It now advances the timing, say, 2 degrees in the 40 MAP cells. Again, I run it up to 20, hit the "2nd run" button, do the pull. When detonation occurs in any cell, *OR when the time in each cell increases*, the timing is rolled back 2 degrees and "locked". The process continues for the 40 MAP cells until they have all been locked. Then, I move up to the 45 MAP cells, do it all again. What we're looking for is the strongest pull (least time) in each cell at a given MAP value. I realize there are LOTS of variables at work here, but getting an "upper envelope" on the spark curve, and having a wide range of data to look at, would be useful.

Another idea: in the "ALDL Dash" windows, if you could set "alarms" on monitored values: for instance, you could have the computer beep if vehicle speed exceeded 65 mph, if detonation occurs, if the recalibrated BLM (from above) approached 100 percent, or if coolant temperature exceeded 230 degrees. You could have "min" and "max" fields in the dash cells.



Something like that. I realize such alarms wouldn't always be appropriate for non-analog data (such as "BLM cell in use" and such).

Also in the "ALDL Dash" (or perhaps some other, dedicated) window, realtime graphs of the values could be useful. You'd have to make the windows a bit bigger, of course, and have a routine to scroll them like a EKG, but even small graphs would be very helpful at times. Perhaps with the alarm values as horizontal lines? Again, not always appropriate, but maybe useful.

I realize that the ideas above represents *hundreds* of hours of your time, in addition to the thousands you've already burned, and the nature of the .ECU files make some of these suggestions problematical, but I thought if maybe you're looking for ideas...

 

ARE YOU SAYING I NEED HELP? HUH?!!

Just kidding. I appreciate the offer, but also appreciate developing this project solitarily. Its a labor of love. =)

I too have lots of C# and C++ experience (TunerPro uses the latter - quite a few users are using old, slow, Win98 machines and I don't like the idea of having to rely on the framework for these users).

 

The idea for me is to keep the dash simple. You can select what you want to show, but there isn't going to be any fancy "wow, this looks just like the dash in my car" crap. Functionality over form in this instance.

 

Scott T -

Thanks for the great write up and mockup pics. Here's a brief (and by no means complete) list of major things that I'm aiming for in the 4.0 series (maybe not the initial release):

1) Realtime ALDL and tune correlation - you can visually see where the car is running in the spark table, for instance. When you open the constant editor to alter where your fans turn on and off, you'll see the car's current temp. That kind of thing

2) Auto-tuning - Craig and I have a lot of ideas in this direction. Its going to take a few revs to get the technology (both hardware and software) there, but its very do-able, and very important to us.

3) Lots of enhancements to table editing, including multi-select, color coding, etc.

4) A new bin definition format (this is where most of my development time will be spent in the next 2 or 3 months) that will allow ALDL integration, auto-tuning, etc. A lot of work needs to be done here, as this is the foundation for the future technologies.

5) quite a few ALDL enhancements that make it easier to use (while tuning especially), as well as analyze the data (max, min, currents, averages, etc, etc).

Keeping in mind that this is just a hobby and is nothing but fun (and I plan to keep it that way - as soon as its not, I'll get out of it), there's going to be some very cool things to come. Your support is appreciated! Thanks guys!

 

Doc and I been preaching that for the last few decades.

For Hardware, Software, and Firmware.

 

Excellent. I'll work hard to practice what you preach. Both of you.

 

Great work, Thanks for the sneak peek !
:yourock:

Anxiously awaiting the unveiling.

 

WOW!

If it ends up looking like your posting and working as intended u can count me in! Great looking stuff there Mangus...

later
Jeremy

 

6) Prominator support???

My only other request is for SpeedReader/Lockers support when it comes out. RBob can furnish you with the format of the output; we're going to try to get it setup to where it will go through the serial as well as the parallel port.

 

:hail: :hail: Sweet, I look forward to the release!!

 

Yes, Prominator support. You and Bill and I need to engage in some discussion therein.

Regarding the new device, man, you guys are software developer masochists, huh. Serial and parallel port? Why not just drop the parallel port? Its even more outdated than serial (considering serial can easily be converted to USB with a $3 chip) and about 10 times more of a pain to program for. ;-)

 

Mark, all I can say is WOW!

Simply incredible. You are accomplishing leaps and bounds with TunerPro....it's becoming exactly what I always hoped it could be.

I'm quite pleasantly surprised to see that you're considering auto-tuning. I've figured for a while that the most experienced PROMmers could put together a "flowchart" or method to how they tune, and to simply put those methods into programming. It may be slightly inexact without the human touch, but it will definitely promise a good start for those in the dark and needing significant tuning changes.

I am simply at a loss of words. Great job.

 

A new bin definition format

Could you elaborate on this some.

and please take the time for your self to enjoy lifes finer things, we don't want TunerPro's Code monkey to reach Burnout.

thank you for your innavations

 

BTW, Mark, RBob said in another thread he'd be willing to work with you/Craig on the auto-tuning feature. He already has that running in DOS.

I'm still doing research for a USB interface for the Prominator/SpeedReader stuff. Hopefully I can come up with something by the end of the year. This stuff is kinda ugly.

 

I enjoy many (most?) of the finer things in life. This represents only a portion of my spare time (if you can believe that). Thanks for the concern, though. I really do intend on making every effort to avoid burnout, but various goings-on accelerate the burnout process (does 58.ecu ring a bell?).

Regarding the new bin definition format:

The ECU file format is functional, but very limited and weak. The new features I'm talking about (ALDL - bin data correlation and auto-tuning) require that the ALDL data definition and the bin definition talk to each other (figuratively speaking). So when the ALDL data says, "hey, right now the car is running at 2300 RPM at a load variable of 87", the bin definition can look at the fact that the spark table is being displayed, which is a function of RPM and load, listen to what the ALDL info says, and output to the user, "Well, the ALDL info is telling me the engine in running in *these* cells currently".

In order to do that, the bin definition needs to know exactly what the breakdown of the cells is in no uncertain terms. It also needs be able to calculate and display the hysteresis (the difference between cells and how the difference is used by the ECM) in a logical way.

Auto-tuning is similar, yet more complex. The bin definition needs to know how to take the ALDL data, say BLMs, and convert that to a correction factor for a particular cell or groups of cells in the MAF table. How much change should be made for a given BLM? In what cell? Heck, first it needs to know what table! So tables/constants in the bin definition need to be tied to constants in the ALDL output.

That sort of thing. Its really a huge, huge can filled with many, many worms. Luckily I eat worms.

 

Worms always seem to go down better with Habanero pepper sauce..... Ditto on the USB port stuff and Double Dittos on the great work you are doing on TunerPro (No I don't like Rush Limbaugh, he's way too liberal for me ).

I hope to install the Tuner Pro on my laptop and look at my car on my next day off. (Friday the 9th). Do I need to have the computer hooked up to the ALDL during the install of the program?

 

Few sentences could convey more confidence....good to hear!

 

Captain....the only thing you need to be hooked to the ALDL for is datalogging. I've done a fair amount of playing around in TunerPRO already, and I don't even have a fuel injected vehicle to log/tune (yet.)


I've been sticking together an initial tune for the TPI motor I'm building for my truck. I'm going to put all that torque to VERY good use, in a 40-year old 4x4.


Mark, the work you're doing is awesome. TunerPRO is already a very well-constructed tool, and the upgrades you're talking about will make it even more useful. Bravo!!!

Now to come up with the money for a PROMinator........

 

hmmmm All this cheap wideband renaissance :-0

Now autotuning too? hmmmmm What are the probabilties that the auto tuning and wideband could be used together?

Or at least to dial in the overall curve? and then run thru to correct to 128? Just an idear I had lol . Love the new stuff thats coming and wondering how far this stuff is going to go

thanks
Jeremy

 

I'd say you can count on auto-tuning making good use of a WB input, be it through ALDL or via a separate input (AutoProm A/D, etc).

 

I definitley need to do some data logging as I have an idle problem that I can't seem to find the answer for. I may have to switch back to my 165 computer (from the 870) but I need to double check my wiring first. It's probably a bin file problem with the A/C switch but I really don't want to trash the A/C (again!!!!).

Once I confirm, the wiring harness is ok I can stick the 165 back in with my aftermarket chip and see if it shows the A/C is on when in reality it's off. After that's done, I'll be able to tackle the datalogging for the idle problem..... Then PROMinator.

 

:yourock:

AWESOME. I CAN'T WAIT. I'M going to crap my pants....oh wait no i'm not. But I still can't wait!

 

YES!

 

Any plans for a UNIX version for those of us who will NEVER run anything microsoft?

 

Sure man. I'll turn that right out for you, provided you're willing to pay by the hour. You would be, afterall, the only user who'd use it. ;-)

And maybe one for all 1 of the tuners out there who tune their cars with a Mac?

 

my primary box at home is running Gentoo kernel 2.6.7 using fluxbox as a window manager... guess who's running a windows based computer JUST for tunning the car..

would be nice if you atleast released the source code.. the linux community would port it

 

Another Linux user here.

I was thinking of writing my own scantool and prom editing software since I can't seem to get them to run under WINE.

 

No source code, no Linux support, no mac support. The work load far out weighs the demand.

Sorry guys. I can't please everyone.

 

how 'bout the capability to monitor 3 graphs instead of 2? I ask to support the development of VE tables. This would allow monitoring BLM, MAP, and RPM.

 

Thats the plan... Up to 10 monitor graphs.

 

Drooling!!