DRB III Reverse Engineering Project

[Mumbles05]

https://www.amazon.com/dp/B07D21GG6J/

I thought it was made by OTC and was later bought out by bosch who was providing repairs service for them up until a couple years ago.
The switchbox for the sensors just handles cycling between the two sensors or selecting a single one. If you look back on the first page when I replied about the screen, it says it uses a 16 MHz Motorola 68332 which is a Motorola 68000-based CPU core.I don't believe the SC designation is of any consequence; the core architecture is still part of the same family. PEP is an abbreviation for "peripheral expansion port" and it was intended to host multiple different modules, though only one was ever made to fit there, so it will very likely be a generic protocol. It would have been way more difficult to develop and maintain a proprietary protocol. The PEP module itself accommodates many different attachments, so again, it will likely be some standard protocol.

I strongly suspect those sensors are just a rebranded off the shelf inclinometer. There was no reason they would have tried to develop their own when it had such a limited application to their vehicle line. The best route to pursue would be hunting down the manuals for existing similar sensors on the market, that explain how to add them to a system and communicate with them, and try to use the same commands to initiate the Viper inclinometer. Otherwise you will need to get a logic probe/analyzer and record the traffic from the DRB 3 to the sensor.

Going that route, you'll need a logic analyzer, an actual DRB 3, the switch box with sensors and the knowledge on how to interpret the data you collect.
There is no sense in jumping off the deep end by trying to dig that far into the DRB 3 when all signs point to a standard communications protocol being used to drive a rebranded off the shelf inclinometer. (SPI I2C UART RS-232)

I did receive that single senor I ordered but haven't had the time to look into it more. I had a bunch of equipment become available so I've been working my butt off to sell some stuff to keep my head above water with the new stuff coming in; had 15 used micropod 2's come in just this week. The holidays had me a bit busy as well. I might get some more time later to assist you but you are the only one with any relevant knowledge or experience in this area. I am also not in a position to buy additional hardware like a logic analyzer for investigating this.

 

[MoparMap]

Yeah, I guess the more I think about it the more it seems like it should just be RS232. The level shifter chip is in there and the port "looks" like a standard 9 pin serial, so it would make sense to actually operate like one (aside from the multiplexing part and power). As far as I can guess it seems like there should only be three messages the DRB III uses too. There would be one to zero one axis, one to zero another, and one to read back an axis (probably another one for the other axis, but I don't think the DRB III actually uses it). I haven't seen any consistent message setup on the few serial inclinometers I've found, but I guess that's still somewhere to start. Finding someone with a DRB III, sensors, and a signal analyzer does seem to be the issue, though that would probably be the fastest way to get an answer. I need to see if there is a generic serial "ping" command or something so I can at least verify I have the right baud rate. I've tried screening into a sensor with my Raspberry Pi at some typical baud values, but I don't see any feedback. I'm not sure that just doing that would actually give me any feedback though since that's more trying to SSH in than just send a command.

I did hear back from some contacts, but not quite the detail I'm looking for yet. They did say that they tested the sensors against an alignment machine and found that they were within 3%, so at least they aren't as critical as some have made them out to be in the past. Though they are about the only way to check rear caster as the "normal" way to measure that is to turn the wheels 20 degrees either direction. Not sure that rear caster is as important, but wouldn't hurt to be able to measure it to at least keep it consistent side to side.

 

[MoparMap]

I think I have an idea of the baud rate after reading up on some RS232 info and looking at my pictures again. On the sensor itself there is a large blue component that I think is somehow related to the clock generator. It doesn't look like a typical oscillator, but based on the part designation on the board (X1), I'm guessing it's not a capacitor. It appears to have 1.84G printed on it. From what I was reading, the baud rate is typically the clock rate divided by 16. 1.84 divided by 16 is 0.115. Moving some decimals around I'm guessing that's probably 115,200 baud. Will see about putting the scope on a sensor again this weekend to see if I can see any signal fluctuation at power on. I'm thinking it should make some kind of "noise" at power up if there is any type of boot sequence in it.

 

[Mumbles05]

I think I have an idea of the baud rate after reading up on some RS232 info and looking at my pictures again. On the sensor itself there is a large blue component that I think is somehow related to the clock generator. It doesn't look like a typical oscillator, but based on the part designation on the board (X1), I'm guessing it's not a capacitor. It appears to have 1.84G printed on it. From what I was reading, the baud rate is typically the clock rate divided by 16. 1.84 divided by 16 is 0.115. Moving some decimals around I'm guessing that's probably 115,200 baud. Will see about putting the scope on a sensor again this weekend to see if I can see any signal fluctuation at power on. I'm thinking it should make some kind of "noise" at power up if there is any type of boot sequence in it.

I wish I could be of more help. I'm not too keen on sending my DRB 3 through an unnecessary tumble dry cycle, also known as the mail. I don't own the switchbox to go with my sensor and I don't own a Mixed signal oscilloscope or logic analyzer. I wouldn't know what to do with them if they were available to me either. If you want to formulate the experiment and mail me the appropriate hardware needed to use with my DRB 3, I'd be happy to help but it's not practicle for me to buy that stuff and learn the ins and outs of hardware communications protocols at this time. I'll read up on it in my spare time but it would take me awhile to catch up to what you already know so I'm not sure how helpful I would be.

If you find yourself in the market for an oscilloscope, I'd suggest this one. It's well reviewed online and includes the protocol decoder.
https://www.amazon.com/dp/B0771N1ZF9

 

[MoparMap]

No worries. I'm not really in a hurry to do it, it's more just a side project and I tend to get really focused on stuff and dig in further than I probably need and get carried away. CTC actually rents the real deal DRB III, $150 for 3 days if I was super desperate. I really don't have the equipment to be doing this the way I want either, but I have enough to be dangerous. I have a little cheapo digital oscilloscope my parents got me for Christmas several years back. Doesn't do much aside from displaying, but I can always screenshot it and do the "math" the long way. I think I more just like the challenge of trying to figure this out because it seems like a "simple" enough problem and if I can get the commands sorted out I have the parts to build a sensor reader already on hand. I've mostly just been posting everything I come across as a kind of journal to keep the info in one place and in case anyone else wants to follow along and has any ideas.

From what I found online OTC is the one now owned by Bosch, which I think got their start with GM tools. It looks like the Miller line of Dodge tools is really just a named they badge on any tool that Mopar had made for dealers. If you go to the current Mopar tool site and the contact tab it actually shows that the correspondence is care of Snap-On. The CTC website claims they developed the original DRB III and the emulator afterwords. I've emailed them, but haven't heard anything back yet. Was hoping I could get a datasheet on the inclinometer from them, but not holding my breath. Don't suppose you have a contact there from all the troubleshooting and work you've done regarding the DRB III?

 

[Mumbles05]

No worries. I'm not really in a hurry to do it, it's more just a side project and I tend to get really focused on stuff and dig in further than I probably need and get carried away. CTC actually rents the real deal DRB III, $150 for 3 days if I was super desperate. I really don't have the equipment to be doing this the way I want either, but I have enough to be dangerous. I have a little cheapo digital oscilloscope my parents got me for Christmas several years back. Doesn't do much aside from displaying, but I can always screenshot it and do the "math" the long way. I think I more just like the challenge of trying to figure this out because it seems like a "simple" enough problem and if I can get the commands sorted out I have the parts to build a sensor reader already on hand. I've mostly just been posting everything I come across as a kind of journal to keep the info in one place and in case anyone else wants to follow along and has any ideas.

From what I found online OTC is the one now owned by Bosch, which I think got their start with GM tools. It looks like the Miller line of Dodge tools is really just a named they badge on any tool that Mopar had made for dealers. If you go to the current Mopar tool site and the contact tab it actually shows that the correspondence is care of Snap-On. The CTC website claims they developed the original DRB III and the emulator afterwords. I've emailed them, but haven't heard anything back yet. Was hoping I could get a datasheet on the inclinometer from them, but not holding my breath. Don't suppose you have a contact there from all the troubleshooting and work you've done regarding the DRB III?

I wasn't even aware CTC had anything to do with it. You should really give the patents a look. Chrysler has a bunch of them that may be helpful.
https://patents.google.com/?assignee=Chrysler+Motors+Corp&page=2

 

[MoparMap]

So I think I found the *** of gold at the end of the rainbow, the only problem is it's currently locked in a box I can't open. I'm pretty sure I found the project lead that worked on the development of the DRB II and III. No surprise he's the current president of CTC. Now the issue is trying to either find someone that knows him or an email address he might respond to. Any former Chrysler engineers out there that know the guy? His name is Dan Marus. Shows he worked at Chrysler developing diagnostic tools from 83-91 and then started CTC after that and still works there.

 

[Mumbles05]

So I think I found the *** of gold at the end of the rainbow, the only problem is it's currently locked in a box I can't open. I'm pretty sure I found the project lead that worked on the development of the DRB II and III. No surprise he's the current president of CTC. Now the issue is trying to either find someone that knows him or an email address he might respond to. Any former Chrysler engineers out there that know the guy? His name is Dan Marus. Shows he worked at Chrysler developing diagnostic tools from 83-91 and then started CTC after that and still works there.

That is great. Be sure to mention the patents for the DRB 3 have expired so he wouldn't be doing anything wrong by discussing it with you.

https://patents.google.com/patent/US6181992B1/
2020-01-05 Application status is Expired - Lifetime

https://patents.google.com/patent/US5541840A/
2020-01-05 Application status is Expired - Lifetime

 

[MoparMap]

Those are interesting. The circuit "schematics" are novel to look at, even if they don't spell out actual circuitry but more at a data level.

I messed with the inclinometers some more this past weekend, but I'm coming up empty. It looks like they don't run any kind of OS or bootloader, which doesn't entirely surprise me. The Tx line just goes high and stays there as soon as they power on. There doesn't appear to be any kind of initial messages sent for stuff like serial number or calibration values or anything. I did stumble on an idea I didn't think of before though. My little oscilloscope isn't great for trying to capture communication style signals as they happen. It really doesn't have the power or the settings. However, it seems you can set up a Raspberry Pi as a signal analyzer, so going to see about trying that at some point this week. I'll need a level shifter as the Pi has very limited voltage input levels, but that saves me the cost of a real logic analyzer. I might test it out on the connection between the VCI pod and the car and see how it works. If it actually gives me something useful I think I'd have a way to see the signals between the inclinometer and the DRB III with tools already at my disposal.

 

[MoparMap]

So to stray a bit from the topic again, I think I figured out how the TPMS module is supposed to talk to the system. Reading back over the communication protocols, I think the TPMS module uses the ISO 9141 (also known as K-Line) standard. One of the links I posted earlier discusses how it works and mentions it can be combined with the SCI Tx wire. The PCM runs on SCI and uses 5 volts to communicate, but 9141 uses 12 volts. 9141 is also single wire, so it doesn't need a separate transmit and receive.

Still need to scope the output of the emulator and see what it's doing, but I wonder if the VCI pod doesn't have the circuitry to provide the 12V necessary for the TPMS module to communicate.

 

[Mumbles05]

So to stray a bit from the topic again, I think I figured out how the TPMS module is supposed to talk to the system. Reading back over the communication protocols, I think the TPMS module uses the ISO 9141 (also known as K-Line) standard. One of the links I posted earlier discusses how it works and mentions it can be combined with the SCI Tx wire. The PCM runs on SCI and uses 5 volts to communicate, but 9141 uses 12 volts. 9141 is also single wire, so it doesn't need a separate transmit and receive.

Still need to scope the output of the emulator and see what it's doing, but I wonder if the VCI pod doesn't have the circuitry to provide the 12V necessary for the TPMS module to communicate.

I need to open up one of my original ones in a couple days to resolder the reset button, so I'll snap some pictures of it when I do. The OBD 2 port supplies it 12v power so it's reasonable to assume it would have a way to send 12v out again for 9141.
If you have your pod connected via usb, you can actually navigate to the debug menu and see the voltages on the various lines.

http://172.22.22.22/webconfig/sysdebug.bsp

 

[MoparMap]

Yeah, once I thought about it some more I realized that it would have easy access to 12v, so that didn't make as much sense. I'll have to try that debug menu.

I do wonder if maybe it's not on the right pins though. 9141 typically lives on pin 7 of the diagnostic connector I believe. Don't remember what the PCM SCI line is on, but it might be different, so there's a chance it's just not talking on the right pin for the module to hear. Should be easy enough to check.

 

[Steve-Indy]

Just happened to be looking at DLC:

#2....PCI

#6...SCI Receive

#7...SCI Transmit

 

[MoparMap]

Lol, one more theory out the window potentially. Just need to try to log some communication at this point and see what happens.

 

[DJ'sviper]

You lost me at DRB III

 

[Mumbles05]

Behold, the holy grail! CDA 6 offline. Cost me an arm and a leg but I finally got my hands on it.

You must be registered for see images attach

 

[MoparMap]

Sweet! Certainly helpful for the newer cars I imagine. When did the CDA series start? Was that the first CAN based cars? 5 at least doesn't appear to do much for the gen 3, though I haven't toyed with it all that much. Was hoping to be able to do some communication logging without having to build something inline, though I think I at least know what I'm looking for now. Partially waiting on parts (12v to 3.3v converter so my Raspberry Pi can see the signals) and partially just haven't had a lot of incentive to dig into in. The cold weather around here also makes sitting in a garage with a computer a little less pleasant.

 

[Mumbles05]

Sweet! Certainly helpful for the newer cars I imagine. When did the CDA series start? Was that the first CAN based cars? 5 at least doesn't appear to do much for the gen 3, though I haven't toyed with it all that much. Was hoping to be able to do some communication logging without having to build something inline, though I think I at least know what I'm looking for now. Partially waiting on parts (12v to 3.3v converter so my Raspberry Pi can see the signals) and partially just haven't had a lot of incentive to dig into in. The cold weather around here also makes sitting in a garage with a computer a little less pleasant.

Well, based on the numbering I would assume it started at CDA 1 but the lowest version number I have seen or heard about was CDA 3. I have no idea what form it was in prior to that but CDA 3 as I knew it was software that ran on the starscan. There may have been a desktop version of 3 but I haven't seen it. There is no demand for it either so that is probably lost to history. I have only seen CDA cover CAN bus vehicles. Prior to that, the iBox II+ was part of what they used. I know very little about that and nothing about what software was used in conjunction with it.

No worries about the progress with the other stuff, I've got my hands full with other things at the moment myself. I did get some more pictures of that factory tool that used the vci pod. It was referred to as the blue brick from what I've been told. I didn't get a complete one, I just got the pictures of it in it's native form.

You must be registered for see images attach

You must be registered for see images attach

 

[MoparMap]

Very interesting. Doesn't look all that pleasant to use with that tiny keyboard, lol.

The more I think about it the more I can understand why "generic" tire tools might work with the Viper module. It appears to use an established standard communication protocol on standard wiring. I'm thinking you could probably even use a generic OBD II dongle and a laptop if you know the right commands. From my understanding it works like old modems, you just have to know what to send. Haven't actually tried out the little dongle I have yet.

No luck hearing back from the CTC guy yet or finding anyone else that knows him. I'm thinking at this point it's just going to come down to getting my hands on a real DRB III to try to record the signals to the inclinometers. That or open the sensors up and try to rewire them to connect directly to the sensor and not the controller inside. Guessing the sensors themselves are normal voltage or current output like I was expecting and the controller inside just translates that.

 

[Mumbles05]

I haven't forgotten about you. Had my hands full recently (see below). Sounds like you have a gameplan though. It'll just take time and money as all things do.
The computer part of that blue brick is touch screen so I doubt anyone had to fiddle with the keyboard. It has some heft to it though so that would have been annoying. Had to trade my other arm and leg in to buy microsoldering equipment. The price difference between the 'toy' version and quality equipment is staggering. A nice stereomicroscope cost me close to a grand.

You must be registered for see images attach

You must be registered for see images attach

You must be registered for see images attach

 

[MoparMap]

Wow, that is quite the collection. And yeah, I know what you mean about good equipment. I've had enough cheap tools that barely even make it through a single job. I remember buying a power steering pulley puller from Harbor Freight because I was tired of renting one every weekend when I was dealing with my power steering issues and the first time I used it it just bent and didn't even pull the pulley off.

I think the next big electronics tool I want is a desoldering gun. I have the little spring pump version, but it's hard to run it and an iron at the same time. Saw someone using a heater desoldering gun and that instantly went on my list. It's not like I even work on electronics that often, but that would be a major quality of life improvement.

 

[MoparMap]

So there has been some new life breathed into this little project of mine. I had to pick up a real DRB III for some tuning stuff with my car, so I now have one in my own hands to play with. Planning to get things hooked up with my angle sensors to see if I can intercept the communications between the two and figure out what is going on. I'm hoping my Raspberry Pi is going to work for this, but will have to see. If nothing else I'm hoping I can see some life on the communication lines via an oscilloscope, so maybe I can pause and record that data and interpret it.

 

[MoparMap]

Progress at last! I managed to intercept the command the DRB III is sending to the sensors and can replicate sending that command from a PC terminal program and get a response back. Now I have to decode exactly what that response is saying. I have an idea right now, but haven't checked it against the readout on the DRB III to see if my calculations are correct.

For those who care about the geeky details, the DRB III sends a 6 byte command to the sensor and the sensor responds with 6 bytes as well. The first 3 bytes of the response don't appear to change, regardless of sensor orientation, so it looks like I only have to figure out the last 3 bytes of the message. When changing the orientation of the sensor 90 degrees at a time, the first of those three bytes changes from 0-255 in increments of 64, so it looks like it's splitting 360 degrees into 8 bit resolution basically. My suspicion is that the second two bytes might be minutes and seconds of angle, each in 8 bit resolution as well. It's a bit odd because the readout on the DRB III is only 0.1 degree precision, so going down to seconds of angle is almost irrelevant, but it makes some sense in my head.

My plan going forward is to use a digital angle finder I have to hold the sensor at some set angles and see what the readout on the DRB III is and what message the sensor is sending back. If my math doesn't work out at the very least I have an 8 bit resolution angle value. Not great since it would be more than a degree per step though.

 

[deyan]

Were you able to make any progress on this?

 

[MoparMap]

I haven't really touched it much since then. Since I bought an actual DRB III this hasn't been as big of a deal for me, but if someone has sensors and is really interested in a small program that could talk to them, I could probably write something up with what I suspect is happening. The other thing I need to do is track down the connectors the sensors use as I talk to them directly and not necessarily through the breakout box that comes with them. That just allows you to use two at once (kinda, it really just keeps swapping back and forth between the two) and might have some level shifting in it, but it's one more step to figure out and not necessarily as important, though it does get you to a DB9 style connector. I don't think it's necessarily pin compatible with a computer though because of the extra wires used for the multiplexing of the sensors.

So the short version is I know what command the DRB sends to the sensors to make them read, I just haven't taken the time to try to decode the reading to confirm the accuracy. Maybe I need to build a spreadsheet calculator and try some different values to work out how it's splitting up the angle. Or I just need to take a whole bunch of measurements and put them in a table with their respective HEX values and see what I can figure out. It's reminiscent of CAN style communication, but I'm not really super skilled with that, I just know about it from what I've seen at work. I'm a mechanical guy, so it's not what I do day to day, but I have some knowledge of how it works at least.

 

[deyan]

That would be great, if it's something truly do able! I just acquired the incline meters with the miller toolkit, and would like love to use them, but I don't have access to a drb

 

[MoparMap]

Let me see what I can dig up again. I have a spare Raspberry Pi that would probably work fairly well as a cheap way to do it, but the caveat that would be you'd need a separate screen, which is a bit cumbersome. Might be able to do something in Windows that would work on a laptop though. I think I still have some screenshots I took somewhere when I was doing the comms test and getting some results back, so hopefully I can remember what command I need to send, lol.

 

[deyan]

Don't have much experience with Raspberry Pi, but it would be worth it if this can be made to work! Wish I could be more of a help!

I am currently trying to create lower control arm camber/caster shim plates, since non exist for the 2nd gens. Just got V1, and it's pretty good fit, doing another round with some improvements, and then I am hoping to release the templates to the community if all checks out.

 

[MoparMap]

Are those like the comp coupe shims or does the gen 2 use a different alignment mechanism? I bought an incomplete set of comp coupe ones for my gen 3, but I had at least one of each variation, so I made up a drawing of them in case I ever wanted to try to get the rest made. Someone already came out with an updated set in better material, but I have a hard time swallowing the cost for something I rarely ever use. I just like the idea of them because I can swap between street and track really easily since I know the difference between the plates. Basically just have to toe it up after a swap and I'm ready to go, so realistically I only need two sets, unless I feel like playing with the settings.

All that said, I did mess with the inclinometers a little more just now. Seems like they are just a linear output as far as I can tell. I took some measurements at ~15 degree increments and the math appears to hold. The toughest part is more just figuring out how I would want to interface with them from a program standpoint. The main issue is that the inclinometer splitter box takes 12v power, so it's not quite as straightforward as a "plug it into a laptop", even though it's already got a handy DB9 plug on it. The sensors themselves I believe are just 5v, but I'd have to do some more digging on serial ports to see if they are always powered or not. I know I have a bluetooth dongle on a Megasquirt setup in my 67 Dart that runs purely off of the serial port for power, but I don't recall if the Megasquirt was uniquely designed with that in mind or if that's typical.

The "simple" answer for either situation is just a special plug that breaks out signal and power into separate connectors. The power could run off of a cigarette lighter (or any other handy 12v source) and the signal could go into a traditional DB9 connector. That's basically what I'm doing on my test bench now, though just with bare wires at the moment. I guess if you plugged in at the sensor level you could split a plug into a USB for 5v power only and another plug for the signal. If I knew enough about electronics I'm guessing the whole thing could be run off a single USB plug (it does stand for universal serial bus after all), though I'm not as familiar with the differences between traditional RS232 and USB. May have to read up on that one some more and see what I can find out.

I found the parts to make a mating connector that would plug directly into the sensors, though haven't bought anything yet as I was still trying to figure out what level I wanted to hook into the system. I prefer the idea of being able to keep the splitter box so you could plug into both sensors at once and the plug is a standard one you can find anywhere, but the thought of being able to run everything off a single USB plug is kind of tempting as well.

 

[deyan]

Yeah, it's basically the same, it's just I wanted something that fits tighter in the Gen 2, the Gen 3 shims are shorter. My car is purely a track car, so it makes it much easier to setup with the shims. I also quickly realized I need different width shims front to rear.... probably why no one makes them for the Gen

Thanks for all the work on this, sounds promising!! The shims do take away the need to measure rear caster and front is pretty straightforward, but it would still be cool to get those sensors working