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.
How much current can I source though the OBD2CAN???
How much current can I source though the OBD2CAN???
- Attachments
-
- RACE CAPTURE 2 - NEW Schematic - no Analog Gages.pdf
- (41.11 KiB) Downloaded 370 times
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
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
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!
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,
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
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
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!
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!