✅ BMW i3

[Tombmwi3]

Starting a new thread for the BMW i3

[jeff]

Welcome! Once you've had a chance to test Sidecar out with your car please share any feedback here!

[jeff]

Hey @Tombmwi3! Based on your logs, it looks like we'll need to try a few command sequences to see how we might get your car to talk to us. If you can run the following in a Sidecar Terminal session when you're connected to the car via OBD, and then email me the OBD scan logs after, we'll be able to make some progress here:

Code: Select all

ATCEA07
ATFCSH6F1
ATSH6F1
ATFCSD07300000
ATFCSM1
ATCRA607
22DD68

[jeff]

Getting closer! We actually got a response this time which is promising.

Let's try some small adjustments to the sequence and see if we can get full packet frames back.

Code: Select all

ATCEA07
ATSH6F1
ATFCSH6F1
ATFCSD07300800
ATCRA607
ATFCSM1
226335
22DD68
22DD69
22DDBC
22DDC0

[Tombmwi3]

Sent more logs over!

[jeff]

Oh! So there's maybe something else going on here. The response we got is:

Code: Select all

607 F1 03 7F2278
607 F1 05 62 DD68 99BE

The F1 after the header is unexpected, and is usually associated with the tester identifier. Trying to find in the ELM327 / CAN specification where and why those two bytes would be getting inserted into the sequence

[Tombmwi3]

would it be related to doing it while moving?
I’ll try it again when I’ve stopped.

[jeff]

Nah nothing to do with that; I think it's to do with the configuration we're using and is probably working as expected, I just don't fully understand why it's behaving this way. I'll see if I can reproduce this on my Juke.

[jeff]

As expected I can't reproduce on the Juke because it doesn't respond to the extended addressing changes. Going to do some research to make sure I understand what's going on here and then may need to make some adjustments to the OBDb scanning specification to allow extended addressing.

[jeff]

So the ELM327 documentation includes the following note about using ATCEAhh:

Sending the CEA hh command causes the ELM327 to insert the hh value as the first data byte of all CAN messages that you send. It also adds one more filtering step to received messages, only passing ones that have the Tester Address in the first byte position (in addition to requiring that ID bits match the patterns set by ATCF and ATCM, or ATCRA). The ATCEAhh command can be sent at any time, and changes are effective immediately, allowing for changes of the address ‘on-the-fly’.

I wonder then if "only passing ones that have the Tester Address in the first byte position" is referring to the F1 we're seeing here in byte one after the header . If so, I'll definitely need to make some adjustments to the Sidecar scanner Estimating probably about an hour of work to get it implemented so I'm gonna sleep now and take a stab at it tomorrow!

Thanks for the quick responses on the logs!