Help please, Scangauge II messed up my engine! (1 Viewer)

[Surfdc]

Update:
Well after replacing the battery, fusable link, and battery terminals, the truck has been running perfectly since saturday. My old battery was a sears diehard, 2 yrs old. It was wet on the top, and the terminals were wet, so im assuming it was leaking. Thanks again MUD!

 

[Wingmaniff]

Just plugged my new scanguage in looked at the numbers and the next morning my truck won't even crank. It was fine until I plugged this thing in. I bypassed my alarm system thinking it was that ,nope. AAA came over tried to jump it couldn't . It s now sitting at the dealership waiting to be diagnosed for $185 thanks scanguage.

 

[LFD2037]

Once again, it's not a SG II issue I'm willing to bet.

 

[1973Guppie]

obd 2 readers just "read" the data, nothing else, it is unlikely that the reader is causing problems......

 

[Timpanogos Slim]

obd 2 readers just "read" the data, nothing else, it is unlikely that the reader is causing problems......

I'm under the impression that they send a command that requests data, but there's no way the scangauge hurt the truck unless the truck's wiring was already wrong.

In the volkswagen world, the typical scenario is that someone installs an aftermarket stereo and it turns out that the wire harness on the vehicle side has some unlabeled wires coming out of it, and the installer has a couple wires on the stereo side that don't match a labeled wire on the vehicle side, so they put two and two together and, eff things up because those two wires are for the alarm and the diagnostic bus, and they just got attached to the radio's dimmer input and power antenna control output. And this does in fact interfere with diagnostics. But the stereo works and the alarm works, and all seems well until they land at a dealer or specialist shop and the car won't talk to the diagnostic tools.

But our trucks are, well, much dumber than that. There aren't the smarts in it to be perverted by someone who doesn't know what they are. It's very stone-age aside from the EFI system.

 

[Dave 2000]

I have no experience with the SG or affiliation with SG but, I have used a couple of the cheaper OBD scanners in the passed and then found problems occurring, non starting and rough running are but two, or the central locking starts playing up......coincidence?

Disconnecting the battery and leaving for an hour or so and all normally returns to normal, I now use an expensive system and that never causes problems, my point is that plugging 'anything' into the OBD port can bring about problems so is not just a SG issue.

regards

Dave

 

[Kernal]

Dave 2000: what system do you use?

 

[Wingmaniff]

obd 2 readers just "read" the data, nothing else, it is unlikely that the reader is causing problems......

I lope your right because i was reaqlly looking forward to being able to monitor the engine parameters. But I have seen with my wifes 09 camry after getting an inspection and they plugged into the OBD port the car ran terrible for about 10 miles then smoothed out. So I am suspect about accessing the info on the computer. I dont have a tuner on my truck it only has 80K on it and ran perfectlyuntil I plugged this in.

 

[Surfdc]

Wingmaniff,
Here is my $0.02...
There is not enough research to conclude that a SGII is causing symptoms to our engines. We haven't made the distinction of whether or not its causation or coincidence.
Having said that, I have been reading about it a lot since it happened to mine, and I will say that, like mine, it coincidentally happened the second i plugged mine in. Was the SGII the cause then or was it coincidence? Who knows.
Mine continued to run horribly after the SGII was removed, and truck was repaired. See post #21 for what ultimately fixed mine.
Here is what I have learned from all my reading:
1. Never plug the SGII in to an already running vehicle.
2. Never unplug the SGII from an already running vehicle.
3. Only plug it in first, then start the vehicle and leave it alone. Unplug after the vehicle is shut off.
4. There is a signal that is sent to the cars CPU that asks for info, but should not be detrimental to the CPU, or cause malfunction.
5. THere is considerably less incidence of malfunction of Ultraguage users. (dont know why)
Hope that helps.

 

[george_tlc]

For an OBD2 reader to report information it must send requests (search OBD2 PID) to the vehicle's ECU to get that information.

So, it is 'feasible' that plugging in/out while live could send a damaged request to the vehicle's ECU, but it would be very poor form if the ECU would then get 'confused', unless that code was written by a very junior/idiot programmer...

Seems more likely a mind over matter situation... you plug in an OBD2 reader expecting to find something bad and your vehicle's ECU reads your mind and provides you exactly what you were hoping not to find

I've got an ultragauge and a BT reader (for my android devices), never had problems with either, though I tend to wear a tinfoil hat...

cheers,
george.

 

[socallove]

I had an issue with my SGII, after I plugged it into my 97, nothing happened it just worked too perfectly and I'm disgusted.
It says my truck is getting 99999 MPG but my tank go empty every 4 days, i then realize it only says 99999 when I let go of the gas paddle.
I wanted to get optimum MPG by never stepping on the paddle but I couldn't get anywhere, damn you Scan Gauge II.
I'm just messing around, I'm glad mine didn't give me any issues.

 

[Dave 2000]

Dave 2000: what system do you use?

Autocom,

regards

Dave

 

[Surfdc]

Forgot to mention earlier that when I called Scanguage about this issue, they were very aware of this scenario, and recommended that I use an "ISO only" cable instead of the cable that the SGII came with for my specific vehicle. The tech stated that that way there is no confusion between the SG and the OBDII port and the CPU, since our trucks use an ISO protocol. They sent it for free, I have not tried it yet.

 

[Kernal]

Surfdc: so using something other than an "ISO" cable can mess things up, different pins sending different requests to the ECU?? Can you post up a side-by-side photo of an ISO connector and the connector you used when this happened?

 

[TrickyT]

Forgot to mention earlier that when I called Scanguage about this issue, they were very aware of this scenario, and recommended that I use an "ISO only" cable instead of the cable that the SGII came with for my specific vehicle. The tech stated that that way there is no confusion between the SG and the OBDII port and the CPU, since our trucks use an ISO protocol. They sent it for free, I have not tried it yet.

View attachment 1000890 View attachment 1000891

Wrong!!! FZJ-80's use the J1850 variable pulse width (VPW) OBD-II standard, _not_ ISO. So for the OBD-II connector that's pins 2 (Bus positive SAE-J1850) and 5 (signal ground). The Scan Gauge II also uses pin 16 (+12v) for its power. I've built several custom cables for an FZJ-80 OBD-II port to connect a Scan Gauge using these 3 signals and they work right every time. ISO came later.

And, like George said above, while it's technically conceivable that a poorly designed OBD-II "reader" could cause abnormal operation of your vehicle, it is _highly_ unlikely. While there are a few OBD-II commands that can cause a running FZJ-80 engine to stall, these commands are not part of the normal PID parameter set (see http://en.wikipedia.org/wiki/OBD-II_PIDs) but rather vehicle specific "mode 30" commands. I have played around _a lot_ with the FZJ-80 OBD-II and have never found any command that I could send to the OBD-II interface to have a lasting effect on vehicle performance. The only (qualified) exception is that you can send commands that cause emission-related tests to be marked as "incomplete" that then may take several driving cycles before they are complete again (this is a normal part of the OBD-II standard).

 

[TrickyT]

Another point: there are no connections on an FZJ-80 OBD-II connector other than the J1850 interface pins. The connector that Surfdc shows in his pictures for his "iso only" connector are _not_ only for the ISO OBD-II standard.

 

[Kernal]

TrickyT: so to clarify, does it matter what cable/connector type can/should be used for hooking up to a FZJ-80 OBD II port, or is it more dependant on the device being hooked up?

 

[TrickyT]

For the Scan Gauge II the cable is definitely device-specific, since the SC-II uses an RJ-45 connector. In other words, the cable that comes with the SC-II has a standard OBD-II connector on one end and an RJ-45 connector on the other. (RJ-45 is the same type of connector that wired Ethernet uses.) And I've seen scan devices that use DB-9 connectors on the device end as well. The OBD-II standard defines the connector and pin assignments on the vehicle side, but device manufactures can do whatever they desire on the device side.

 

[Timpanogos Slim]

TrickyT: so to clarify, does it matter what cable/connector type can/should be used for hooking up to a FZJ-80 OBD II port, or is it more dependant on the device being hooked up?

There are only 3 pins that make any difference on the truck side.

 

[Surfdc]

Wrong!!! FZJ-80's use the J1850 variable pulse width (VPW) OBD-II standard, _not_ ISO. So for the OBD-II connector that's pins 2 (Bus positive SAE-J1850) and 5 (signal ground). The Scan Gauge II also uses pin 16 (+12v) for its power. I've built several custom cables for an FZJ-80 OBD-II port to connect a Scan Gauge using these 3 signals and they work right every time. ISO came later.

And, like George said above, while it's technically conceivable that a poorly designed OBD-II "reader" could cause abnormal operation of your vehicle, it is _highly_ unlikely. While there are a few OBD-II commands that can cause a running FZJ-80 engine to stall, these commands are not part of the normal PID parameter set (see http://en.wikipedia.org/wiki/OBD-II_PIDs) but rather vehicle specific "mode 30" commands. I have played around _a lot_ with the FZJ-80 OBD-II and have never found any command that I could send to the OBD-II interface to have a lasting effect on vehicle performance. The only (qualified) exception is that you can send commands that cause emission-related tests to be marked as "incomplete" that then may take several driving cycles before they are complete again (this is a normal part of the OBD-II standard).

TrickyT, You are right, and the tech on the phone was wrong, our trucks use J1850 VPW, not ISO. So that cable they sent me was a mistake, and in looking at it, has different pins than the female connector on the truck so I bet it would not even work.

Surfdc: so using something other than an "ISO" cable can mess things up, different pins sending different requests to the ECU?? Can you post up a side-by-side photo of an ISO connector and the connector you used when this happened?

Now that we know our truck are J1850 VPW, I'm going to assume you are asking if we use something other than a "J1850 VPW" cable can mess things up? i have no idea.