Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations waross on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

I need to test mixing J1850 and J19

Status
Not open for further replies.

RRiver

Automotive
May 21, 2018
119
I need to test mixing J1850 and J1949 protocols on a vehicle CAN Bus. Both signals are operating at the OBDII application level. Because both signals are operating at the same OBDII I don't see any problems and none of the later extended format signals are involved. I do want to protect the modules though should I be wrong and place a signal blocking device like a diode on the signal Bus so nothing can inadvertently backtrack and damage the source module. I'm no electrical engineer though. Will a diode work for this and what size would I need?

The purpose or goal of this testing is to retroactively update older vehicle electronics without reinventing the wheel for the garage mechanics building cars but have no understanding of modern vehicle electronics. I can further explain what's going on but want to avoid an essay for now.
 
Replies continue below

Recommended for you

Something seems amiss. What is J1949?

I would guess that operating multiple standards on the same wires is much the same as adding electrical noise and will interfere with and/or degrade the performance of the various components.
 
My mistake. Sorry. J1939 which allows for the extended frame format is what it should have read. I'm not sure why you say interference and degrade? Isn't the worst that can happen is the signal is rejected by the Bus? If accepted by the Bus the worst that can happen is there is no place that will accept the signal.

For example: VSS or variable speed sensor. Someone puts a donor engine and PCM in an older existing OBDII vehicle. VSS, for Ford anyway, is an Engine PCM initiated signal. If that signal is tapped in to the existing wiring and the original engines PCM VSS signal is removed why would it not be accepted? It's no different. If someone is doing this through the datalink there is no problem but it eats your datalink.
 
How many devices are actually able to listen in? My concern would be that someone shortcutted their design and the extraneous data winds up sending one or more devices to la-la land.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
 
IRstuff,

My apologies for missing your post. I thought this had run it's course with responses.

The number of devices doesn't matter. Here's an example of what is wanted. The Ford FRPP Copperhead Control Pack PCM doesn't have a VSS (Vehicle Speed Sensor) out. Let's say the shop in question is doing a resto mod on a F150 and installing a 5.0 Coyote engine and a Tremec TKO transmission (manual). Ford, for the F150 used an electronic VSS and the output to the instrument cluster came from the PCM. The Tremec allows for both a cable\gear speed output or an electronic VSS sensor. If the proper 8,000 pulse VSS for the Tremec is used the sensor output can be directly spliced in to the original PCM VSS input and will output the information to cluster. The cluster will accept the signal with no problems. The original PCM won't discriminate against the new sensor. It won't notice any difference.

---Bear in mind the FRPP Copperhead PCM does nothing but control the engine with limited extended functions like for the effects of running AC. There is no interference between the trucks original PCM and the Copperhead. The only way any interference "may" be involved is if they try to communicate with each other. Both the OEM PCM and the Copperhead PCM use the J1850 protocol for the CAN. The difference is the Copperhead uses the newer, extended format Bus, ISO 15765-4 which didn't become the mandated US standard until 2008 although most vehicles were compliant in 2006.

(I've tried to upload an image here but I'm not sure what's going on with images or pasting to the forum. The image button does nothing. Nothing seems to work although as an attachment it might have?)

Not looking to write an essay (I've been informed not to in the past) but it is the ISO 15765-4 that I'm concerned or unsure of. I don't think there will be any issues collecting the data needed to get it to the cluster but my primary concern is protecting the Copperhead PCM. I'm thinking if I use a diode I can protect any unwanted signals trying to communicate with the Copperhead. Problem is I have no idea of what diode(s) I would need to use to test the transfer of information to the OEM PCM. I'm not even sure a diode would work for this application. Ultimately I don't think I'll have any problems with the engine signals like the oil pressure or coolant temperature from the Copperhead but I'd feel better with some insurance.

I hope I've made myself clear with this???? If not please let me know. Signal interference from multiple standards was mentioned but there really aren't multiple standards for the information I'm wanting to collect and transfer. ISO 15765-4 does allow for extended signal formats but it doesn't mandate all signals to be extended. From what I'm told it is primarily used for capabilities like traction control where information from multiple sensors are used at once.

If this is too long please let me know. EDIT: Ah, the attachment is the datalink by protocol.
 
 https://files.engineering.com/getfile.aspx?folder=f3b78126-c5bd-4920-854e-a2ac967b016f&file=OBD2-Connector-DLC-Data-Link-16-Pin-Out-J1962-.png
Status
Not open for further replies.

Part and Inventory Search

Sponsor