Hi there!

Recently I tried to connect two OBDLinks to my car with a Y-split-cable and two android devices (if you wish, I can explain ;)).

This did function, but gave me a lot of instability in the received data.

Now I am trying to pinpoint, what can be the reason for the instability.

It seems, both adapters sent data requests to ECUs on the Can bus. I can happen, that both of them ask different thongs to the same ECU (one the RPM, the other one the temperature for example).

If both adapters use the same node ID to request data, it would be obvious, that they can not keep the answers apart, and adapter1 (asked for RPM) can eventually think, the answer for adapter2 (temperature) is his RPM-answer – result – confusing data on the screen of Torque…

My questions are:
What node ID uses Torque?
Is there some default ID for OBDII adapters?
Does the App define the ID, or does the Adapter do it?
Can I change the ID for my Torque?

Best regards

Mateus

Hello Capp777!

Thank you for your answer!

I know the TA command, I will read about the PP06 command.

The question is, even if I send this command, and it will be properly processed, I’m afraid, Torque will override this – this would be a question to a programmer, who know, how it is done internally…

You wrote “I believe your adaptor defaults to F1” – where do you have this address from? Is that a standard OBD-Adapter-Address, a common default address, or some protocol rule?

If I want to use Torque and Hybrid Assistant, as I described it in my previous post, it would be crucial, to use two different Node IDs.

Any thoughts will be greatly appreciated

Regards

Mat

PP 06 is actually a parameter that can be saved
as the default tester address.

I will definitely read about this.

Do you think, the node ID is defined by the hardware of the adapter, and not by the application?

F1 is the default tester address used by
elm327 according to its documentation.

OK – apparently my reading was not thorough enough 😉

Is there a “secure” ID, that one could use on a cars CAN bus, so it does not collide with anything?

And thank you again for your input!

Regards

Mat

Sorry I can’t test with my OBDI Jeep.

You might try adding the ATTA command to
the custom init string in the vehicle profile. It’s
my understanding that the Tester Address should
be set prior to initializing the protocol.

I would be curious if Torque would pick up the
change and continue to work with the new
address.

Only Ian knows for sure. Hoping he will respond.

I also suspect that Torque uses the same default
address as other apps making using other apps
at the same time likely unreliable.

The PP xx Sv yy command would allow the adapter
to retain the setting between sessions whereas the
TA command would be just for that session only.

Based upon my readings, there is a second step
required before the parameter change is used…

PP xx ON

to enable change.

It would be nice if Torque used the elm PPS command
to extract the desired Tester Address for its internal
pids (immediately following execution of the custom
init string).

There is probably a range of addresses
reserved for test devices… I would try
something close to F1 like F2.

Again, I am unable to test myself so
not sure.

Node IDs aren’t really used in vehicle CAN.

F1 is a default scan tool ID but it’s only used when the communication uses extended addressing, which standard OBDII doesn’t.

The CAN ID of the request message will be 7DF for standard OBD requests, or something else for requests direct to a specific ECU (e.g. 7E0 for the engine).

You can’t change this as the ECUs won’t respond, so having 2 devices on the bus doing similar things is always likely to cause issues because:

They’re trying to send messages on the same CAN ID (7DF).
They will see all responses, so depending how clever the device is at decoding the ECU reply you can have a situation where device 1 requests engine speed and device 2 requests coolant temperature very shortly after, device 2 sees the response to engine speed, but thinks it’s the response to the coolant temperature it’s just asked for. This can be worked around if you filter the responses based on the PID but it gets trickier when the responses span multiple CAN frames.

If you have one device talking to the engine on 7E0 (responses on 7E8) and one device talking to the transmission on 7E1 (responses on 7E9) then you wouldn’t have an issue, but having 2 devices trying to communicate on the same CAN IDs will always give you lots of work to do filtering the responses.