Gyphon and Scangauge used together is a no go.
#1
Gyphon and Scangauge used together is a no go.
I wanted to use both of them to monitor more info. I received the ODB Y splitter today and found the that the Gyp hon's readout wasn't constant with them both hooked up. The gages I am monitoring readouts from were fluctuating... speedometer was reading 0 one second then 62 the next all while I was sitting in park at ideal That sucks I was hoping to have them both working together. The guy I spoke with and ordered the splitter from told me this may be an issue when trying to run two monitors at the same time. Makes me wonder what the splitter purpose then?
Also, I got a question here. The rpm gauge on the scan gauge reads constant at ideal, the Gyphon's rpm gauge fluctuates a little and never reads a steady rpm. Why is that?
Also, I got a question here. The rpm gauge on the scan gauge reads constant at ideal, the Gyphon's rpm gauge fluctuates a little and never reads a steady rpm. Why is that?
Last edited by whitecrystal1; 11-14-2008 at 01:42 PM.
#2
For question 2 (RPM fluctuations), this is because the Gryphon is reading the RPM directly as the ECM sees it from the crank sensor. As you may well know, the engine is NEVER going to rotate at a 100% stable RPM. The reason the Scangauge doesn't fluctuate is because they are either buffering the RPM input and feeding out an average or they are displaying Desired RPM which is what the ECM is trying to achieve for RPM.
As for the communications conflict, that's another story. You cannot have two devices with the same Device ID (or CAN Node as the case may be) on the communications bus at the same time. The reason is as follows...
Device 1 (on ID 0x7E0) asks for RPM.
Device 2 (also on ID 0x7E0) ask for RPM.
ECM (responding on ID 0x7E8) disregards the second request thinking it's from the same device.
Device 1 or device 2 receive the data depending on who was ready to grab it first. This results in the device that missed the message having a timeout and trying to request the data again.
Or to make it simpler, picture 3 people on a phone call at the same time and all 3 are talking at once. Everyone gets confused. That's what's happening here. Other scenarios are possible as well, but I think you get the idea.
Hope this helps clear some of the confusion.
As for the communications conflict, that's another story. You cannot have two devices with the same Device ID (or CAN Node as the case may be) on the communications bus at the same time. The reason is as follows...
Device 1 (on ID 0x7E0) asks for RPM.
Device 2 (also on ID 0x7E0) ask for RPM.
ECM (responding on ID 0x7E8) disregards the second request thinking it's from the same device.
Device 1 or device 2 receive the data depending on who was ready to grab it first. This results in the device that missed the message having a timeout and trying to request the data again.
Or to make it simpler, picture 3 people on a phone call at the same time and all 3 are talking at once. Everyone gets confused. That's what's happening here. Other scenarios are possible as well, but I think you get the idea.
Hope this helps clear some of the confusion.
#3
I'll switch them up to monitor different things and see what happens. I wasn't planing on using them to monitor the same stuff, it's just that the Gyphon came with the RPM and Speedometer already on display when I plugged everything in. Hopefully that's all it is.
Thanks for the help Bill
Thanks for the help Bill
#4
Even if you aren't requesting the same data, the problem is that both device must use the same ID. This actually can exaggerate the problem because the 1st device will ask for RPM, the 2nd device will ask for vehicle speed, and the PCM will only return the RPM. Depending on who is ready, the 1st device could miss the data and the RPM could go to the 2nd device which will totally confuse it since it was expecting MPH. Stuff like that.
Take care.
Take care.
#7
Trending Topics
#8
They are usually used for plugging in two devices, one active device and one passive monitor. The passive monitor would be used to watch traffic between the active device (such as a ScanGauge, Programmer, or other scantool) and the ECM or other devices on the CAN bus. The passive device doesn't send any messages... it just listens on the bus and doesn't interfere with the rest of the messaging. Anyway, that's the general reason for the Y-cable. Of course, you can use two active devices, just not at the same time.