OBD2 Y cable use

[DGA]

Want to use an OBD2 Y type cable, so I can have a DashDAQ and the HPT scanner hooked up at the same time. I would assume this would work, but am wondering if it is safe to flash the ECU while the DashDAQ is also running?

[Bill@HPTuners]

Pretty sure it won't work but let us know how it works out.

[DGA]

Would the "won't work" also be me bricking my ECU?

[1998Ws6]

I have caused an ECM to be non responsive until power cycled on a 2001 corvette with a Y cable and a datalogger and tuning product connected at the same time. It would work fine AS LONG as you stopped the datalogger before flashing, but when the datalogger started to talk when flashing, it resulted in the pcm failing the flash. Fortunately I was able to recover it as it was a cal only flash.

[DGA]

Scares me, and I'm fearless.... Thanks for the tip, this is because the plug is impossible to access until I dismantle part of the dash. I'll make sure to disconnect the DashDAQ before flashing then.

[C Del]

The problem with this is that OBDII uses a serial protocol for data transmission, meaning only one device can be transmitting data at any given time. For simply scanning diagnostic information, using multiple scanning devices is likely to work without too much trouble, as the serial bus protocol will prevent multiple devices from talking over one another, but it isn't exactly an optimal condition.

To my understanding of the signaling protocol specified by SAE J1850, which is used in older GM vehicles (like my '02 Camaro), a scanning device always needs to request information. That is, there doesn't appear to be a command like "send me these PIDs until I tell you to stop". Because of this, coupled with the fact that SAE J1850 is rather slow by modern standards (10.4 or 41.6 kB/s), the more PIDs you log, the less frequently you can log them. Now, when you add another scanner to the bus, that device will issue its own requests for data, in addition to those already being sent by the first scanner. Not only will the additional requests eat up bandwidth, but the second device will almost certainly not recognize when data it wants is sent to the first, meaning that it will ask for that same data again, using up even more bandwidth needlessly.

Slow data retrieval can be annoying, but multiple devices connected to OBDII can become a real problem if you try to program the PCM. I can't be sure, not knowing the OEM-specific PCM flashing protocols, but I suspect that, after the command to begin flashing is sent by the first scanner, the PCM may interpret subsequent data requests issued by the second scanner as part of the flash. If you were trying to write the entire PCM when this happened, you would likely overwrite the operating system with garbage data, which should brick the PCM unless the OBDII flashing code is stored in non-erasable read-only memory, which I would not expect.

The bottom line is that OBDII will tolerate multiple clients (scanner-type devices), but it is not designed with that in mind. The best thing to do is to scan with one device at a time, then send that data to other devices if necessary; this will prevent scanning slowdowns due to unnecessary overuse of the bus. I can almost guarantee that even having another device connected while attempting to flash will result in unhappy times.

Note: Newer vehicles that use the CAN bus for OBD communication will likely be less affected multiple scanning devices, as far as scanning speed is concerned, due to the higher transmission speed afforded by the bus. This does not affect the flashing problem.