DRB III Reverse Engineering Project

[MoparMap]

Yeah, I have a 2004. My problem isn't necessarily programming new sensors, I've already got cloned sensors that seem to work fine and after I get rolling the error seems to go away, but I'm not sure why the code comes up to begin with. Based on the service manual, the sensors don't broadcast until 20 mph and the BCM should know the speed, so it's supposed to ignore a "no broadcast" condition until the minimum speed is reached.

My problem is that the tpms master module (not the sensors) isn't even showing up in a module scan. I can't get into any menus to program or check sensors because it doesn't see the module to begin with, but the BCM is getting a "critical tire pressure" warning code set, so it has to be getting a signal from the module somehow.

When doing a module scan on the DRB III emulator I get the PCM, BCM, MIC (instrument cluster), OCR (airbags), ABS, and HVAC. No TPM and interestingly no security system, though the PCM reports some theft features, so maybe it's not a separate system in the Viper? Just curious what the full list of modules should be. Maybe the TPM isn't part of the J1850 bus, but it's wired on the same harness, so don't think it's a different CAN protocol.

 

[MoparMap]

As a side note, I'm aware that some Dodge products had the TPM built into the SKIM/SKREEM system (the DRB says as much), but based on the DRB manual the Viper and prowler are the special ones that have a dedicated module for it and should report as such.

 

[Steve-Indy]

I thought that CAN bus did not appear on Vipers until 2008...noting at that point the PCI bus still persisted for TPM and ABS among others. Somewhere I have a diagram outlining said systems for Gen IV.

 

[Mumbles05]

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.

Thank you for the information and clarification. You are the person I was thinking of when I mentioned there was someone offering a cloning service for them. I was actually engaged in a conversation about witech 2.0 on a different forum under the name "toolafterlife" and I am not sure I cross posted all the info here so forgive me if I'm repeating anything.

I am certain you are correct that the real DRB 3 is required to accomplish the TPMS programming for those years. Chryslers documentation is very vague about what functions were included and which ones were left out of the emulator. There are a variety of combinations of the hardware and software that you could be referring to though so I'll need to ask a few questions about the setup you used to clarify things a bit.

Are you using the original DRB 3 emulator released circa 2012 or are you using the "enhanced DRB 3 emulator" that was released around 2016?

What hardware interface did you use? Starmobile, VCI pod or Micropod 2?

If it was the VCI pod or Micropod 2, was it a chinese clone tool?

Also, do you know which module in the vehicle is associated with the sensors in 2003-2006 and 2008-2010? I only ask because the 2008-2010 vipers were a hybrid bus system which used witech and the emulator, depending on the module. The original DRB 3 emulator may not have fully supported the communications protocols in the Drb 3 only Vipers.

A description of the Original DRB 3 emulator and it's limitations.

You must be registered for see images attach

Enhanced DRB 3 changes.

You must be registered for see images attach

You must be registered for see images attach

Hybrid Bus vehicles and module breakdown

You must be registered for see images attach

You must be registered for see images attach

 

[Mumbles05]

I thought that CAN bus did not appear on Vipers until 2008...noting at that point the PCI bus still persisted for TPM and ABS among others. Somewhere I have a diagram outlining said systems for Gen IV.

Correct, the CAN bus first appeared in the Viper in 2008. It was very limited based on the module list showing the emulator as being required for all but 2 modules. 2006 and prior were purely covered by the DRB 3.

 

[Steve-Indy]

"Are you using the original DRB 3 emulator released circa 2012" ....Yes...and that did not work on our 03, 08, and 10 for the TPMS


"or are you using the "enhanced DRB 3 emulator" that was released around 2016?"...NO...as about a year or two before hat they stopped supporting the original wiTECH sold to the "aftermarket". That said, I spoke with a couple of very experienced Viper Techs using the latest wiTECH system's emulator in2017 and they were unable to program the TPMS in Gen III and IV Vipers at that time...so, I lost interest in tracking said use.

"What hardware interface did you use? Starmobile, VCI pod or Micropod 2?"...VCI Pod connected as standalone to laptop. By the way, I could NOT get the dealership STARSCAN to work on any of the Gen III Vipers' TPMS. Others may have had a different experience.

"If it was the VCI pod or Micropod 2, was it a chinese clone tool?" ...VCI Pod purchased around 2010 directly from DCC Tools through Tech Authority...including Pod Kit, license, and yearly "wiTECHsupport". Initial cost about $2,800.00....with $280.00 per year for support including updates but not "flashes".

"Also, do you know which module in the vehicle is associated with the sensors in 2003-2006 and 2008-2010? I only ask because the 2008-2010 vipers were a hybrid bus system which used witech and the emulator, depending on the module. The original DRB 3 emulator may not have fully supported the communications protocols in the Drb 3 only Vipers.' .. I will try to look at each of our Gen III and IV's to read module info using DRB III shortly.


As an aside, when Tech Authority/wiTECH support contacted me a short while after terminating support on my original system, the initial quote per telephone to "get back into action" was several times my original dollar outlay. Then, I received a letter quoting the more reasonable prices offered today...buy, way too much "a la carte" pricing for my hobbyist-diagnostic activities...at least in my mind.

While "stand alone" is the only system that appeals to me personally...though, admittedly, I don't actually NEED one at all since I live 3 miles from a "Viper friendly" dealership.

Thanks for the great discussion !!

UPDATE:

2003 Viper TPM "Id 10910, Version 15, 06/11/02"

2008 Viper TPM "Id 43035, Version 15, 04/07/08"

2010 Viper TPM "Id 60718, Version 15, 03/04/10"

I HOPE that this module info means something to you as I know nothing more!!

 

[MoparMap]

Any idea why the "real" VCI pod would be necessary for the TPMS system? It should all be the same communication protocol as far as I could see. Not really sure I understand why the clone system wouldn't be able to deal with it. That's one of the few things I think I'd ever even want or need to do myself in the future, so kinda disappointing if that's about the only thing a clone tool can't do.

As a side note, Steve, how did you get that module info? If the DRB emulator wouldn't pull it, what did you use?

 

[Steve-Indy]

Well, I got in the Vipers, hooked up my DRB III, and went through the steps to read the the modules...easy to do...except one required a ladder to reach it on a 4 post lift and the another required a short trip to my warehouse.

By the way, I do use a SuperCard 2 in the DRB.

 

[MoparMap]

Ah, so a real physical DRB III then? Hmm...

 

[Mumbles05]

Any idea why the "real" VCI pod would be necessary for the TPMS system? It should all be the same communication protocol as far as I could see. Not really sure I understand why the clone system wouldn't be able to deal with it. That's one of the few things I think I'd ever even want or need to do myself in the future, so kinda disappointing if that's about the only thing a clone tool can't do.

I don't think it's anything to do with the vci pod clone or the clones in general. I think it's the emulator software itself that left it out. However, there are reports from around the web that some versions of the chinese clones are not able to communicate with many vehicle modules in vehicles where the original hardware can. It's hard to nail down since I usually find the posts months or years after they were posted and the person doesn't respond or have the hardware anymore to carry out further testing. I'm pulling the info from across various Chrysler platforms so it's not necessarily Viper specific. Crossfire, Sprinter, Ram, Charger, etc, etc,

I've had some lengthy discussions with the guys at Brightstar Engineering, the people who made everything from the starscan forward, and they even said that there are differences in the micropod hardware that means some of the newer models do not fully support the older communication protocols. I haven't tested this and I didn't get anything very specific regarding that but I would assume they were probably talking about the oldest one, CCD. Him or I could even be mistaken about if it was the newer or older models. I know that some of the early micropod 2's used a WCP serial number prefix instead of the standard WSP prefix on all the newer ones. Among the newer ones WSP's with too low of a serial number are not considered secure micropod 2's and therefore not allowed with Witech 2.0. So there are at least 2 candidates there that likely had hardware changes.

At any rate, I just want to identify all the variables involved before I start attributing it to anything specific. Which version of the software being used, what hardware and if it was original hardware or not is relevant to keep my info straight and to identify things that may require further investigation to verify.

 

[Mumbles05]

"or are you using the "enhanced DRB 3 emulator" that was released around 2016?" I spoke with a couple of very experienced Viper Techs using the latest wiTECH system's emulator in 2017 and they were unable to program the TPMS in Gen III and IV Vipers at that time...so, I lost interest in tracking said use.

I could NOT get the dealership STARSCAN to work on any of the Gen III Vipers' TPMS. Others may have had a different experience.

"Also, do you know which module in the vehicle is associated with the sensors in 2003-2006 and 2008-2010? I will try to look at each of our Gen III and IV's to read module info using DRB III shortly.

While "stand alone" is the only system that appeals to me personally...though, admittedly, I don't actually NEED one at all since I live 3 miles from a "Viper friendly" dealership.

2003 Viper TPM "Id 10910, Version 15, 06/11/02"
2008 Viper TPM "Id 43035, Version 15, 04/07/08"
2010 Viper TPM "Id 60718, Version 15, 03/04/10"

I am very interested in tracking the issue since I've made it my hobby to document this stuff. If you spoke to some suitably experienced techs who were unable to access it with the newest version of the emulator then I would say it was likely left out all together. A shame since the enhanced DRB 3 emulator was being marketed to the dealers as the definitive version and one that would finally allow the dealers to let their actual DRB 3's go. The enhanced version was a $4000 add on the dealers had to buy seperately and since they are not supporting it in Witech 2.0, dealers who purchased it, still have to maintain a Witech 1.0 installation on a computer and a dedicated device configured for witech 1.0 to use it.

The enhanced DRB 3 emulator states it only works with the micropod 2. As it turns out, that is not true. The starmobile, the vci pod and the micropod 2 are functionally equivalent as it relates to the DRB 3 emulator. I was able to implement a work around to use them with the Enhanced emulator version and have tested it on one of the DRB 3 sprinter vans to ensure it worked correctly. There was also an added/updated option for the air adaptation in the sprinter vans that is only available in the enhanced DRB 3 emulator. So there is at least one documented thing that the enhanced DRB 3 emulator can do that an actual DRB 3 can not.

The starscan only supports CAN bus vehicles so it should not support the Gen 3 Viper at all. The final software release for the tool to dealers was 9.07 which covered 2004-2009 but is known to work with later model years if the model didn't change at all since one of the years that was already covered. Like a 2010 jeep that didn't change electrically from a 2009 would still work on the starscan by selecting the 2009 year one.
I have a manufacturing version of the software for the starscan M9.03, that covers 2008-2011 vehicles. I assume that excludes the powernet architecture vehicle in those years though.
I also have an engineering release of the software that runs on the starscan, CDA E4.02.45 but that requires you to have the engineering files for the years you want to use it with and frankly the desktop version of the CDA software would be a much better choice if that was the route you wanted to go with it.

If you are looking for a standalone setup, I would be happy to go over what I have available and what I know to be available from various places online. That VCI pod you have is not a paperweight. The cloned tool option is the most cost effective one I have seen and seems to be a popular choice. I only deal with original hardware though. There are some other things available for the more knowledgeable people that go deeper than witech will take you; I'm not referring to any 3rd party offerings.

What I am really interested to know is, has anyone tried using something like the old snap on red brick MT-2500 to program the TPMS on non-CAN Vipers? They are very cheap to get ahold of and just might cover it with the main Chrysler Cartridge.

"2003 Viper TPM "Id 10910, Version 15, 06/11/02"
I unfortunately don't know what this means. Where did you find this information? What I was actually trying to ask you is, under what module in the DRB 3 menu system did you find the option to program the TPMS? For the purposes of comparing the DRB 3 to the emulator; I/we are trying to determine if the module itself isn't being listed in the emulator or if it's just a menu entry missing somewhere. So, if you could list which option you selected on each menu screen that lead you to it, that would be very helpful. Also, what were the other menu options on the last 2-3 menus on your way to it?

Thank you for helping with this and contributing to the conversation.

 

[Steve-Indy]

The info that I posted on the three Vipers all came from screens labeled

"TPM Module Information"

If you like, drop an email to [email protected]
and I will send a couple of screen shots to you from the DRB III pathway.

 

[MoparMap]

So as a complete sidenote, does anyone have any experience with the AE Tools DRB III emulator setup? It appears to be a direct inline module with a OBD ii plug on one end and USB on the other. (https://www.aetools.us/products/drb-iii-emulator/). By all means it appears the same as any other emulator as I'm guessing it runs the same software, but it almost sounds like it runs the emulator directly and not through the witech tools software. To my knowledge this was also a tool direct from OTC as an aftermarket option for running a DRB III emulator "legally" so to speak. Wondering if the capabilities or software is any different.

 

[MoparMap]

Looks like that emulator is actually from controller technologies, AE Tools appears to be linked to witech as a supplier.
https://www.controllertech.com/products/drb-iii-emulator
Curious to know if anyone out there has ever used this particular setup though. The emulator software looks to be standalone (called DRB III pass thru emulator in the screenshots).

 

[Mumbles05]

Looks like that emulator is actually from controller technologies, AE Tools appears to be linked to witech as a supplier.
https://www.controllertech.com/products/drb-iii-emulator
Curious to know if anyone out there has ever used this particular setup though. The emulator software looks to be standalone (called DRB III pass thru emulator in the screenshots).

Yes, I've used it before and had some long conversations with the guys over at CTC as well. They are the ones who developed both versions of the DRB 3 emulator. As I understood it, there was some licencing dispute regarding the original DRB 3 emulator software which is why it was previously installed automatically back in witech ~v12 but had been removed by witech ~v14. CTC's version of the enhanced DRB 3 emulator still requires a separate multiplexer module for the Sprinter and Crossfire.
https://www.controllertech.com/products/drb-iii-emulator-multiplex-cable
I have already tried that multiplexer with an actual DRB 3 to see if it worked and it was a no-go as a replacement for the CH 9043 multiplexer cable. I made a pretty strong case for them revising the hardware of the multiplexer unit to allow it work with the actual DRB 3 but they seemed unmoved by it.
At ~$2500 for their hardware I never considered it a viable replacement choice so sold the hardware off. You can freely download the emulator software from their website but it is coded to only work with their hardware and I was not able to make it work with a variety of 3rd party J2534 tools. Their emulator, both versions, have the same limitations as the ones available through witech. It would be cheaper to get your hands on an actual DRB 3.

This is a vci pod running the Sprinter specific portion of the enhanced emulator without their multiplexer adapter. The cloned tool option you got would be the cost effective choice.

You must be registered for see images attach

You must be registered for see images attach

 

[MoparMap]

Ah, good to know. I just saw the download section as well and was wondering if their version had any different functionality. Maybe I'll dig into the SAE standards some more and see if I can make sense of anything. I believe the Viper system is a J1850 bus protocol, so wondering if I can do a module scan on the emulator and watch the USB port to see what signals are being sent and retrieved and interpret them using that. I'm somewhat familiar with CAN systems from my work (we use J1939 on our vehicles), and it seems like the bus setup is similar on the Viper, just with a different protocol. That being said, I'm not sure how the modules pick their addresses on the bus or how exactly that works for J1850. I know on J1939 the different computers usually fall in specific addresses (like 0 for the PCM, 3 for the transmission, etc). Don't know if J1850 has a similar setup or not. I would wonder if a generic CAN software (like Vector CANalyzer for instance) would be able to read it as I believe you can configure the protocol in the settings to "interpret" the signals correctly. "CAN" is kinda a loose term anyway. The Viper still uses a communications bus, and I think "CAN" as we know it today is really just a specific SAE standard, so you could say the Viper has had a CAN system all along, even though that's not quite how it's defined in the diagnostic tools.

As a total side note, if CTC developed the original emulator software, wouldn't they be the ones to talk to regarding certain features not working like the TPMS module not showing up? Seems like a fault/omission on their side and like they "might" be the ones to be able to update the software to actually work.

 

[Mumbles05]

As a total side note, if CTC developed the original emulator software, wouldn't they be the ones to talk to regarding certain features not working like the TPMS module not showing up? Seems like a fault/omission on their side and like they "might" be the ones to be able to update the software to actually work.

A fair warning, you are embarking down a path that will eat an inordinate amount of your free time and cost you tens of thousands of dollars. lol

I would encourage you to give them a call. You might get further with them than I did. Try the technical support department. They didn't seem very enthusiastic to be talking with me especially when it didn't relate to me getting their hardware working again and questions related to not using their hardware or using something other than their hardware with the emulator. I'm assuming the software was made under licence to Chrysler and they are likely to deflect you to the virtually non-existent witech support for anything regarding that version of the emulator.

I know the vector brand hardware has been used by chrysler for their engineering level work so that is a good avenue to pursue. As far as sniffing the USB bus traffic or decoding the J1850 protocol, that is pretty far over my head so I will have to defer to you and what you are able to do and discover.
I know the current vector hardware in use is the Vector card VN-1610

This thing pictured below is probably the holy grail. It is called the iBox II plus and was used for the development of calibration files during the DRB 3 era. I never got my hands on it but it sold on ebay a while back and went for something like $4500 for the whole mess. They now use a software called Chrysler Diagnostic Application for this purpose and it is different than witech. They have already iterated through CDA 4 and CDA 5. Pictured below is CDA 6. I believe they are still on CDA 6 just a higher version number.

You must be registered for see images attach

You must be registered for see images attach

You must be registered for see images attach

I have a few more pictures of this I lifted from the listing if you want to see more of it but this should be enough to get an idea.

You must be registered for see images attach

 

[MoparMap]

Wow, always interesting to see behind the scenes. I'm kinda amazed that stuff even made it into public hands too knowing how my company works at least. We're way smaller than a major automotive OEM though.

I was doing a little more searching to try to better understand the bus setup on the car and stumbled across this forum post on the intrepid forums: https://www.dodgeintrepid.net/threads/pci-bus-documentation-reverse-engineering.1457441/. Looks like the emulator uses a database file to handle the interpretation, I'm thinking similar to a .dbc file for modern CAN systems. Wondering if maybe the TPMS module info isn't in that database so it may be communicating, but the software doesn't know how to interpret the answer. That module was unique to the Viper and Prowler, so I could see it getting missed due to low volume. I think it could be added easily enough, but would have to know what actually needs to be there. Interesting note in that forum too is that you can put a scanner on the diagnostic port with a DRB at the same time, so you can log what it's sending and receiving. Could be one way to reverse engineer the TPMS signals.

 

[Mumbles05]

Wow, always interesting to see behind the scenes. I'm kinda amazed that stuff even made it into public hands too knowing how my company works at least. We're way smaller than a major automotive OEM though.

I was doing a little more searching to try to better understand the bus setup on the car and stumbled across this forum post on the intrepid forums: https://www.dodgeintrepid.net/threads/pci-bus-documentation-reverse-engineering.1457441/. Looks like the emulator uses a database file to handle the interpretation, I'm thinking similar to a .dbc file for modern CAN systems. Wondering if maybe the TPMS module info isn't in that database so it may be communicating, but the software doesn't know how to interpret the answer. That module was unique to the Viper and Prowler, so I could see it getting missed due to low volume. I think it could be added easily enough, but would have to know what actually needs to be there. Interesting note in that forum too is that you can put a scanner on the diagnostic port with a DRB at the same time, so you can log what it's sending and receiving. Could be one way to reverse engineer the TPMS signals.

I know. I'm registered as Deepfreeze01 on there and participated in that thread. It's a pretty safe bet that I'm in most of the discussions of this topic across the web. Any that were of any consequence anyways. Unfortunately because of the value of the vehicles involved, most of those threads tend to die out rather quickly. I'm hoping it stays alive on here longer because the vehicles are worth enough to keep trying.
I was picking usernames based on the email I used to signup. I would love to be able to change the username though. Can I change my username on here somehow? I'm trying to consolidate all my tool related stuff under the tooafterlife email and username.

I would encourage you to investigate 3rd party scan tools that may have supported the TPMS programming. No need to reinvent the wheel if there is already an inexpensive solution available.
OTC Pegisys up to 2014
MT 2500 up to 2006 depending on the version of reprogrammable cart you have.
Modis oldest model can cover up to 2016 depending on the software version on it.
These are 3 I have here that can be reasonably found under $500

 

[Mumbles05]

Interesting note in that forum too is that you can put a scanner on the diagnostic port with a DRB at the same time, so you can log what it's sending and receiving. Could be one way to reverse engineer the TPMS signals.

I'm sure there are obd 2 splitter cables or you can use something like the "J1962 Breakout Box, CH7002" listed in the DRB 3 Hardware Operations & Accessories
Reference Guide P/N CH6050
PDF copy found here: https://diysprinter.co.uk/reference/Sprinter_DRB_III_Manual.pdf

That manual also describes the Viper inclinometer and how to operate it from the DRB 3. That starts in section 5-1
Press F2/Zero–this zeros both inclinometers in one direction. Rotate both inclinometers 180 degrees and press F2 again, this zeros both inclinometers in the other direction.

If you were trying to sniff the traffic off of the emulator after the tool, this little number appears to be set-up for exactly that purpose. I could be convinced to part with it for the right price, just the external board and cable part if you already have a vci pod or I would otherwise consider loaning it out provided you left a deposit for it. I'll even toss in a copy of CDA 5 which includes CAN bus logging functionality and a copy of the engineering files for it (~4300 of them).
CDA 5 is only compatible with the starmobile and VCI pod and is only for CAN bus vehicles. It does not work with the micropod 2.

You must be registered for see images attach

 

[MoparMap]

I had a feeling you were probably on that forum as some username, lol. And I think I agree that if I really really needed TPMS module support that going to a full 3rd party aftermarket setup probably makes the most sense from a financial standpoint. At this point it's more just tinkering with it to try to understand why it doesn't work on the emulator as it doesn't really make any sense. If it was an "easy" fix of just adding some info to the database that would complete the emulator to add the module that would be awesome, but even that is probably above my head to some degree and I'm sure will be more involved. I was thinking about trying to talk to controls guys at work to see if they had any advice they could give. I assume the logging capability of CDA 5 doesn't really do any good for the PCI bus on the older gens? I have a clone VCI pod setup now, and if that software could help me log communication between the car and the VCI pod I might be interested in the software at least, but if it's limited to the modern CAN modules on newer cars that's probably not as much help. I was going to go over the wiring diagrams a little closer and try to draw up a communication bus schematic to get a better idea of how the bus(es) are laid out. In reading up on it, the PCI bus is so limited in speed and whatnot that I can understand why there are separate discrete signals out of controllers instead of just broadcasting everything on the bus. Also wondering if J1850 has a digital annex like J1939 that spells out typical SPN and PGN type stuff. Planning to read over the SAE documents posted on the Intrepid forum to see what all it spells out.

As a side note, I'll see what I can do about the username. I think we can change the name and keep some associations, but not sure if it would keep the links to your existing post content or not.

 

[MoparMap]

So something isn't adding up with the TPMS module. Looking at the wiring diagram, there are 4 wires to the module: power, ground, output, and SCI transmit. Power and ground make sense, output is interesting but based on the service manual is easy enough (it's basically either grounded or open depending on what is going on with the sensors themselves). What doesn't add up to me is the SCI transmit line. Interestingly enough, based on what I've found regarding Chrysler communication protocols throughout the years (a good read here: https://www.autonerdz.com/yabbfiles/Attachments/dcx_network_ppt.pdf), the SCI bus isn't actually a "CAN" style bus, it's more like a serial port on a module and the only module that typically has an SCI port is the PCM. It is used when diagnosing bus issues as it allows communications with the PCM even if the PCI or CAN bus is dead. It's weird to me that the TPMS module would operate on the SCI bus vs the PCI bus, but what's even stranger is that it is only a single wire. By the wiring diagram it only has a transmit wire, which would mean it could report module status, but I know you can program sensors through it, which is what doesn't add up. I would think it would have to have a receive wire for that. I know that there are some single wire serial ports out there, so I guess it's theoretically possible that you wouldn't need two, but it just seems really odd. I could understand if Dodge was using an "off the shelf" TPMS system and just gluing it into the system with what was available (it is made by Schraeder after all, at least based on the sticker on it), but the weirdest part is when you open the module up and look at the board it actually says Viper/Prower v1.1 (at least mine did), which would indicate it was specifically built for Dodge. I guess they could still just be adapting the board to work with Dodge communication protocols, but it still seems odd they would have taken the route they did.

This does make some sense as to why this particular module is the red headed step child though. It doesn't operate on the typical communication bus and may even be more unique in that it could be single wire communication. I wonder if there isn't some magic going on with the output line as well though. Maybe something like if the output line is forced high or grounded externally or something like that then the SCI line flips from transmit to receive? I wonder if Schraeder would actually be willing to tell me anything or if that info is still proprietary to Dodge. I'm guessing they changed modules for the Gen 5, but that would still mean the "old" system was in use until 2011, so it's not that old.

 

[MoparMap]

Another interesting communication protocol read here: https://www.cnblogs.com/shangdawei/p/3570546.html. It's annoying that companies use their own names for standardized stuff, though I guess everyone has their little tweaks here and there.

 

[MoparMap]

So to continue to spam this particular thread with info, here's a screenshot I took while browsing through the DRB emulator database.mem file:

You must be registered for see images attach

It would appear that the TPM module info and signals are in the database, so looks like that wasn't the "magic bullet" I was hoping for. Though this does spell out the messages to some degree, it's a bit like reading a foreign language that uses the same alphabet. It makes some sense looking at it, but I'm not really sure what it's saying. Have you ever messed with the database reader program that guy put out? I'm just trying to understand the format of each line to know what it really means.

Modsearch appears to list the module "name", don't really know what SC means, generic module function description, and something like an address maybe? Doing a "modsearch ZB" for Viper specific modules gives me the BCM, MIC, ABS, ORC, and HVAC. The PCM doesn't show up, but that's because it's a "generic" JTEC controller that was used in other vehicles, so the ZB chassis code isn't unique to it. If you do a modsearch for Viper you get the engine controller, VTS (theft system, interesting mine isn't showing up on a module scan), and radio. If you look at the VTSS signals though most of those are duplicated in other menus, so I'm not sure if any of the functionality is actually missing.

Looking at an individual signal analysis (in this case the "low tire pressure threshold") gives the following:

You must be registered for see images attach

Again, not really sure what I'm looking at. Would be nice if there was a "generic" signal description somewhere to better understand how to interpret each value. The original thread is 3 years old, so not sure I'd get anywhere asking there. It would appear though that if someone knew what they were doing that they might be able to transmit the appropriate commands directly and read the results. I'm just not sure how you do that. A USB ODBII dongle can communicate over the lines, but I feel like you would need some kind of encryption key or something to "open the line" to begin with.

 

[MoparMap]

Thought about it some more and I think I was looking at the wrong "level" so to speak. I think the more interesting lines are in the signal list for a specific module (after the modtxlist command). This one seems to spell out some kind of communication or bus protocol. It appears to show the signal name, some type of protocol, the command to transmit? (I think it's xmit: command), I think the next part is the source (I'm thinking sc: XXXX stands for source: module, or where the signal is coming from/going to), and some kind of memory address maybe?

The important thing here is the protocol section. If you do a modtxlist on the PCM for instance, you get a variety of options varying from CCD, to SCI, to J1850, so I think this column defines that. The question then becomes what does P158 and P155 mean as those are the two that show up when looking at the signal list for the TPM module. I can't find any reference to it in some general Google searching and it doesn't sound like any communication protocol I've seen so far. I have a feeling this tells the VCI Pod what interface pins it is supposed to be using to talk to the modules and what voltages/signal to expect. On the diagnostic connector there are two main communication ports (PCI and SCI) and two pins for flashing modules (one for BCM and the cluster and one for the ABS module). Not sure why there are CCD messages in the PCM as you can't have both CCD and PCI busses in the same car, but might just be legacy data in the controller.

For what it's worth, a search of the database for all signals that use P158 only comes back with the TPMS signals. A search for P155 comes up with a much longer list though that includes everything from PCM to TCM to HVAC and more.

 

[MoparMap]

So a bit off topic, but has anyone ever played with an Autoenginuity system? It was one of the original aftermarket tools on my list as it seemed like it could do pretty much all the same stuff as the DRB III and even CDA style functions of enabling different "sales codes" in the different modules based on options. It claims that it supports the Viper and even the TPMS, but I've never seen it myself or really heard of anyone that had one. I just read through some other threads on various different Dodge forums, but most of them are dealing with the newer CAN based cars, so it's unclear to me just how useful the tool is on older computer systems. The hardware, base software, and Dodge specific enhanced package comes in just under $500, so it's at a similar level to a cloned VCI pod setup with potentially more capability as it appears to work from ~96 or so to current vehicles. I'm a bit skeptical of it and prefer the factory tools as I know they were designed with the correct systems in mind, but for the average guy it seems like it could be a reasonable option.

 

[Mumbles05]

So a bit off topic, but has anyone ever played with an Autoenginuity system? It was one of the original aftermarket tools on my list as it seemed like it could do pretty much all the same stuff as the DRB III and even CDA style functions of enabling different "sales codes" in the different modules based on options. It claims that it supports the Viper and even the TPMS, but I've never seen it myself or really heard of anyone that had one. I just read through some other threads on various different Dodge forums, but most of them are dealing with the newer CAN based cars, so it's unclear to me just how useful the tool is on older computer systems. The hardware, base software, and Dodge specific enhanced package comes in just under $500, so it's at a similar level to a cloned VCI pod setup with potentially more capability as it appears to work from ~96 or so to current vehicles. I'm a bit skeptical of it and prefer the factory tools as I know they were designed with the correct systems in mind, but for the average guy it seems like it could be a reasonable option.

I think it would work well as a standard scan tool, allowing you access to various tests like the injector kill test and cycling the ABS pump. I haven't seen anything like it that could activate sales codes. On older vehicles that usually a matter of flipping a switch in the software, it may have been an entirely different flash file and could have been a different hardware version of that module all together. The only 3rd party offerings I've seen that approach that level of tinkering were companies like Diablosport and HP tuners. Even then, you would need to purchase the custom tuner software which can run an additional 1k or more. The programmers usually come with some premade tunes and allow you to change a limited number of parameters using the software on the device but for the entire range of parameters and the ability to make fine adjustments, you need their 'dealer/custom tune' software. I think the clone tool option is the best deal for the money and beyond that, I'd just pay for a custom tune from a place that already has the software/hardware.

Here is the link to the Autoenginuity Chrysler coverage:
https://www.autoenginuity.com/products/oe-level-coverage/chrysler-and-dodge-family-ei04/

As far as all the Hex code and BUS discussion above; I haven't gotten to read it all yet but I can for sure tell you it is way over my head. When that guy was working on the database, I was still trying to work out how to get the emulator software working correctly. His interest related to his specific model car which I think was not similar to my personal vehicle at the time (NGC3) so I wasn't really tracking what he was doing all that closely. I was just doing my best to share what I had that may have aided his efforts and hoped he turned up something that was useful.

I am certainly trying to learn more about all of that stuff. But it takes awhile to learn the basics and could take a lifetime to try and reverse engineer what an entire team of people built; especially if they've put security features into it to thwart such efforts. As it applies to the DRB 3, some of the software and hardware is now completely obsolete or defunct (pSOS, PCMCIA). It's always a difficult cost/benefit analysis when deciding whether or not to pursue those things because the knowledge gained would have very little application outside of that project. Just like it wouldn't make a whole lot of sense for a programmer to spend a bunch of time learning Fortran now. It'd be a much better use of time and resources to track down someone who was already an expert and pay them for their time to do what you need.

That being said, understanding what is happening conceptually would still be a worthwhile pursuit and narrow focus projects like the inclinometer are reasonably achievable goals. Feature creep is real and usually what kills these threads before anything of value was produced. I'd say lets focus on the inclinometer and once we have solved that issue, we can start a new thread about the TPMS stuff.

 

[MoparMap]

Yeah, fair enough. I realized it was getting more and more off topic the longer this was going. I did some packet capture on the emulator the other day to see if I could match up anything to the DRB III database, but I have limited knowledge with it and nothing really stood out. Ordered some parts to build a breakout box though so I could hopefully intercept signals at the diagnostic port itself (similar to the J1962 breakout box Miller offered). Hoping those look more like the database file info.

Getting back to the inclinometers though, I think where I'm at now is just understanding what exactly it is I need to send them to get an answer back. This is way over my head, but I wonder if it's possible to dump whatever coding might be on the chip inside the sensor. I got the impression that was how a lot of reverse engineering happened, but I wouldn't even know where to begin. Without a datasheet for the chip I'm even more in the dark. Maybe there are some generic serial commands out there though that I could start with to see if I get any communications? Something like a "ping" command would be a good place to start so I could at least try to get the baud rate and general setup going. The other path would be trying to figure out who actually made the sensor. It really doesn't look like an off the shelf part to me, so I'm inclined to believe that someone like Brightstar or CTC or whoever may have been the ones to develop it. Did you have any contacts with them from all the discussions you've had in the past? Might be interesting to see if they know anything and would be willing to share a command list or something.

Did you ever get that one sensor you ordered? I'll have to look back over the pictures I took to see if there was any vendor name on the sensor PCB. I think the breakout box might have had Miller silkscreened on it, but will have to look again.

 

[MoparMap]

So while doing some more general research I found another reverse engineering thread here: https://300mclub.org/forums/viewtopic.php?t=35340. The most interesting thing I pulled from that is that it seems most of the controllers in DCJ vehicles at the time used Motorola chips, often times custom ones apparently (denoted by the SC prefix if I'm following that thread correctly). The controller in the inclinometer is a Motorola chip with an SC prefix, so it would seem it is a somewhat custom affair. It could be based on another similar controller (similar to what the thread mentions), but that's anybody's guess.

I'm still baffled why they would build their own sensor though, especially if it's not connecting via their normal communication protocols (it's accessed from a totally different port on the DRB III). Though that might be part of the key. Since that chip is similar to other controllers and appears to use a serial style communication setup, I wonder if it doesn't use SCI communications similar to an engine PCM. That would give a hint at the baud rate and how the bus is expecting to communicate (SCI holds the transmit line high and grounds the signal for communication). I'm not sure how the RS232 converter plays into that though. Seems odd they would convert it and not talk to it directly since the DRB III would certainly have the functionality built in to do so though.

There's also a chance that it could be a "generic" chip and the only reason it's SC is because an OEM was buying a lot of them, maybe preprogrammed or something. It means custom, but doesn't necessarily define what custom means.

 

[MoparMap]

I'm reaching out to the few Dodge contacts I have in hopes that someone might have some info on how the sensors work. I'm not sure who ultimately designed them as if I remember correctly, CTC was who actually made the DRB III, so it kinda feels like they would have been the ones to make the sensors too, but it also looks like the chip inside is similar to what Dodge used in their other controllers. Either way I would think that both companies would have had to exchange a lot of info regarding protocols and whatnot, so even if Dodge didn't make it maybe they can point me in the right direction. The sensor is kinda independent of Dodge in that it was only used with a DRB III and not natively by any cars, which is my main worry that Dodge might not really know anything about it. Will have to wait and see.