TunerPro User Forum

The dump to file features requires you to type in an extension yourself in the "save as" dialog box (as the extension filter defaults to all file types).

For your 88, you need to send $80, $56, $01, $29 out to the port at 8192 baud, then immediately poll the port until you get the reply. Keep in mind that the ECM reply will be the 4 byte echo of the data you sent (due to cable design) + 3 bytes of ECM header info + 63 byte data packet + 1 byte data c...

Check out the white paper I wrote on ECU file creation:
http://www.supportfitness.com/mark/tune ... ngECUs.htm

Sorry I missed this post. =) I don't use activeX, nor do I intend to. The reason is basically that I'm not using MFC (MFC makes easy the task of wrapping ActiveX and OLE controls). I create all my controls using standard, straight Win32 C++. I'm not sure what impact the user would see if I did use a...

Thanks guys. I've been putting some thought into this and it is "on the list". I'd eventually like to have VE table tuning, MAF table tuning, and spark table tuning integrated in TunerPro. However, a number of things need to happen first in terms of the code design that won't be addressed ...

Well, the good news is that each of the streams is 20 byte length. This means you should get real data if you set the packet size to 20. =) Then its just a matter of interpretting the data correctly. From the looks of it, the first many bytes of the stream are identical between these!!! You shouldn'...

Yes, its the definition. Email Jonas and see if you can get the ECM ALDL information for that setup from him. That will allow you to create a definition with certainty.

Yeah, you may need to place the .dll in the system path (windows directory or windows/system directory). Alternately you can place it in the TUnerPro root folder.

a crash in user.exe is outside of the control of TunerPro, and is VERY likely to be an OS issue.

Yeah, I'm aware of how to sample the audio inputs. Right now thats more than I want to implement. I'll get it working and fleshed out via the AutoProm first. Sound card later. =)

Thanks again for the sweet idea!

Didn't you say you can no longer reproduce this issue?

Also, note taht you can copy a table from Excel into a TunerPro table and vise-versa (right click in the tunerpro table, you'll see what I mean).

you can only sort the summary list. Thats why its there.

Haven't even started implementing this yet. Once I do, it should only take a couple hours.

I'll *try* to have this in for the next release (which should be in the coming week or two, hopefully), which will be the last release for a while (I need to keep myself from burning out).

actually, this could theoretically be done via AutoProms 3 channels of A/D... i can monitor the channels and use them to tweak values.

damn, that'd be cool!

interesting!

nutty, but interesting.

actually, its a pretty sweet idea. I'll chat with craig about it. there may be better ways. maybe another standalone device.

open the summary list, click on the header by which you'd like to sort. click again to change the order. click a third time to reset to the original order.

1) yes, this is planned (but not listed) 2) sounds like you're referring to "ALDL Charts" which is also planned (and is listed). 3) Given you have the ability to edit the definition for whatever conversion calculation you like, this would be redundant (and difficult, considering all math t...

right click on the ecu file to download it, click "save as". save it to disk. you should then be able to open it in tunerpro.

yes, the moates G2 will work for you.

craig and i are working on this issue. in the next version of tunerpro and the next firmware release for AutoProm, this problem will no longer be there, as we are moving to higher speeds (and we can't repro the problem at higher speeds). Rest assured, though, that if you get it to verify just once (...

Yeah, could be an issue caused by the crash (mid-operation).

if you don't want to start over, send me the definition and I'll fix it so you can start where you left off.

OK, looking more at this, if it verifies *once* then you're fine. The failures are due to a strange port timeout issue that we're investigating. So again, in summary, if you can get it to verify just once, you know your burn is fine. PS- you might also run into this bug when verifying the emulation ...

oops... just went back and played some more... now i can repro it somewhat regularly (like you say, just about every other time).

i'll work on figuring out whats going on.

I'm running the same firmware. I don't have a single issue with verification. just burned a C256 and verified 5 times in a row successfully, loaded a different bin to buffer and verified and it failed (as it hsould have). one of two things is happening to you: 1) you're changing the buffer addressin...

can you give me the details that windows gives you after the illegal operation? what bin? is it the appropriate size?

what ECU? does the ECU reference items outside the memory range of the bin?

worst case, send me both the bin and ECU file.

have you tried this in XP?

when i change to a new definition file format, this should be possible. Until then, there's no way to save the item organization (easily) within the ECU file format.

these are driver related crashes and are happening outside of code i have control of. Theres not much I can do about it, unfortunately. I'd say make sure you have the latest video card drivers.

if you'd like to create one, i'd appreciate the help!

yessir, this is in the works.

with the exception of #2, there aren't bugs in the software, but in the aldl datastream definiiton. if you'd like to fix it (since i dont have access to a car to test it with), i'd be much appreciative... especially if you'd send me the resulting file. #2 is a known issue, and I can't quite figure o...

are they similar hardware? similar video card?

im guessing its crashing due to a video card issue, perhaps with a driver.

good information. so its win98 only issue.

i'll continue to look into it. Thanks for your help, Plant.

Very strange. I can't seem to get this to happen. Using the hex editor, I just changed 3 values in a bin, saved a copy out, and compared it with the original. Only the 3 values I changed were different (plus the 2 byte checksum that was recalculated, of course). Can you reproduce this every time? If...

I'll take a look. Thanks for the report.

(I really need to do some work on the hex editor... i put it in as a "temporary" thing until I had time to create a real one and probably shouldn't have).

MNy software does not interface with this emulator. It doesn't appear to be an "on the fly" emulation (it states a reset is necessary between changes, which would stall the car's engine).

I can look into it for a future version if there is enough interest.

These are good questions for www.thirdgen.org/techbb2 The short answer is you'll probably need to change some of the MAF, AE, and DE tables to compensate for the different airflow. "hitting a button" to change the BPW would require you to change actual source code and would be no easy task...

To display voltage, it should be set to multiply and the factor should be 0.019608.

There should be one included when installing TunerPro RT. Does taht one work correctly? If not, check the TPS item in the definition and make sure its defined correctly.

print to file is there. v3.06. file menu.

i'll be revamping the information shown in the status bar, and it will include the address. thanks!

sounds like the aldl datastream definition you're using is incorrect. which are you using?

WOT throttle locks BLM and INT to 128. Since you mention "mashing on the pedal", sounds like you need to change fuel delivery during throttle changes (AE). You might post to the thirdgen message boards and explain your setup.

and/or send a mail to the diy-efi.org GMECM mailing list.

sounds like an acceleration enrichment problem. play around with the AE tables and see what happens.

GDI. I won't be using images. I'm mainly interested in function. Putting extra effort into it just so people can choose between white face gauges with blue lettering vs black faced with white lettering is beyond my scope.

yup, this is on the list already. =)

definately unique to your installation and in code that belongs to windows.

Also, if it happens again, make sure you're using the latest video driver for your video card.

FYI - this crash is happening outside of TunerPro (its crashing in user.exe). This further solidifies that the issue is likely in your OS installation (or a driver issue, most likely your video card).

Plant -

Try the newly released 3.06 version. If you get a crash, send me the crash info (like you sent above).

Mark

Lots of new features in this latest release. See the app downloads page for more information.

M

many issues look the same, but they arent. Dave's problem was completely unrelated (and has been fixed in the upcoming 3.06 release).

I'm almost certain the problem in this thread is related to something out of whack with the OS installation (Win9X was notorious for this kind of stuff).

i'll look into the crash info you gave me, but i can almost guarantee you that this is an issue with your OS install. This would be rampant if it wasn't (and I haven't been able to repro in any OS I've tried - Win98, Win98SE, WinXP)

I've been goofing around with win98 and can't reproduce this problem (nor can i think of anything that could cause it).

Again, *solid* step by step repro would be good.

Also, can you get me the crash info (that pops up in the dialog box) when it crashes?

TunerPro User Forum

Search found 1926 matches

TunerPro and TunerPro RT version 3.06 released