ELM327 unable to connect to car

[stibbzy]

I just received my WiCan (USB) and having trouble on my BMW i3. When I use Carscanner with a BT OBD2 adaptor it connects just fine and I can get sensor data from the car. However, when I connect Carscanner to the WiCan, it says “succesfully connected to ELM327, but ELM327 wasn't able to establish connection with your car.” The green LED is on and the orange LED is flashing. I’ve tried turning MQTT on and off, and disabled battery alerts. Different bitrates don’t work either. The Carscanner log has a lot of “BUS INIT: …ERROR” messages. I've attached screenshots from Carscanner when it is working via the BT adaptor and when it isn't via WiCan. I've attached the log as well.

Carscanner log.txt

[harkoprinssen]

Last screenshot says it's connected to the ECU. Still not able to read data?

[stibbzy]

Last screenshot says it's connected to the ECU. Still not able to read data?

No, that is a screenshot illustrating how the Bluetooth OBD2 adaptor connects just fine to the ECU. Carscanner cannot connect to the ECU when using WiCAN

[harkoprinssen]

Ah, now I see. Behaviour seems like the issue I am facing, however I do not get the orange light blinking connected to my car

[meatpiHQ]

@stibbzy do you have both adapters connected to the same bus at the same time?

[stibbzy]

@stibbzy do you have both adapters connected to the same bus at the same time?

No, one at a time. I turn off the car in between.

[meatpiHQ]

@stibbzy Try setting it to AP mode, disable mqtt logging and MQTT. Submit the settings and do not use the Monitor tab. The. Then try to connect.

[meatpiHQ]

@stibbzy looking at the logs... seems that there are some elm327 commands that are not supported by WiCAN. I will try to add them and upload new firmware version for you to try.

[harkoprinssen]

Could that possibly also help me out? https://github.com/meatpiHQ/wican-fw/issues/142

@stibbzy looking at the logs... seems that there are some elm327 commands that are not supported by WiCAN. I will try to add them and upload new firmware version for you to try.

[stibbzy]

@meatpiHQ Thanks so much! I’ll also try your other suggestion in the morning (Sydney time)

[meatpiHQ]

@harkoprinssen I'm looking at your issue now.

[stibbzy]

@meatpiHQ I just tried setting to AP mode, disabled MQTT and MQTT logging, and didn't use the Monitor tab. Connected to the WiCAN's wifi and ran Carscanner, same result - can't connect to ECU. I also set Carscanner to run through 17 different CAN protocols to try to detect the right one (different bit count, baud rate etc) and none of those worked.

[stibbzy]

@meatpiHQ I just spent another hour in the car trying different things but nothing worked. For what it's worth, Carscanner has a toggle to detect fake ELM327 clones. When I toggle that on, it detects the WiCAN as fake... not sure if that means anything or not. Also, under Carscanner advance settings, it can display AT commands that aren't supported by the adaptor. When I use the BT adapter, that field is blank, but with the WiCAN, it displays all these.

[meatpiHQ]

@stibbzy WiCAN only emulates an ELM327 device and is not intended for diagnostics. It allows for extracting and logging data from the bus for reverse engineering and integration with Home Assistant. While this has worked with most cars, some vehicles require specific commands to function properly.

One approach is to log data from your other BLE adapter and use this information to configure WiCAN.

[stibbzy]

@meatpiHQ Yep, all I want to be able to do is to pull the battery SOC into Home Assistant. Would an updated firmware likely start giving responses in CarScanner? I note that OVMS has a BMW i3 plugin working, would that be of any help: https://docs.openvehicles.com/en/latest/components/vehicle_bmwi3/docs/index.html

[meatpiHQ]

Would an updated firmware likely start giving responses in CarScanner?

Yes, that's the plan. But it might be faster if you log the SoC data using the other EM327 adapter, by clicking on the sensor on carscanner. All we need is the PID request and response.

[stibbzy]

@meatpiHQ Ok, here is the log once I clicked the sensor and let it go for about 10 seconds... BMW i3 Batteru SOC.txt

There seems to be some mention of an initialisation sequence and then some PIDS here that seem similar to the log: https://web.archive.org/web/20231210170809/https://forum.abetterrouteplanner.com/topic/317-decoding-the-i3s-pids/page/3/#comments

Apparently, 22DDBC is the battery SOC and that is present in my log, eg:

22DDBC 607F1037F2278 607F1100962DDBC027D 607F121031C0050FFFF

If I just take the first frame and convert the last byte? 027D into decimal, I get 637, and my current SOC according to Carscanner is 63.7%. I then ran the car down to 63% SOC according to Carscanner, and the byte returned was 0276 in the log, which is a perfect match.

But if WiCAN can't get any RX responses, I'm not following how this can be used?

[meatpiHQ]

22DDBC is the OBD request.

These frames are the PID request and response. We need to translate these into CAN frames and send it over MQTT. I'll have a look at it later tonight.

[stibbzy]

Thanks so much!

[meatpiHQ]

I think the PID request should be:

{"payload":{"bus":"0","type":"tx","ts":0,"frame":[{"id":1777,"dlc":8,"rtr":false,"extd":true,"data":[3,34,221,188,170,170,170,170]}]}}

After you send this frame you should expect a rx frame with the first data byte is 16, once you receive that, you have to send a response frame:

{"payload":{"bus":"0","type":"tx","ts":0,"frame":[{"id":1777,"dlc":8,"rtr":false,"extd":true,"data":[48,0,10,170,170,170,170,170]}]}}

This issue is a good reference.

https://github.com/meatpiHQ/wican-fw/issues/97#issuecomment-2089644589

[stibbzy]

I'm still not understanding... Do I publish that to the topic directly under wican (wican/ecda3ba6d52d)? I tried, but I didn't get any rx response. That's what I don't understand, I have never seen a rx response in MQTT Explorer:

[harkoprinssen]

I think you should be publishing in the ../tx topic.

Mine goes to wican/f412fa377d01/can/tx

[stibbzy]

@harkoprinssen Ahh, thanks very much for the suggestion. Unfortunately it didn't give a response on either wican/ecda3ba6d52d/can/tx or wican/ecda3ba6d52d/elm327/tx

[meatpiHQ]

Yes to the tx topic. Make sure you have " MQTT ELM327 logging" disabled.

[stibbzy]

@meatpiHQ OMG, I finally have a response after disabling logging! No 16 value though, but that might be because I'm getting ~1000 responses per second {"bus":"0","type":"rx","ts":37927,"frame":[{"id":304,"dlc":5,"rtr":false,"extd":false,"data":[5,240,252,255,255,0,0,0]}]}

[meatpiHQ]

That's great, but it doesn't look like the frame we're after.

Btw you can have the BLE and WiCAN adapter connected at the same time if you want, you can see Rx frames over MQTT.

[stibbzy]

@meatpiHQ I'm using the wiCAN adaptor with a spliced OBD2 cable at the moment, so the BLE can't be plugged in as well unfortunately. Is there only supposed to be one frame with the 16 byte? If so, I would have missed it with all the messages coming in. All the messages are identical, apart from the ts value of course.

I added this filter, and then after republishing, I got this response, which is just the tx frame. But I really don't know what I'm doing, I had no idea on start and stop bits: {"payload":{"bus":"0","type":"tx","ts":0,"frame":[{"id":1777,"dlc":8,"rtr":false,"extd":true,"data":[3,34,221,188,170,170,170,170]}]}}

[meatpiHQ]

If so, I would have missed it with all the messages coming in. All the messages are identical, apart from the ts value of course.

what are the messages coming in?

Note: You should only add the filter after we figured out the message structure, if you added a filter you won't see a more messages coming only the filtered ID.

[stibbzy]

@meatpiHQ Without that filter, there are ~1000 messages per second, and they all say {"bus":"0","type":"rx","ts":37927,"frame":[{"id":304,"dlc":5,"rtr":false,"extd":false,"data":[5,240,252,255,255,0,0,0]}]}

I was just trying the filter to try to see if there was my desired response buried in there. But I don't know how to determine the CAN ID number or the PID that the reply would come back on. Based on this BLE response from before, 607F1100962DDBC027D, I just tried CAN ID 1543 (Hex 607) and PID 241 (Hex F1) but that didn't work either.

[meatpiHQ]

Since your car broadcasts over the CAN bus we can try a different approach.

Try adding this filter:

ID: 1074 Name: SoC PID: -1 index: 0 Start Bit: 0 Bit Length: 1 Expression: B4/2 Cycle ms: 1000

I found a DBC file for I3 not sure if its compatible with your car model, but you should give it a go.

https://github.com/damienmaguire/BMW-i3-CCS/blob/main/i3_LIM_dbc1.dbc

[stibbzy]

@meatpiHQ Thanks for finding the DBC file.... it would very likely be compatible, but I have no idea what a DBC file is or how to use it. Is that where you got the CAN ID?

Why are all my rx frames without a filter identical?

I tried your filter, then published the tx json, but there was nothing received. Are my screenshots correct?

[meatpiHQ]

Since your car is always broadcasting then there is no need to publish any tx frame. Did you store and submit ? If it works you should see an mqtt message like : {"SoC": 51}

The DBC file is a database file that would tell you how to interpret CAN frames:

The CAN frame id is 1074. The Display_SoC is what ever your car display is showing, 32|8@1+ means that the SoC value is in Byte 4

[stibbzy]

@meatpiHQ Yes, I stored and submitted, and after refreshing browser, the filter was there. The rx topic is not receiving any messages. I guess my question was, with no filter, why is every received response identical?

[meatpiHQ]

You mean that the car is always broadcasting the same frame? is the engine ON?

[stibbzy]

@meatpiHQ There is no engine as such (electric), but it is powered on, in drive, with my foot on the brake. Without a filter, every single frame (1000s per second) is: {"bus":"0","type":"rx","ts":37927,"frame":[{"id":304,"dlc":5,"rtr":false,"extd":false,"data":[5,240,252,255,255,0,0,0]}]}

[meatpiHQ]

Ok. Motor then :)

This frame is the like a keep alive frame, not useful for what your trying to do. This tells us that the DBC file is not compatible.

[stibbzy]

@meatpiHQ Ok, so I probably do need a TX frame, and then somewhere within the keep alive frames will be my response frame, once we figure out the frame structure?

Is there any way to filter out the keep alive messages lol?

[meatpiHQ]

so I probably do need a TX frame, and then somewhere within the keep alive frames will be my response frame, once we figure out the frame structure?

Yes you need to send the TX frame.

Try this firmware, it will publish the CAN frame by ID. So each frame with different CAN ID will go to a different topic.

wican/ecda3ba6d52d/can/rx/xxxxx

(Extract the bin file from the zip and upload it to the device) wican-fw_v299_hv300.zip

[stibbzy]

@meatpiHQ OK, I'll give it a go.

[stibbzy]

@meatpiHQ 304 is the only ID, unless I push a tx frame... are these issues a possible reason for Carscanner not connecting to the wiCAN either?

[meatpiHQ]

What are the other IDs if you push the tx frame?

No the carscanner is not working because sending an unsupported command, that changes the message format so it's failing to parse the response.

[stibbzy]

@meatpiHQ I don't get any other IDs if I push a TX frame. In my screenshot, I show the response with a TX frame, it just has 304 rx, plus the transmitted frame

[meatpiHQ]

What about if you send this frame?

{ bus : 0 , type : tx , frame :[{ id :2015, dlc :8, rtr :false, extd :false, data :[2,1,0,170,170,170,170,170]}]}

[stibbzy]

@meatpiHQ No change:

[meatpiHQ]

seems like its a problem with the mqtt explore, try this

{ "bus":0, "type":"tx", "frame":[ { "id":2015, "dlc":8, "rtr":false, "extd":false, "data":[ 2, 1, 0, 170, 170, 170, 170, 170 ] } ] }

[stibbzy]

@meatpiHQ No change, I've also tried issuing these from the Home Assistant MQTT add on with no luck.

[meatpiHQ]

Something does not add up.. Just to confirm please double check the tx topic in the configuration page?

[stibbzy]

It matches:

[meatpiHQ]

try this frame again in this format

{ "payload":{ "bus":"0", "type":"tx", "ts":0, "frame":[ { "id":1777, "dlc":8, "rtr":false, "extd":true, "data":[ 3, 34, 221, 188, 170, 170, 170, 170 ] } ] } }

[stibbzy]

@meatpiHQ Nope... are we sure these are real frames that are being received? There seems to be some mention of an initialisation sequence on this page, do we need to do that?: https://web.archive.org/web/20231210170809/https://forum.abetterrouteplanner.com/topic/317-decoding-the-i3s-pids/page/3/#comments

[meatpiHQ]

{ "payload":{ "bus":"0", "type":"tx", "ts":0, "frame":[ { "id":1777, "dlc":8, "rtr":false, "extd":true, "data":[ 3, 34, 221, 188, 170, 170, 170, 170 ] } ] } }

I accidently had the extended flag turned ON "extd":true , try the frame below.

{ "payload":{ "bus":"0", "type":"tx", "ts":0, "frame":[ { "id":1777, "dlc":8, "rtr":false, "extd":false, "data":[ 3, 34, 221, 188, 170, 170, 170, 170 ] } ] } }

are we sure these are real frames that are being received?

Yes, I'm just translating them into CAN frames.