Sure you could go either way with this project. You code build a micro
to intercept the pulses, or just flash the sucker to death. I would
still feel better if we knew what the SBEC was really doing. I am just
paranoid of doing a hack and slash like the rest of them out there. The
micro is not terribly complicated. all you need is a bit of time with
the right emulators, and BAM you should have a fairly legible idea of
how the SBEC code really works. Once you know what is going on at the
software level. you can them mode the code by turn those bits the way
you want them.... It is still a hack and slash, but you really should
get down and dirty with the root code. You can scope out the voltages
on the PCM. I'm sure a few EE gurus out there could tap into the
harness and make sense of all the gizmos under the hood. I think it is
a rough and tough way to go myself. Cracking code is a bitch of a job,
but so are those @#!$!@$%@$% darn signals on a scope, hahahahahaha....
I fired off my first email examining the idea of reverse coding the
SBEC. Once the boss man here is free. I will talk hack and slash terms
with him.
Jason
2/23/99 11:16 AM
-----Original Message-----
From: Bridges, Bruce [SMTP:bbridges@alarismed.com]
Sent: Tuesday, February 23, 1999 10:33 AM
To: 'dakota-truck@buffnet.net'
Subject: RE: DML: R/T SBEC (Computer) Rag session
Jon,
Seems like we need a Lab view interface to the PCM. Just Tap
into the PCMs
harness, and watch the bouncing lines... you could generate
trending data
to correlate with the trucks "state" to determine whats up!
Since all we're
really after (for basic mods) is crank sensor, Injector pulse
width, rev
limit and speed limit it shouldnt be too hard to either build a
microprocessor that "takes over" in these areas... It could
"reject"
anomalous commands and let the stock PCM do its thing (alright
its starting
to sound like a lot of coding would be required...) reflashing
seems too
"proprietary" but after seeing what JET is doing I get the
feeling its not
that hard to do better...
.02
BKB
snip" You could probably run the custom computer
in tandem with the PCM, with the custom computer intercepting
all signals
to and from the PCM. Anything that hasn't been implemented by
the custom
unit could be "passed through" so the PCM won't generate an
error code
for a sensor it doesn't see... One problem with this method is
the OBD-II
tests. The PCM will sometimes purposely run the engine lean or
rich to
test the O2 sensors, so if the PCM sprays extra fuel and the
engine
doesn't go rich, it'll probably cry "foul".
This archive was generated by hypermail 2b29 : Fri Jun 20 2003 - 12:12:43 EDT