OBD2 splitter that works

[jflogerzi]

Does anyone know of a working obd2 spliter that will allow for 2 monitors to work at the same time. Example p3 vent gague and ecutek bluetooth to monitor the car(no flashing) or a generic obd2 to be used with hp tuners track addict...

Sent from my GM1915 using Tapatalk

[FR-S2GT86]

I don't think you would be able to get two OBD2 plug-in tools to work coherently. I actually have a splitter in my system to use as an extension and for testing purposes, but I would not try plugging two tools in at once for fear of confusing the ECU and doing some permanent damage.

[Brz866]

I use a splitter on my OBD2 port. My maestro for gauges on my pioneer headunit and the other end for tuning on ecutek. Unfortunately though, I cannot use both monitors at the same time as the OBD2 can't do this. So we're stuck with one at a time on an OBD2 system. No damage caused it just reads one or the other.

[BRZyJ]

Huh, I've been using a cheap one from Amazon for the last ~3 years, connected to a ScanGauge II and an OBDLink SX and they both work at the same time no problem.

[jflogerzi]

Originally Posted by BRZyJ

Huh, I've been using a cheap one from Amazon for the last ~3 years, connected to a ScanGauge II and an OBDLink SX and they both work at the same time no problem.

Tried a cheap one from Amazon and no dice. Once the ecutek one kicks on it kills my p3 vent gague

Sent from my GM1915 using Tapatalk

[timurrrr]

Originally Posted by jflogerzi

Tried a cheap one from Amazon and no dice. Once the ecutek one kicks on it kills my p3 vent gague

That might be a problem of the gauge rather than the splitter.
What parameters do you use the gauge for?

[ermax]

Yeah it’s not the splitter that is the problem. There are actually hundreds of things connected to the CANbus. If two devices are communicating in a conflicting way then you will have issues. But it’s not the splitter at fault.

[jflogerzi]

Originally Posted by ermax

Yeah it’s not the splitter that is the problem. There are actually hundreds of things connected to the CANbus. If two devices are communicating in a conflicting way then you will have issues. But it’s not the splitter at fault.

Damn they are trying to access the same data so makes sense

Sent from my GM1915 using Tapatalk

[timurrrr]

Assuming you use the gauge for things like oil temperature, AFR, etc.:
if it doesn't work it just means that it isn't a well-designed product.

The way the OBD-II protocol works is that each device first sends a request for certain data (PID request),
and then the car responds with that data. It is a high-level protocol implemented over lower-level protocols,
such as the CAN bus. The OBD-II connector has the pins for the CAN bus (more on that later).
OBD-II is not a very efficient protocol. The biggest benefit is that it's standardized, and widely supported.
It's possible that when there are multiple devices requesting info at the same time using this protocol
they start to interfere with each other, up to the point of not functioning at all.

A purpose-built digital gauge for BRZ/FRS/86 could instead read the data from the CAN pins of the OBD-II
connector without using the OBD-II protocol. The car broadcasts a lot of data all the time
(see some info here), without the need for the peripheral device to make any requests.
The downside is that it's not standardized.

If a digital gauge designed for BRZ/FRZ/86 can't just listen to those, it's not a very well designed gauge.
From the manufacturer's perspective, "it works in most cases" and they've either never tested
interoperability with other peripheral devices; or not prioritized that.

[Compelica]

Originally Posted by timurrrr

Assuming you use the gauge for things like oil temperature, AFR, etc.:
if it doesn't work it just means that it isn't a well-designed product.

The way the OBD-II protocol works is that each device first sends a request for certain data (PID request),
and then the car responds with that data. It is a high-level protocol implemented over lower-level protocols,
such as the CAN bus. The OBD-II connector has the pins for the CAN bus (more on that later).
OBD-II is not a very efficient protocol. The biggest benefit is that it's standardized, and widely supported.
It's possible that when there are multiple devices requesting info at the same time using this protocol
they start to interfere with each other, up to the point of not functioning at all.

A purpose-built digital gauge for BRZ/FRS/86 could instead read the data from the CAN pins of the OBD-II
connector without using the OBD-II protocol. The car broadcasts a lot of data all the time
(see some info here), without the need for the peripheral device to make any requests.
The downside is that it's not standardized.

If a digital gauge designed for BRZ/FRZ/86 can't just listen to those, it's not a very well designed gauge.
From the manufacturer's perspective, "it works in most cases" and they've either never tested
interoperability with other peripheral devices; or not prioritized that.

With that said - there should not be any issues of an OBD2 tool reading the PID of oil temp and another tool (eg. Tactrix) reading the oil temp memory address via CAN simultaneously?

[timurrrr]

To the best of my understanding, yes.
If something on the CAN bus / OBD-II is doing something so nasty that the data over the CAN bus is unreadable, your instrument cluster will probably turn into a Christmas Tree

[ermax]

Originally Posted by Compelica

With that said - there should not be any issues of an OBD2 tool reading the PID of oil temp and another tool (eg. Tactrix) reading the oil temp memory address via CAN simultaneously?

This works fine in my car. I have my Tactrix set to log oil temp but at the same time I can monitor oil temp over OBD2 with no problem. I’ve also run a Raspberry Pi on the CANbus for various fun projects while monitoring PIDs at the same time.

[Compelica]

Just did a test with a splitter with a generic ELM OBD2 (with Torque) and my Tactrix for logging. While I wasn't sure the Tactrix was logging right but my Mode21 PIDs in Torque started spitting incorrect values, particularly oil temp and fuel gauge. Common PIDs (coolant temp, intake temp, ambient temp) worked fine. Not sure if it was a glitch but I intended to do some logging for an hour's drive so I couldn't have the Tactrix log screw up - might try other options later.