1227747 to 16197427 Conversion Box!

[EagleMark]

Some datalogging cables and cables for proper scanners do have the pins for M and E jumpered together.

I had talked to a freind whos a mechanic at dealership and he told me no way... but he hasn't seen anything but OBDII for years... then I looked at my Auto Xray 7000 scan tool that does all OBDI and OBDII cars and has several plugs for ALDL ports. Well it only has one plug for OBDI GM so your right, it must have E and M jumpered.

[1project2many]

I have had trouble using emulation on a friend's APU1. I never followed up but the symptoms were as EagleMark described. I would restart the software and usually that was enough but sometimes I had to restart the laptop. I had hoped it was a problem specific to his configuration.

[d0nk3y]

I appreciate all of the help! :) There are a couple of things I tried w/o thinking - just because I have about 20 years experience with fussy data acquisition and windows. I disconnected / reconnected / rebooted / reloaded drivers and even promised ice cream if the durned thing would just behave - with only limited success.

My next thought on this (the same one the kept me awake last night, LOL) is from JeepsandGuns similar experience between $0E & $0D: I'm wondering if the bins we both started with for $0D have a certain set of bits enabled that cause a meltdown from using such drastically different hardware / missing transmission signals. My thinking is this: the PCM initializes and either doesn't see what it is looking for or has a signal sitting on a pin it doesn't expect or cannot handle - then loses its goshdarned mind.

I got up outta bed and start going through all the trans bits (cause I couldn't sleep) and started to disable everything trans I could think of (vehicle has a 400R in it). I also noticed the datastream showed it is in 4WDLO - which may cause other issues as well, but without a VSS/OSS, that may be moot.

I'm also going to try another PC today and see if my "failing-eyesight-friendly" laptop is just getting uppity in its old age. :D

~Scot

[gregs78cam]

I am sure you guys already know this bit, but you did disable the checksum right? I had a similar problem with the Camaro, I tried uploading the bin, then emulate, then remembered to disable checksum. it never worked, until I disabled checksum in TP, save .bin, then upload, then enable DA, and emulate.

[JeepsAndGuns]

I have never had any problems with tunerpro reconizing the autoprom. My laptop only has two usb ports, one I keep my mouse plugged into, the other one I always use for the autoprom. I will plug in the auto prom, windows always makes the do-do noise when its pluged in, I then start tunerpro and it instantly reconizes it.
I have never tried closing, then restarting tunerpro, and both switches on the autoprom are in the correct spots. The odd thing, was that I could try the non working bins, back to back with the working one. The 0E bin would work, the 0D and 31 would not.

One other thing I noticed about those two bins I couldnt get to emulate. Normally when I burn a file to a chip, or load to the emulator, it takes a few seconds for the progress bar to go across. Now when I tried those two other bins, about the first 1/8th, to 1/4 of the progress bar would jump forward in a split second, then the rest would go normal. When using my working 0E bin, its the same speed all the way across. The file sizes on the other two were the correct/same size.
Since I am using a manual trans, I had took the proper steps in the bin to turn off auto trans controlls.

[JeepsAndGuns]

I am sure you guys already know this bit, but you did disable the checksum right? I had a similar problem with the Camaro, I tried uploading the bin, then emulate, then remembered to disable checksum. it never worked, until I disabled checksum in TP, save .bin, then upload, then enable DA, and emulate.

We posted at the same time.

Um, I have never done anything to "checksum" I do not even have any idea what that is. Can you mabey tell me or explain it to me what it is?

[gregs78cam]

We posted at the same time.

Um, I have never done anything to "checksum" I do not even have any idea what that is. Can you mabey tell me or explain it to me what it is?

In TP open the mask ID parameter and change it to AA. That disables the checksum function. then save .bin, then upload, then emulate.

[d0nk3y]

I will check this out - more info I was unaware of!

[Six_Shooter]

On TP RT V4, there was a selection on the preferences that allowed automatic checksum disable when a BIN was uploaded to an emulator. Mark removed this in V5 because it seemed to be too confusing for the common user. The issue was that different codes used different addresses for the Mask ID byte.

When switching between codes, are you powering down the PCM for at least 10 seconds between?

[d0nk3y]

Damn program.

Any time I try to load a acquisition def file that has things like "TP5 V250" in it, the program locks up while using 100% of the CPU and doesn't come around after 10 minutes of deep thought. So...I can't find any $0E acquisition defs that will let me see if I've even addressed the issue.

...because setting the mask ID to AA didn't fix my $0D woes.

[d0nk3y]

PCM "off"
Mask ID == AA
Bin saved
Bin uploaded to emulator
Key on, and get the following result. (along with nothing running correctly)

[93V8S10]

Where did you download your copies? Seems that there is some problem with the ones at the TP site.

There are downloads of these files here and at Moates too.

[d0nk3y]

http://www.gearhead-efi.com/gearhead-efi/def/

[dave w]

Attached is a $OE .bin I've used in an Ostrich 2 Emulator. I did not need to change the mask ID with the Ostrich 2. The attached BHDC .bin has been modified from it's original code!

dave w

[d0nk3y]

I'm going to call Moates tomorrow.

The dang thing won't even work with the original 7747 that I did my initial calibrations with. I think my emulator has failed, or does not like the cold temperatures.

This has not been a good weekend.