meatpiHQ
commented
1 year ago @rostchri Thanks for the logs, please try this firmware
Open rostchri opened 1 year ago
meatpiHQ
commented
1 year ago @rostchri Thanks for the logs, please try this firmware
rostchri
commented
1 year ago Still no sucess with version 166b:
===== LOG STARTED: 07.03.2023 19:09:45=====
=====Version=1.97.0 Build=1.97.0 P=True NoDelayELM327Init=False
====Connection profile=Skoda EV MEB: ID.3, ID.4, ID.5, ID.6, ID.Buzz, Enyaq, Q4 E-tron, Cupra Born, etc.
[Connection type: WIFI]
[WiFi name: <null>]
[Connecting to 192.168.178.157:3333]
client = new TcpClient();
BEFORE await client.ConnectAsync(server, port);
client.Connected
got stream from client
[Connected to 192.168.178.157:3333]
ATZ
ATE0
[ELM RESET]
ELM327 v1.3a
>OK
>
Initialize(initMode=Default)
InitializeDefaultInitString(ProtocolNumber=7,initMode=Default,useATST96=False)
ATE0
OK
>STI
?
>VTI
?
>
[ELM RESET]
ATD
OK
>ATD0
OK
>ATE0
OK
>ATSP7
OK
>ATE0
OK
>ATH1
OK
>ATM0
OK
>ATS0
OK
>ATAT1
OK
>ATAL
?
>ATST96
OK
>0100
BUS INIT: ...ERROR
>
[cmd_reply=] BUS INIT: ...ERROR
>
[Trying to decode:
OK
>
ELMFormat=CAN29bit]
[DecodeResult=False]
0100
BUS INIT: ...ERROR
>
[cmd_reply=] BUS INIT: ...ERROR
>
[Trying to decode:
OK
>
ELMFormat=CAN29bit]I can‘t see any difference in the log
meatpiHQ
commented
1 year ago @rostchri I'll get back to you on this later, I need to simulate this.
meatpiHQ
commented
1 year ago @rostchri Please try this firmware, there was a bug with the 29bit protocol. This should fix it, please share the logs after you test.
scytacki
commented
1 year ago @meatpiHQ what change did you make? I see in the release notes for v1.68: https://github.com/meatpiHQ/wican-fw/releases/tag/v1.68 this fix is mentioned. However when I compare v1.68 to v1.65, I don't see any changes to the code: https://github.com/meatpiHQ/wican-fw/compare/v1.65...v1.68
Using v1.68 I'm able to connect with carscanner to an VW ID.4 (should be similar to Skoda Enyaq) using BLE on Android, by choosing ProtocolNumber 7 in advanced settings (settings/adapter/advanced settings). The default automatic protocol setting didn't succeed. However I'm not seeing any readings in the dashboard view, so I'm guessing something is still wrong. I don't have another obd2 adapter yet to compare this to.
@rostchri where did you get that logfile from carscanner? I haven't been able to find it yet.
rostchri
commented
1 year ago Sorry for the delay, i did not have enough spare time to do further investigations. But i tested the above firmware from Mar 10 and there was no change at all. The logoutput was the same like in the cases before. I simply forgot to attach the logfile here. So for me until now the wican adapter still not work in my skoda enyaq. And yes the ID4 should behave very much like the Skoda Enyaq, because it is based on the same platform (MEB). I recognized too that in the source code I can’t find any related changes, but maybe this is only an internal firmware for tests and the code is not commited yet?
@scytacki: I used iphone carscanner app and if i remember correctly it was very easy to send the logfile of the current carscanner session. But i did not remember details. But I will try it again today later.
meatpiHQ
commented
1 year ago @scytacki @rostchri
I've updated the main branch with the latest changes. I'm not sure if I sent you the correct binary before, please try again with version v1.69.
@rostchri Please try to set the protocol manually to 7 or 9
" ProtocolNumber 7 in advanced settings"
scytacki
commented
1 year ago Thank you both.
I found the "Export log" button on the bottom of the "Settings/Adapter" screen.
Here is a trimmed down log from my attempt yesterday https://gist.github.com/scytacki/55e9d782ea0eb8da6210040809f70b87
It looks look it got further since there is a decoded response from >0100.
After this it sends >0100 multiple times, receiving the same response. I cut that part out with a comment ::: ....
Then it goes into a loop of LOOPV3_NO_DATA_LIMIT_REACHED.
Since I haven't used any of this stuff before I could be doing something wrong in the app which results in this log. But my guess is that the successful >0100 commands were happening after I connected before I tried to open the dashboard view. Then when I opened the dashboard carscanner started issuing the other commands. carscanner didn't get the responses it wanted and went into a LOOPV3_NO_DATA_LIMIT_REACHED loop.
I haven't tried "Protocol 9" yet, I'd guess I'd need to change the settings in the WiCAN to be 250 kbaud before doing that.
rostchri
commented
1 year ago I can report some progress 😁. I tested the v1.69 firmware today and I was able to connect to my Skoda Enyaq using 500 kbaud, Wifi-Connection, carscanner-connection profile=Skoda EV MEB: ID.3, ID.4, ID.5, ID.6, ID.Buzz, Enyaq, Q4 E-tron, Cupra Born, etc. and ProtocolNumber=7 (which I configured explicitly in advanced carscanner settings). The carscanner elm and ecu connection are working fine now and I think I got some successfully readings from my cars sensors. However I did'nt move the car (just turned it on) and I need to do some further tests reading the sensors I'm interested in and finally send them via mqtt ... Here is the log of a successful connect and some readings.
scytacki
commented
1 year ago Looking at the elm327.c code and the various logs. I see the ATSP7 command, so I now understand that I should not have to set the 250 kbaud in the WiCAN settings.
Also looking at my failed logs it seems like there might be something odd with the ATSH command. It seems to be often called with ATSHDB33F1. Which suspiciously matches the default ecu_address used in protocol 7 and 9: 0x18DB33F1, but it is missing the "first" byte of 0x18. And almost all of the ATSH* commands in the log only have 3 bytes, with the exception of ATSH710.
Looking at https://www.elmelectronics.com/wp-content/uploads/2016/07/ELM327DS.pdf
I see the ATCP command is used to set the most significant 5 bits of the CAN ID and that they should default to 0x18. So since elm327.c doesn't seem to have support for ATCP, it should be adding on the 0x18 to the ecu_address it computes when it gets an ATSHxxyyzz command.
But maybe the messages work fine without those 5 bits, so maybe this isn't isn't really a problem.
meatpiHQ
commented
1 year ago @rostchri If you want to use MQTT, It's a good idea to have a look at this: https://github.com/meatpiHQ/wican-fw/issues/17#issuecomment-1464904125
@scytacki The ATSH command sets the ECU header the app is trying to talk to, it's possible that its specific to your car. I'll add support for ATCP command and the default 0x18 byte.
scytacki
commented
1 year ago Thanks @meatpiHQ. If I can find some time, I hope to work on elm327.c to implement the other commands that carscanner is trying to send.
rostchri
commented
1 year ago I made some tests today using mqtt and node-red together with carscanner-app. In carscanner-app I'm successfully connected to the wican-adapter using wifi, and I'm using the "Live data" mode, but I reduced the sensors to a few standard sensors, because if I select all sensors the carscanner app stopped working after 3 seconds (this is maybe related to @scytacki problems).
I see the incoming "rx" mqtt-messages ("wican/my-id/can/rx") in node-red which are related to the carscanner-app "live data" sensors. All of these messages are matching the following conditions:
(msg.payload.frame[i].id == 417001733 && [4,5,12,13,66].includes(msg.payload.frame[i].data[2]))
|| (msg.payload.frame[i].id == 417001729 && [13,66].includes(msg.payload.frame[i].data[2]))
Complete example message: {"bus":"0","type":"rx","ts":42506,"frame":[{"id":417001733,"dlc":8,"rtr":false,"extd":true,"data":[3,65,12,0,0,170,170,170]}]}
Above pids matches the documentation and the selected carscanner sensors:
4 = calculated engine load 5 = engine coolant temperature 12 = engine speed 13 = vehicle speed 66 = control module voltage
So far so good. But what I'm not understanding is how to achieve the same without a running carscanner app, by only publishing a "tx" mqtt-message?
What I already tried is to send messages like:
msg.payload = { "bus": "0", "type": "tx", "frame": [{ "id": 417018865, "dlc": 8, "rtr": false, "extd": true, "data": [2, 1, 0, 170, 170, 170, 170, 170] }] }
to "wican/my-id/can/tx" after "wican/my-id/status" becomes online, but nothing appears on "wican/my-id/can/rx".
Why?
And I'm not quite sure if "id": 417018865 is correct?
I tried to understand https://github.com/meatpiHQ/wican-fw/issues/17#issuecomment-1464904125 but it is not quite clear to me how to determine the value of "id" in the mqtt-message?
At the end the solution (for VW UP) was to send:
For Temperature:
{ "bus": "0", "type": "tx", "frame": [{ "id": 2015, "dlc": 8, "rtr": false, "extd": false, "data": [2, 1, 70, 170, 170, 170, 170, 170] }] };
For SoC:
{ "bus": "0", "type": "tx", "frame": [{ "id": 2015, "dlc": 8, "rtr": false, "extd": false, "data": [2, 1, 91, 170, 170, 170, 170, 170] }] }
For Kilometers after after last Error Reset:
{ "bus": "0", "type": "tx", "frame": [{ "id": 2015, "dlc": 8, "rtr": false, "extd": false, "data": [2, 1, 49, 170, 170, 170, 170, 170] }] }
What is clear is that the decimals pids (third data-column) can be found here:
70 == 0x46 (temperature) --- 22 F4 46 91 == 0x5B (soc). --- 22 F4 5B 49 == 0x31 (kilometers) --- 22 F4 31
But I don't understand how the needed header: 0x7E0 (request ) 0x7E8 (answer) is related to the "id": 2015? Why not "id": 2016? (0x7E0 == 2016)
As soon as I understand this and mqtt is working, it should be possible to read the more advanced pids too... For my Skoda Enyaq and other MEB-Cars the non-standard but interresting pids can be found here. For example:
[CCAN=UDS,13600,0x17FC007B,1014,200,REG={0x22,0x1E,0x3B},TYPE={+,24,16,MSB},CONV={0,1,4},EXT] # BMS Spannung Hochvoltbatterie
[CCAN=UDS,13702,0x17FC007B,3,200,REG={0x22,0xF4,0x0C},TYPE={+,24,16,MSB},CONV={0,1,4},EXT] # Motor RPM
[CCAN=UDS,13704,0x17FC007B,1010,5000,REG={0x22,0x02,0x8C},TYPE={+,24,8,MSB},CONV={0,10,25},EXT] # SOC %
Above description contains the information about how to parse the results too, but at first I need to define the correct ID and rest of the mqtt-message for the header: 0x17FC007B. The pids of the above examples are 0x3B=59, 0x0c=12, 0x8C=140
scytacki
commented
1 year ago Just a follow up on ELM327 support. With the following changes:
I'm able to get Carscanner to show many of the interesting EV metrics. There are still a few metrics that require flow control support, so I'll be working on that next and will put that in a new PR.
jypma
commented
7 months ago @rostchri Could you share the latest status on using the WiCAN with an Enyaq? I'm considering getting a WiCAN, and just want to know how much "homework" would be expected from myself. I can see that one of the PRs mentioned in https://github.com/meatpiHQ/wican-fw/issues/19#issuecomment-1538920155 was closed.
Thanks a lot!
Hi, I‘m unable to get the wican adapter to work properly with my enyaq ev. The wican adapter itself (wifi,accesspoint,webui) works fine so far. I‘m on newest version v1.65. I tried many protocols, but I‘m focusing on elm327 + wifi + ios carscanner now: The elm connection is fine, but the ecu connection always fail with the „elm327 wasn‘t able to establish connection with your car“ message …
I own a normal bluetooth obd2 adapter (Vlink icar pro) too, and here everything is working properly. See carscanner logfile of a working connection here:
So i know that ProtocolNumber=7 (ISO 15765-4 CAN 29 bit ID, 500 kbaud) is the correct mode. But with wican (can bitrate: 500K, mqtt: off) i always got a 0100 BUS INIT: ...ERROR message. Some of the AT commands seem to work … Here is complete log, where ProtocolNumber=7 is chosen in advanced settings. Probing other Protocolmodes does not work either. Always the same error …
The enyaq should behave similar to the ID3, so I tried the custom init-codes in: https://github.com/nickn17/evDash/blob/master/src/CarVWID3.cpp but this does not work either …
Regardless of my connections problem, it would be very nice if the wican could somehow provide an interface (perhaps using mqtt or via web-ui) where multiple PIDs can be individually predefined, so that similar to the loop-functionality like in the above code for the ID3, the wican continously work on the given PIDs in a loop with a user defined delay and combined with the mqtt-feature, send the results of each pid to mqtt. This would be very usefull, because no additional app needs to be executed and the mqtt-results can be used in node-red for further processing (for example to use influxdb and create grafana dashboards).