Will the DRB II record?

[Shadow]

Does anyone know if I can capture(record) data on the DRB II? Also, does anyone know how the DRB II determines total timing? Does the total timing you see include your base (initial timing) or not?

[bakes]

Yes it will data log look on the menu for copilot but it has limitations. you will also need the program for PC for play back.

[Shadow]

Yes it will data log look on the menu for copilot but it has limitations. you will also need the program for PC for play back.

Can I play it back on the DRB?

[bakes]

I cant remember but i think it will show data as number values but not a graph though.

[Shadow]

Do you know where I can get the program for PC playback?

[bakes]

All i have on DVD is the newer star scan software .
i have updates disc pre star scan but i dont know whats on them with out opening the files

[bakes]

change that have disk pm me

[powermaxx]

Not to butt in...

Didn't know the DRB II can download to a PC. Can you educate me?

[bakes]

Not to butt in...

Didn't know the DRB II can download to a PC. Can you educate me?

you need the program to view Data it will show both value and graph and over lapping graph
it can also be use to flash later pcm an tcm

[jwillis84]

I'm new to using a DRB-II and OTC-4000E

This website [ www.jwhweb.com ] has a cable diagram for left port on an OTC-4000E

There is also a Zipfile with a program called TurboDodge Run Logger V2.0.11 which downloads "captured" data from the OTC-4000E

The DRB-II has a similar port with the same number and pattern of pins

This website [ www.sheenconsulting.com ] has a section on datalogging

There is also a Zipfile with a program called Vehicle Scanner Data Logger v1.4f for "continuously" downloading readings

The OTC-4000E seems to be supported by OTC GTI 3441 OBD I Scan Tool Graphing Software written for Windows 95 or Windows 3.1

I don't know if any of this software will work on a DBR-II and I do not have the scanner to PC cable but they might

[Force Fed Mopar]

Also, does anyone know how the DRB II determines total timing? Does the total timing you see include your base (initial timing) or not?

Forget about the distributor setting, all it does is sync it to the crankshaft. The total timing is completely based off the timing tables in the computer and has nothing to do with the physical setting of the distributor.

Basically it's like this. When you put the computer in default to set timing, it fires at 12*. Doesn't matter where the distributor is sitting at, it's still firing at 12*. You turn the distributor until it shows 12* in the timing window, then it is sync'd with the computer and therefore the crankshaft. If this is done, it adds nothing to the total timing.

If you turn it to 14*, then you will have 2* extra timing everywhere. But, the computer will not know this, because it has no way of telling.

[ShelGame]

FWIW, I have a DRBII Co-Pilot for sale. No idea how to use it.

http://www.boostbutton.com/store/gar...-co-pilot.html

[Ondonti]

I videotape my scanner and frame by frame review it.

[jwillis84]

I'm still really new to the DRB-II and built my first cable to power it up last night.

However while I have one of the older (original DRB-IIs) I have also ordered an OTC4000E because both were made by the same company (OTC) and share a lot in common. For one thing they both have a PC serial port in the form of a mini-XLR connector on the top left of the device.

From what I can tell both are Motorola M68HC11A1 computers with multiple serial ports, one serial port is the traditional RS-232 style which can communicate with a PC. Two others are connected to the vehicle through special cables. One of those connects to the Chrysler SCI serial communications interface of the engine. The other connects to the Chrysler CCD collision communications detection interface of the body. (Warning) I have a Using the DRB-II training manual which mentions a connector in the trunk of some vehicles for [auto leveling] that looks like a CCD connector (but) It Is Not! a CCD connector. Connecting the DRB-II to the connector in the trunk can destroy the DRB-II.

I came across a copy of the OTC Graphing software which works with the OTC2000/4000/4000E for Windows 3.1 and Windows 95 it will not install on Win7x64 but I read that that was because Microsoft removed the WOW - windows on windows 16 bit emulator when they stopped making windows32. Its been suggested it would work on Win7x32. Instead I installed it on WinXP home edition on an old netbook.

After looking around the OTC graphing software offers (all in one) a [remote] console for the OTC4000 for viewing all the sensors in columns and rows at once, or for graphing their values over time. It can print either to a printer or save the information to a file. It can also load information saved to a file and graph it. So it comes with demo copies of data from several vehicle types. It can also allow you to navigate the OTC device from the program instead of pressing keys on the device.

Since it appears to be so generic in function, and because I've browsed some of the DRB-II menu options and its mentioned [remote connection: on] and because I've sort of read indirect descriptions of a terminal mode.. I believe hooking up a PC or modem to an OTC2000/4000/4000E or DRB-II will present some sort of terminal interface with a text menu.

I've ordered a USB to RS-232 cable (where the electronics are in the USB connector and the cable is tinned wires) and a mini XLR connector from digi-key.. they should be here later this week.

If it proves out here are some of the things that might be possible:

1. The OTC graphing software covers so many of their devices, its seems reasonable to assume it might work with the DRB-II

2. The Terminal mode (if it exists) might mean a wireless modem or bluetooth adapter could provide a wireless interface into the DRB-II and the DRB-II might become like a universal communications device for your vehicle.. just leave it inside behind the dash and access the functions and information remotely via a cell phone, ipad or laptop computer.

I put a couple YouTube videos online from my "first" boot of the DRB-II yesterday. They are tagged DRB-II so they should be easy to find. In case someone would like to see what a DRB-II looks like started when its not connected to a vehicle.. or they're just curious as to what is a DRB-II first generation ODB-0 device looks like.

[jwillis84]

I've been collecting old MOPAR training manuals and came across manuals for the MDS - Mopar Diagnostic System.

It's given me a whole new perspective on the DRB-II

First the MDS was a partnership with Microsoft to deliver an IBM PC loaded with not only a Modem and a storage cabinet for testing tools like the DRB-II, but also software created to assist a Mopar Mechanic. Its basically a Pre-Internet IBM PC loaded with CD-ROM drives and an early Windows operating system that served the function of a "Website" before there was anything like MOSAIC or Netscape. Content was delivered via CDROMs in the mail, or over a Modem and a handset on the back.

The DRB-II from all the patents filed and details I've run across was more "Radio" than actual computer.. it could communicate on several kinds of serial buses with the right cables, and load EPROM programs from its cartridge slot like a Nintendo or Atari Video game. The Keypad was like its game controller. It was ruggedly made but very simple. It was a Motorola 68C11 based microcomputer in a oblong plastic box with cables and connectors.

As a universal dog-body it could be reprogramed on the fly by inserting a new or updated cartridge (its rugged form of a floppy disk).

The MDS (IBM Computer) could also be plugged into the DRB-II with a special cable and the DRB-II "booted" off a special MDS cartridge to go into a fairly dumb mode where it downloads its operating system from the connected MDS system which fed it a customized Diagnostic or Data Recorder operating system specifically for the DRB-II.

As far as I can tell unless you have one of these ancient MDS Computers in working condition and the MDS cartridge to go with it.. you can't reboot and start the DRB-II in this special MDS Data Recorder mode.

The manual does speak of running the DRB-II in a hyperspeed serial mode as opposed to its slow normal mode. In this mode it could super sample all of the values of all the sensors the Logic Module could see (SMEC or whatever) several hundred times a second. It also allowed you to narrow down the list of sensors being monitored and there by increase the sampling speed. The Logic Module was still doing the work of converting the sensor values into digital numbers the DRB-II was just acting like a Radio to request and store those in the MDS.

With this information the MDS could create graphs and mechanic could narrow down problems.

That the DRB-II could be used stand alone seems to be its original intent and as an add-on peripheral "bridge" between vehicle and the MDS computer but graphing and collecting lots of data in recorder mode doesn't seem like that was what it was original designed to do.

The DRB-II does know how to activate solenoids and turn things on an off by talking to the Logic Module of the vehicle and requesting it do so. This is probably highly proprietary and unique to each Logic Module (PCM, TCM, BCM, SMEC, SBEM, ect..). Since SPX/OTC built the original DRB-II for Chrysler (as etched in its circuit board) they were in the best position to be familar with the feature.. and I think their scanner tool products from that era are most likely to be very useful if you don't have a DRB-II.

The OTC tools 2000, 4000, 4000E ect.. also covered other manufacturers vehicles of the time (including Chryslers).. which might increase their value to anyone who works on more than one vehicle of that era.

The Co-Pilot device is also mentioned in the MDS manual, but sounds more like a smaller lower powered version of the DRB-II with no display screen or keyboard and only a single button to trigger a single recording session.

It looks like the DRB-II was used tethered to the MDS Computer (since it was booted from the MDS via cable) and to the vehicle in the shop for Data Recording, while the Co-Pilot could be used independently away from the shop and the data downloaded/uploaded into the MDS Computer later for graphing and diagnosing.

The MDS is very old school computer maybe an x386 and maybe running Windows 3.11 so bare this in mind when you consider acquiring such a tool. Its a bit like getting a tool from the 50s to work on a car from the 50's.

The OTC tools while just as old, appear to be more universal in nature, and their graphing software was more "open" to being run on any 32 bit Windows Operating system up through at least Windows XP (proven) and possibly Windows 7 x32. Their cables (including the serial port to PC cable) were and are still available on Amazon or eBay, they aren't especially hard to find, but they are pricy.. probably because they are very strong and hardy cables meant to handle a lot of shop abuse.

The communications protocol to retrieve sensor values from the Logic Modules seems fairly well know by a lot of software available on the Internet, so data logging using a simple USB cable even on a Windows 7 PC is not uncommon. A DRB-II isn't really needed to create very sophisticated Windows Based Digital dashboard for old Chrysler vehicles.. just check YouTube.

The communications protocol to activate sensors and do other unconventional things rather than just "watch" the status of a vehicle is being discovered, and some of these generic tools already have the ability to do a few of them. But coverage will probably never be like a company like OTC could provide. The DRB-II is a very interesting part of history but might be frustrating to use to modern mechanics or people who have used a modern computer. It certainly takes a lot of patience, the right ancient manuscripts and a good deal of luck to get very far.

[wowzer]

do the manuals detail how to put the drb-ii into "hyperspeed" mode or any of the actual communication protocols used to test sensors?

[jwillis84]

do the manuals detail how to put the drb-ii into "hyperspeed" mode or any of the actual communication protocols used to test sensors?

I sincerely wished that it did.

But no.

There are no protocol descriptions or instructions for putting the DRB-II into hyperspeed mode, its just mentioned that is what can be done by the MDS to the DRB-II.

The directions and screen shots all pertain to the MDS blocky "MS-DOS" looking interface.

It stresses the DRB-II must be loaded with the MDS cartridge.

Everything after that is performed on the keyboard of the MDS IBM Computer.

I would liken it to the DRB-II being used as a "car" > "Modem" for communicating with the vehicle by the MDS.

If you were around back then and remember 3 Mhz PC computers, MSDOS programs were not well documented, if at all. Everything was still typeset using a physical typewriter for the most part. So reams of program code were not routinely printed out, that was a rare event. Application Programming Interfaces were still being called "Binary Interfaces".. frankly they didn't even know "how" to write a Manual for software.. it was all very experimental.

The MDS manual has a set of "drawings" of the other books available for the MDS System.. one even has the old original IBM PC-DOS logo on the cover.. so they didn't even bother to try and rewrite the guide tailored for the system.. they just threw in an IBM manual as part of the set.

The diagrams look kind of "hand drafted" like someone laid them out on an architects drafting board.. not in a computer.. so its sometimes hard to recognize what they represent in real life. A Cartoonist would have gotten closer to the quality of a graphic designer person or an illustrative "Artist".

Adobe Illustrator and even PageMaker were many years [into] the future.. so all is very old school

You have to put your coal miner hat on and go play Indiana Jones to tease out fragments of meaning from a lot of this.

Since it appears the MDS had a "hard drive" but not for certain, but it did have CDROM drives (so they were around) the ideal thing to do would be to examine the binary code on the hard disk to discern meaning. Copyright might prevent all but for an academic interest.

Most companies from that era still around threw away source code listings if they ever had them.. they often outsourced or paid someone else on commission to write the software.. my strong "guess" would be it was the original Minnesota company OTC (or SPX) who wrote and then maintained the software on the cartridges and for the DRB-II. The MDS was put together by Microsoft using an IBM PC.. so they probably just communicated with the DRB-II. OTC according to wikipedia was a specialized tool company from almost the turn of the last century, SPX specialized in software.. both were acquired after the 21st Century by Bosch (a German company).

The design of "Scanner" boxes and methods has changed several times in the last 30 years so the new people probably have no recollection about how the old system worked. So ultimately someone who retired from OTC or SPX probably knows all the answers.. or knew them.

Would that I could; it would be fun to go to Minnesota and interview some of the people originally involved in the development.. but its been probably close to 30 years since that project started.. they might not even still be alive.

We're left with these software relics from the past.. that have more historical value than other value today.

[jwillis84]

Got another Manual today, from 1993 it is apparently a "later" revision of the first manual I had. This one describes the DRB-3 (DRB-III) but also refers to the DRB-II. The DRB-II requires the MDS-Scan-Tool Cartridge to be inserted before connecting it to the MDS Computer so that it can be reprogrammed and put into Data Recorder mode by the MDS Computer. The DRB-III (DRB3) does not require this cartridge to go into data recorder mode.

It also describes the MDS Computer as an IBM 386 PS/2 Computer with a 19 inch monitor, a 3.5 inch floppy drive, internal hard drive, modem, and telephone handset. A few more drawings. A customer service mention about the [OTC Division, SPX Corporation, on Eisenhower Drive, Owatonna, MN 55060]

An interesting chapter that says " The MDS has a function that allows the Scan Tool to be used as a Data Recorder when test driving a vehicle. This prepares the Scan Tool for recording vehicle information. " So I guess it could be used away from the MDS after preparation.

Also " the Scan Tool provides the following when used with the MDS [ Storage of information in a special RAM cartridge (DRB-II) or internally in a DRB-III for up to 96 hours so that the Scan Tool can be used as a Data Recorder ]

NOTE: the manual also says the DRB-III draws 1.5 amps when connected to the vehicle so it says "don't leave it connected when not in use" after 96 hours.. the original vehicle battery might be very low.

So if you have an MDS to reprogram the DRB-II and one of these special MDS "RAM cartridges" to store the data I guess it could be used as a data recorder. That is more than I had expected based on previous research.

Still no information on protocols or procedures outside of pressing keys on an MDS while the DRB-II is hooked up.

The two MDS manuals I've collected say (Technician Reference Guide for Release 5/15/1992) and (MDS Users Guide 1993) they have the same content and layout, one is simply newer and discusses both the DRB-II and the newer DRB-III the older one only discusses the DRB-II. But otherwise they have the same content.

[jwillis84]

Just a side note, but I've also started collecting OTC manuals for the 2000/4000 series of Scan Tools. The difference in the documentation from the DRB-II and the MDS is stunning.

The manuals are thick, thin pages, and very detailed. They describe hooking the devices up to PCs extensively and not only a specific PC, but generically. The service address for OTC in MN is the same as in the MDS manuals for these devices. I'm only at the tip of the iceberg on these but it seems they are much easier to work with in the modern age.

Unfortunately a sign of those times is they talk a lot about VT100 terminals and ZModem or XModem for transfering files back and forth with the OTC "Tester". Antique just jumps into my mind.

[jwillis84]

The answer for the DRB-II and DRB-III and the Co-Pilot devices is "yes" they can all data log.

The DRB-II procedure for setting up to data log is in the :

Mopar Diagnostic System: Technician Reference Guide for Release 9
Chapter 4. Data Recorder

This manual is for the Computer workstation with the MDS Software. It can be used with a special MDS Cartridge inserted into the DRB-II to "turn the DRB-II from a Diagnostic Tool into a Data Recorder". When the DRB-II is in Data Recorder mode it streams data from the engine into the DRB-II "eight times faster than the DRB-II with a normal Service Cartridge".

This manual goes into the procedure in depth.

Essentially you have a default method to setup the DRB-II in data record mode and a custom method to setup the DRB-II in data record mode.

The default method is to insert the MDS Cartridge into the DRB-II and connect it to the MDS Computer.

1. Then call up "Quick Setup to Record" on the MDS Computer, it will automatically download a (sensor and switch list) called a Template into the DRB-II and beep when finished.
2. Then disconnect the DRB-II from the MDS Computer and connect it to the vehicle, when it powers up it will say "MDS Data Recorder"
3. Press F2 to begin
4. Menu options will be [1] record data, [2] move data to mds, [3] reconfigure DRB-II

Basically that is all you can do in data recorder mode, you can manually trigger a recording that will last 45 seconds and be stored as an "event" or you can upload the event to the mds computer when its back at the garage, or you can command the DRB-II to reconfigure itself as a diagnostic tool by downloading its old personality from the mds computer that was stored on the mds computer when it became a data recorder.

Once the event is on the MDS computer it can be graphed, printed or saved to the hard drive or a floppy disk... or uploaded to chrysler.

The custom method is mostly about creating a Template that defines the specific list of sensors and switches a data record event will capture. This will then be uploaded to the DRB-II when placing it into data recorder mode. This method also allows for automatic triggers that will begin an event if your so lucky as to know what your looking for.

The "mode" of the DRB-II as a "diagnostic tool" or a "data recorder" is determined by what's on the DRB-II screen when it powers up.

Make a Selection - means its in "diagnostic tool" mode
MDS Data Recorder - means its in "data recorder" mode

The DRB-II was a relatively slow computer by todays standards. It ran at 4 MHz according to the DRB-II Operators Manual. It also did not "multitask" well it did one thing at a time and did not save data collected in between task switching. So it basically only ran one program at a time. Long term storage was limited and storing event data for 96 hours was expensive. So capturing data and getting it back to a computer where it could be downloaded was hard.

Since the Templates originated on the MDS computer and were downloaded to a DRB-II. And because the MDS not only put the DRB-II into data recorder mode and then put the DRB-II back into diagnostic tool mode.. I don't really see a method of using the DRB-II without an MDS Computer system.

The DRB-II can be used to "freeze frame" or "hold" current monitored sensor values or switch statues while it is being used as a diagnostic tool with a normal service cartridge. And while this is after the serial interface has been commanded into "high speed" or "parameter mode", there is not a way to download the values to a PC easily. The display can be made to "echo the DRB-II screen to the RS-232 serial port to any attached computer listening for communications.. but the fundamental problem "is" while it is doing that.. it is pseudo-multitasking switching from one task to another, collecting data, updating the screen, updating the remotely attached PC computer over the serial port.

The longer the list of sensor and switch values on the current DRB-II screen displayed.. the longer it takes to loop all the way around and collect and then update their display. The end result is everything runs really slow and data is missed and doesn't have much fine grained resolution. A problem could occur and be completely missed. Or continue to occur and the resolution of the collected data so coarse it couldn't be recognized.

The Turbo Dodge users have been modifying engine computer firmware for sometime and come up with some modern computer programs running on laptop or android phones that connect to the SCI port the DRB-II normally connects to. Using a FTDI serial to usb cable they have been able to figure out some of the DRB-II commands. At a minimum the ones for going into "high speed" "parameter mode" and running much faster and running modern operating systems that do multitasking very well.. they have mastered data recording with chrysler vehicles and produced customizable realtime displays, which also data log. They are creating their own "templates" which list the memory locations of interest to monitor and keep expanding the programs capabilities.

I love learning more and more about the DRB-II but if you need a data logger for a practical purpose, check out MPTune and MPScan, they are the best way forward.

But if you know someone with a Mopar Diagnostic System computer in their garage.. I'd love to hear about it.

For clarity, here is an MDS Cartridge I picked up in a bundle of cartridges. I didn't know what it was at the time, but finally do.

Fig 1. Mopar Diagnostic Cartridge for the DRB-II



The DRB-III has a patent application that describes these modes in very similar terms, however it is much more robust in that it can be put into any of these modes without an MDS and and select different Templates for data logging without major reconfiguring of the device.

Hand held automotive diagnostic service tool - Patent link

"Data Logger

Another important feature of the hand held unit is its ability to function as a data logger... By monitoring vehicle parameters on a real time basis, the technician can obtain a better understanding of the conditions which may be causing the problem.


To operate the hand held unit as a data logger, the technician selects the data logging option from the menu. With the hand held unit connected to the car via the communication ink, all of the parameters which were available for measurement during measurement and testing procedures are also available for logging."