Emmulation and $0D Programming Issues, and Commanded AFR 94 Chevy K1500 5.7

I'm new to Tunerpro and some of the basic functions are probably very simple, however I have no idea what I need to do here.
I'm working on a 94 z-71 5.7.
ECM#16196395
Starting BIN File: BJLF (this is straight off the PCM)
XDF File - Advanced $0D TP5 v250.xdf (I've even tried the $0D TP5 v250.xdf straight from the tunerpro downloads page. even tried the $0E.XDF)
Definition - A217_0D_v250 - 4L60

For starters I cannot emulate. I'm using the Moates Autoprom. It will start out fine and slowly start glitching until it either wont shift or wont run, however I can burn a chip and it's hit and miss. Yesterday it ran but was commanding 23,000 degrees of timing randomly throughout the RPM Range. Pulled the chip and re-installed the original and it worked fine. I have an old Hypertech chip for the truck. I can put it in and it runs great, so that tells me it's not a computer issue. Still stumped. when it starts crapping out it starts throwing all kinds of random codes like EPROM ERROR, Fuel pump relay, etc. So far the Datalogger works, but again when it starts crapping out I loose tach, TPS% and so on while logging. So far I've had better luck programming under $0E than I have $0D. I have the switches in the correct locations on the Autoprom. (both pushed towards one another.) When I put it in pass-through it stops all-together. I do not believe I have an issue with any hardware as I recently tuned a 91 Camaro and everything worked fairly well. It was a little glitchy and I had to constantly upload the BIN or it would start to freeze up. It has to be something i'm not doing correctly. Just for curiosity I checked the Hypertech chip's Mask ID and $0D is what came up. so I'm not sure why the $0E worked better.

While I'm at it here's another question - I'm wanting to watch and compare the Desired AFR to what i'm getting on the wideband and when I go to the values tab there is a message in the box that says "For data logging "Desired ARF" instead of "Battery Voltage". The bin must be change at L520C to support this." I have absolutely no idea what I need to do here and cannot find anything in the forum about it.

Thanks in advance for the help.

:welcome:

Links to Moates.net AutoProm information:
https://www.youtube.com/user/craigmo...A878598D87BA29
http://support.moates.net/autoprom-apu1/

Gearhead-efi ink for WBO2 Tuning WITHOUT using an AutoProm: http://www.gearhead-efi.com/Fuel-Inj...g)-Spreadsheet

dave w

The Spark advance number is a glitch caused by the ADX using an unsigned (0-infinity) value rather than signed (negative-positive) value, when $0D can have negative Spark advance values. There’s a fixed ADX here: http://www.gearhead-efi.com/Fuel-Inj...ll=1#post79291

Dave, I've had Dave Blundell at moats remote in before and we made sure that everything was installed correctly and that the do hickey was changed to 1ms in the control panel. as of yesterday I cannot emulate. It will work for a little while then the truck stalls and it sets a code 51 checksum error. I've tried using another chip adaptor and all the hardware I could think of changing I've tried to change. It's almost as if the APU1 is actually faulty. It programs chips just fine so far, but it keeps going in limp mode and starts running like crap and the log quits reading all but MAP sensor. I can keep uploading the BIN to the Emulator but it makes no difference. I have to disconnect the battery to clear the code 51. Not sure what to do next.

Set code mask to AA to disable the checksum error.

dave w

Quote:

---

Originally Posted by dave w

Set code mask to AA to disable the checksum error.

dave w

---

x2 I have always had to do this with any of the 64K PCMs. $E6, $31, $OD, $OE, $63 and the like.

So is RT emmulation inherritantly glitchy? I can burn a chip and everything works great, but running through the emulator is very glitchy. I can post logs if anyone wants to take a look but it has gotten bad enough that just loading the tune wont work. I have to cycle the ignition and re-flash and ive even had to insert a chip just to get me back running so i wouldnt be broke down on the side of the road. I got an error one time about a Ram issue with the emmulator. I did find the chip adaptor was bad. If you touched it or bumped the PCM it would glitch. Swapped it with another one and its working a lot better. However it hasnt fixed the glitchy issues im having.

I don't own an APU1, likely I never will.

I own and use the Moates.net Ostrich 2.0 to Emulate $OD applications and several other OBD1 data streams. I have ZERO emulation issues with the Ostrich 2.0.

Possibly there are glitches with the $OD .adx file. Recent post with a $OD timing glitch: http://www.gearhead-efi.com/Fuel-Inj...-Spark-Advance There is an updated $OD .adx in the linked thread.

dave w

Emulation is not inherently glitchy, once everything is set correctly.

The biggest thing you have to do is disable checksum, by changing the MASK ID in the bin to AA. This goes for all OBD1 GM ECMs.

Sometimes the APU1 needs other settings in the XDF and/or the ADX changed to be able to emulate and catalog at the same time, but $0D is not one of the masks that should need that.

Make sure you have the proper hardware selected in Preferences > dataloging.

Make sure you have the switches on the APU1 set correctly for emulation.

I suspect most of your issues are coming from not disabling the Checksum though. Start with that.

Just for refer6i own and use both the Ostrich 2.0 and the APU1.

Disabling the checksum was one of the first steps i took when i started on the truck. Switches are right. Ive tried it with the 10K switched also. It wont work at all when you switch it to passthrough. Correct Com Port. As mentioned above ive had the Moates Tech guys remote in befote and check the drivers and port setup. So can anyone tell me anything in the adx or xdf that could be off?

I wonder if the engine computer could be the emulation problem?

dave w

I have the same problem with the $OD on a 95 truck, data logging and emulating are very glitchy. I have been through every thing to try and eliminate the problem but have just resorted to flashing a chip and running with it then changing the tune on file and reflashing as required. I had one instance while emulating with the cruise control active where the transmission neutralized and the engine went to red line bouncing of the fuel cut off threashold, after that episode i decided to just flash and try tune.

I fixed my glitchy datastream on $0D by adding a pause in the macro for send and receive data. See screenshots for what I changed in my adx file I use. 1ms of delay between messages made a world of difference in my datalog quality. Your mileage may vary...
Hope this helps,
Brian

After talking with Dave Blundell at moats I believe we've narrowed it down to the emulation cable being the culprit. According to him if i'm only having issues emulating and not with the chips then the cable has to be it because they both share the same circuitry. He's sending me a replacement this week and hopefully this is the cure-all for all of my emulation glitches. If that doesn't work i'll try sturgillbd's Macro fix and see where that takes me.

The macro fix is only for the data logging side, it should have no effect on the emulation side.

Another thing you can try is uploading the entire bin when change things instead of each individual change.

Also what location are you changing to AA?