[NAJ]

I'll read-up on MAP calibration too.

I posted you a link to a thread on checking Map Calibration.

 

[jwillis84]

Update:

I came across a 4/87 version of the 'DRB-II Operators Manual' and it is about 10 pages longer than the Revised 7/89 version of the "DRB-II Operators Manual'. It doesn't exactly have a "lot" of new information, but a few phrases confirm assumptions or heresay from the forums. Example: It has 32K of RAM which can store data for 72 hours.

I would say the 7/89 "Revised" manual did "condense" what was in the original 4/87 version of the manual. And I think the 7/89 revision made some of the common mistakes that happen when a manual gets revised. The author is usually intimately familar with the topic and "takes out" things or rewords them "Assuming" .. "Well everyone Knows that, don't need to say it in this revision.."

So some more elementary procedures and topics get better described in the "older" version, like what to expect when powering up, lights and beeps and such. Which is "not" in the revised version. Obviously price per page also figured into cutting back on the length of the Operators Manual.

It does have several sets of procedures for carbeurated or fuel injected versions of engines.

Taken together they are more complementary rather than duplication. And I don't recall a pin-out in the earlier edition for the cables.

Also.

Came across a set of Quick Reference cards for 83-88, briefly describing menus.

Also.

Came across a Master Tech Ref guide (from 1992) for abbreviations that appear on the DRB-II display. Its nice to have it in print exactly what those abbreviations mean.. as opposed to simply getting a definition from a Service Guide when a specific procedure is performed. This does say Copyright on the back of it though.. but points out that Master Tech must have run some training or produced documentation on the DRB-II.. so that's a discovery.

I have read somewhere online that at one time they ran an entire article on data collection and logging using a DRB-II.. but I have not been able to find a copy or a solid reference other than a general 'waving the of the hand' description in an article on a different topic.

I know the MDS shop computer that Microsoft sold/partnered with Chrysler to produce seems to be the key to a lot of information. Other than serving as a DOS browser for Technical Support Bulleting CDROMs.. some editions seem to go as far as possibly Windows 1995 before falling out of support.

In the year 1996 ODB-II became the defacto-standard and the DRB-II had a patented adapter for continuing to use the DRB-II with an ODB-II connector.. but the DRB-3 also became available then, and seem to replace both the DRB-II and the Microsoft MDS shop computer all at once. It used PC Cards with EEPROM memory instead of proprietary Cartridges. But at the current eBay rate of $5000 for a DRB-3 and 'not great' backwards support for vehicles before 1996 and iffy around the launch date. The DRB-II still looks interesting to me.. if only from a history project stand point.

 

[cadman777]

jwillis,

Thanx for all that detailed info.

Would you mind scanning both of those DRB II manuals and posting them in here for us to download?

Also, I'd like to see a service manual for older cars that uses the 1994 Super Cartridge instead of the original cartridges. The menus are quite different between the two.

Cheers ... Chris

 

[jwillis84]

Chris,

Check your private messages.

Not sure the Forum rules allow that, if anybody has an opinion though. I'd be happy to listen.

 

[bamman]

It wouldn't be the first time Chrysler copyrighted material hit the internet. Cough, cough, cough, cough, cough.

 

[cadman777]

Or a myriad of other Service Manuals ... like the Honda, Toyota and Infinity FSM's that I found on the web.

 

[jwillis84]

Its a tough call, but I can see Chryslers point of view and eBay users trying to sell their DRB-II devices. If you have a DRB-II already though, contact me and perhaps we can share some information.

Honestly I'd like to write a book about it sometime if I could collect enough materials and gather enough experience.

 

[jwillis84]

Huh.. just made a new discovery.

Apparently the Cartridges "themselves" had some kind of documentation.

Quite unexpectantly.. I'm stairing at a huge chart called

DRB-II Functional Flow Diagram
1991 2.2L Turbo III
Diagnostic Service Cartridge
Copyright Chrysler Motors Corp, 1990

If each released Cartridge had one of these "Flow Diagrams" that is quite interesting.

I'd love to find one for the SuperCartridges or many of the Single Year Cartridges.

This looks like it was drawn on a Large Format Plotter around October 1990.

I see.

It appears many were "gifted" as part of a Diagnostic Procedures Manual that covered the procedures for that piece of equipment or vehicle.. but not always.

A Universal probably doesn't exist because that would be unbelievably huge, and the SuperCartridges are essentially all things, topped off with a menu to the "Year" selected and "Vehicle" identified at startup.

 

[cadman777]

I've seen that type of huge flow-chart on other Dodge/Chrysler/Plymouth forums.

Find attached a couple pics of my DRB II, w/my home-made cable.

This DRB II was the 'cat's meow' in narrowing-down problems w/my neighbor's car. I also used it w/another neighbor's Ram 1500. It had multiple problems. We figured-out all but two of them with the first use of the scanner.

Then I also managed to get a Hickok scanner for Fords for a very reasonable price on Ebay. It does 1984-2005 (non-CAN). That scanner, combined w/an EEC IV breakout box, enabled me to diagnose an ABS problem on a 2003 Sport Track 4WD in all of 15 minutes. Took longer to change the sensor than diagnose it.

"The right tool for the right job!"

Cheers

 

[jwillis84]

I've seen that type of huge flow-chart on other Dodge/Chrysler/Plymouth forums.

Find attached a couple pics of my DRB II, w/my home-made cable.

This DRB II was the 'cat's meow' in narrowing-down problems w/my neighbor's car. I also used it w/another neighbor's Ram 1500. It had multiple problems. We figured-out all but two of them with the first use of the scanner.

Then I also managed to get a Hickok scanner for Fords for a very reasonable price on Ebay. It does 1984-2005 (non-CAN). That scanner, combined w/an EEC IV breakout box, enabled me to diagnose an ABS problem on a 2003 Sport Track 4WD in all of 15 minutes. Took longer to change the sensor than diagnose it.

"The right tool for the right job!"

Cheers

Very nice pictures.

I really like puzzling over these old devices. They really do help in getting solid definitive answers from the engine, or the decision maker for the fuel and spark.. which you just can't get any other way.

The cabling is really awkward to use by todays standards. And the serial communications is really slow compared to what we can do today.

Its simply frustrating a low cost, easy to get alternative doesn't exist. Or that better documentation isn't available.. from the source itself, Chrysler.

 

[jwillis84]

I've been reading over some Patent filing from Chrysler regarding the DRB-II and I think its making more sense to me.

First:

DRB-II Patent link
DRB-III Patent link
Mopar Diagnostics Systrem (MDS) Computer Patent link

The DRB-II evolved from experiments to connect a standard computer RS-232 "like" serial port to multiple RS-232 serial ports (all) on the same two wires. Like train-tracks this created a "shared" bus. They then taught each computer to "read" at the same time they "wrote" to the wires, and if the two were not the same, they "detected" a "collision" assuming they were trying to write data to the "bus" at the same time as another device sharing the two communications wires. A computer detecting a collision then waited a random period of time and tried again.

The reason they did this was to "save" having to wire up a bunch of point to point communications wires and simplify wiring a communications system under the hood of the vehicle.

So the SCI is a "physical interface" in that it doesn't "care" what is being communicated but defines a way of wiring up RS-232 serial ports so multiple computers can "share" the same two wires running all around under the hood from the Powertrain computer to the Transmission computer to the Cluster Dash Display computer, Brake computer, AirBag computer and so on..

Once this was defined it was turned into a Specification that other AutoMakers could follow called J1850. Eventually they turned this wiring Spec into a physical "Chip" so that standard computer parts that only had RS-232 serial ports could plug into without having to worry about detecting and backing off and retransmitting. The communications method became a simple "part" of the wiring harness.

So once that was done they had to come up with a Testing procedure and formalized that in a Patent.

And once that was done they had these "computers" on a communications bus listening and waiting to respond to various commands. The simplest being the SMEC and SBEC engine computers.

The SMEC and SBEC computers have thier own wiring that goes out to various sensors and switches point-to-point with no bus inbetween, to collect data and sense switch positions and drive spark coils, relays or solenoids. But they also have this SCI "physical interface" which connects to a DRB-II.

The DRB-II can go into "Command Mode" or "Interrogator Mode". The first is slower than the second.

The DRB-I apparently only had a "Command Mode".

The thing is the protocol for communications "is not" defined by the DRB-II, it "is" defined by "what its talking to.."

So that means if your connected and talking to an SMEC engine computer, then you need to speak its protocol "or language" which happens to ressemble "Command Mode" or "Interrogator Mode" but what those "Commands" or "Words" or language are.. depends entirely on that SMEC computer for that engine computer.

I would suspect that the early SMEC or SBEC engine computers would support a "root language" which all the similar year or subsequent models "build upon" as time moved forward. Which would explain why a "SuperCartridge" could emerge over time.. but not in the beginning.

The DRB-II is a simple computer with some tricky electronics to support the SCI connector and the CCD connector.. and subsequent Adapters. It only had 512 bytes built-into the CPU. And that was basically its BIOS for startup.. mostly it went looking for a Cartridge and started loading whatever was there into memory and jumped to the loaded programs "start" location and started executing a Cartridge specific computer program.

Since there are only one or two DRB-II devices I imagine the startup code is fairly generic. The Cartridges probably follow a somewhat standard program format with SMEC or SBEC specific codes or routines all designed to work over the same physical hardware.

I think whats required is not a better understanding of the DRB-II as a better understanding of the SMEC or SBEC devices themselves.. their "command" language and an understanding of what variables they make available when requested.

At the same time.. if the DRB-II is merely a simple computer.. finding or figuring out how to build a Cartridge that extends it, and allows data capture or PC communications is one approach.. but the platform is old and hard to acquire.

A different approach might be a WiFi or Bluetooth "modem" but its kind of techy and subject to all kinds of harsh engine noise.

I think some more thought is warranted.

But I also think the MPScan folks may be on to the right approach.

 

[WowZer]

i think rob Lloyd (and others) have pretty well figured out how to communicate with the lm/smec/sbec and the "commands" it uses. in fact, alot of the what mpscan (and mptune) uses to communicate has come from monitoring the drb2 protocols/requests and how the ecu's respond via logic analyzers and the like. in fact, over the last couple weeks i have been monitoring the communication used between the drb2 and the t2 smec, which is quite different then the t1 smec. and probably this week i'll update mpscan "settings" files to reflect some of the new things i've discovered. the only real benefit of the drb2 at this point is to perform some of the diagnostics solenoid tests. mpscan has some basic testing in it but i've never had the time to fully develop all the diagnostic tests for the t1, much less the t2 or lm.

honestly, i don't see a real benefit to spend the money to acquire a drb2 unless you are just curious. i can scan and display all the ecu info the drb2 reports in mpscan as well as ALL the other ram locations the drb2 doesn't access. and mpscan does it faster, provides logging, graphing, export for simply the cost of an ftdi usb cable (i would also spend the money for a flashable chip setup!)

 

[jwillis84]

i think rob Lloyd (and others) have pretty well figured out how to communicate with the lm/smec/sbec and the "commands" it uses. in fact, alot of the what mpscan (and mptune) uses to communicate has come from monitoring the drb2 protocols/requests and how the ecu's respond via logic analyzers and the like. in fact, over the last couple weeks i have been monitoring the communication used between the drb2 and the t2 smec, which is quite different then the t1 smec. and probably this week i'll update mpscan "settings" files to reflect some of the new things i've discovered. the only real benefit of the drb2 at this point is to perform some of the diagnostics solenoid tests. mpscan has some basic testing in it but i've never had the time to fully develop all the diagnostic tests for the t1, much less the t2 or lm.

honestly, i don't see a real benefit to spend the money to acquire a drb2 unless you are just curious. i can scan and display all the ecu info the drb2 reports in mpscan as well as ALL the other ram locations the drb2 doesn't access. and mpscan does it faster, provides logging, graphing, export for simply the cost of an ftdi usb cable (i would also spend the money for a flashable chip setup!)

I totally agree.

I'm retracing steps taken long before.

The work on the Android MPScan and the pocket App looks particularly attractive at this point. From a "practical" viewpoint.

The DRB-II contains parts that even FreeScale who acquired the CPU designs for the 68HC11 no longer "makes".

For newbies and future historians though.. attempting to "organize" the information and "make sense" of it really is my focus.. kind of Indiana Jones "like".

I keep coming across threads you and ShelGame/Lloyd were very active in.. and a few webpages here and there. But nothing like a compendium.. and until very recently YouTube and Google just had hardly anything on the DRB-II. A Wikipedia article with some depth of coverage by someone like ShelGame would be awesome.. especially with his IDA Pro Skills.. and familarity with the code.

I've toyed with the idea of a personal Blog like a couple of other people.. but those tend to go away with time.. archive.org does a good service but even it is subject to revisionist history.

Could be an "ageism" thing.. I'm getting up there in years and thinking about future generations of software archeologists. I know a lot of Atari, BeOS, DOS and console Gamers thinking about stuff like this.. could be putting to much thought into it.

Time and time again however I've tried to get away from the meager interest and wound up confronted by a new cache of information I didn't even know existed.. so a little more than "reverse" engineering.. the landscape is still ripe for "exploration".

Oh.. I did buy an FTDI usb cable to connect my DRB-II to a PC and OTC4000 to a PC. And I bought an FTDI to SCI connector from Boost.com(?) I think .. anticipating getting deeply into using MPScan.. but honestly.. MPScan is rather hard to get started with.. though the YouTube videos about MPScan helped. The documentation is just targeted a little narrow to serve the people who created it. Its really hard to recall what it was like not "knowing" something once your an expert at a topic.. user manuals written from that perspective tend to be hard for a disoriented newbie to read or understand.

The very "best" user manuals are written when a "newbie" starts out with a topic and keeps asking why, and makes mistakes.. asking the expert to explain something.. often the expert gets a new perspective (if they don't pull all their hair out and go bald trying to explain stuff..) those are so easy to spot when you read them, they are a real pleasure to read.. but the experts just can't tolerate them.. total waste of time by then to them.

I particularly like the ELM hack to use a PIC processor and its built-in WiFi or Bluetooth to provide a wireless connection to the SCI port. Very clever. I hope he turns it into a product.. I would buy one. Or if he gets the Android MPScan App in the Google Play store.. I would buy it for the "logging" features alone.

 

[cadman777]

These patent links are golden.
Thanx!
It's gunna take me some time to download them all and look them over.
The past is the key to the present and future.

 

[jwillis84]

These patent links are golden.
Thanx!
It's gunna take me some time to download them all and look them over.
The past is the key to the present and future.

I'll add on a little more information then.

I am not perfect and I get things wrong sometimes.

But this page "Vehicle Network Protocols" link seems to describe the CCD bus as running at the slower speed 7812.5 Bps between computer modules, which can include the engine and transmission or dash or abs computer modules. Sometimes they are hooked up to both an SCI port and a CCD bus. One for diagnostics, One for sharing information while the vehicle is being driven.

And I believe the SCI is linked typically only to the engine through a different set of wires. The DRB-II Patent says it is important to have a second interface independent of the shared "CCD bus" so that a problem with the CCD bus can be determined to be either a fault with the bus or a fault with a computer hanging off the bus.

Also the SCI direct connect interface is capable of running in two speed modes, either the old fashioned 7812.5 Bps speed called "command mode" or the higher speed J2610, 62.5 KBps "parameter mode" which is meant for data logging.. basically either the DRB-II or another device connected to the SCI port "shoots" questions called "interrogatives" at the engine computer demanding the current value of a RAM location, which corresponds to the current value for sensor or status of a switch or relay, or some value that had been calculated by the engine computer and stored at that location.

The speed is "important" according to Chrysler in their TSB that describes the Co-Pilot data logger TSB 18-029-05 "Co-Pilot Support and Correct Cable Usage" link

".. The technician has a choice when it comes to making a recording of a supported Powertrain Control Module (PCM) or Transmission Control Module (TCM). The recording can be done using a DRB or using a Co-Pilot. The Co-Pilot was released to provide a cheaper option that would allow a vehicle driver to capture intermittent problems to help in identifying problems.

Whether a module can be data recorded effectively depends on a number of factors. The most important is communication speed between the tool and the module. DaimlerChrysler vehicles using modules that support Serial Communication Interface (SCI), currently our fastest serial communication, on PCMs or TCMs have the communication speeds to make recordings viable.

To be viable, the module communication speed needs to be 62.5 Kbps (kilobytes per second) or higher.

Modules that use slower communication options such as the CCD bus are too slow to be effective in making data recordings.

DaimlerChrysler does not provide data recording support for these slower communication options.

The modules currently supported for data recordings are the PCM and TCM. "

And Chrysler Patents themselves reference "prior art" including this one that describes a Cartridge based Diagnostic Tool made before Chryslers DRB-II. The illustrations look a lot like those of the the DRB-II "Data Readout Boxes" and the OTC/SPX line of "Diagnostic Monitors"

Method for testing auto electronics systems Patent link

Since the earlier DRB-I and LM modules only supported something like "command mode" over SCI for reading Diagnostic Trouble Codes and the later DRB-II and SMEC, SBEC modules added on the ability to read values in "parameter mode" over SCI it seems a natural progression.

Data logging led to graphs and profiling dynamic problems that were hard to catch while merely idling or under perfect road conditions.

It could be a wild coencidence but there was a James V. Zaleski (the guy who eventually got the patent on the Diagnostic Tool design) who was from Wisconsin and worked on the Apollo 13 mission ground team. He later went on to work at General Motors and later founded Vetronix.

I'd love to find a patent application on the code, which would probably reveal or confirm the command sets and data traffic traveling across the serial lines. It might be in a patent for one of the LM/SMEC/SBEC as an Engine Control Unit or Powertrain Control Module.. but so far I've failed to find anything like that. It just seems like it should exist.

Software thanks to Bill Gates took a different path in history more akin to Trade Secret.. or Copyright as in a "book".. and as far as I know those don't require a submission or description of the method of action. I "think" you just slap on a "Claim of Copyright" someplace in your code and that's basically it. Further code is almost encrypted by its very nature.. so it protects itself by being hard to read... like a Trade Secret. The DMCA makes things even more complicated. I think it both grants a license to "backup a copy" while also forbidding certain rights to the owner of a device. And DMCA protects deliberately "encrypted" things, but not "unencrypted" things.. its a splended legal trap.

 

[jwillis84]

A little more information.

The SAE (Society of Automotive Engineers) appears as a standards body in the literature.

Historically after the California Air Resource Board (CARB) and the Federal government created ODB-II, Chrysler began making plans to comply and adapt as much of their existing pre ODB-II protocols and test equipment as possible.

As a result the SAE created a hierarchy of "standards" of both old and new standards definitions as defined by the existing manufacturers.

The SCI interface on the existing DRB-II got retro-actively "standardized" partially.

The SAE Publication:

SAE J2610 DaimlerChrysler SCI(Serial Communications Interface)

The SAE J2610 does not define the Chrysler "Message Protocol" it only defines everything up to that point. That is the physical electrical connections. And the data frame that transforms a pattern of bits into a byte. A byte is then treated as a "Message" but this document doesn't define the "Messaging protocol"

Later SAE tried to reconcile the various message protocols being passed back and forth in these data frames for the SCI interface and other manufacturers interfaces, assigning them document numbers.

The SAE J2190 (since abandoned as too old and left "unfinished") more or less attempted to define the messaging protocol at least for Fetching Trouble Codes, Modes of Operation and Diagnostic Modes for capturing real time data.

Draft documents of the SAE J2190 still exist on the Internet.

I am vaugely aware of a GitHub project to document the DRB-II messaging protocol which if I recall correctly "looked" like it might match up to the last SAE J2190 draft document I saw.

A fragment of a picture for SAE J2610 explcitly refers to:

SAE J2190 Diagnostic Protocol for PCM Applications, DaimlerChrysler Corporation
SCI Diagnostic Protocol for PCM Applications, DaimlerChrysler Corporation

The sad and exciting thing is.. these documents might finally make complete sense of the framework underwhich the messaging protocol for all Chrysler cars and trucks from the ODB-I were created.

Its obvious they weren't created randomly and fit some sort of pattern.

 

[jwillis84]

An interesting "tidbit"

The Co-Pilot Instruction Manual is available for download direct from the TechAuthority

Co-Pilot Instruction Manual link It is in PDF form.

I was rather suprised they still made something from 1992 still available for free download.

It describes how to use it with a Mopar Diagnostics System 1 (1987-1995) or 2 (1995 - ) computer system.

Has some screencaps of the MDS screen and procedure for transfering log data from the Co-Pilot to the MDS for graphing.

I would guess the same thing applies to one of the DRB-II models generation 1 or generation 2

 

[jwillis84]

The DRBII is driven or enabled by cartridges with EPROM or PROM chips in them.

The lifespan of an EPROM after programming is estimated at 10-15 years due to background radiation or exposure to light which discharges the programming charge in the chips.

That would suggest that any using EPROMs are living on borrowed time.

The last of SuperCartridges would have been "burned" in or around 1994-1996 meaning they would be about 19-20 years old.

Unless they are backed up and "re-burned" or verified any EPROM based cartridges should begin failing, perhaps not all at once, but certain paths in their diagnotic procedures will slowly begin to corrupt and produce errors.

As far as I can tell there was a company that licensed or produced a DRB-II "Emulator" with a hardware interface box. Recently techauthority said that company would be the only source going forward.

I don't know if its possible, but backing up those EPROM chips into S19 files or something would seem to be the only way to preserve them.

 

[jwillis84]

New rules out for things that DRM can be circumvented legally for.. includes vehicle ECU apparently.

Security Researchers May Hack Cars