Getting different CAN BUS protocols to communicate

Thread Starter

Back to school

Joined May 22, 2019
106
This is my first post and I have to admit I don't meet the "profession" requirements offered while joining. If my participation is offending to anyone please let me know and I will withdraw from the forum.

To keep this post from becoming an essay of explanations my goals are ultimately to find a way, if possible, to get the different CAN BUS protocols that were used over the years to communicate with each other. Pre-Can BUS era cars are getting harder to find and often financially out of reach to the average car enthusiast. A lot of devices have become available in recent years to make CAN BUS era vehicles accessible to building but they all involve removing perfectly good harnesses and rewiring.

The current vehicle I'm working on is a 1999 Ford F150. The original protocols of the truck were J1850 PWM and ISO J9141-2. The new crate engine's PCM's protocol is the current mandated ISO 15765. The new engine and PCM work fine but I believe there has to be a way to get the new PCM to communicate with the older control modules so all the original electronic features of the vehicle can be used avoiding the expense of replacing each system individually. This includes everything from the ignition, instrument cluster, ABS, Air Bags to simpler circuits like "Door Ajar," and obviously many more.

I've found products like the ELM 327 which will translate protocols and devices that will capture one frequency or baud rate and retransmit at another but I haven't received any responses from anyone about how these devices can or if they can help me with my goals. I have talked to people who are in the custom ECU business but so far their interest has been limited to engines and engine performance. All they've told me is this can't be done and I'm not interested in building race cars anymore.

I know a lot of people that built cars for years and have just given it up because of the mandated CAN BUS mandates. It's a shame. I would appreciate any thoughts or advice you professionals can offer about achieving my goals. I'm a disabled vet so time isn't an issue for me and I have a masters degree in Economics and was working on my PhD so although this may be new to me I believe I can learn and understand what will be required.

Thank you, Don.
 

OBW0549

Joined Mar 2, 2015
3,550
This is my first post and I have to admit I don't meet the "profession" requirements offered while joining. If my participation is offending to anyone please let me know and I will withdraw from the forum.
"Professional requirements"? We ain't got no professional requirements here. There's people here who can't add two and two and come up with a sensible answer, and people who haven't figured out yet which end of the soldering iron is hot. Anyone can join.

But we also have a bunch of experts, no doubt including some on the CAN bus. Sad to say, though, I'm not one of them; my expertise lies elsewhere (I'm pretty much an "analog guy").

But I imagine someone will come along shortly who can help you.
 
Honestly Don you may be overthinking things. I used to have a 98 Explorer that I knew fairly well. A quick search of wiring diagrams leads me to believe they will be very similar.

For the most part everything will work as is... most of the dash lights and gauges are directly connected to the other end. I can't find my Hayne's manual to check everything out, but if I remember correctly the only thing the engine controller sent to the dash was the RPM and speed. The gauges all went directly to their respective sensors. You may have to find holes for both your current sensors and the ones the new engine ECU expects to see which if you're lucky will be just standard tapered pipe fittings.

There really wasn't any sort of body controller in the Explorer. The wipers were their own system, the radio was it's own system, and the lights were all their own with normal 12 volt on / off signals between when needed.

The cruise will be a challenge. If like the Explorer it was all contained in the box under the hood with the cable coming out. All it needed was a speed input from the ECU and maybe a tach signal too. The brake switch it wired directly, the clutch switch (if present), and the steering wheel controls are all wired directly to the module. If the engine you are installing still has a manual throttle body you could simply modify the cable end and be done other than the speed and tach inputs. If it's of the new electronic variety then obviously it will take some work...

The transmission and transfer case controls all came from the engine controller via separate wires for each valve, sensor, and actuator. The shift lever itself should be connected by a mechanical cable to the transmission gear selector. Obviously you will have some work transmission wise, but it is doable. I should mention I'm assuming automatic transmission... manual will just be wiring up the transfer case. Actually if I remember correctly the transfer case was it's own dedicated controller so that may also just be a case of providing a speed and RPM signal.

I know this is right around the time things started getting more complicated electronics and controllers so I may be totally wrong. I do know the Haynes manual for the Explorer had some pretty good nuggets hid in it about how the electronics worked as well as pretty well drawn wiring diagrams. You may want to see if there's one available for the F150.

Good luck!!
 
Last edited:
One more thing I just thought of... I found that the electronic speedometer sensor from the Explorer's transmission would fit beautifully into a 1976 era Dana transfer case. The only difference it the gear is a little shorter on the Explorer. All I did was swap the gears.
 

Thread Starter

Back to school

Joined May 22, 2019
106
"people here who can't add two and two and come up with a sensible answer, and people who haven't figured out yet which end of the soldering iron is hot. Anyone can join.
OBW0549, thank you for your response. I hate to admit it but I've burned myself more than once with a soldering iron.

geekoftheweek, also thank you for your response. I avoided writing an essay of explanation but the PCM for this engine comes from Ford Performance (formerly Ford Racing) and has little relationship with production PCM's. I have a Ford VCM and subscription link to Ford but it doesn't recognize much about the new PCM. The subscription works based on the vehicle VIN which the new PCM doesn't use or have. What I'm hoping to pull off somehow is to power the original modules and send them the translated CAN data from the new PCM. I will also need to disable the PATS or security\anti theft system because there is no way it can communicate with the new PCM. It doesn't exist so the system will never receive data let alone the wrong data. PATS alone, until defeated will prevent the instrument cluster and ignition from working. I could get this to work but it would require dedicating the CAN Bus to the old PCM.

The truck doesn't have a module called a Body Control Module (BCM) but it does have what Ford calls the GEM module (General Electric Module or sometimes Generic Electric Module) which on the truck controls everything you've mentioned.

Other differences you mention: The new engine is throttle by wire. There is no cable. I have multiple options for speed control from both the engine and new transmission. The truck is 2WD so thankfully 4WD controls aren't an issue.

Other considerations: KWPWR, (Keep Alive Power) isn't as prevalent in the new PCM as it is in the old one. I'm probably going to have to install a boost to the fuel pump or change the pump and as of now, I'm not sure if or how this might effect the original cluster. One system I'm really unsure of has to do with the AC that was in the original truck but is now gone. It's amazing how many systems\circuits data from the AC effects. I'm far from figuring this one out but I may need to add a vacuum pump if I decide to add AC. I want to remove the belt driven PS pump and put in an electric hydraulic pump. The new PCM has an AiM EAPS (Electrically Assisted Power Steering) circuit which I imagine I will have to alter to work with an hydraulic pump but this is far down the list.

I'd also like to use the original harness so I can use the data link on it. The new PCM harness has a data link connector on it but I'd like a second one. I can't find anyone who can or will verify if adding a second data link connector to the new PCM harness will degrade the CAN signals or the voltage. I want to do this because as I work on these goals I can use something like a RacePak instrument cluster which can run off the data link and allow me to legally drive the truck. Dedicating the data link to the cluster means it's not available for any other purpose.

This I hope gives you an idea of what I'm working on. BTW, I'm often accused of over thinking things.
 
back to school... I think we're kind of thinking along the same lines. Unfortunately I know little about how CAN networks work, but I would think a well built connector shouldn't cause a problem as long as your terminating resistances are kept within spec after you add on whatever... it's done from the factory that way more or less.

The fuel pump may cause a problem due to the sending unit's resistance for the fuel gauge, but other than that is should not affect anything else.

Do you by chance have the digital odometer? I don't remember when that started, but thought of that and thought it might throw a wrench in my thinking. My Explorer had the mechanical type which may lead to incorrect thinking on my part.

If your gauges are how I imagine and individually wired to the sensors converting the CAN will be the easy part... the hard part will be getting the gauges right. Analog gauges have a huge curve in the voltage to position values that make them tough to do anything with. I've tried driving a few with a PWM signal and due to how they physically work there are just too many variables to account for. It's just not worth the time in my opinion. You would be better off plumbing in the stock senders / sensors until you get your new dash.
 
I forgot to mention the speed and RPM gauges on the other hand should be just a simple square wave to figure out.

Feel free to write an essay or two. There are some pretty smart people on here that may know a better way with the right details. I'll try based on my knowledge of my Explorer, but I might be talking apples and oranges in this case.
 

Thread Starter

Back to school

Joined May 22, 2019
106
back to school... I think we're kind of thinking along the same lines. Unfortunately I know little about how CAN networks work, but I would think a well built connector shouldn't cause a problem as long as your terminating resistances are kept within spec after you add on whatever... it's done from the factory that way more or less.

The fuel pump may cause a problem due to the sending unit's resistance for the fuel gauge, but other than that is should not affect anything else.

Do you by chance have the digital odometer? I don't remember when that started, but thought of that and thought it might throw a wrench in my thinking. My Explorer had the mechanical type which may lead to incorrect thinking on my part.

If your gauges are how I imagine and individually wired to the sensors converting the CAN will be the easy part... the hard part will be getting the gauges right. Analog gauges have a huge curve in the voltage to position values that make them tough to do anything with. I've tried driving a few with a PWM signal and due to how they physically work there are just too many variables to account for. It's just not worth the time in my opinion. You would be better off plumbing in the stock senders / sensors until you get your new dash.
The sensor data on the truck is transmitted over the CAN and diagnostic protocol. The gauges are not directly wired to the sensors. I considered trying to break out the sensor data and send it directly to the gauges which are electronic. I was told that this could be done but it would degrade the signal to the gauge and the data link if both were tried to be used at the same time. I haven't verified if this is true or not but it makes sense considering the basics of Ohms Law.

The Odometer is digital. I can take the signal from the engine or transmission and the transmission also offers the use of a gear and cable. There are devices available that translate the analog cable signal to a digital one.

I've put a higher capacity Walpro pump on the sending unit but I haven't pushed the engine to the point yet to know if this alone will work. I really am trying to stick to the engines break in procedure this time. It's also possible new higher capacity injectors alone will solve any problems if there are any. This may involve some pulse width tuning though.

I've got a couple of Wi-Fi data loggers sitting around and I expected to use one on the truck along with a removable Windows tablet mounted in the truck. Like you, I don't want to mess with analog gauges because of their quirky effects on voltage. I'd have to go to stand alone circuits for them and that's one of the issues I'm trying to avoid.

Ultimately what I want to do if I can is translate the mandated ISO 15765 protocol to J1850. That's easy enough to do with an ELM327 interface but will inserting the translated CAN data in to the old circuits along with separately powering the old modules be enough to get the old modules and devices operating properly? I also don't know if an ELM device will properly translate the proprietary data? I don't want to put a lot of time into this to find out I can only get half way there and have to start over.

Apples and oranges or not your input helps. It gets me thinking and helps with focus. I sometimes get scattered and lost in this. Thank you.
 
Last edited:
I believe the odometer made the difference. I'm pretty sure my sensors all had splices... one wire to the dash and the other to the PCM.

This sounds like a fun project in ways. I haven't dug into anything newer since I had the Explorer so I have no clue about modern day electronics in cars and trucks. Good luck.
 
Maybe you've already seen this... https://www.instructables.com/id/Low-Cost-OBD2-Communications-on-K-line-ISO-9141-2-/

Even with the element of proprietary data at the simplest level it should at least follow the basic message format and use basic defined messages where possible. Engine data, basic diagnostics, and some safety related things I would think would follow the spec just because the standards are due to regulations to begin with. The lights and creature comforts should be able to be worked out over time.

Your project resembles one of mine in a way... same concepts, but totally different vehicles.
 
Unfortunately I doubt the ELM 327 will translate proprietary data. At best it will just ignore it and you'll have to find another way. It doesn't seem to be programmable either in the sense you could add your own translations or rework the internal code to meet your needs.

Doing a little research on my own project and poked around the datasheet.
 

Thread Starter

Back to school

Joined May 22, 2019
106
Most of what I'm looking for should be available. The bigger problem is Ford quit supporting and publishing almost everything pre-2008. Even most post 2008 proprietary data is available through developer.ford.com using openxc. The problem with this resource is it's mostly used by professional developers that don't have much patience for non-professionals. Systems that few will be able to break in to are those like "Sync" which is Ford and Microsoft's partnership with satellite communications with vehicles. Considering Jr. high and high school kids demonstrated to Homeland Security they could take over vehicles over Sync and all the manufacturer's interactive communication systems I'm fine with them not being accessible. They proved on simulators and on closed tracks they could wreck cars. Some of these kids became employed by places like Bosch after the demonstration. Those that do get access go through a long and involved security process. From what I understand though, those that go through the process get large, instant pay raises and guaranteed job security.

What I have to deal with are systems that are initiated with OBD, those that communicate with OBD and those that have nothing to do with OBD. Those that communicate with OBD are available, Those that have nothing to do with OBD don't matter for now. The problem is with those systems that are only initiated through OBD. As I understand it, those systems are not on keep alive power and are turned on by a gate through the PWM or Gem module when the key is in and turned to power. Once the power is on they are powered up and only get turned off by turning the key off. It doesn't matter if the system is being used or not. They are available. That's a clue to how the systems work. If the lights on a vehicle are left on but turn off after a timed event while the key is out than lights are not an OBD initiated only system because the power is off at the key. This is not necessarily true with post 2008 vehicles. A system not easily accessible would be the radio or power windows not on the timed system. Something like ABS, I'm not sure of.

Granted, I have my work cut out for me. If I wasn't doing this though I'd be looking for something else to do. The joys of retirement. I accept I may never get it done??? I've been told by some custom ECU designers that this can be done but it would be a handful for a OBD Can designer let alone what's basically a hobbiest in automotive electronics, me.

I did come across something yesterday about how until 2002 I think it was, some cluster functions were kept old school. That explains why your speedo is on a cable while mine isn't even though they are basically the same vehicle on the same chassis. There was no explanation about why this was done. Just that is was.
 
Last edited:
I'm starting to get a better sense of how it all works. I kind of made some way wrong assumptions from the beginning... you know the ins and outs more than I'll ever get around to learning.

Actually my speedo runs off the PCM. It's kind of a hybrid thing where there's a motor in the dash to spin everything like a cable would. I'm guessing it's kind of an in between design where they were starting to convert things over, but just didn't go the whole way. Something sparked the memory of the digital odometers in the trucks and I started to realize I was probably wrong the whole time.

I'm slowly working out a J1939 reader for heavy duty equipment (semi trucks mostly). Unfortunately I don't have one sitting in my driveway to tinker with and there isn't much information online to work with. We have the right software for what we normally work with on a daily basis, but for the rest I thought maybe if I had a way to watch for changes in the message patterns it may help with diagnosing a few things here and there. There are certain things that should be common to all due to the spec, but nothing is actually mandated as far as I know so it will be hit or miss as to what actually works and what doesn't.
 
That is pretty awesome Ford put the information out there for people. I was always under the impression they were a little more free with information than the rest are. You could almost see it in the Haynes books.
 

Thread Starter

Back to school

Joined May 22, 2019
106
Actually all the US companies have opened things up when it comes to the operation of electronics. They didn't do it out of the kindness of the hearts. Far from it. They were very comfortable with the laws we had about hacking their software. This was forced on them by the EU and legislation they passed about what they call "Blocking." Blocking isn't only in the sense of interference but about legislation mandates that pull together things that are similar to create conformity within the laws. Especially between the US and Europe.

Almost all manufacturers in the EU started with their electronics being open source but the new laws mandated it on all vehicles sold in the EU. It wasn't only about electronics. Companies made contractual agreements with suppliers for their spare parts which made it illegal for anyone else to make the parts. The blocking laws made it so anyone could make the parts. Obviously prices on spare parts dropped fast. The US companies accepted adopting the EU laws company wide rather than build EU specific vehicles or give up the EU business. We can thank the EU that none of what we are talking about still being illegal in the US. There are still aspects that are proprietary like Ford Sync or GM Onstar. For Sync and Onstar it's a separate contractual obligation with system originators. There are also access limits where safety and security are involved.
 
I did do some more looking at the ELM 327. I'm getting the feeling it is only designed to work with one bus at a time. Most likely you will need one for each bus. If I'm correct they should look like a diagnostic tool to the rest of the respective bus so it shouldn't cause any problems there. One of the biggest issues is going to be the speed of the whole operation. Having one decode the message, send it to your processor (computer, microcontroller, whatever) to be processed, then sent to the other ELM 327, and finally back out to the other bus may create a noticeable lag.
 

Thread Starter

Back to school

Joined May 22, 2019
106
I'm not sure what you're getting at? I have a couple of problems to solve. The first is running two PCM's at the same time. This is necessary because of the embedded controllers in the original PCM. Everything that isn't OBD(2) related shouldn't be an issue. What is OBD(2) related or initiated is what I'm most concerned with. The speedometer for example as we discussed. I can't send two different protocols to the instrument cluster. Converting protocols speeds should be controlled by the convertor. That's part of the converting process using protocol standards. All am ELM327 would be used for is to look at what and how information is being processed by using a PC so I can see the signals. The ELM327 would not be a permanent data link fixture. If I can do this, which I don't know, I won't be using the data link. I originally hoped I could do this connector by connector but I realizing more that it may have to be done circuit by circuit. A PITA and may beat me done to giving up.

For now I'll start with data that is only read by the PCM's, sensor data voltage. Can I send the data to both PCM's without degrading the signal? The problems will be with data that communicates with the PCM like variable cam timing. For example, data that communicates with the check engine function rather than just singularly sensed by it.

I have a pretty good understand of the CAN Bus system but suing two protocols at once and getting what needs to transfer between the two is all new to me too. But from what I understand it doesn't matter how often a signal gets on to the CAN Bus as long as the protocol is accepted. If the frequency and baud rate match, the protocol will accept the data. Data is prioritized so there is no mandated consecutive, organized data loop the data must fit in to be accepted by the protocol. If processing data eats up a second or two, I'm not sure that matters for a street vehicle. Am I making sense?
 
I guess I should have re read the original post. I'm not the best visualizer, don't have the experience, and this is really out of my league. It would be fun to learn and figure out, but without seeing it I won't be any help... and even then who knows. Good luck!!
 
Top