does your ALDL setup have indicators on it that light up when comms are happening? I think I'm going to have to throw more mode 8 commands into the initialization scheme and specifically shut up both E and T side before attempting to communicate with either. it's strange, for whatever reason the calibrations I run in the same PCM don't exhibit the same behavior, when I send mode 8 commands to it, it quits talking for the 2 or so second timeout that a mode 8 with nothing after it should cause.
1995 Chevrolet Monte Carlo LS 3100 + 4T60E
Yes, I have indicator LED's on both the RX and TX lines. I'm not the only person with this issue with the P66 stuff either, there are at least 2 others on Tunerpro's forums-however when I PM'd one guy about it he was having the issues with P66 and 7165, so maybe he has a different issue-He fixed it by removing and re-installing a slightly older version Tunerpro, however that did not work for me. I think that the ghost-in-the-com-driver error *probably* isn't the issue with this now that Mark's pointed out the multiple replies to the data requests.
I will get more data for you this evening-I'll go out to the shop and play with the connection and try to video the comm lights so you can see what kind of data activity is happening with specific commands (I'll key on, and you can watch the DIC data, then mode 8 command, then mode 1 communication requests, etc)
Here's a video of the TX/RX LED's, hope this helps. The LED's are superbrites because that's all I had...and they're so bright they mess with the camera. They seem to be pretty well seperated and if you need more info, just ask.
https://youtu.be/qwc5YBlfo6s
finally had a chance to watch this.
most of that, I was expecting, but there should have been a good period of silence after the mode 8 commands.... like the amount of time that it quit communicating after the mode 1 requests, that's what I would expect from a mode 8. the fact that it never quit is odd, to say the least.
I did just have a really dumb thought though. assuming you don't have anything integrated like a 94-95 Grand Prix Driver Information Center, there's really no reason to have the PCM chattering so much... could clear the ALDL message scheduling tables, then it should never attempt to send data until prompted. not the greatest fix, but it may be enough to at least get the boost patch troubleshooting done. I don't have those tables listed in the XDF at the moment, but they're already documented on both E and T side IIRC.
1995 Chevrolet Monte Carlo LS 3100 + 4T60E
That would be helpful-I had thought about integrating the trip computer at some point but that isn't really a priority. Antus and Charlay86 on PCM Hacking are taking a stab at it too. They are thinking that the pcm may be taking the 3x input and defaulting the Baro/map stuff due to an error. Also, in Charley's experience the map code mods can't have a jump splitting them up or he had the same problem.
I am collecting all my info and your info and wiring info for these and getting it all to them to see if we can all work together and get this cracked. I dug into the code with my local buddy, and that cylinder count thing LOOKS like it may be all you need to change to 4-cylinder mode!
Ok, so today I turned off the E-side ALDL scheduling, and the E-side communications were MUCH improved. Totally usable, except that a lot of data no longer worked...so I will have to be selective with what I turn off. Just need to work out what the DIC stream location is, and turn that one off-it may be done via process of elimination.
Odd thing is that I did not turn off the T-side scheduling, but the DIC chatter was stopped completely-so the DIC info is coming from the E-side???
Here are the datalogs and details from today's work on things.
First off-shutting off everything in the ALDL scheduling table (at least the one we've found so far and implemented in the XDF) does NOT stop all the chatter. Something else (probably something on the T-side table) is still chattering away.
The E-side ADX does not get all the data once we start turning stuff off on the ALDL scheduling table. The important bits still seem to work, but RPM & TPS for example are not being received. Notice the Baro and MAP values...I think the patch is screwed up again. (had a bit where the patches would only partially apply, which is superweird.)
The T-side ADX (normal ADX) is still receiving all the data we want to see-and it is stable, good data now. I did have 6 data errors, but they were well defined short-duration events and the data stream recovered properly. I actually started and ran the engine with the 1-bar code, and have a decent length datalog. I didn't try with the 2-bar code, as the engine does not run with it so it's me flailing at the accelerator pedal to sustain a running engine, and the above E-side ADX showed issues with the baro updates and map updates.
I will be adding the Wideband O2 internal modification to the PCM in the truck this evening. Hopefully I can figure out the patch format to add the patch to the XDF and get it to apply correctly, as this greatly simplifies the checksumming process.
Ok, so I have written the wideband O2 code for the E-side and added the input to the PCM. How do I get the code I wrote into the "patch" function on the XDF? Is there any documentation on this anywhere?
Posting Permissions
Reply With Quote
Bookmarks