✅ [29-bit] Acura TLX (1st gen)

[sidbmw]

Also the TestFlight build expired. Not sure if that’s by design

[jeff]

Ah yeah; added build 185 so it should extend the TestFlight timeout period

[sidbmw]

Awesome thanks. Let me know if there’s something else to test with the Acura. I’ll get to the BMW soon

[jeff]

Not yet! I just realized that Mercedes also speaks 29 bit CAN but does so in a relatively novel way (0100 responds with a ton of ECUs), so I'm going back to the textbooks and trying to battle harden the 29 bit CAN decoding logic. May be stuck in this rabbit hole for the rest of today.

If you're feeling adventurous, https://github.com/ElectricSidecar/Acur ... 1abc9f7639 is the pull request for adding tire pressures. If you follow a similar format and the documentation in https://sidecar.clutch.engineering/scan ... nded-pids/ you should be able to to try out adding more of the pids you found on your fork.

[sidbmw]

Haha, good luck! I’ll try finding more PID’s when I get a chance

[jeff]

That moment when you're googling for a 29-bit CAN-ID and...you end up on your own forum post

[jeff]

So documenting what I'm learning so far.

Up til this week, Sidecar has mostly dealt with the 11-bit CAN-ID format, which has a relatively well-documented set of headers/receive addresses most vehicles work with, e.g. 7E0/7E8 for most engine control unit pids. This convention had made it fairly straightforward to define a "hdr" / "rax" format as documented in https://sidecar.clutch.engineering/scan ... nded-pids/.

The 29-bit CAN-ID format, on the other hand, is a bit of a different beast. A 29-bit header might look like 18DAF158, which can be broken down as:

• 18: Priority
• DA: Physically addressed
• F1: Target (scantool)
• 58: Sender (??)

To get data from this sender, you can set the header to ATSHDB33F1, which is broken down like this:

• DB: Functionally addressed
• 33: Target (??)
• F1: Sender

What I'm trying to understand right now is how to make a correlation between the functional group and the physical sender.

Screenshot 2024-09-30 at 10.36.04 PM.png (944.71 KiB) Viewed 2270 times

Code: Select all

18DAF14D06410098180001
18DAF15906410098180001
18DAF18706410098180001
18DAF15A06410098180001
18DAF158064100BE1CA813  # <- This ECU responds to functional group 33
18DAF16206410098180001

The reason this matters is because if we take, for example, the response to 0100 on a Mercedes Benz G-Wagon, we end up getting back supported pids from 6 different physical ECUs, and it's not abundantly clear to me how we might send messages to only one of these ECUs at a time.

• What is the correlation between functional group 33 and physical address 58?
• Is there a way to determine how to set a header for a given command?
• In 29-bit CAN-ID mode, should I just not require a header to be specified, as is currently the case with 11-bit CAN-IDs?

Still hunting down the answers to each of these questions

[jeff]

OK I think ISO-15765-4 has mostly answered my questioning. Seems that for the most part, 18 DB 33 F1 is the right 29-bit CAN-ID header to use for addressing on-board diagnostics equipment, which is primarily what we're interested in. In rare cases, we might need to send a command to a physical address via 18 DA xx F1, but this should be the exception rather than the norm.

So with this in mind, the signalset format for the standard SAEJ1979 Service 01 pids will look roughly like this:

Code: Select all

{ "hdr": "DB33", "cmd": {"01": "0A"}, "freq": 1,
  "signals": [
    {"id": "FP", "path": "Engine.Generic", "fmt": { "len": 8, "max": 765, "mul": 3, "unit": "kilopascal" }, "name": "Fuel pressure"}
  ]},

With each pid getting sent to the generic OBD functional group and no receive address filtering.

More specific, non-standard pids will often be sent to a physical address, and will look more like this:

Code: Select all

{ "commands": [
{ "hdr": "DA10", "cmd": {"22": "2660"}, "freq": 5,
  "signals": [
    {"id": "CRV_ODO", "path": "Trips", "fmt": { "bix": 344, "len": 24, "max": 4294967295, "unit": "kilometers" }, "name": "Odometer", "suggestedMetric": "odometer"}
  ]}
]
}

[bravoinc]

For non-standard pids, how can we know which HDR value to use?

[jeff]

Either need to do brute-force PID scanning or find someone who already knows which header to use. PID scanning is something I'm planning on adding to Sidecar in the medium term future once I feel like most of the OBD fundamentals are in place.