OBDII - J1850 and CAN Protocols

[LCD Gauges]

As I move my focus to programming and developing an OBDII module for the LCDi system, I'm wondering
how much time should be spent on CAN bus. My guess is very little at the moment.

If you have a second, please reply or update the poll with your PCM's communication protocol. If you're not
sure, most engine computers before build year 2006/2007 will use J1850. I suspect most of us will fall into
this category.

From 2008 onward, all PCM's use the CAN bus protocol.

Thanks for your time!
Tino

[LCD Gauges]

My guess is very little at the moment.

I guessed wrong! Based on this small sample so far, I'll have to split my time equally on these platforms.

[Blast3r0]

Tino,
I answered CAN however it is an aftermarket Holley ECU, I'm expecting you will see a lot more of the Holley,Megasquirt, and other stand alone ECUs end up in these cars. Holley offers a CAN dash for 800$ specific to their ecu on a 7" screen but is only so customizable. I'm not sure which market you would like to go for but I thought I'd throw that information out. There are still plenty of people that run the obd ecu's for swaps especially within groups like sloppy mechanics that could take advantage of a customizable dash.

[LCD Gauges]

Thanks for the reply. I checked out Holley and other similar units (Autometer, MoTeC, etc.) and they all seem to have the typical basic 7" display.
$800 USD for the Holley 553-106 - Digital Dash . Sensors and features such as GPS($107), harnesses, etc. are extra from what I've read.

My kit will work with the Holley, Megasquirt, and any other stand-alone ECU's which is awesome. The only feature that is questionable is whether
I'll have the ability to tap into their CAN bus to receive standard OBD diagnostics.

Maybe I'll bother you one day to become a beta tester (once I get my CAN controller working) . :cool:

[LCD Gauges]

I'm very close at configuring the OBDII code. CAN bus is closer than J1850; I'm hoping to
have both going for early April.
6558365584

These are the PID's that I'd like to have working for the first release, along with the ability to
clear error codes:

#define ENGINE_COOLANT_TEMP 0x05
#define FUEL_PRESSURE 0x0A
#define MANIFOLD_PRES 0x0B
#define ENGINE_RPM 0x0C
#define VEHICLE_SPEED 0x0D
#define IGN_TIMING 0x0E
#define INTAKE_AIR_TEMP 0x0F
#define MAF_SENSOR 0x10
#define THROTTLE_POSN 0X11
#define O2_VOLTAGE 0x14
#define ENGINE_RUN_TIME 0x1F
#define CYCLES_SINCE_CLR 0x30
#define DISTANCE_SINCE_CLR 0x31
#define BARO_PRESSURE 0x33
#define OUTSIDE_AIR_TEMP 0x46
#define OIL_TEMP 0x5C
#define INJECTOR_TIMING 0x5D
#define DEMAND_TORQUE 0x61

[Tmzand]

Looks like some good stuff on that list. The advice when logging with Hptuners is to keep the # of pid's below like 20 or so, guess you already know. Probably to keep network traffic on an acceptable level.

You can probably send can messages as well? Thinking of ac request and Cruise control for LS swaps running standalone e38's.
Might be a way to open the market.

I've been trying to find gmlan protocol info, but found only scattered bits. Most seem to not be standalone ecm (bcm kept)
You might want to check out https://is.gd/gmlanbible if you haven't already.

I have a datalogger/dash from aim trying to find a solution for injecting ac and cruise can messages, no cigar yet.

FWIW
/Thomas

[LCD Gauges]

Thanks for the link Thomas, I'll check it out.

You are correct about the amount of PID's to poll; having even 15 would slow the system down considerably, however CAN is much faster than J1850.

The PID's above will be used for polling or data logging, but not all for displaying necessarily. Some of the
critical parameters such as fuel pressure, tachometer, oil pressure, manifold pressure will be polled by the
LCDi box in real-time.

CAN bus will be used for the more basic items that don't need immediate attention like ECT, Fuel level, and
turn signals to name a few.

Sending CAN messages is not a problem. You can do pretty much anything to a device that's connected to
the network. With my little adventure programming the Ford GT's, we would poll several devices for information
and test the horn, individual lights, turning on the A/C, etc., directly from a laptop.

Essentially, everything you interface with (buttons, switches, levers) as the driver is not connected directly
to a piece of hardware. If you press the A/C button, the computer checks whether you pressed the button
and reads it as a CAN message.

The computer then interprets that message as a request and sends the appropriate command to the
corresponding output. It's a crazy system and I often ask myself why a simple light couldn't be
connected with a wire and a switch...there doesn't seem to be any reduction in vehicle wiring using CAN.