DRB III Reverse Engineering Project

[MoparMap]

So the other day I picked up a Miller 6990 kit, which has the control arm bushing remover/installer, the caster fixtures (for gen 2 unfortunately), and the inclinometers and switchbox used by the DRB III to read caster. I don't have a DRB III, but I have some background in sensors as I helped to set up the test department where I work and deal with sensors and DAQ equipment on and off. I figured the sensors were probably typical 0-5V output or 4-20 mA like most lab style sensors you can find for data acquisition systems. My thought was I would plumb the signals into a simple microcontroller like an Arduino or even just a volt meter and figure out what angle corresponds to what output. Well, I was wrong. These sensors are a little more complicated than I was expecting, so I'm wondering if anyone out there has any background knowledge of the DRB III tool.

I took the switchbox and sensors apart and pulled the numbers off of all the chips I could see inside and have been trying to trace the wiring to get an idea of what goes to what. As best I can tell and guess, the switchbox itself outputs an RS232 signal to the DRB III. That in and of itself would be easy enough to read with most microcontrollers. I think the DRB also supplies 12V to the switchbox over the cable, which is not exactly in the RS232 standard pinout, but makes some sense. I haven't tried hooking it up to anything to try to intercept data just yet, so I don't know if the sensor just constantly outputs data without being asked or if it will require a request for data before it sends. That is the big question I have right now I'm hoping someone might know.

The sensors themselves are also quite a bit more complex that I was originally expecting. While I think at their very base level they are probably a simpler output, inside the aluminum box is a sensor on a PCB with a microcontroller (coincidentally the only chip I can't find a datasheet for). The PCB does have the wire hookups clearly marked as RX, TX, +, and - though, so guessing it is also outputting something like RS232 serial data. I would rather not remove the sensor from the board, even if that may be the easiest way to do what I want.

So long story short, any electrical engineers out there that want to help out in trying to reverse engineer the setup? Or does anyone have a lot of in depth knowledge of how the DRB III communicates with the external sensors? If I can figure out how these sensors talk it would be easy enough to build a small box that would just be a live readout for them to let anyone use them to measure caster without needing the $3000 DRB III. The cheaper DRB III emulator isn't an option as it can't talk to the external sensors, it's just software. If all else fails I could always just get some generic inclinometers and find a way to attach them to the caster brackets, but this seemed like a novel enough side project and the parts are reasonably available.

Some pictures inside the switchbox and the sensors themselves:

Switchbox:

You must be registered for see images attach

Inside the sensor:

You must be registered for see images attach

Other side of the sensor board when removed from the case:

You must be registered for see images attach

 

[MoparMap]

I did find some interesting videos on YouTube the other day. They were the original Chrysler training videos when the DRB III was released and walked through what all it did and how to use it. They even had a very short section on these inclinometers, though it didn't say all that much other than "powered serial port". Did a little more digging into that and it looks like there is a standard pinout for RS-232 that supplies power (12V typically), so at least some precedent there. Also found a guy that was doing WireShark data dumps on the DRB III emulator that runs on a WiTech VCI Pod. The emulator still shows a menu option for the PEP module, so thinking I might have a chance and seeing what command is sent when turning on the inclinometer if I ever get a VCI Pod setup, which is certainly easier to come by than a real physical DRB III.

 

[MoparMap]

So the circuit in the switchbox appears to be simple enough from what I can guess. It appears to be a fairly straightforward multiplexer and level shifter. The SP233ACT chip at the top right converts an RS232 signal to 5V logic (the level shifter part), so the DRB III appears to deal in RS232 and the inclinometers themselves only deal in 5V. The small chip on the far left is a voltage regulator to take what I presume is 12V in from the DRB down to 5V to run all the chips in the switchbox and the sensors themselves. The top middle chip is a simple inverter, there are six channels in it, but only 2 are used. The last chip is a multiplexer, or more simply basically just a switch that flops which sensor you are talking to. So the Rx and Tx ports on the DB9 connector for the switchbox are your standard RS232 serial connections, and you've got 12V and ground coming in as well. The last wire is the signal that toggles which sensor you want output from. Here's a logic diagram I drew up based on the schematics:

You must be registered for see images attach

So at this point I'm pretty sure I understand how to wire up something to try to talk to the sensors, but the bigger question still looms for what signal I need to send the sensors and what their response will look like. T1 in and R1 out on the diagram go to the SP233ACT chip to convert from 5V to RS232 levels. Judging from the readout on a DRB III, I'm expecting a signed floating point number to come out of the sensors, so I have some idea what to expect there, but still in the dark for what I might need to send the sensors to request them to send that info back. At this point I may just hook things up and see if it constantly broadcasts.

 

[Mumbles05]

I don’t have accesses to anything to capture the signal nor do I have the sensor but I do have several DRB 3’s. I will try to upload some pictures of the PCB inside the PEP module later (assuming I am allowed) so that you can see what it’s connecting to inside the DRB 3. The guts of the DRB 3 are a lot more complex than you might imagine so there isn’t going to be an easy way to replicate that side of the hardware. That sensor plugs into the DRB 3 PEP module which itself plugs into the bottom board of a stack of 3 large PCBs and a 4th small one on top. I buy sell and repair Chrysler scan tools through eBay mostly so I’m familiar with the tools inside and out but I’m definitely not an electrical engineer so won’t be able to add much to the conversation in that respect. I do actually sell the VCI pod (real) with laptop setup running witech 17.04.27 and the “enhanced DRB 3 emulator” which was their later version of the emulator software that added support for the crossfire and sprinter vans, but I’m not yet familiar with the forum rules regarding buying/selling so I’ll hold off on anything regarding that until I check the forum rules. I’ve got ~6 of them out in the field though, including a viper shop in SoCal, so I know they work as they should but they do not support the inclinometer or other PEP accessories.

You must be registered for see images attach

 

[MoparMap]

Ah, very cool! I have a DRB III manual I've been reading through and watched some of the original training videos for the fun of it. That thing can do an awful lot of stuff, so I can understand that it's not simple by any means to reverse engineer the whole system. I think the individual PEP module stuff still seems like it would be relatively more straightforward though, assuming there isn't some wild code exchange between the DRB and PEP sensors. I found one guy online that was doing WireShark data dumps from the emulator as there was another group trying to do a more thorough reverse engineering and I don't think anything looked super complex, but then again I don't know what all was going on either.

 

[Mumbles05]

I do know the DRB 3 OS is “pSOS+” the + sign is part of the name. The pep tools programming is on the supercard 2 PCMCIA card. The PCMCIA card contains all of the software needed for the vehicles and functions it covers. When doing something that requires the supercard 2, the DRB 3 does a warm reboot and boots off of the card, running the programming contained on it in place of the software installed on the DRB 3. So, any reverse engineering/decompiling effort on the software side would be best focused there. The PCMCIA card is of the Linear type. The DRB 3 only appears to be compatible with Linear or SRAM card types. If you were to get your hands on something like the “Elan Memory Card Explorer” software, you could dump the contents of the card.

 

[MoparMap]

Interesting, I'll have to keep my eye out and see what comes up in the future. I'm still kinda surprised that the sensors were as complex as they were. I really figured they would just use "off the shelf" style lab sensors with typical voltage or amperage output. It seems a bit odd they would put a microcontroller in each sensor to convert data to a digital style output, but maybe they had their reasons for it. I guess you have to have a pretty good filtered power supply and sensitive circuitry to read that, but seems like it would be easier to built that into the DRB III instead of each sensor.

 

[Mumbles05]

Here are pictures of the front and back of the PEP PCB. I do not have the master tech issue pictured below that; just those two pictures.

You must be registered for see images attach

You must be registered for see images attach

You must be registered for see images attach

You must be registered for see images attach

 

[Mumbles05]

The patents also had some good information so are worth a read. The first 2 are for the DRB 3. The last one seems to be for the DRB 2 but may contain some additional useful info.

https://patents.google.com/patent/US6181992B1/

https://patents.google.com/patent/US5541840A/

https://patents.google.com/patent/US5278759A/en

 

[Mumbles05]

This is the top board in the DRB 3. This is the primary ‘CPU board’ and has the interface for the LCD, Keypad and Vehicle cable. A very small board not pictured sits on top of this and handles the DVOM functions.

You must be registered for see images attach

 

[Mumbles05]

This is the ‘mid board’ (2 variations of it side by side) and appears to handle the serial and GPIB communicates. It also has a fair amount of RAM and Memory on it. It sits directly below the main board and connects to it electrically via 3 risers.

You must be registered for see images attach

 

[Mumbles05]

This is the bottom board (2 variations of it side by side). The picture got cut off a bit. It sits below the ‘mid board’ and connects to it via risers. It has the PEP connector on it (Peripheral Expansion Port), the PCMCIA card slot and a variety of other important looking IC’s that I haven’t spent much time investigating.

I hope this helps. I can get more detailed pictures of specific components if needed. These pictures were taken awhile back so I may not have a particular hardware revision but I have a DRB 3 I can disassemble to photograph.

You must be registered for see images attach

 

[NVViperTech]

I think I still have that Master Tech booklet. I appreciate the update on this post. It would be great if the inclinometers could be used with the Enhanced DRB3 Emulator. Eventually my DRB3 will fail and I will need to have an alternate method for checking caster angles. I had no idea the DRB3 internals were so complicated. Please continue to update this post with any new information.

 

[MoparMap]

Thanks for all the pictures! I think the PEP ones are going to be the most interesting for me at the moment. I'll have to see if I can follow any of the traces from the "Inc/Exh" port and check out those chips. I still need to try to hook up to the inclinometers again with a basic shell interface or something and see if anything shows up. Saw an interesting video the other day about "reverse engineering" serial ports, so might have to dig into that some more and see what the sensors are doing. Seems pretty extravagant to think they are running even a highly stripped down Unix style OS, but you never know.

 

[Mumbles05]

Here is a link to the June 1996 Mastertech Video for the PEP module.
~38 min. This should cover the same info that was in the above pictured booklet, eliminating the need to track down a hard copy.
The section covering the gas analyzer and inclinometer starts at 24:05

"The DRB III becomes a display device when connected to the inclinometer through the powered serial port that is labeled INCL"
"Remember, the DRB III acts as a display device only. You must already have the 1996 Viper alignment tools."

Chrysler (US) - MasterTech - June 1996 - DRBIII Multifunction PEP Module

xc_hide_links_from_guests_guests_error_hide_media

 

[AviP]

I'll admit I understand zilch of what you guys are talking but am impressed with you guys taking up this challenge.

 

[Mumbles05]

I found a similar looking 2 axis inclinometer on ebay that had a RS232 wiring diagram.
You can use an open source terminal emulator like "Tera Term" it would be a good place to start for interfacing with the sensor via serial port.

Based on the fact that the DRB III functions only as a display and apparently has a "zeroing" function, my best guess is the same as yours, the sensor is most likely continuously broadcasting while powered and that zeroing function is probably just a power or ground interrupt signal to the PEP for the port it's all connected to.

I have to admit this is all a bit over my head. I did Chemical Engineering and only had an intro to C++ course and a numerical methods for engineers course using MATLAB. So I am a complete noob as far as programing. I've been meaning to get into Arduino to fill in that knowledge gap but haven't gotten around to it yet.

Oh, concerning the PEP menu option in the DRB 3 emulator, it just says "Not Available" if you actually select it.

https://www.ebay.com/itm/Tilt-Angle...RS232-RS485-TTL-Modbus-Optional-/292787013039

You must be registered for see images attach

 

[Mumbles05]

I'll admit I understand zilch of what you guys are talking but am impressed with you guys taking up this challenge.

Yeah, it always starts out as a small side project, trying to solve a problem and save a few dollars. The next thing you know you're a subject matter expert and own way more equipment than you ever thought possible.

You must be registered for see images attach

An acquaintance who was trying to program new key fobs for his 97 Jeep Grand Cherokee has gone full hoarder with the DRB III's. He was the one who provided me with the comparison pictures between hardware revisions.

You must be registered for see images attach

 

[MoparMap]

Wow, that's where they all went, lol.

 

[Mumbles05]

On a slightly unrelated note, I'd love some help working out a replacement solution for the LCD in the DRB 3. It was a specially designed screen used only with the DRB 3 and uses a 40 pin connector (IDE cable plug) for the screen. Nothing else the company made and nothing else I've seen online uses a 40 pin connector. I'd like to know the pinout of the connector and the type/communication protocol used so that an adapter could be found to use it with something else available on the market. 8/16 bit parallel is my best guess. These are the 2 different versions of the screen. I couldn't fix the orientation so they appear rotated 90 degrees clockwise.

You must be registered for see images attach

You must be registered for see images attach

 

[MoparMap]

Hmm, that's an interesting screen board. Looks like it's more a controller than just the display itself. I assume the display plugs in at that top ribbon cable? Random question, but have you got an idea how many lines the display is? I wonder if it's some kind of setup where each wire in the cable goes to a certain line of the display or something like that. Still seems a bit odd, but I'm not really that well versed in display technology.

On a different note, I played around with the sensor and control box on my bench some more tonight. Unfortunately to me it looks like it is waiting for some sort of "start" signal. I tried powering the control box and screening into it with a Raspberry Pi, but nothing was coming up by default. I also tried powering the sensor directly and putting a scope on the Tx line and it was just sitting high, not oscillating like I would expect if it was trying to send a serial style message. I'm guessing it's waiting for some kind of "go" signal on the Rx line before it transmits. That leads me to my next question. I know the inclinometers attach to the PEP module, but I was thinking you got to them via a different menu option than the PEP module functions. On the manual I have it says to select the "Inclinometer option" from the "DRB Standalone Menu". Sounds like this is outside of selecting the PEP module menu first. Does the enhanced emulator show this menu option by any chance? I'm guessing it's going to give the same response as the PEP module option, but if it's there could you try clicking it and seeing what it says? If we got lucky we could see if it tries to talk to the computer serial port or something. I'm guessing this is the "go" signal that the sensor is waiting for before broadcasting. That seems to be the next step I can think of.

 

[MoparMap]

So I got to thinking about this some more and did some general searching around to see what was out there. It looks like there are any number of serial based inclinometers available. The main thing with the few I have looked at though is that they all seem to wait for a "get" style command before returning any value, so it would seem that there is some "ask" command that needs to be figured out. Sniffing the communication between the DRB and the switchbox would probably be the most realistic way to do it, though I think some guess and check could also be an option with limited chance to break anything. An example sensor datasheet with serial/UART communication is here: https://www.leveldevelopments.com/w...cuments/LCP-45_Dual_Axis_Inclinometer_PCB.pdf. Toward the bottom they have a "control command" section with the commands that you can send the sensor for different settings and responses. It looks like some kind of "get" command is perhaps common to the sensors I've seen, though I don't know to what degree. The "best" way to handle this would be to look at the sensor itself closer and see if we can't find out something more about the chip(s) on it. I never had much luck finding anything about the large Motorola chip on it. This sensor looks quite a bit different than many of the IC style ones out there now though, so I suspect the sensor itself is probably a typical voltage/current output and the chip on the board is probably converting that to serial instead of building that all into a single IC. That makes things a little tougher as it would mean the IC is just a generic microcontroller that is likely programmable, so it may not have any kind of datasheet that would be useful.

Just some more musings as I've been thinking about things. I may try to find more example sensors and see what sort of communications they have. If there is a common bitrate or very similar commands it could give a place to start with things to try at least. I've got a spare Raspberry Pi setup with an RS232 level converter, so should be "easy" enough to do some testing at least.

 

[steve e]

Holly cow, just read through all of this space age stuff, not to high jack the post, does anyone know how to set the points on a 57 Chevy with a small block V8.

 

[MoparMap]

Holly cow, just read through all of this space age stuff, not to high jack the post, does anyone know how to set the points on a 57 Chevy with a small block V8.

If I remember right I think it involves a paper match from a matchbook stuffed between the points for gap

 

[Mumbles05]

You must be registered for see images attach

You must be registered for see images attach

I’m still alive and paying attention. Just got some hardware in that I’m tinkering with. It’s from a manufacturing plant. It’s running a manufacturing version of witech. It seems to be locked into the specific models that manufacturing plant was making though. Only covered 2 years as well. 2016 and 2017. Some interesting cables for this thing and I have never seen a VCI pod that had an external pcb attached to it.

I’ll circle back to the DRB 3 stuff later this week and post some more info.

 

[Mumbles05]

Hmm, that's an interesting screen board. Looks like it's more a controller than just the display itself. I assume the display plugs in at that top ribbon cable? Random question, but have you got an idea how many lines the display is? I wonder if it's some kind of setup where each wire in the cable goes to a certain line of the display or something like that. Still seems a bit odd, but I'm not really that well versed in display technology.

On a different note, I played around with the sensor and control box on my bench some more tonight. Unfortunately to me it looks like it is waiting for some sort of "start" signal. I tried powering the control box and screening into it with a Raspberry Pi, but nothing was coming up by default. I also tried powering the sensor directly and putting a scope on the Tx line and it was just sitting high, not oscillating like I would expect if it was trying to send a serial style message. I'm guessing it's waiting for some kind of "go" signal on the Rx line before it transmits. That leads me to my next question. I know the inclinometers attach to the PEP module, but I was thinking you got to them via a different menu option than the PEP module functions. On the manual I have it says to select the "Inclinometer option" from the "DRB Standalone Menu". Sounds like this is outside of selecting the PEP module menu first. Does the enhanced emulator show this menu option by any chance? I'm guessing it's going to give the same response as the PEP module option, but if it's there could you try clicking it and seeing what it says? If we got lucky we could see if it tries to talk to the computer serial port or something. I'm guessing this is the "go" signal that the sensor is waiting for before broadcasting. That seems to be the next step I can think of.

I will elaborate more next week but the short answer is that those menu options say "Not Available" when you click on them. The DRB 3 lcd is 320 x 240.

You must be registered for see images attach

You must be registered for see images attach

 

[MoparMap]

Woah, that's some crazy setup on that vci pod. I actually got an emulator setup for Christmas and had a totally separate question. Do you have a Viper yourself? Any chance you could run a module scan and tell me what comes up for you? My TPMS isn't reporting on the bus and it's constantly chiming. By the service manual it's a critical tire level warning and the BCM is seeing the same DTC, but the car isn't even rolling. If it was a communication error it shouldn't be constantly chiming from what I can read.

 

[Mumbles05]

Woah, that's some crazy setup on that vci pod. I actually got an emulator setup for Christmas and had a totally separate question. Do you have a Viper yourself? Any chance you could run a module scan and tell me what comes up for you? My TPMS isn't reporting on the bus and it's constantly chiming. By the service manual it's a critical tire level warning and the BCM is seeing the same DTC, but the car isn't even rolling. If it was a communication error it shouldn't be constantly chiming from what I can read.

Negative, I do not personally own one at the moment. I hope to rectify that in the not too distant future though. I do stop by the local Viper shop occasionally since I provided their scan tool setup. I need to swing by there in the next week or two and update their software though. What year is yours? I can commandeer the one most like yours and scan it. From what I have been reading around the web, the TPMS sensors on the Vipers are a major PITA. The Crossfire as well. There was someone offering a cloning service for the Viper ones I believe. That seemed to be the most popular solution to people's woes. I could be mistaken but I believe you need a seperate tool to wake the sensor up so that the appropriate vehicle module can marry to it. I would need to look at what the service manual says to be sure. You could probably have whatever tire shop mounts the tires, use their TPMS tool to wake the sensor up while you run your emulator setup to complete the process. Be careful with the emulator if it's a clone unit. It should be fine for most things but I looked into the clone tool issue further recently and it seems that the tool is prone to overheating which causes the firmware to crash. That isn't an issue when pulling codes or reading live data but if you're trying to write to a module and it crashes, there is the possibility it could brick the module. I would probably use one personally if I didn't already have original hardware but I wouldn't feel comfortable selling a clone tool to someone else.

Pictured below are some examples of the TPMS tools I'm referring to. The Chrysler one was for vehicles back when the starscan was still in use so it will not be useful to anyone now. The 2nd one is the OTC tool, OTC 3834EZ. They run ~$300. A tire shop will definitly have something like the OTC tool. So if the Viper needs to have the sensor woke up as part of the procedure, having a tire shop use their tool to wake it up for you while you run the emulator is your best bet.

Edit: The chrysler branded one is actually a "ATEQ VT60"
https://www.ateq-tpms.com/en-us/support/vt60-industrial-tpms-tool/
The awakening transmission frequency is: 125 kHz (LF). The reception frequencies are: 433 MHz and/or 315 MHz (VHF) following the geographic zones.

You must be registered for see images attach

You must be registered for see images attach

 

[Mumbles05]

Woah, that's some crazy setup on that vci pod. I actually got an emulator setup for Christmas and had a totally separate question. Do you have a Viper yourself? Any chance you could run a module scan and tell me what comes up for you? My TPMS isn't reporting on the bus and it's constantly chiming. By the service manual it's a critical tire level warning and the BCM is seeing the same DTC, but the car isn't even rolling. If it was a communication error it shouldn't be constantly chiming from what I can read.

Okay I have done a bit more reading on the topic. It took me a lot of digging but you have an 04' correct? Most of the viper TPMS systems seem to be a self learn system. Information varies about speed and duration but they are pretty consistent in that you need to maintain a moderate speed continuously for a length of time. (-Drive the car for at least 10 minutes and maintain speeds above 15 MPH.)
Other methods are also listed here
http://www.thetpmsforum.com/showthread.php?51-Resetting-Chrysler-TPMS

I do own a Tire pressure relearn magnet for chrysler vehicles. Tool is "Miller 8821". I believe it is primarily used with the DRB 3 but could also be used for the vehicles that allow you to initiate the relearn from the vehicles information display system.
I found a listing for it here: https://www.freedomracing.com/tps-relearn-magnet-8821-u.html
I don't know how accurate this information is but they list this on the page with it
TPS Relearn Magnet 8821

• 2006 (Viper, Crossfire) - Systems (22 - Tires and Wheels, 28 - DTC-Based Diagnostics)
• 2007 (Crossfire) - Systems (22 - Tires and Wheels, 28 - DTC-Based Diagnostics)
• 2008 (Viper, Crossfire) - Systems (22 - Tires and Wheels, 28 - DTC-Based Diagnostics)
• 2009 (Viper) - Systems (22 - Tires and Wheels, 28 - DTC-Based Diagnostics)
• 2010 (Viper) - Systems (22 - Tires and Wheels, 28 - DTC-Based Diagnostics)

The miller magnet is listed for $75 but there appears to be another one on amazon for $25 named "Schrader 20143 TPMS Magnet"
I assume Schrader in the manufacturer of the sensor. It sounds like the manufacturer use for the crossfire ones.
https://www.amazon.com/Schrader-20143-TPMS-Magnet/dp/B004A42MZI

I also found this info: https://www.tpmsdirect.com/Schrader 20028_TPMS_Relearn_a/800.htm
Schrader 20028 TPMS Relearn Procedures
Dodge

2009 Viper
2008 Viper
2006 Viper SRT/10 Convertible
2006 Viper SRT/10 Coupe
2005 Viper SRT/10
2004 Viper SRT/10 Convertible

It just really comes down to what year vehicle you have and what sensor model it is. If it is self learn by driving, programmed with the scan tool, programmed through the in vehicle information display, and/or if it requires you to wake the sensor up as part of that process; which depending on the sensor model, may need to be triggered by a magnet or triggered by a RF signal.

In short, I need more information lol.

You must be registered for see images attach

You must be registered for see images attach

 

[Steve-Indy]

Fascinating thread...you guys are way over my head !!

Two points of observation:
2003-2006 and 2008-2010 Viper Tire Pressure Sensors are not self learning. They must be programmed in a set sequence using a DRB III and a magnet. Sadly, fewer and fewer dealerships have tech who are aware of this...though there are plenty of techs who replace modules randomly (and unsuccessfully) on these Vipers after their programming attempts fail. Through the years, I have happily filled this void locally at tire shops, dealerships, and other meet-up locations...or, by coaching techs remotely per phone. the procedure takes less than two minutes with the correct tools.

Also, my original wiTECH's "DRB emulator"would not work on the stated years of Vipers even after it was last updated. I have not attempted this reprogramming using a wiTECH 2.0 at a CJDR dealership, so I will be interested to hear the experiences of others.

2013-17 Viper systems are self learning.