experimental cheap and relatively easy scantool
#71
Senior Member
Posts like a Supercharger
Thread Starter
Join Date: Mar 2004
Location: Columbia, MO
Posts: 175
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by GreenMachine
Enmityst,
I already modified them. There'* not that much different between them, other than a couple not used becoming boost control and a couple factor values different. So far I'm liking it. I also figured out the macros. You can alternate between "hush chatter" and a normal command automatically. I will try that out tonight to see if it helps with stability.
Good luck on your intake repair.
I already modified them. There'* not that much different between them, other than a couple not used becoming boost control and a couple factor values different. So far I'm liking it. I also figured out the macros. You can alternate between "hush chatter" and a normal command automatically. I will try that out tonight to see if it helps with stability.
Good luck on your intake repair.
-b
#72
Member
Posts like a V-Tak
Join Date: May 2004
Location: San Diego,Ca
Posts: 97
Likes: 0
Received 0 Likes
on
0 Posts
Ah, okay. I've tried the alternation between hush chatter and a data request, but for some reason CarBytes doesn't like that, at least with my setup; for every hush chatter command sent, it logs zeroes to the data, so that when you view the data, every other reading is zero.
#73
Senior Member
Posts like a Supercharger
Thread Starter
Join Date: Mar 2004
Location: Columbia, MO
Posts: 175
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by GreenMachine
I believe your right, but I think I may be able to come up with a way to remove the 0 data by post processing the alg file that comes out. If I can stabilize it without this, I won't need it. I'll keep you posted.
-b
#74
Member
Posts like a V-Tak
Join Date: May 2004
Location: San Diego,Ca
Posts: 97
Likes: 0
Received 0 Likes
on
0 Posts
You got that right! I use perl almost on a daily basis. Once you know it, it'* a real time saver. I used to use mostly C, and still do in some cases, but many times, in less than half hour I can get what I need with perl. I think we may lose some viewers with all this geek talk, but this is a geeky subject. :P I can't tell you what a Godsend this website is for me. I've been in the dark too long with my beloved bonnie. She needs some tuning up, and it'* nice to not have to depend on mechanics with expensive tools if I can avoid it.
#76
Senior Member
Posts like a Supercharger
Thread Starter
Join Date: Mar 2004
Location: Columbia, MO
Posts: 175
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by BonneMeMN
I wouldn't be able to modify my pcm, and it'* values from my laptop with a setup like this, could I?
My best guess is that you'd need to physically pull the PROM and use a reprogrammer to modify PCM operation, which would require an intimate knowledge of the PROM'* memory layout and characteristics, unless you had some pre-made binary from somewhere or another to dump into it.
-b
#77
Member
Posts like a V-Tak
Join Date: May 2004
Location: San Diego,Ca
Posts: 97
Likes: 0
Received 0 Likes
on
0 Posts
Enmityst,
I was able to get some clean runs on my car by setting up a macro that first does a few hush chatter commands, followed by 10000 mode 0 commands. With this, I get an error free train of data, except every 1024 counts, which appears to be a carbytes bug (that is where it clears the screen buffer). This is a minor annoyance. It appears all my flags come up clean, and all the sensors are doing what they're supposed to do. There is only one error I'm getting, and that is with the m1m1 setup, and collecting mode 1 data, I get all 1'* on byte 49 QIMRDY08. This is the same on both L36 and L67 specs. I'm wondering if you had the same thing come up on yours. It doesn't make sense that all 8 bits come up error, unless there is either an incorrect spec, or the ECM is faulty. One of the bits is catalyst monitor malfunction, and I don't think the 95 has a catalyst monitor. What'* your take on this?
I was able to get some clean runs on my car by setting up a macro that first does a few hush chatter commands, followed by 10000 mode 0 commands. With this, I get an error free train of data, except every 1024 counts, which appears to be a carbytes bug (that is where it clears the screen buffer). This is a minor annoyance. It appears all my flags come up clean, and all the sensors are doing what they're supposed to do. There is only one error I'm getting, and that is with the m1m1 setup, and collecting mode 1 data, I get all 1'* on byte 49 QIMRDY08. This is the same on both L36 and L67 specs. I'm wondering if you had the same thing come up on yours. It doesn't make sense that all 8 bits come up error, unless there is either an incorrect spec, or the ECM is faulty. One of the bits is catalyst monitor malfunction, and I don't think the 95 has a catalyst monitor. What'* your take on this?
#78
Member
Posts like a V-Tak
Join Date: May 2004
Location: San Diego,Ca
Posts: 97
Likes: 0
Received 0 Likes
on
0 Posts
Just a correction on my last statement. Byte 49 is a 0F which indicates the first 4 bits are high. This is the I/M readiness flagword. I wonder what I/M readiness means. One of those bits is misfire detected, but the other code pulls don't show any misfires. :?
#79
Senior Member
Posts like a Supercharger
Thread Starter
Join Date: Mar 2004
Location: Columbia, MO
Posts: 175
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by GreenMachine
Just a correction on my last statement. Byte 49 is a 0F which indicates the first 4 bits are high. This is the I/M readiness flagword. I wonder what I/M readiness means. One of those bits is misfire detected, but the other code pulls don't show any misfires. :?
When I get it back I'll check it out. It'* entirely possible that spec on that word is incorrect; there are a number of bits/words/bytes in the m1m0 response that don't seem to mesh with the datastream spec.
-b