Soul Spy?

Kia Soul EV Forum

Help Support Kia Soul EV Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Status
Not open for further replies.
goev said:
Btw. what kind of OBD-readers are you guys using? I tried to log every single frame on the can-bus, but my two ELM-clones give up after 20 frames or so because the serial buffer got full. Any tips to a really good OBD-reader?

Mine have the same issue. I just monitor one message ID at a time by using ATCRA hhh before ATMA.

Depending on which messages you want to watch you could probably do a few at a time by creative use of ATCM hhh and ATCF hhh.
 
TyrelHaveman said:
Mine have the same issue. I just monitor one message ID at a time by using ATCRA hhh before ATMA.
Depending on which messages you want to watch you could probably do a few at a time by creative use of ATCM hhh and ATCF hhh.

Yes, but I have no idea which ID's to look for :) I want to find which commands are causing the doors to lock/unlock, which commands can roll up the windows, open the charge door, turn on the heating and so on. It is near impossible with the crappy ELM-clones.

I'm thinking about buying an Arduino CAN-bus shield, as they are operated using SPI at 10MHz, and then buy a SPI->USB adaptor, effectively skiping the Arduino all together. That way I might be able to actually log that amount of data without any serial buffers filling up. It means a bit more work, but it'll cost only USD40-50 instead of USD300.
Not sure if it will be a feasible solution, though. Maybe $300 is not that bad ;-)
 
Here's some data from my car. Not very interesting since it's pretty new (purchased at the end of September). It's got 589 miles on it. I'm in the Seattle area and my driving has almost exclusively been in-city (very little highway, alot of inner-city acceleration from stoplights). If I'm reading this right, my battery is at a max deterioration of 0.5%.

>2101
7EC 10 3D 61 01 FF FF FF FF
7EA 10 0E 61 01 F0 00 00 00
7EC 21 B1 1A 65 23 28 03 00
7EA 21 56 06 3E 03 00 00 00
7EC 22 26 0F 26 10 10 10 10
7EA 22 00 00 00 00 00 00 00
7EC 23 0F 10 0F 00 0F CA 10
7EC 24 C9 30 00 00 90 00 00
7EC 25 1D 96 00 00 1C A6 00
7EC 26 00 0A D0 00 00 0A 3F
7EC 27 00 06 2A FF 45 01 89
7EC 28 00 00 00 00 03 E8 00

>2105
7EA 03 7F 21 12
7EC 10 2C 61 05 FF FF FF FF
7EC 21 00 00 00 00 00 0F 0F
7EC 22 10 00 00 00 00 1A 78
7EC 23 23 28 00 01 55 0F 0F
7EC 24 00 05 0C 00 00 01 BA
7EC 25 00 00 00 00 00 00 00
7EC 26 00 00 00 00 00 00 00
 
BigEdgar said:
Here's some data from my car. If I'm reading this right, my battery is at a max deterioration of 0.5%.
Yes - max deterioration of 0.5%. and min deterioration of 0.0%.
Also Cumulative Discharge = 262.3 kWh
My car which is 6.5 months old has max deterioration of 3.5%. and min deterioration of 0.0%.
With Cumulative Discharge = 1738.2 kWh
If these things were linear then your car is following the same pattern as mine.
I have added your data to the stats I am keeping, it would be great if you could update in a few months time.
I will post an updated graph on the Battery Ageing Model thread tomorrow.
 
Alex added 2100 data to the 7EA (VMCS) in the spreadsheet, and in there I have identified the gear positions bit mapped in byte 21:4. Updated the spreadsheet.
 
I did some testing of the motor and MCU-temperatures today and I got values around 70C and 80C. The standard OBD-II engine temperatures are t=A-40, so that seems to be somewhat correct. The motor temp value was around 50 something when I started driving, and considering the temperature was around 10C, A-40 seems plausible.
 
I ran the BMC's 21 01 and 21 05 on my car and posted the data in the sheet again, because my wife took it on a trip to her mom's house and did a few DCQCs along the way. We're at 2300 mi (3701 km) on the odometer now and still no deterioration reported.

I also did 21 00 on the VMCU and added that. There are a couple fields where both Elmil and I are the same, but different from Alex. Fascinating!
 
notfred said:
Bad news on the TPMS. I only got to spend a few minutes with the car parked but I can confirm that those 0x37's in the sheet are not pressures. I have the same 0x37's and my TPMS sensors are showing slightly different pressures and temperatures and none of them are anywhere near 37psi, mine were 34.0-34.5psi or 231-234kPa and 9-11C yet all mine were byte for byte identical apart from the sensor ids.

I suspect the pressures and temperatures must be somewhere else.
Today i was again at the garage and the mechanic read out the TPMS sensors:
The data (pressure and temperature is in the 2106 answer: The first 4 bytes is the sensor ID (as we already knew). The next byte is the pressure (i got 9d hex = 157 /4 = 39,25psi, and 9C = 39,00psi as shown on the tester). The next byte is the temperature (i got 4B and 4A and the tester showed 20°C and 19°C. Not exactly sure about the calculation, Offset of 55?). The other 2 bytes is additional binary info i can't extract (Battery level, status, mode,...)

The interesting thing is that when we first read the sensors we didn't get any data (sensor ID + 00 37 00 00 -> like the response Tyrel got).
Only after learning (writing) the TPMS ID's to the ECU we were able to read the data.
I bought the tires in a non KIA-garage, so they obviously haven't programmed the TMPS ID's correct.
I'm sure i also have the command to write the sensor ID's in the trace, so we should be able to write new ID's...
Update: In the trace i saw that the ID's of left and right back tires were switched. Maybe that was the reason i didn't get temperature the first time?
Writing command is 10 12 3B 8B +4 times sensor ID, but in the trace i saw that there was a security access before writing the ID's:
27 01/67 01 55 55 55 55 and 27 02 KEY / 67 02 34. Not sure if the key is calculated. "55 55 55 55" doesn't look like a random seed.
 
Fantastic job Alex! I sure hope we can program the codes ourselves soon :)
But, how do we find the correct codes? Are there any reader we can buy to identify the 4 byte code of the TMPS'?
 
Make we just have to do something to wake up the sensors, and writing the IDs to the ECU is a way to force that? Maybe if we just checked 2106 while driving we would get the info in this response.
 
To get the sensor IDs you need to either get them from whoever supplied them or get someone with a reader to do it. I've got an Ateq VT30 and that reads them. If you have a local tyre shop you could see if they will read them for you.

I think this is kind of weird though, I can't see needing to write the sensor id to read the pressure and temps. Surely they have to be there anyway?
 
Found vehicle speed and Acceleration Pedal Depth in VMCU data. Also a couple of buttons and brake switch.
Spreadsheet updated.
 
I'm back from a 500+ trip again :lol: 3 QC stations visited on each way. On our way back, we almost pushed the limits of the battery, skipping a few QC in Québec City. We arrived there at 3%, with the turtle blinking :)

On our way back, the deterioration values changed. It was "7EC 24 00 32 2B 00 06 0D" before, I have now "7EC 24 00 2D 2D 00 01 01".


Raw date here : https://docs.google.com/spreadsheets/d/1yKIsCBAIh8Loofof10xjqqXK3_vQgKpZ7Cx3guciLjg/edit?usp=sharing
 
We just took a trip in ours as well (just 286 km, 3 DCQC sessions) but unfortunately I forgot my OBD-II adapter so I wasn't able to collect any data long the way. The DCQC at one Kia dealership we stopped at was not working (it was working a couple days ago when my wife used it), so we had to go a couple blocks to our favorite Nissan dealership instead, where we had to wait in line for an hour for the DCQC. Anyway, someone charging in front of us was a 2013 LEAF with 75,000 miles (120,000 km) on it. He had not yet lost the first capacity bar, which means he still has less than 15% capacity loss!
 
When i was at the garage on Friday we also made some "function" test with the KIA tool. The mechanic was in a hurry so we couldn't make too much tests, but i go some commands we can try for ourselves.
Following commands have been used, i add it to the spreadsheet to assign the function to the command. (He sent some commands for central locking, power lifters, Lights and relay's). I hope there is some useful stuff:
BCM (CAN ID 7A0):

2F B0 00 02
2F B0 20 02
2F B0 40 02
2F B0 60 02
22 B0 01
22 B0 02
22 B0 03
22 B0 04
22 B0 05
22 B0 06
22 B0 07
22 B0 08
22 B0 09
22 B0 0A -> Negative response / not supported
22 B0 0B -> Negative response / not supported
22 B0 0C
22 B0 0D -> Negative response / not supported

SJB (CAN ID 771):

2F BC 00 02
2F BC 20 02
22 BC 01
22 BC 02
22 BC 03
22 BC 04
22 BC 05
22 BC 06 -> Negative response / not supported
2F BC 14 03 -> Negative response / not supported
2F BC 14 00
2F BC 12 03
2F BC 15 03
2F BC 15 00
2F BC 02 03
2F BC 02 00
2F BC 01 03
2F BC 01 00
 
goev said:
Great, Alex :p

Do anyone here knows how to sends these commands using ELM?
Is it 7a0 2f b0 00 02?

If you want to listen for a response from 7A0, first use:
Code:
atcra 7a0
Then type the command:
Code:
2f b0 00 02
And you should see the response.

There's probably a way to send the command only to 7A0 (otherwise it'll go everywhere and possibly mess things up), but I haven't messed with that yet. Possibly setting the header prior to sending the command:
Code:
atsh 7a0

Let me know if that works.
 
I tried running these commands using AT SH xxx first to select 7a0 and 771, and then send the commands like this: 22 b0 01
Nothing happened! For 7A0 I got response from 7A8 and for 771 I got responses from 779. Which seems to be the same +8.

I see that the list of commands starts with either 22 or 2f. Isn't that the mode? And mode 22 is ​ReadDataByCommonID, so we shouldn't expect any action from anything except som can-messages. Or am I wrong? And what is mode 2f?

This is the log from what I did:
Code:
>at sh 7a0
OK

>2f b0 00 02
7A8037F2F7F

>2f b0 20 02
7A8037F2F7F

>2f b0 40 02
7A8037F2F7F

>2f b0 60 02
7A8037F2F7F

>22 b0 01
7A8101262B00140C000
7A82100000100000000
7A8220000020200AAAA

>22 b0 02
7A8100962B002000000
7A821000000AAAAAAAA

>22 b0 03
7A8100B62B003E00000
7A821009500EF00AAAA

>22 b0 04
7A8100B62B004F2000E
7A8217D0E000000AAAA

>22 b0 05
7A8100B62B005279A10
7A8218240000800AAAA

>22 b0 06
7A8100B62B006060000
7A8210060000000AAAA

>22 b0 07
7A8100B62B007202001
7A821E000040000AAAA

>22 b0 08
7A8100B62B00830400D
7A8218000000000AAAA

>
22 b0 09
7A8100B62B009000000
7A8210000000000AAAA

>22 b0 0A
7A8037F2231

>22 b0 0b
7A8037F2231

>22 b0 0c
7A8100B62B00C030300
7A821E000000000AAAA

>22 b0 0d
7A8037F2231

>at sh 771
OK

>2f bc 00 02
779037F2F22

>2f bc 20 02
779037F2F22

>22 bc 01
779100962BC01400000
77921000003AAAAAAAA

>22 bc 02
7790762BC0200000000

>22 bc 03
779100B62BC03FD7E7C
779214B00600000AAAA

>22 bc 04
779100B62BC04F5FF70
77921C201000042AAAA

>22 bc 05
779100B62BC05401300
779210200000000AAAA

>22 bc 06
779037F2231

>2f bc 14 03
779037F2F22

>2f bc 14 00
779037F2F22

>2f bc 12 03
779037F2F22

>2f bc 15 03
779037F2F22

>2f bc 15 00
779037F2F22

>2f bc 02 03
779037F2F22

>2f bc 02 00
779037F2F22

>2f bc 01 03
779037F2F22

>2f bc 01 00
779037F2F22
 
goev said:
I tried running these commands using AT SH xxx first to select 7a0 and 771, and then send the commands like this: 22 b0 01
Nothing happened! For 7A0 I got response from 7A8 and for 771 I got responses from 779. Which seems to be the same +8.
The response ID's are correct, the OBD answers are always +8.

goev said:
I see that the list of commands starts with either 22 or 2f. Isn't that the mode? And mode 22 is ​ReadDataByCommonID, so we shouldn't expect any action from anything except som can-messages. Or am I wrong? And what is mode 2f?
Yes, 22 is only reading data... but 2f is "InputOutputControlByIdentifier", so this should be the commands which generate a action..

goev said:
>2f b0 20 02
7A8037F2F7F
I see you get a lot of negative responses for the 2F services, and the reason is probably that the ECU is in the wrong session (the last 7F means "serviceNotSupportedInActiveSession", 22 means "conditionsNotCorrect")
So you have to send "10 03" to change the session before using the commands. But you have to be fast, because normally after a few seconds the ECU changes back to "normal session" if no request is coming.
A positive answer for the the 2F request should be e.g. 10 08 6F B0 20 02 ...
 
Yeah, I learned after I wrote that that you should -8 from the ECU you want a response from when using AT SH.

You'll probably get better responses if you do that.
 
Status
Not open for further replies.
Back
Top