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.
A few of us have been spending time on this and we're finding some interesting things on the C_CAN. Not much has been done with M_CAN. I'm not sure how or if I can get that with my ELM327s? From what I can see the ELM327 probably isn't wired to the necessary pins to get the M_CAN. But on the other hand the LEAF seems like it has two ("normal" and "EV CAN"). Maybe I'm just confused?

I'm worried because there's a lot of stuff we see in the screenshots from Kia's maintenance utilities that there's no evidence of on C_CAN. For example, there's nothing that looks like it could be the voltages of all 96 cells of the battery. Maybe that has to be retrieved another way?
 
notfred said:
So at 7EA we have an ECU that doesn't want to tell us what it is, but at 7EC we have "BECM-B+EnergyCtrl".
The ECU at 7EA is the one that responds with the VIN to a 0902 request.

BECM-B+EnergyCtrl is the same value returned by the ECU in the Chevy Spark EV: https://gist.github.com/anonymous/b6d68671772a2ca1ecc9

They list a bunch of Mode 22 codes it responds to in the Spark. I've tried a bunch of these (and other random values) and can't get anything useful, always this to each request:
Code:
>22 0000
7EA 03 7F 22 11 
7EC 03 7F 22 11

7F indicates that neither ECU understood the request.

I ran through some other modes to see if it would respond to anything else (over 09 obviously), and found these:
Code:
>14 0000
7EA 03 54 00 00

Code:
>17 0000
7EA 02 57 00

Code:
>20 0000
7EA 01 60 
7EC 01 60

I went all the way up to mode 0x50 trying 0x0000 on each one and those are the only ones that responded. None of them look like the Spark's response to 22 0000. But there may be interesting things to look for there.

So... what's the probability that I can cause something to break in the vehicle by sending random requests like this?
 
Tyrel: I think you have already realised the answer to your first question.
"...there's nothing that looks like it could be the voltages of all 96 cells of the battery. Maybe that has to be retrieved another way?"
This data is almost certainly got by querying the Battery Energy Control Module or BECM.

If you type BECM-B+EnergyCtrl as a search query into google you get the result about the Chevy Spark EV that you link to.
But if you type the same query into DuckDuckGo you get the result http://www.opel-ampera-forum.de/viewtopic.php?f=39&t=1147 about the Chevy Volt

And on that page is one answer to your second question.
"So... what's the probability that I can cause something to break in the vehicle by sending random requests like this?"
"It is too dangerous. Calling random services without knowing what you're doing, can adjust one of the modes. For example, changing the steering angle sensor ... and oops you can no longer steer!"

A less worrying answer is here http://www.canbushack.com/blog/index.php?title=scanning-for-diagnostic-data&more=1&c=1&tb=1&pb=1
"Keep in mind that you may get some CAN BUS errors. This is to be expected, but should not cause concern. You may also have some strange affects on the car such as a windshield wiper move or blinker kick in. This is because you are sending data on the bus that is interpreted by other controllers and you may have inadvertently activated another command. Cool, huh?"

I would recommend the cautious approach.
 
JejuSoul said:
I would recommend the cautious approach.

Is there another way to find out what PIDs it'll respond to? Earlier posts on this thread indicate that the service manual doesn't document any CAN messages.

From the Spark EV forum it looks like they may have just brute force tried every possible message on mode 22 and what we see on that github gist are the results. But that's the approach you don't recommend and I am also hesitant to do.
 
The SparkEV hacking pages are really interesting.

The topic begins here: http://www.mychevysparkev.com/forum/viewtopic.php?f=10&t=3926&start=10
They have the same dilemmas as us -
Code:
"It's tempting to buy a cheap Chinese MDI clone from Aliexpress for $200 and a 3-day GDS2 subscription for $57, and then sniff the CAN bus traffic, but who knows if it will work? If it doesn't work, I'll have wasted the money :/
I do agree, BTW, that passively sniffing the CAN bus and avoiding diagnostic protocols is more powerful (and safer), but we probably won't see these values reported without sending diagnostic commands to the BECM."
They did brute force the BECM and it worked.

Next http://www.mychevysparkev.com/forum/viewtopic.php?f=9&t=4199&start=20
Here we have detailed instructions on how to load a custom library of PID codes into the Apple software EngineLink.
No need to write their own software or app. Just install https://itunes.apple.com/us/app/engine-link-obd-ii-vehicle/id591557194?mt=8

So to summarise the situation for other EVs.
Tesla owners use OBD2 to SMS using a SIM card device. Then OVMS software.
LEAF owners use OBD2 over Bluetooth. Then LEAF Spy. (Android software)
BMW owners use OBD2 over Ethernet. Then bootleg official software.
Spark owners use OBD2 over WiFi. Then EngineLink (Apple Software)
 
I decided to go ahead and try some brute-force searching. I first scanned every mode from 0A to FF for PID code 0000. The only ones that responded were those I previously mentioned: 14, 17, and 20.

I then wrote a program to use my ELM327 over Bluetooth and start searching a mode for responses. I spent a while letting it run on mode 14 before I realized I should probably add some sort of indication as to how far it has gotten so I can know how long it's going to take. So I added that and started over. It turns out it will take about 80 minutes per mode!

My initial run on 14 was about 15 minutes, so I probably got close to about 0x3000. The only one that had responded in that range was the original 0x0000.

If I were to spend an hour per night in the car brute forcing these, it would take me nearly a year to search every possible PID. Clearly that's not an option.

Not knowing a lot about CAN myself, I'm wondering a few things: Is it safe to assume that if a mode is going to respond at all, it will at least respond to 0x0000? That is, can we assume that modes 14, 17, and 20 are the only ones that we'll get responses from anywhere? If that's the case, then there's only about 4 hours of searching to do. If we can't assume that, then we'll probably want to seek another approach.
 
I have begun testing my new Konnwei OBD2 Bluetooth adapter.
My software of choice would be open source, so I first used AndrOBD from Fdroid.
The initial page suggests the connection is working.
140vgyc.jpg

I will now have to add a custom PID list so that it can see other data from my car.
Problem with this software is that is has a lot less useful features and is much
harder to use than the commercial TorquePro.
 
The second software I tested was TorquePro with the plug-in TorqueScan.
This also successfully connects to the CANBUS and reads vehicle data.

wi3ev4.jpg


Again I would need to add a custom list of PIDs in order to use this.
I did run the TorqueScan tool for a few hours. It checked all the PIDs in modes 21 and most in 22.
I didn't watch it. I just turned it on and left because TorqueScan tells you this will take a LONG time.
It didn't find anything. I am not surprised.
Mode 21 is used by Toyota. Mode 22 is used by GM.
There doesn't seem to be a way to configure TorqueScan to check a particular range.
 
To continue the series of how other groups hacked the CANBUS
Toyota Prius owners use OBD2 over Bluetooth. see Gen2 Prius: Custom PIDs for Torque (Android App) with formulas
Their GoogleDocs spreadsheet is laid in a style that can be directly imported !
With instructions on how to import the found PIDs into Torque
Code:
Copy the CSV file to Android SD card (could be internal memory)
Download and unzip the CSV file in ".torque/extendedpids" folder on your micro SD card. Keep in mind that ".torque" folder is hidden so set your explorer to show the hidden folders. If you don't see the folder, create it.
Import Custom PIDs
In Torque main screen, press Menu -> Settings -> Manage extra PIDs/Sensors -> Menu -> Add predefined set.
Display Custom PIDs
From the main menu (rotatable items), choose the Realtime Information. From there, you can add those custom PIDs that you imported. Just touch and hold the empty spot and a menu will come up.
looking at the Spreadsheet we can see that Toyota uses mode 21 for its extended PIDs.

Also of interest in this forum was this post
Code:
I somehow managed to disable my PiP, and was hoping I could share my story and get some advice on what I might have done wrong.
I purchased a Bluetooth ScanTool OBDLink MX from Amazon. This seems to be the one that is the fastest according to the Torque website. I was worried about buying an inexpensive one because it might cause problems (heh).
I installed Torque app on my Touchpad.
Connected the OBDLink MX to my PiP and started the car. Then I went to Torque and connected via Bluetooth. I then downloaded the PiP (US) 1-22-2013.zip and copied the following two files to .torque/extendedpids on my Touchpad:
PiP Adv (US).csv PiP Config.csv
Back in Torque, I went to Settings -> Manage extra PIDs/Sensors and added PiP Adv (US) and PiP Config.
I then went to Realtime Information and added held down until Item options popped up, then tapped Add display. I added a Digital Display and "State of Charge". I drove around and it read out exactly what I expected it to! Great!
Then I added a second display selecting Dial (Needle) and "Engine kW (At the wheels). This also worked as expected and showed me how much power I was applying. I adjusted the range so I could better see the amps.
I then pulled over and decided to deactivate the reverse beep. I added a Digital Display and "Reverse Beep Query". It showed 0. I then added an "On/Off display" and assigned "Reverse Beep Disable". Reverse Beep Query immediately displayed 64 and I then only received a single beep when putting it into reverse. I went ahead and deleted the two Reverse Beep related gauges and continued my drive; testing reverse a couple more times (just a single beep when engaged...perfect!).
Everything was looking good as I pulled into my garage for the night. I turned off my Touchpad and brought it with me; but left the ScanTool connected (was this my big mistake?). The next morning my wife pulled out and up the block. Red light comes on for ABS and the one that looks like you are skidding. She tried calling me, but my cell didn't ring. She was late so continued driving (I know). A little while further all the lights started lighting and the dreaded "Pull over when safe" message came up. She did so, and since she couldn't reach me she called the Toyota Dealer.
They had her drive 1 mile to the dealership (?!?). She reached me from there and I asked her to pull out the ScanTool. They checked the car out a little while later and cleared all codes. They road tested it and said this may have been caused by incorrect PDI. Note that I still only get a single beep when going into reverse; so that setting stuck.

Any advice on where I went astray? I am a bit afraid to re-connect my device. Being new to OBD (but not technology), I may have gotten ahead of myself here. Thanks for any advice, and sorry for the length of the post.
And an important lesson learned.
Code:
Since she did not know it was there; she may have bumped it. I need to remember to always alert her when I'm modifying our vehicle ;-)
So to summarise the situation for other EVs.
Tesla owners use OBD2 to SMS using a SIM card device. Then OVMS software.
LEAF owners use OBD2 over Bluetooth. Then LEAF Spy. (Android software)
BMW owners use OBD2 over Ethernet. Then bootleg official software.
Spark owners use OBD2 over WiFi. Then EngineLink (Apple Software)
Prius owners use OBD2 over Bluetooth. Then Torque. (Android software)
 
JejuSoul : Indeed, the Konnwei works, this is the one I have. I test it with other apps you mentionned (namely Elm327 OBD Info and Android OBD-II Reader).

By the way, I see you are testing on a Base 2015 model ;)

I started to write an app last week, main application framework is done and Bluetooth communication should be fully working around this weekend, I'll post a message then!

A few pictures so far:

XoxicMTPkbklVrO37Yx-s3rCBUeCK4TGknF5awuON35gy-vvdCo=w480-h800-no


J5icsFCyzzUia3LtbZZd_xtnTKJ0LG5CLi6hTOcnAdQAOHa3cs4=w480-h800-no


VB_wgYDvntX3Fp2AgBhP7YOeb9pVREyoRxcOOsbut-YEUfjEM4Y=w480-h800-no
 
SiLiZiUMM said:
Thanks, I just fixed the links!

Looks good so far. It's nice to see it looking like a real Android app!

I was thinking it might be a good idea to make an app that has the potential to support multiple vehicles in the future. It'd be great if you're already making your code abstract enough for that.
 
Looks great folks. Just curious any plans for an iOS app?
 
I've been hitting a bunch of PIDs on different modes to see what I can get... I've had some interesting things happen, but no major discoveries.

I scanned all of mode 17: a lot of PIDs returned 02 57 00, usually from 7EA but sometimes from 7EC.

Every PID on mode 20 returns 01 60 from both 7EA and 7EC.

I started doing some random scanning: pick a mode in my head, then scan random PIDs on it. There is where the interesting things started happening.

On a few PIDs I scanned 10,000 random PIDs; then I started doing 2,500 as I was getting tired of waiting.

I have done at least 2,500 random PIDs on modes 10, 11, 14, 21, 22, 23, 25, 26, 27, and 30.

Lots of PIDs on mode 10 cause the brake system to freak out and display all the warnings on the dash.

Some PIDs on mode 11 make a relay click somewhere in the left side of the dash, and the dome lights flash off (I had a door open so they were otherwise on).

Some PIDs mode 27 caused the lights to dim as if I had shut the door, except faster than when I actually shut the door. The display also changed to indicate that the door was no longer open when this happened. But it was very brief (less than a second after the PID was tried).

In all of these cases I don't know exactly which PID did it because I was just hitting random PIDs as fast as possible (about 10 per second).

No sign yet of anything that might return any useful data.
 
To continue the series of how other groups hacked the CANBUS
The English speaking Renault EV owners seem to be following a very similar approach to the ideas on this thread.
(The names suggest they are Danish, Dutch, Norwegian ...)
Their focus is a clone of Leaf Spy.
And interestingly just like with the Soul EV the German speakers have followed an OVMS approach.
Am curious to see which way the French owners will go!

The website is here http://canze.fisch.lu/
Here's what they have so far. Click for bigger image.


There is a lot of interesting info on this website that is particularly relevant to us.
  • Recommended hardware - Konnwei KW902, must be version 1.5 or 1.4. Newer version will not work!
    The app has “safe driving mode”, which does not allow to manipulate the app while driving.
    The source code is open and available at https://github.com/fesch/CanZE
    Looking at the issue tracker https://github.com/fesch/CanZE/issues. There is a strong focus on safety and stability.

So to summarise the situation for other EVs.
Tesla owners use OBD2 to SMS using a SIM card device. Then OVMS software.
LEAF owners use OBD2 over Bluetooth. Then LEAF Spy. (Android software)
BMW owners use OBD2 over Ethernet. Then bootleg official software.
Spark owners use OBD2 over WiFi. Then EngineLink (Apple Software)
Prius owners use OBD2 over Bluetooth. Then Torque. (Android software)
Renault owners use OBD2 over Bluetooth. Then clone of LEAF Spy. (Android software)
 
I'm not going to do any more random probing of the OBD-II modes. It is obvious that doing so can make things happen and I'm afraid something is going to get messed up now.
 
TyrelHaveman said:
I'm not going to do any more random probing of the OBD-II modes.
Good idea.

I also just noticed this https://github.com/openvehicles/Open-Vehicle-Monitoring-System/commit/803e4195a28b641c483e482b5a054658ac02dee5

The first alpha release of the OVMS software for the Soul EV.
 
JejuSoul said:
TyrelHaveman said:
I'm not going to do any more random probing of the OBD-II modes.
Good idea.

I also just noticed this https://github.com/openvehicles/Open-Vehicle-Monitoring-System/commit/803e4195a28b641c483e482b5a054658ac02dee5

The first alpha release of the OVMS software for the Soul EV.
Yes we are just starting to test the SW...

I already got SOC, Status of loading, Range and GPS to my Phone via SMS :)
 
Status
Not open for further replies.
Back
Top