Data Bus Conversion HS CAN >J-1850VPW
#81
This is awesome! I need this technology ans would love to help in some way, time and or $$.
I've been researching this for a few years off and on (when I started 2 current projects) both are 2013 GM powertrain and managment systems and instruments that need pruned of many sub systems.
being the repair industry I'm aware of many of the networks used and have access to loads of vehicles, could I simply start sniffing the buss on every late GM vehicle that comes in while playing with the different I/o devices and build a library over time?
yhere are many folks doing this on most vehicle makes already, I've spoken with a few through the black hat group ans "car hackers", what I la k is a few pieces of hardware, the correct software and a little education, (it would have be easier when I was younger)!!!!!
if this would help let me know, we see 250 vehicles a month and I've got the time.
thanks for all your work.
B
I've been researching this for a few years off and on (when I started 2 current projects) both are 2013 GM powertrain and managment systems and instruments that need pruned of many sub systems.
being the repair industry I'm aware of many of the networks used and have access to loads of vehicles, could I simply start sniffing the buss on every late GM vehicle that comes in while playing with the different I/o devices and build a library over time?
yhere are many folks doing this on most vehicle makes already, I've spoken with a few through the black hat group ans "car hackers", what I la k is a few pieces of hardware, the correct software and a little education, (it would have be easier when I was younger)!!!!!
if this would help let me know, we see 250 vehicles a month and I've got the time.
thanks for all your work.
B
#82
Restricted User
Pete, I know that this is a little off topic, but are you at all familiar with Megasquirts 29-bit proprietary CANBUS protocol?
I can do basic 11 and 29-bit CANBUS with an arduino without any issues. Working with MS3/MS3x and CAN has been a piece of cake.
Switching over to MS2 and attempting CAN communication has introduced some unique hurdles for me.
I can do basic 11 and 29-bit CANBUS with an arduino without any issues. Working with MS3/MS3x and CAN has been a piece of cake.
Switching over to MS2 and attempting CAN communication has introduced some unique hurdles for me.
#83
TECH Enthusiast
Thread Starter
On my lunch so this will be a bit short.....
JoeNova, I know what MS is but have no 1st hand exp with it. In the next month or so I'll be looking for bus data from the MS3 setup. I have framework to get this up and running rather quickly. While it's not so popular I have a tested and 100% working conversion module for an AEM system that won't be very hard to switch to MS3. What I know is that MS2 was a lot harder to work with and data from the bus wasn't easy to log with most tools. To be of any help on that one I would need to have direct access to a working setup to see it first and and figure out how it works.
For those that care...... Holly EFI is also on my list making it directly compatible with the OEM data bus's using one of my data converters. So using a standalone EFI would integrate the same as an OEM pcm meaning stock gauges and all that good would work on the newer vehicles that get cluster data off the bus network.
bbtech......logging many vehicles is far less productive than a couple of very specific one's. Collecting the data is very hard to do it on a computer but it can be done saving it to an SD card with out bottle necking. This does make it hard to split logs if your looking for more then 1 item in the log since your file is just going to run together all as one. Collecting it via SD card is simple and cheap but going though the logs is VERY time consuming. If you were able to live log where you can save each log as you test various things it'd make log analysis much easier. I MUCH prefer live logging but its so hard to find something to keep up with the data, I've tried all sorts of tools and devices and only have 1 that's even remotely easy to work with but it comes with some big draw backs. I've been working on a program that is just about ready to test that might make live logging a LOT easier and simplify log analyse by about 10 times less work. I just got my last hope for a tool that I'm praying will work, since Microchip makes most of the CAN chips I figured why not go straight to the source and buy the Microchip development tools. Well they arrived yesterday but I have not tried them yet to see if it's really going to make my life as easy as they tools claim they will. So fingers cross this tool does the trick........
There are 4 parts to car hacking, most don't understand this or see this until they are pretty far invested. 1) Aquire the ArbID and then decode the data bytes for each bit of data and map them out mathematically. 2) A gate way system, you need to be able to read data in real time, change it to something else and then transmit that data back to the other side of the bus with out dropping any packets or slowing down the commutation speed. Can messages have a VERY short window on the amount of time a message is going to be valid for. 3) Design the hardware needed to deal with at least 2 different types of data buss'es. 4) decode the data for the other end of the bus, you need the PCM data AND the vehicles data the pcm will be running. So you actually need to decode 2 totally different data bus's and work out a way to make the data agree with each other.
More to come later......
JoeNova, I know what MS is but have no 1st hand exp with it. In the next month or so I'll be looking for bus data from the MS3 setup. I have framework to get this up and running rather quickly. While it's not so popular I have a tested and 100% working conversion module for an AEM system that won't be very hard to switch to MS3. What I know is that MS2 was a lot harder to work with and data from the bus wasn't easy to log with most tools. To be of any help on that one I would need to have direct access to a working setup to see it first and and figure out how it works.
For those that care...... Holly EFI is also on my list making it directly compatible with the OEM data bus's using one of my data converters. So using a standalone EFI would integrate the same as an OEM pcm meaning stock gauges and all that good would work on the newer vehicles that get cluster data off the bus network.
bbtech......logging many vehicles is far less productive than a couple of very specific one's. Collecting the data is very hard to do it on a computer but it can be done saving it to an SD card with out bottle necking. This does make it hard to split logs if your looking for more then 1 item in the log since your file is just going to run together all as one. Collecting it via SD card is simple and cheap but going though the logs is VERY time consuming. If you were able to live log where you can save each log as you test various things it'd make log analysis much easier. I MUCH prefer live logging but its so hard to find something to keep up with the data, I've tried all sorts of tools and devices and only have 1 that's even remotely easy to work with but it comes with some big draw backs. I've been working on a program that is just about ready to test that might make live logging a LOT easier and simplify log analyse by about 10 times less work. I just got my last hope for a tool that I'm praying will work, since Microchip makes most of the CAN chips I figured why not go straight to the source and buy the Microchip development tools. Well they arrived yesterday but I have not tried them yet to see if it's really going to make my life as easy as they tools claim they will. So fingers cross this tool does the trick........
There are 4 parts to car hacking, most don't understand this or see this until they are pretty far invested. 1) Aquire the ArbID and then decode the data bytes for each bit of data and map them out mathematically. 2) A gate way system, you need to be able to read data in real time, change it to something else and then transmit that data back to the other side of the bus with out dropping any packets or slowing down the commutation speed. Can messages have a VERY short window on the amount of time a message is going to be valid for. 3) Design the hardware needed to deal with at least 2 different types of data buss'es. 4) decode the data for the other end of the bus, you need the PCM data AND the vehicles data the pcm will be running. So you actually need to decode 2 totally different data bus's and work out a way to make the data agree with each other.
More to come later......
#84
PeteS160, I don't know much about the whole process but have studied it a few years now and have found folks using devices in conjunction with a laptop that make the sniffing, recording and identifying messages (in response to manual inputs) relatively easy but yes time consuming. I'm just saying with a set up like this I could gather a parse a lot of data.
there is also online depositories that have at least some of this already.
the black hat guys have been doing at least some of it for a while.
ill be offline a couple of weeks on vaca but will dig in after the 20th.
thanks for your hard work ans knowledge.
its worth paying for on my part.
B
there is also online depositories that have at least some of this already.
the black hat guys have been doing at least some of it for a while.
ill be offline a couple of weeks on vaca but will dig in after the 20th.
thanks for your hard work ans knowledge.
its worth paying for on my part.
B
#85
TECH Enthusiast
Thread Starter
In my last post I said more to come soon.......
I was waiting to share any information until my most recent project was finished. Well this project hasn't been like the rest of my work, this was a business transaction for a couple dozen projects from a fellow data bus hacker. Long story summed up what started as a hobby for a friend several years ago grew into something that they no longer had the desire or time to continue working on or supporting. My data bus work was very similar to what they had been working on but we had much different goals with our designs and target audience. I see data bus conversion as the next generation of tech similar to when people started moving from a carb to EFI a number of years ago.
I was given the opportunity to buy out all the designs, programs and hardware from my colleague and after a great deal of thought I've decided to go "all in" on the idea that data bus conversion will be the future of swaps. I believe this can be done affordably making this type of tech avaible to just about anyone that could afford to do a junkyard LS swap. It's not going to happen all at once and this is going to be a very time intensive project that will likely never end but that could be looked at as a good thing.
Now this isn't some magic device that just plugs in and works with anything, it still requires data mining and decoding the data bus from the vehicle being swapped and that in it self is a daunting task, what have now is a conversion method that has been in use for a number of years and been proven to work in all sorts of application's once the appropriate data has been sorted out. On the engine side of things I now have all the data necessary for dash function on the 512k and 1mb pcm's as well as the E38 pcm's. I also have designs that have been in use for several years doing CAN to CAN, CAN to J1850 VPW, CAN to Analog and J1850 Vpw to J1850 VPW. And of course since these talk back and forth the data conversion can go either way. So doing something like a 3rd gen motor/pcm in a 4th gen chassis would also be possible but I'm not sure what advantage there would be lol.
LS swaps into non GM vehicles are target of this type of device. So doing an LS into a Charger, Mustang or Jeep will become a hole lot easier as I start collecting the necessary data to keep the car's interior working once the stock pcm is removed.
Here are some highlights of what this hardware has done......
I was waiting to share any information until my most recent project was finished. Well this project hasn't been like the rest of my work, this was a business transaction for a couple dozen projects from a fellow data bus hacker. Long story summed up what started as a hobby for a friend several years ago grew into something that they no longer had the desire or time to continue working on or supporting. My data bus work was very similar to what they had been working on but we had much different goals with our designs and target audience. I see data bus conversion as the next generation of tech similar to when people started moving from a carb to EFI a number of years ago.
I was given the opportunity to buy out all the designs, programs and hardware from my colleague and after a great deal of thought I've decided to go "all in" on the idea that data bus conversion will be the future of swaps. I believe this can be done affordably making this type of tech avaible to just about anyone that could afford to do a junkyard LS swap. It's not going to happen all at once and this is going to be a very time intensive project that will likely never end but that could be looked at as a good thing.
Now this isn't some magic device that just plugs in and works with anything, it still requires data mining and decoding the data bus from the vehicle being swapped and that in it self is a daunting task, what have now is a conversion method that has been in use for a number of years and been proven to work in all sorts of application's once the appropriate data has been sorted out. On the engine side of things I now have all the data necessary for dash function on the 512k and 1mb pcm's as well as the E38 pcm's. I also have designs that have been in use for several years doing CAN to CAN, CAN to J1850 VPW, CAN to Analog and J1850 Vpw to J1850 VPW. And of course since these talk back and forth the data conversion can go either way. So doing something like a 3rd gen motor/pcm in a 4th gen chassis would also be possible but I'm not sure what advantage there would be lol.
LS swaps into non GM vehicles are target of this type of device. So doing an LS into a Charger, Mustang or Jeep will become a hole lot easier as I start collecting the necessary data to keep the car's interior working once the stock pcm is removed.
Here are some highlights of what this hardware has done......
Spoiler!
Spoiler!
Spoiler!
#86
Make sure all of your work has some sort of copy protection or patent. No doubt there's some long nose lazy fool sitting back taking notes and ready to steal your work. I would love to put an 09 Escalade cluster in my 99 trans am for my ls3 swap
#87
Agreed. As a former patent attorney, I wouldn't post too much about your actual designs on here.
Good luck - I'm someone who would spend a few hundred to make things easier, so perhaps a potential customer in the future.
Good luck - I'm someone who would spend a few hundred to make things easier, so perhaps a potential customer in the future.
#90
TECH Enthusiast
Thread Starter
Once I finish the cruise module for my current project the next Jeep on my list I think would be considered the TJ? Its the one before the JK and it uses the same data bus type as the KJ and has a very similar message structure.
I've actually had very little interest in a conversion module on most forums/Facebook groups, the vast majority of people seem to prefer piggybacking the stock computer system off the LS and running both computers. The only people that seemed interested in something relatively inexpensive are people wanting 100% OEM type of integration on Pre-Ls swapped vehicles worth like $20,000 and there is already a company that makes a module for vehicles in that category.
There was far more interest in a conversion module for the Holley Terminator X then anything Jeep related but when I was testing the waters of what people were willing to pay for something to interface with the Holley people just jumped on the kick of piggy backing the stock computer again.
#91
1) Cost. It is all there and only takes time to make it work.
2) Necessity. The emulator/BUS converter may not exist to make the gauges function otherwise
In my case, with a 2005 TJ Wrangler, a tach emulator is available, but it is expensive...And I will still need to piggyback the Jeep PCM.
There is definitely a market for your product. Especially, because it can control/translate so much more than just gauges (i.e. cruise control, Rubicon differential lockers, etc.).
Furthermore, I am happy to help data log for you. I have access to stock 2004 Wrangler 4.0L auto 42RLE and a stock 2005 Wrangler Rubicon 4.0L with a manual.
Last edited by sheza65; 02-29-2020 at 07:02 AM.
#92
TECH Enthusiast
Thread Starter
I think this is done for two main reasons:
1) Cost. It is all there and only takes time to make it work.
2) Necessity. The emulator/BUS converter may not exist to make the gauges function otherwise
In my case, with a 2005 TJ Wrangler, a tach emulator is available, but it is expensive...And I will still need to piggyback the Jeep PCM.
There is definitely a market for your product. Especially, because it can control/translate so much more than just gauges (i.e. cruise control, Rubicon differential lockers, etc.).
Furthermore, I am happy to help data log for you. I have access to stock 2004 Wrangler 4.0L auto 42RLE and a stock 2005 Wrangler Rubicon 4.0L with a manual.
I think this is done for two main reasons:
1) Cost. It is all there and only takes time to make it work.
2) Necessity. The emulator/BUS converter may not exist to make the gauges function otherwise
In my case, with a 2005 TJ Wrangler, a tach emulator is available, but it is expensive...And I will still need to piggyback the Jeep PCM.
There is definitely a market for your product. Especially, because it can control/translate so much more than just gauges (i.e. cruise control, Rubicon differential lockers, etc.).
Furthermore, I am happy to help data log for you. I have access to stock 2004 Wrangler 4.0L auto 42RLE and a stock 2005 Wrangler Rubicon 4.0L with a manual.
Logs can be collected with a laptop or a cell phone as long as you have some type of hardware capable of reading messages directly how they appear on the data bus.
99% of the logs I used to map out message bytes used building the conversion module for my Liberty I collected using an OBDLink Lx and my cell phone while I was on test drives with used car lot vehicles I was doing safety inspections on. Gather logs isn't the hard part on anything with J1850 protocol.....it's figuring out what it all means and coming up with formulas to turn the data into data that works with something else.
I am not 100% sure on what year things changed but right around 05/06 is where all the Chrysler stuff switched to CAN protocol. When you look at the DLC if you have a terminal in #2 place then it most likely is still using J1850. There will also be terminals on 6/14 where you typically find CAN however that bus was only used for diagnostics/programming and wasn't what did module to module communication so just ignore those pins.
A 2-3 second data log of bus messages while the vehicle is running and moving would be enough to see how similar it is to what I already have mapped out.
Also...just having a connector for a 2005 Wrangler cluster would also do wonders.....I've had a cluster out of one for quite some time but have not been able to source a connector and given what I had to pay for the cluster I'm not really interested in taking it apart and soldering wiring directly to the circuit board. Chrysler does not sell a repair pigtail for the cluster and none of the local salvage yards will cut the harness in one off those Jeep. I've had alerts setup on eBay for months looking for one but I'm not going to pay stupid money for one.
#93
TECH Enthusiast
Thread Starter
TJ! Yes, please. In particular, the 2005-2006 models. (We've communicated recently on Facebook regarding my tach issues. I believe you're correct, the 32 tooth reluctor wheel/tone ring on the 4.0L flywheel with one wide tooth & one wide gap opposite of each other indicate it is looking for a signal more complex than the GM's Tach Output can provide. This signal should be identical to 3.7L, 4.7L & 5.7L of that era since these crankshaft tone rings share the same pattern as the '05-'06 4.0L.)
This was the first and only pcb design I did as a one off request for lt1swap on his personal vehicle. When I took the design from a bread board to PCB I greatly expanded on the potential use for it thinking there may have been a lot of interest in something like this. The dip switch was setup for selecting the number of input pulses being used and what the designed output wave form it would generate would be. I created something like 3 or 4 CKP profiles while I was waiting for the PCB's to be manufactured but they were specific to GM patterns. The jumper on the left side was for selecting how the input signal would appear, was it a signal that went low to high...or high to low? The circuit had to be flexible since the input signal could be 0-5V, 5V-0, 8V-0, 0-8V or even 12V-0, 0-12V and this was where the trouble started. The input circuit was beyond picky for positive input signal, I built a total of 10 of these modules and 5 of them required a different combination of resistors/transistors for each one to work.....maybe it was just a really bad batch of PCB's or I had a bunch of degraded parts but the amount of time I spent getting 5 of them to work was enough I was already over the whole design concept unless there was some serious interest.
I sent a number off them to lt1swap for some of his other projects and to test long term reliability. I had some other interest initially and sent out most of the prototypes to people who had contacted me looking for something exactly like this and of course these people never got back with me when/if they installed the module. Lt1swap has been using the one's I sent him for a couple of years and other then in situations where battery voltage drops SUPER low(under 10 volts) he has never had an issue with any of the prototypes so other then the input selection circuit the rest of the design was solid however he has only ever used the same input patten/voltage so it doesn't really tell me much about how it would work in other configurations.
Now as far as Jeep specific applications I looked into the crank signal pattern on the 3.7 a couple years ago and it wasn't exactly a simple pattern to recreate but it could have been done until I was told it would also need a cam signal pattern created and that's where this stopped. Making the signal simulator work in real time reading a constantly changing input RPM but to be able to control the speed the output pattern was being generated required using just about every resource the processor was capable of and there was no chance of also adding a cam output signal with the current hardware or program design. It wasn't just creating a second signal that was using a different pattern, it would also need to have been in sync with the crank and that's where the hardware was no longer capable.....at least not with my level of knowledge. I'm sure someone a whole lot smarter then me could make it do both but that would come at a price......something along the line of what the Novak unit sells for I'm sure.
#94
I have OBDLink LX and will figure out how to get some data. If I come across a TJ gauge harness, I will definitely let you know. I wonder if they are the same as other vehicles like a Liberty, WJ or ZJ of that era?
#97
In attempts to finalize my '05 cluster swap, I've been able to follow this thread and some others and get control of my oil pressure, engine temp, and a few of the messages from my laptop. Does anyone have the message structure for volt meter, battery light, and seatbelt light they would be willing to share? Oh and ipc on/off commands?
This is non my 1992 k1500 with an lq4 from an '03 express van.
This is non my 1992 k1500 with an lq4 from an '03 express van.
#98
"
An example of how modules talk to each other would look like this....
1) 8A EA 29 20 A7 00 30
2) AA EB 60 20 A7 00 E7
3) 8A EA 29 20 95 00 69
4) AA EB 60 20 95 00 BE
#1 is the ABS controller sending a message to module EA(Cluster in this case) with a priority of 8A. The actual message being sent contains 2 parts. The 3rd byte of 20 is the command for OFF, if it was being tuned on the byte value would be A0. The 4th and 5th bytes are the item that would be commanded On or Off, in this case A7 00 is the Brake Light . So if we reconstruct the message it would like this. The Abs controller is sending a message to the instrument cluster to turn off the brake light.
"
******
Was able to get these with 20 = off A0=on, last byte 00
C9 - Service 4x4 system
76 - Trans in Warm up msg
83 - Oil pressure low msg
84 - Check Oil Level msg?
85 - Engine Overheat msg
8C - Cruise light on
8E - BATTERY LIGHT
90 - Seat Belt light
91 High beam indicator
94 - Air bag/Seat belt light
95 - ABS circle light
98 - Brake warning light
9A - Traction Active msg
9B - Traction Control Off light
9C - Low Coolant msg
9D - Engine Coolant Hot msg
9E - Security
A6 - Cargo Door Ajar msg
A7 - Service Brake System msg.
Ad - Service Ride Control msg
B7 - Reduced Engine Pwr msg
B8 - Service Stability msg
C2 - Stability System Activ msg
C9 - Service 4 wheel steer msg
CC - Tighten Fuel cap msg
D1 - Service 4x4 msg
D4 - Stability System Ready Msg
D5 - Vehicle Speed limited msg
D8 - Fog light indicator?
D9 - Water in Fuel msg
E2 - Battery Light
E4 - 4wd light
EC - Traction system limited msg
ED - Stability System disabled
F0 - response, no observed change
With A0 9E 50 - Security light flashing
**These are on an 05 2500hd M/T cluster
An example of how modules talk to each other would look like this....
1) 8A EA 29 20 A7 00 30
2) AA EB 60 20 A7 00 E7
3) 8A EA 29 20 95 00 69
4) AA EB 60 20 95 00 BE
#1 is the ABS controller sending a message to module EA(Cluster in this case) with a priority of 8A. The actual message being sent contains 2 parts. The 3rd byte of 20 is the command for OFF, if it was being tuned on the byte value would be A0. The 4th and 5th bytes are the item that would be commanded On or Off, in this case A7 00 is the Brake Light . So if we reconstruct the message it would like this. The Abs controller is sending a message to the instrument cluster to turn off the brake light.
"
******
Was able to get these with 20 = off A0=on, last byte 00
C9 - Service 4x4 system
76 - Trans in Warm up msg
83 - Oil pressure low msg
84 - Check Oil Level msg?
85 - Engine Overheat msg
8C - Cruise light on
8E - BATTERY LIGHT
90 - Seat Belt light
91 High beam indicator
94 - Air bag/Seat belt light
95 - ABS circle light
98 - Brake warning light
9A - Traction Active msg
9B - Traction Control Off light
9C - Low Coolant msg
9D - Engine Coolant Hot msg
9E - Security
A6 - Cargo Door Ajar msg
A7 - Service Brake System msg.
Ad - Service Ride Control msg
B7 - Reduced Engine Pwr msg
B8 - Service Stability msg
C2 - Stability System Activ msg
C9 - Service 4 wheel steer msg
CC - Tighten Fuel cap msg
D1 - Service 4x4 msg
D4 - Stability System Ready Msg
D5 - Vehicle Speed limited msg
D8 - Fog light indicator?
D9 - Water in Fuel msg
E2 - Battery Light
E4 - 4wd light
EC - Traction system limited msg
ED - Stability System disabled
F0 - response, no observed change
With A0 9E 50 - Security light flashing
**These are on an 05 2500hd M/T cluster
Last edited by danbo313; 04-13-2020 at 02:58 PM. Reason: added 9a-9e
#99
TECH Enthusiast
Thread Starter
"
An example of how modules talk to each other would look like this....
1) 8A EA 29 20 A7 00 30
2) AA EB 60 20 A7 00 E7
3) 8A EA 29 20 95 00 69
4) AA EB 60 20 95 00 BE
#1 is the ABS controller sending a message to module EA(Cluster in this case) with a priority of 8A. The actual message being sent contains 2 parts. The 3rd byte of 20 is the command for OFF, if it was being tuned on the byte value would be A0. The 4th and 5th bytes are the item that would be commanded On or Off, in this case A7 00 is the Brake Light . So if we reconstruct the message it would like this. The Abs controller is sending a message to the instrument cluster to turn off the brake light.
An example of how modules talk to each other would look like this....
1) 8A EA 29 20 A7 00 30
2) AA EB 60 20 A7 00 E7
3) 8A EA 29 20 95 00 69
4) AA EB 60 20 95 00 BE
#1 is the ABS controller sending a message to module EA(Cluster in this case) with a priority of 8A. The actual message being sent contains 2 parts. The 3rd byte of 20 is the command for OFF, if it was being tuned on the byte value would be A0. The 4th and 5th bytes are the item that would be commanded On or Off, in this case A7 00 is the Brake Light . So if we reconstruct the message it would like this. The Abs controller is sending a message to the instrument cluster to turn off the brake light.
Or that the source of the message sending it also affects how the message will react.
If you send 8A EA 29 20 A7 00 the light will come back on by it self after a few seconds. And if you look at bus logs you'll see the message is constantly being sent by the ABS module. However the source of the ID sending the message also impacts how the message is treated. When its send from 29(ABS) its a short term light off. But if you send the same message from 10(PCM) the light will go off and stay off with out needing to send the message every couple of seconds like you do when its sent from the ABS.
#100
TECH Enthusiast
Thread Starter
In attempts to finalize my '05 cluster swap, I've been able to follow this thread and some others and get control of my oil pressure, engine temp, and a few of the messages from my laptop. Does anyone have the message structure for volt meter, battery light, and seatbelt light they would be willing to share? Oh and ipc on/off commands?
This is non my 1992 k1500 with an lq4 from an '03 express van.
This is non my 1992 k1500 with an lq4 from an '03 express van.