Mangus

Hey fellas -

I've just uploaded version 4.12 of TunerPro and TunerPro RT. There are a ton of new features this time around. Here's the shorter list:
<blockquote><p class="content"><strong>TunerPro Free</strong></p></blockquote><ul><li><span class="content">Brand new 2D graphing control with the following features:</span><ul><li class="content"> No more aspect ratio distortion or strange resize zoom</li>
<li class="content"> Auto-Range (in preferences)</li>
<li class="content"> Ford-type function graphing (drag X and Y axes)</li>
<li class="content"> Multi-selection (Ctrl + Click or mouse drag)</li>
<li class="content"> True axis valuation (negative numbers show to-left or below Y and X axes respectively)</li>
<li class="content"> Z Axis auto-labeling based on window size</li></ul></li><li><span class="content"> Brand new 3D graphing control with the following features:
</span><ul><li class="content">Surface shading (wireframe mode still available in preferences)</li>
<li class="content"> No more aspect ratio distortion or strange resize zoom</li>
<li class="content"> Auto-Range (in preferences)</li>
<li class="content"> Multi-selection (Ctrl + Click or mouse drag)</li>
<li class="content"> Axis labels (All axes)</li>
<li class="content"> Linear zoom based on window size</li>
<li class="content"> Z Axis auto-label based on window size</li>
<li class="content"> Axis label auto-hide based on axis length for readability</li></ul></li><li class="content"> 3D Table smoothing (in Table Editor Toolbox) - specify a modifier of 0.0 - 0.99, select a region at least 3 x 3, and hit Execute!</li>
<li class="content">Visibility Levels and Categories for items (set for each item). Items shown based on globally selected visibility range and category combinations</li>
</ul><blockquote><p class="content"><strong>TunerPro RT</strong></p></blockquote><ul><li class="content">ALDL Data Tracing<ul><li>Link an XDF to an ADS</li>
<li> Link XDF Items to ADS Items</li><li> Playback Log or actively monitor ALDL stream and see visual feedback on where the engine is running in a constant or table.</li></ul></li><li class="content"> Fixed issue with ALDL cable test</li>
<li class="content"> Smart hardware detection - checks the last port known to have hardware detected first</li>
<li><span class="content"> Fixes simultaneous 160 baud datalogging and emulation for AutoProm users (requires AutoProm firmware v2.13.A)</span><br></li></ul>
Some screenshots (click to enlarge):
<center>
<p><a href="http://tunerpro.markmansur.com/images/TPWorkspace.gif" target="_new"><img src="http://tunerpro.markmansur.com/images/TPWorkspaceTH.gif" width="225" height="229" border="0"></a></p><p>Typical TunerPro WorkSpace</p><p><a href="http://tunerpro.markmansur.com/images/2DGraph.gif" target="_new"><img src="http://tunerpro.markmansur.com/images/2DGraphTH.gif" width="225" height="208" border="0"></a></p><p>2D Graphing</p><p><a href="http://tunerpro.markmansur.com/images/3DGraph.gif" target="_new"><img src="http://tunerpro.markmansur.com/images/3DGraphTH.gif" width="225" height="208" border="0"></a></p><p>3D Graphing</p>
</center>
Enjoy, and as usual, please let me know if you have any issues with the software. I'm sure you will this time around, as there's lots of new stuff (which means new and interesting bugs)!

You can download these versions at:
http://tunerpro.markmansur.com/

As always, TunerPro Free is completely free and is nag free and feature complete. TunerPro RT is still free, but you must endure a nag screen at startup for a few seconds (simple motivation to register). Registration for TunerPro RT is $30 USD and is completely optional. The unregistered version is feature complete and will not expire. =)

Mark

89 Iroc Z

Great work! An awesome program keeps getting better.

thirdgen88

TunerPro RT ROCKS!! Love it with my Ostrich!!

91L98Z28

Ironic - I downloaded 4.12 less than an hour after you posted it and used tunerpro for the first time to fix a few things in a $6e (AUJM to be exact) for running on a $32b application (88 IROC). Probably the first person "in the wild" to burn a chip off of 4.12.

Anyhow - I did notice one tiny nag. The checkboxes for flags don't display - they are always cleared (no matter what the actual value in the BIN). The checkbox works and saves however - if you check the box and click save, then look at the BIN, the setting is correct. But if you then click on the same flag setting, the dialog that pops up shows it cleared.

The compare checkbox on the same dialog (if you are comparing to another BIN) works fine, however.

awesome program! I really like the compare BIN feature where you can actually see what's different between two BINs, broken down to the actual name of the variable/setting.

Mangus

Shoot, I'll fix that. Wouldn't you know it? It's always the last-minute change that breaks stuff.

Shame on me.

New build in a few.

Edit...
Fixed (build 1709). Re-commence downloading...

JP86SS

iTrader: (1)

Super sweet
Really like the grouping and visual levels you added.
Should make many things easier to figure out if they are simple tweaks or advanced touching only.
Great job

JPrevost

Looking a lot better.
No smooth on 2D tables . Why tease us with that option being avail in the toolbox? Remove from toolbox and I won't whine about it.
BTW, even though it's neat, I think the catagory and levels could have been left out. Your best feature is the item finder. I use that exclusively and haven't bothered to organize my ecu/xdf's because of it!!!
I especially like your multipoint select and drag feature. When out in a car I'm usually using my touchpad... it was REALLY annoying making changes because I had to do it to each cell.
The ONLY and I do mean the ONLY thing that still bothers me like a bad itch is how the view of the 3D graphs gets reset every time. So if I open, am working on an area, close, then reopen I have to drag around until I get into the same position as last.

ben73

WOW! Its looking better than ever!! Downloading now!
Mark you are a champ!

Craig Moates

I just wanted to take this opportunity to tell you something about Mark:

He is a totally awesome guy! Brilliant programmer, very sharp. Witty to boot. You couldn't ask for a better fellow.

And he has a great sense of humor.

Better yet, he's on our side. I'd hate to be his enemy .

Thank you Mark, your software developments have truly taken the DIY experience to the next level.

DENN_SHAH

iTrader: (1)

TunerPro just keeps getting better & better
great work mark

liquidh8

Mark, Craig, thank you guys for fixing the 160 baud datalogging/emulating. D/Ling the firmware for the autoprom now, already have the new TPRT, can't wait to try it out.
Now I just nead to figure out how to use all the features in TunerPro, lol

BadDog

I've been watching for an announcement or email of some sort on the firmware to match and this post is the first I've seen. Guess I missed it somewhere. Just found it on Moat's site and downloading now…

Thanks for the quick fix guys! I'm very much looking forward to getting started with this on the weekend…

DM91RS

Thanks Mark.............looks better than ever.



Just wondering............when do you find time to work on your car?

DM

Mangus

I generally do it on a schedule. My wife let's me work in the garage 2 nights a week and 1 weekend day.

We all know that women rule the world.

liquidh8

Well, I downloaded the new tunerpro rt and the firmware for the autoprom. Got it all updated, and had to play with it for 30 minutes or so. NOTE:: For those who run a 7747 ecm ($42 mask), with the G2 switching adapter, tuner pro rt and the autoprom. To get it to emulate I had to disconnect the ribbon cable from the autoprom, upload the bin then verify, then plug the ribbon cable back in and emulate. That's how I got it to work, emulate and datalog.

Before I upgraded today, I used to be able to upload the bin, verify, then emulate, with everything hooked up. I guess with the change in software and firmware something got changed.

BUt I am very happy, can finally unhook the snap-on mt2500 and just us my laptop for tuning/datalogging.

Mark and Craig, thanx!!

Mangus

Contact Craig. You might need to swap a little yellow chip in your AutoProm for a "102" version.

DM91RS

LOL...........at least that's what we have to let them think!!

Mangus

Trust me, if there's one thing I've discovered, it's that women let you think you're letting them think that they rule the world, when really, they actually rule the world. Remember that. Always. Pass it on to your kids.

Dave_Jones

3D graph seems to have the numerical scales, but no axis labels.

Not a big deal, since most times it's very obvious what's what -- but labels might be helpful for newbies, or for preventing stupid mistakes.

Overall, looks great. Outstanding work, Mark!

Ooops, gotta run...wife is calling. ;-)

Craig Moates

Yes, this is a possibility. Get with me offline as needed so I can get you up and going.

There's another possibility as well, and I can check with you on that as well (power source for the 74HCT573 chip used for the data output buffer could be either the target device power or the main Vcc on the APU1. Preferably the latter).

A quick check for the 573 chip power source issue is to try upload/verify cycles with both the vehicle key on and off. See if you have success one way or the other.

For those wondering, there is a '102' chip that was applied to the newer AutoProms. This is a 1.0k resistor network that helps to pre-load the data to the emulator's RAM. It is 'faster' than the older '332' 3.3k resistor network. The newer versions of the firmware have been updated to accelerate the write AND read cycles to the emulator, thus allowing 'bumpless' uploads and reads to keep from disturbing the target device (your ECM). However, the faster routines require the presence of the 102 chip.

You can tell if you have the 102 chip by opening your APU1 case. There is a yellow 16-pin DIP chip that is marked with a 332 or a 102. If it's 102, you're fine with the new firmware. If it's a 332, then you will either need to update to the 102 chip to use the new firmware, OR, you will need to pester me to put together a 'one-off' firmware that will give you all the new features recently added such that it will still work with the 332 chip. However, in that case, your uploads and reads won't be as 'bumpless'. They'll still be pretty good, but I'm striving for improvement so I've left it behind.

Sorry, didn't mean to hijack. Figured it might be helpful though, especially since some folks have been waiting far too long for the integrated 160 baud stuff (shame on Craig!).

junkcltr

iTrader: (1)

I will check it out on the win98se setup this weekend. Thank you for all of the hard work you put into this.

What is "bumpless"? Is that the same as ECM reseting/bus corruption?

Craig Moates

Data presentation corruption. We talked about this some time ago. It is the artifact of 'impure' emulation where the target-bound data is 'misrepresented' just as a read or write request from the micro is processed. By proper selection of the muxing components, circuit layout, logic gating sequence, and strategy of the firmware implementation, read and write cycles can be carried out in under 150nS for real. Plus the target-bound data is latched during the operation and slips out of latched state just as the post-read/write cycle target-device-requested data becomes available. This is thanks in part to the propagation delays in the logic and PCB components as well as the control lines and what-not. A big part of that is the series resistances that are used to protect from contention of the datalines between the NVRAM and the micro. Those same series resistors are used to 'queue up' the data prior to the read/write cycle without applying the data to the actual target device. At no time during that process is the data presented to the target anything but the last or next byte requested from the target. I spent quite a bit of time on the scope and doing calculations and testing different scenarios to find something that would work as needed without being excessively complex.

As you may recall, this was something that was seen as darn near impossible without heavy monitoring of the target CE/OE lines. However, I've been able to successfully implement it as shown by the hundreds of units out there doing just what is described above.

In a newer implementation (RoadRunner) where I utilize a fast CPLD (5nS) to monitor everything (or darn near it) to make timing-critical decisions among a micro and an independent pairing of 16-bit 8-mbit RAMs, I've still found utilizing the CE/OE transitions to arbitrate 'bank swaps' less effective than triggering such events based on address value transitions. The address value transitions, with a couple of delay cycles in the CPLD for the reaction, has been shown to be very smooth, even with the newer PCM applications. Still, you don't want to swap anymore than you have to. So a bit of discretion is called for from the PC software designers' sides. It can be carried out rather elegantly that way.

liquidh8

Craig, i'll check that out. After the updates I can't erase my chips no more, 27sf512, d@#n. At leats I have an old chip to run. Keeps saying check connectivity, firmware, etc. It worked before the update. any clues?? btw, I have the 102 chip in my autoprom..

liquidh8

BTW, I just found out I can use the flash-n-burn utility to erase/program the chips. But i can't use the moates i/o found in tunerpro rt. What gives?? Am I doing something wrong here? I'm pretty sure I kept all settings the same.

Z69

Nice Job Mark


Just to be clear, I have the 332 chip in my APU1.
Can I use the latest TP, and I should not do the firmware upgrade???
Least till I send mine in for the hardware upgrades.

junkcltr

iTrader: (1)

Craig, not trying to harp on this, but it can be done. It also kind of bothers me that people are out there trying to emulate on the same roads I drive on and have the ECM crashing as I drive by. You can successfully monitor the CE/OE line and switch while the ECM is not looking. I use an Atmel AT chip operating at 14.xxMHz and a 25ns CPLD to do the muxing. With a VERY CAREFULL selection of MCU instructions you can switch the bus without the ECM noticing AT ALL. I use the CPLD & Atmel MCU without any resistors on any buses. It is purely digital. No analog kind of stuff like resistors on any buses.

Also, loading the bus with resistors low value resistors like that is a very bad thing to do. It decreases voltage margin and will shorten the life of the vehicle ECM. It is not my intend to hi-jack this so I will not write anymore about this here. But you really should fix that design error because it is pretty dangerous.

The most IMPORTANT part is that when you corrupt the bus like that, you NEVER know what the ECM will do. For example, it may be a bad instruction and cause an ECM reset. Or it could cause a BRA 0xABCD to become BRA 0x1234 and now the ECM is operating out of control. Or it could misintrepret how long the injector pulse width should have been. All very bad stuff that can cause engine to blow and accidents to happen.

Anyway, think about the MCU instruction sequence when you try to switch. Get those ECM killing resistors off of the bus. You can do it. You seem to be rather bright, I am sure you can figure it out.

J

Craig Moates

If the monitoring is done strictly via the micro, then no, it probably can't be done due to the timing requirements unless you can find a ca. 2-3uS downtime. These do occur on some PCMs, but not all. But, if the gating is done with a CPLD, then yes, it can be done for sure. The muxing I do for the read/write does in fact NOT disturb the ECM. You can upload and read entire binaries without so much as a blip. So, it works by experience. I'm definitely not saying it's the 'best' way, but it is something that does work consistently.

As for loading the ECM, no, I don't load it at all. As you say, that would be a bad thing to do for sure. Purely digital TTL logic between the emulator and the ECM is used. Just one side of the muxes for the address lines, and a latching 8-bit buffer for the data. With a fast OR gate for the CE/OE that drives the data buffer output directly (that's a cool trick BTW...).

The loading is done among the micro, the NVRAM data lines, and the data buffer input. Very safe in that zone, even though a little bit of amperage is potentially wasted during the cycles ca. <40mA short duration) and it has never caused a problem. I pumped some extra decoupling in there, and did some careful routing to avoid induced noise. The NVRAM is very capable of driving the inputs of the buffer to the proper levels even when the other side of the resistors is pre-loaded with the micro-sourced data queued up for writing.

I definitely see your point with respect to loading the bus. That is a very bad thing, especially at 1k. The closest I come to that is pulling some of the high address lines up with 100k to keep them from floating during 24-pin operation. Some of those ECM lines are fairly sensitive, and they're designed pretty strictly for TTL logic levels. I try to make em happy ;^).

The MCU instruction sequence is pretty key, you're right. First the data is preloaded at the MCU output to the backside of the resistor network. A first instruction controls the NVRAM OE<hi, databuffer LE<lo, WE<lo, and mux DIR<mcu. As soon as that OE<hi, the data from the MCU cascades over to the NVRAM which is common to the buffer input, but the buffer input is not affected, since the latch is enabled for this short period. A second instruction controls the WE<hi, NVRAM OE<lo, mux DIR<target, still leaves the buffer LE<lo. Finally, on a third instruction cycle, the LE is set back high, allowing the 'fresh' data to come on through.

So, you see how it works in terms of sequencing. The ECM only sees the 'last' requested byte, and then no more than 140nS later (70nS clock cycles on the MCU, plus maybe 5nS for the propagation delay on the LE<hi), the ECM sees the 'next' byte. If it so happens that the ECM doesn't even get around to providing new address request info before the emu comes back online, then it just gets a continuation of the 'old' data that it was seeing during the latch sequence.

Not trying to get too carried away here on the details, but I'm sure some people wonder how their 'tools' work. I'd rather see folks learn and understand stuff like this rather than just 'use it'. If anyone has questions like this and wants to chat more about it offline or on, just let me know. There's always room for improvement, and I'll keep getting after it.

Craig Moates

Yes, that's correct. If your 332 chip is 'socketed', just get with me offline and I can send you the 102 chip in the mail. IF it's soldered in, then yes, it will need a return visit for the upgrade.

Craig Moates

Sounds like a software glitch. If it works on the FlashBurn utility and not in TunerPro RT, then it must be. I'll try and replicate on my end, and I'm sure Mark will get after it on the debugging end.

This is with the AutoProm, right?

By the way Mark, I think I saw something like this as well. If I recall correctly, it was just with the TP application with an AutoProm. It had problems, and would identify the wrong version number for the device when entering into the Prom IO section. Is this what you're seeing? I think that I had some other COM port stuff 'ahead' of the AutoProm (maybe modem, COM port, or something). Moved it down and it went away if I recall. Could be a clue.

Mangus

In response to Craig's verbosity:

I like burritos.

Regarding the chip IO problems, I'll have to look into them, but I don't remember changing anything around how the chip stuff works. I'll be releasing a version tonight and will have a fix in for that build if it's broken.

EDIT:

Found and fixed the problem. Look for a new build tonight (with a number of other bug fixes).

M

DM91RS

Too late..........both are girls and have this subject pretty much covered. Just ask their husbands...........

liquidh8

Mark, craig, thanx for the replies. Look forward to the update Mark, hopefully it'll get me fixed up. hehe, BTW, has there been any issues with replying the datalog's? I recorded twice, and when I tried to replay the logs, tunerpro rt gets an error and is closed. If I go back to some previous logs, the play fine. Maybe the dat got corrupt while recording. I'll have to try again tomorrow or something.

Craig Moates

Yeah, how about datalog corruption? I know that caused me a bit of heartache before, particularly when a data link was lost mid-session (ie. Bluetooth etc). Hopefully something can be done to allow 'safe exit' a little more readily.

gbody5

I agree, thanks Mark !!!

Mark Tonazzi

BadDog

Did the update ever happen? Looks like it's still the same one.

Mangus

Not yet. Ended up playing video games all night last night. Sorry.

It should happen tonight.

liquidh8

hehe, that's great. I did the same thing, but I was loaded. lol. Look forward to the update.

mrnuke

Does this work with '870 ecms?

I use tunercat pro now, but wouldn't mind checking this one out as I've heard it's good..

liquidh8

any news on the update yet?? Thanx magnus

Mangus

New build is up (build 1751). Check the download page for a list of fixes.

http://tunerpro.markmansur.com/

BadDog

Thanks, now maybe I can put WinALDL to rest except for the BLM wide/narrow average stuff.

I also ran across that chip erase bug today too. Finally started some real "tuning". After going through about 6 iterations with the VE tuning, I thought I was loosing my mind. Chasing numbers back and forth with no predictable pattern. The results of changes made no sense. Finally figured out that fuel pressure was fluctuating. <sigh> Maybe with this version and a new regulator diaphram I can make some progress.

mrnuke

Anyone?

Mangus

Yes. Definition here:
http://www.moates.net/files/3)%20Bin...nitions/1F.xdf

ben73

Hi Mark,
TunerPro is looking better than ever!
I do have one suggestion, just in case you are sitting around with nothing to do ;-)
Would it be difficult to implement a BLM logging table like that in WinALDL and TunerPro? I find it extremely useful for tuning the VE tables, and its the only remaining feature I still need that tunerpro doesn't have..
Just a thought...

yager

yes, please Thanks for all the work you've done, definlty worth the $30...

Craig Moates

This would feed well into an AutoTune functionality. Histograms, fuel trim data, wideband data, VE table correction on the fly. Right?

scuzz

Now that sounds like an awsume addon. I have not had the first problem with tunerpro rt. I'm new and after you got me started in the right direction, I have edited several bins and am datalogging without problems, and learning to do my VE tables. Thanks a million.

Mangus

Hi Ben -

I have one more release coming up very soon here (I'm taking some time off work for the Holidays, so maybe in as little as a week), and then I plan probably one more after that to fix bugs that I might have introduced. After new years I'll be starting work on completely re-writing the ALDL stuff, including a new file format (ADX, to follow in the footsteps of XDF) and a bunch of new features (much better logging, better connection routines for the more complex ECMs, histograms, etc).

So, look for all of that in version 5.0. My lofty target wouild be to have that complete by June-ish.

Of course I reserve the right to delay, miss my release date, change my plans, and take lots of time off at my choosing. You know, the same old disclaimer.

Sound good?

ben73

Oooooooo YEAH!

liquidh8

Has anyone had a problem creating a new look up file for the datalogging, ads files?? I have, everytime I try to make a new one I get the error and tunerpro shuts down. Figured I'd run that by everybody.