J1939 communication.

xtech007

Senior Member
Good Morning all!
Did searched on the forum but no luck.
OdbII did showed up, but that's not the same.

Can any of the picaxe chip family communicate with J1939 devices?
At the moment just want to receive data from the device and display the data .

Thanks in advance!
 

hippy

Technical Support
Staff member
Can any of the picaxe chip family communicate with J1939 devices?
Not sure because I have no idea what a J1939 is. Do you have a link to the device datasheet and/or details of the protocol it uses ?
 

xtech007

Senior Member
J1939 for heavy equipment

Hippy thanks for your interest!
J1939 is used on heavy duty equipment and trucks to communicate with ECU and diagnosis codes. Just like ODBII Protocol.

Here is a link:
http://www.sae.org/misc/pdfs/J1939.pdf
How packets are sent.
 

JimPerry

Senior Member
:confused::(
Hippy thanks for your interest!
J1939 is used on heavy duty equipment and trucks to communicate with ECU and diagnosis codes. Just like ODBII Protocol.
.

Controlling tractors and diggers with a Picaxe is not recommended
 

xtech007

Senior Member
not TryiNg to CoNtRoL any equipment!

I see the confussion!
Not trying to control, but read data off from it!
Like your code scanner from cars that use ODBII.

I would like to get that data and display it on an lcd via picaxe!

Trust me it only allows you to read data not send, like rpm, oil temp, coolant and that sort of stuff.

No heavy equipment or vehicle allows you to control its ECM's, just read of from it and erase some trouble codes.

The only way I have controlled tractors in the past with ECM's Via RC with actuators and cylinders on the pedals and steering wheel!!!
Scary!!!!
 

MFB

Senior Member
I think you need to search the range of PIC based products that are specifically programmed to bridge between automotive networks and any microcomputer with a UART. There are certainly versions available for LIN and CAN for example. Although all the low level communications will be handled by the bridge device, you may still have to undertake some PICAXE development to decode and display data.
 

PhilHornby

Senior Member
According to Wikipedia, the ELM327 understands SAE J1939 (250kps & 500kbps). Wikipedia would have you believe that the cheap Chinese clones are useless, but in my experience they aren't. (Buy a cheap module from eBay, crack it open, remove the USB interface and wire directly to the PIC... My very first Picaxe project monitored an ECU for pending faults, and reset it before they could become hard faults and switch on the Check Engine lamp - the car ran fine with a dead Camshaft Position Sensor!).

That's where I start to get a bit hazy though ...
...the cheap ELM327 'modules' contain hardware interfaces for "K-line" and CANBUS ... i.e the actual hardware level. They contain the ELM327 (PIC) itself which handles protocols such as ISO 9141-2 that I used, or SAE J1939... and various others. Then there is a higher level protocol: I was requesting EOBD PIDs which are apparently defined by J1979.

I assume there must be a different, but equivalent definition to J1979 for use in the Truck world ... but I've no idea what it is? ... or if the ELM327 understands it. Another complication might be the physical connection to the vehicle ... is the J1962 connector used?

This document: https://www.kvaser.com/about-can/higher-layer-protocols/j1939-standards-overview/ seems quite informative. It seems to imply a whole set of J1939 standards. ELM327 may only do some of them.
 

inglewoodpete

Senior Member
A PICAXE could not interface directly with any vehicle bus due to the overwhelming amount of data that these systems produce. As Phil mentioned, the ELM327 or its many Chinese knock-offs are an entry level interface built on an 8-bit PIC. Even so, you may need to set up some serious data filtering if you want to monitor your vehicle's diagnostic bus with a PICAXE.

A better interface is the STN1100 series of interface chips (based on a 16-bit PIC). The STN1100 emulates everything that the ELM327 does, with much better filtering capability using the its 16-bit core and more RAM. Sparkfun offer an interface module that uses the STN1100.
 

xtech007

Senior Member
interesting!

Thank you guys for the explanations.
Will check out few modules and go from there. On my own research did find some modules that do the conversion from CAN to UART and others to serial.
Maybe we can go from there!
CAN is actually the native protocol for
J1939.
 

PhilHornby

Senior Member
A PICAXE could not interface directly with any vehicle bus due to the overwhelming amount of data that these systems produce. ... Even so, you may need to set up some serious data filtering if you want to monitor your vehicle's diagnostic bus with a PICAXE.
I don't know if that's necessarily the case - if you connected directly to the main vehicle CANBUS, that could be true, but normally you are connected via the Diagnostics Socket directly to the ECU, albeit by another, separate, CANBUS. At this point, unless using the undocumented, manufacturer-specific protocols, you're limited to the OBD (emissions-related mainly) stuff - and most of the interesting stuff is inaccessible.

Having said that, even on 64MHz 20X2, a project like this might be out of reach: http://hackaday.com/2011/03/08/can-sniffing-for-steering-wheel-button-presses/

Trust me it only allows you to read data not send, like rpm, oil temp, coolant and that sort of stuff.

No heavy equipment or vehicle allows you to control its ECM's, just read of from it and erase some trouble codes.
Don't be so sure!

I know that in the car world, the manufacturer-specific protocols allow you change all manner of things - for example, using this software it was relatively easy to change my car's Power Steering sensitivity ... along with quite a few other tweaks ;-)
 
Last edited:

inglewoodpete

Senior Member
I don't know if that's necessarily the case - if you connected directly to the main vehicle CANBUS, that could be true, but normally you are connected via the Diagnostics Socket directly to the ECU, albeit by another, separate, CANBUS. At this point, unless using the undocumented, manufacturer-specific protocols, you're limited to the OBD (emissions-related mainly) stuff - and most of the interesting stuff is inaccessible.
There may be some vehicles that keep the CANBUS separate from the diagnostic but not very many. On my late model Toyota, for instance, the "diagnostic jack" is directly connected to the main CAN bus- as I said, (almost) overwhelming amounts of data at over 1Mbits/s. To use your words "plenty of interesting stuff", mainly in Toyota's high-level propriety protocol. You'd spend a lifetime decoding it if you tried. The only separate bus is the certification bus (remote key receiver: lock/unlock/immobiliser and/or smart key, depending on model).
 
Top