How much current can I source though the OBD2CAN???

Discussion and research on OBDII integration, especially on OEM specific PIDs from Ford, GM, Chevrolet, BMW, Porsche, Audi, Toyota, Volkswagen, Mazda, Honda, Subaru, Mitsubishi and others.
Post Reply
davef_dci
Posts: 38
Joined: Wed Mar 22, 2017 4:57 am

How much current can I source though the OBD2CAN???

Post by davef_dci »

Howdy,

I am using the Race Capture Pro 3 with a 96 Dodge Neon. Previously we were piggy-backing our existing mechanical gage cluster with the race capture on an android.

For this race we are proposing two big changes:

1) We've decided to go "all-in" on race capture and dump our analog gage cluster.
2) We purchased the OBD2CAN harness and hope to use this to get MAP and RPMs directly.

Many of our sensors are NOT on OBDII so we'll still need to power secondary sensors. This includes fuel tank level, oil pressure, oil temp, H20 temp and trans temp. In addition, we hope to add a brake light sensor so we can grab GPS coordinates when we brake.

We have the cheap low resistance gauges (the one's that Brent doesn't recommend). I have characterized the resistance as a function of the measured value for each of them though.

I'm planning on using roughly 250 ohm pull-up resistors as shown in my schematic below.

Previously i was powering these sensors via 12V so that the old analogue gages would still work - but now I'm assuming I need to use the Vref (5 v).

Can I still source enough current through the OBD2 cable to power all these sensors? It would seem that the load per sensor is still pretty low (V=ir - V = 5V. Rmin = 250 ohms. i max = .02 amps).

Mechanical engineer here so I just want to make sure I'm not missing something.
Attachments
RACE CAPTURE 2 - NEW Schematic - no Analog Gages.pdf
(41.11 KiB) Downloaded 4 times

gizmodo
Posts: 138
Joined: Mon Aug 05, 2013 10:22 pm

Post by gizmodo »

I have the OBDII adapter on a 2005 neon and when compared to the tach driver input I have the OBDII RPM data shows a significant lag.

davef_dci
Posts: 38
Joined: Wed Mar 22, 2017 4:57 am

Post by davef_dci »

that's good to know. Has Brett weighed in?

I can stay with the Coil-X RPM we currently have but the reason we got the ODBII was that it was the only way to get MAP. We are hoping to data-log RPM, MAP and O2 (we have a wide band O2 sensor) so we can see fuel mapping.

It makes me nervous - if there is a lag on MAP I'm wondering how that will map to our RPM and O2 if those are coming in via traditional sensors.

Brett, are you looking at this thread? Any ideas?

Dave

brentp
Site Admin
Posts: 5955
Joined: Wed Jan 24, 2007 6:36 am

Post by brentp »

Hi, Brent here :)

gizmodo is right, you should keep the fast sensors on direct wire connections, especially RPM. The best use for OBDII is for slow moving sensors, such as temperature and so on.

We have a pretty advanced OBDII query scheduler that optimizes channels with faster sample rates - we do everything possible to query OBDII data as fast as the ECU will allow.

Must read: this blog post explains why OBDII is inherently slow and how we're squeezing the most amount of performance out of it : https://www.autosportlabs.com/racecaptu ... -released/

For power consumption it safely handles 12W of power. You should be fine with your sensors - but that's mostly limited to the current capacity of the 5v Vref (500mA on MK3, 1A on MK2).

Hope this helps!
Brent Picasso
CEO and Founder, Autosport Labs
Facebook | Twitter

davef_dci
Posts: 38
Joined: Wed Mar 22, 2017 4:57 am

Post by davef_dci »

Brent,

that's very helpful and I learned a great deal from the article. It's possible what we're trying to do won't work. We'd like to use data logging to recreate our fuel map. So as inputs to the map we have RPM and MAP (as a proxy for engine load) and the output is the reading from our wide-band O2.

Our wide band O2 is an on an analog input and I can keep RPM using the CoilX, however our only access to MAP is via OBDII - we've not had the courage to piggy back that into an analog input.

Do you have any sense of what the lag is likely to be on a MAP reading via the OBDII?

Ideally, we'd like to log RPM, MAP and O2 at an instant but if the MAP we are reading is actually lagging the RPM and O2 readings our fuel mapping won't be very useful. Any thoughts on what we're trying to do?

Dave

brentp
Site Admin
Posts: 5955
Joined: Wed Jan 24, 2007 6:36 am

Post by brentp »

Hi Dave,

The lag is entirely dependent on the OBDII protocol and the design of the ECU and how fast it actually responds to OBDII queries.

You can do some direct measurements by just enabling one channel - RPM or TPS and observe how fast the response is. E.g. you could measure the lag between 0% TPS and 100% TPS.

If that's not acceptable for you, you could add a secondary MAP sensor and tap that into your intake manifold.

Hope this helps!
Brent Picasso
CEO and Founder, Autosport Labs
Facebook | Twitter

Post Reply