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.
This topic has been fairly quiet of late, so am adding some info so that it stays near the top.

Development of the Soul Spy app seems to have paused, so in the meantime I am using the Torque Pro app to get OBD readings from my car.
Soul Spy - https://github.com/pemessier/SoulEVSpy
Torque - http://www.mykiasoulev.com/forum/viewtopic.php?f=6&t=471

This thread has also been used in the past for analysing the CANBUS. I am currently looking for the temperatures values for the OBC and a value that shows when the Electric Water Pump comes on. Anyone know? Currently I have to watch the value for the VMCU heatsink temperature and listen to the sound to hear when the heat pump comes on and off. It would be easier to log this automatically if we had the PID codes. What I have found so far is that the OBC heats up quite fast during charging. The EWP comes on at 47C and quickly cools the OBC back down to 35C when it shuts off.

I am using a Konnwei KW902 OBD adapter. I have now added an OBD extension wire with a switch. This solves the possible problems that the KW902 has. 1/drawing power when the car is off. 2/having an insecure password.
Tonsiki OBD 2 Cord 16 pin M/F Male to Female Right Angle Diagnostic Extension Cable with Power Switch to avoid battery drain

I pushed the OBD connector back out of its clip to allow room for the plastic cover to be closed. The OBD extension wire is threaded under the steering column so that the switch and adapter can sit under the navigation by the accessory ports.

2e372wj.jpg
 
JejuSoul said:
I am currently looking for the temperatures values for the OBC and a value that shows when the Electric Water Pump comes on. Anyone know? Currently I have to watch the value for the VMCU heatsink temperature and listen to the sound to hear when the heat pump comes on and off. It would be easier to log this automatically if we had the PID codes. What I have found so far is that the OBC heats up quite fast during charging. The EWP comes on at 47C and quickly cools the OBC back down to 35C when it shuts off.
You could try to monitor bit 2 in the VMCU record: (21 00 -> [22 3]:b2) and see if it follows the EWP activity.
See the VMCU tab of the Kia Soul EV CAN messages spreadsheet:
https://docs.google.com/spreadsheets/d/1YYlZ-IcTQlz-LzaYkHO-7a4SFM8QYs2BGNXiSU5_EwI/edit?pli=1#gid=1449971753
 
Elmil said:
You could try to monitor bit 2 in the VMCU record: (21 00 -> [22 3]:b2) and see if it follows the EWP activity.
See the VMCU tab of the Kia Soul EV CAN messages spreadsheet:
https://docs.google.com/spreadsheets/d/1YYlZ-IcTQlz-LzaYkHO-7a4SFM8QYs2BGNXiSU5_EwI/edit?pli=1#gid=1449971753
Thanks bit 2 in the VMCU record: (21 00 -> [22 3]:b2) does match the EWP activity.

But the 2 items in the spreadsheet for 'EWP speed' and' EWP Control Target RPM Request' are not correct. The EWP comes on in 2 situations I have seen so far. 1/The AC is on and the car is stopped or driving slowly. 2/The car is charging and the motor heatsink goes above 47C. Turns off at 35C. In the first AC case the 'EWP speed' stays at zero. Hence it does not measure EWP speed. In the second case OBC charging both these values start at about 40 and go up fairly quickly to about 150. When the EWP turns on both these values then decrease back to 40. The second value is always one or two higher than the first.
 
Yes but the one I choosed is able to replace the original one to clip in the front panel for kia dealer actions and my obd2 dongle always stays in the dashbord :)
 
JejuSoul said:
But the 2 items in the spreadsheet for 'EWP speed' and' EWP Control Target RPM Request' are not correct. The EWP comes on in 2 situations I have seen so far. 1/The AC is on and the car is stopped or driving slowly. 2/The car is charging and the motor heatsink goes above 47C. Turns off at 35C. In the first AC case the 'EWP speed' stays at zero. Hence it does not measure EWP speed. In the second case OBC charging both these values start at about 40 and go up fairly quickly to about 150. When the EWP turns on both these values then decrease back to 40. The second value is always one or two higher than the first.
Yes, I have been puzzeled about them for awhile too. On my car I see two different scenarios: 1) During slow charge at night, they normally indicate "activity" every two minutes or so at the beginning, escalating to permanent "active" closer to charge finish. The "EWP speed" is mostly 0x30 - 0x31 and the other one always 0x32 when "active", otherwise they are both 0x00. 2) During winter I have noticed these cells active during drive with the climate system on. They were then showing values at the 0x7D-0x7F region.
Apparently they are not related to the EWP as indicated from the GDS protocol.. Need more investigation :roll:
 
JejuSoul said:
But the 2 items in the spreadsheet for 'EWP speed' and' EWP Control Target RPM Request' are not correct.
I do not see the same behaviour or values as you. Will check again to make sure I am using the same PIDs as you. Is it possible we have different sensors in the car and different cooling systems?
I believe these values are temperature/2 and are related to the coolant system, but not the EWP itself. I see them come active in two situations.

1/ When driving above 20km/h with ambient temps 24C, VMCU Heatsink 35C, VMCU Motor 40C these values and the EWP are off (zero). But when you slow down or stop at a traffic light the EWP will come on. The two unknown values stay zero. EWP switches off when you start going faster again and then the two unknown values show a temperature about 1 degree higher than ambient for about 20 seconds before going off again. Hence I do not think they measure a Heatsink because that temperature is well above ambient.

2/ When L1 or L2 charging the EWP will come on when the OBC temperature goes above 47°C. Turns off at 35°C. (as measured using VMCU Heatsink). The two unknown values are active throughout they seem to start at ambient, go up with the Heatsink to a value about 75°C and then come back down to near ambient when the EWP is on. The OBC temperature rises and falls in this pattern throughout the charging.

---------------------------------------------------------
update 8th July, hottest day of the year so far 32°C.

Just drove a short way in the midday heat - the EWP was on all the time. The two values I am now calling Cooling Temps 1 and 2 were active the whole time. They started out at 32C and went down to 27.5C. After that they were rising and falling slightly within that range.

---------------------------------------------------------
update 10th July - 23°C car parked - air con on.

In this test the EWP was permanently on. The The two unknown values were active throughout. The first swapped between 7D and 7E. The second stayed at 7E. These values match what Elmil has been seeing, and do not match what I had seen previously. Using my temp/2 calculations these values were 63°C which does not make sense.
 
Driver SoulEV2016 in France has also posted some data about these two values. - http://www.automobile-propre.com/forums/kia-soul-ev/torque-pro-android-et-le-kia-soul-ev-t5386-20.html#p65879

Here is a translation from google translate.
SoulEV2016 said:
- I ride 90km / h at the wheel (94km / h dash)
- The car is fixed to this speed to the controller (Accel Pedal = 0%)
- And a descent occurs.
- In which I did not touch anything.
Note also that when solenoid valves are open to release the coolant from the radiator they are losing = 4 ° C the temperature controller that powers the motor.

They trigger at 40 ° C (internal temperature of the engine controller).

Nevertheless, the pump must match (Climate 1) and the other to a solenoid valve (Climate 2) when you think about it a little better.

SqaABS.png
 
ZuinigeRijder said:
I used the free Android App "alOBD terminal", but I have a bluetooth dongle, see this post:

http://www.mykiasoulev.com/forum/viewtopic.php?f=6&t=135&p=3081#p3081 (Sun Jan 17, 2016 8:42 pm)

And you can paste the values in the spreadsheet in this post:
http://www.mykiasoulev.com/forum/viewtopic.php?f=6&t=135&p=3085#p3085 (Mon Jan 18, 2016 10:51 am)

I did made a spreadsheet, so people can copy/paste the hex data to the spreadsheet and then the computed values are shown.
You can download the spreadsheet here: https://dl.dropboxusercontent.com/u/35461579/KiaSoulEV/KiaSoulEV2101_2105.xls

There was a small error in the spreadsheet for the Battery Module 7 temperature (column K25) , so I fixed that.
 
There's some new CANBUS decoding being done on the Nissan L eaf for L eafSpy to find the version numbers of the various ECU's - http://mynissanleaf.com/viewtopic.php?f=44&t=11676&hilit=EV+CAN+active+sampling&start=130#p463562
I wonder if we could do the same. It would be great for diagnosing the various versions of the OBC firmware to know the software version numbers.

Code:
Moving on from there, I thought it would be great if L eafSpy could check the software version number of the various control units. This isn't any more difficult than all the other great stuff that L eafSpy does already. To request the software code from a control module you send the following on one of the CAN IDs listed above:

0x: 02 10 C0 FF FF FF FF FF

This just opens a diagnostics session. The ECU will reply with:

0x: 02 50 C0 FF FF FF FF FF

Then request the ECUs software version with:

0x: 02 21 83 FF FF FF FF FF

a sample of how the final result would look in L eafSpy

kFaPxG.png
 
After checking many of my log files I have found that the battery temperature mapping seems to be wrong. Particularly the Max and Min values, as they appear to be just two of the module temperatures. The only mapping that fits my data is if Max and Min go where Temp1 and Temp2 are today. Then all of the Temp1-Temp8 should shift accordingly.

I have made some notes in the spreadsheet with suggested remapping.
 
Elmil: I agree that the current mapping for the temperature of the modules is misaligned. We have commented on this on the torque pro thread for a while. But the realigning of the data is not so straightforward. While I accept Module1 Temp could be called the Max Value. My analysis does not show Module2 Temp to be the Min Value.

I used a database with 2400 readings for each of the 10 values.

The value we currently call Module1 Temp is always the highest temp. 77% of the time it does show the maximum value from the other 9. But 23% of the time it is on its own as the single highest value.

The value we currently call Module2 Temp is not always the lowest temp. 60% of the time it does show the minimum value from the other 9. But 40% of the time it is a higher value. (although only by 1C)

A better fit for Min Value would be Module7 Temp.
Although Module7 Temp is not always the lowest temp. 79% of the time it does show the minimum value from the other 9. But 13% of the time it is a higher value. For 8% of the time it is the single lowest value.

-----------------------------------------------------------------------------------------

Watched the temps for 15 minutes just now after I got home. I left the car on without AC so that the fan would keep running and continue to cool the battery. It's 10.30pm, ambient is 28C, but not as humid as its been for the last 6 weeks. The two values we currently call max and min both showed 32C throughout. Early on one of the other values changed from 33 to 32 but apart from that for 15 mins there was no change. I prefer Module7 Temp as the min value not Module2 Temp

b5i4bd.jpg
 
JejuSoul, I see basically the same things as you, although on my car it's the current Module6 Temp that is mostly the lowest. Here's a sample where Module6 is 2C lower (hex bytes from the log):

Code:
M1 M2 M3 M4 M5 M6 M7 M8 LO HI (Current interpretation)
=============================
24 21 24 23 22 21 22 23 24 24
24 21 24 22 22 21 22 23 24 24
24 21 24 23 22 21 22 23 24 24
24 21 24 22 22 20 22 23 24 24
24 21 24 23 22 20 22 23 24 24
24 21 24 22 22 20 22 23 24 24
I can not explain why the Max and Min values don't exactly match the max/min module temperatures, but with the interpretation below they both seem to match exactly or +1C. The reason could be either that there is some s/w filter applied on them, a resolution/rounding issue or else there are actually 10 temperature sensors..

Code:
hi lo m1 m2 m3 m4 m5 m6 m7 m8 (Proposed interpretation)
=============================
24 21 24 23 22 21 22 23 24 24
24 21 24 22 22 21 22 23 24 24
24 21 24 23 22 21 22 23 24 24
24 21 24 22 22 20 22 23 24 24
24 21 24 23 22 20 22 23 24 24
24 21 24 22 22 20 22 23 24 24
The above would make perfectly sense, also because of the way the modules are arranged in the pack:

[m1-m8] Front
[m2-m7]
[m3-m6]
[m4-m5] Back


Higher temps in the front modules, cooler in the back.
 
Elmil said:
The above would make perfectly sense, also because of the way the modules are arranged in the pack:

[m1-m8] Front
[m2-m7]
[m3-m6]
[m4-m5] Back


Higher temps in the front modules, cooler in the back.

I am not convinced that higher temps in the front modules, cooler in the back makes sense. It is not what I get when I put my numbers into your proposed arrangement.
Also when the battery fan is on I would expect the reverse, cooler in front and warmer in the back. I don't get that either.

The size of the module stacks varies. I would expect modules 1, 4, 5, 8 to heat up more because they are bigger stacks.

28i2q07.jpg



Perhaps the only way to resolve the question is to go ask an SK Innovation engineer at the Seosan battery factory. I am thinking about how best to do this.
 
JejuSoul said:
I would expect modules 1, 4, 5, 8 to heat up more because they are bigger stacks.
Not necessarily. They also have larger encapsulation area to spread the heat in.

I agree that we cannot know for sure where any of the 8 module temp values are located in the BMS data. However, I think it's more important to identify the max and min temperature values, which are more useful when presenting the data.

In my logs, there is a very clear difference in the behaviour between the values we now call Module1 and Module2 on one hand, and the other 8 values on the other. I slow charge (2kW) during night, so the battery has a very slow temperature rise, around 3°C during 8 hours. The resolution of the temperature values is one whole degree, so there is always a time frame of several minutes, where the temp value is toggling between the two values, until the higher value is stable.

This is true for all of the other 8 temp values, but not for "Module1" and "Module2". When those two change value, they always go to the new value and stay there without any "flicker". To me this means they must have some sort of filtering or hysteresis, and that they are probably the max and min values.
JejuSoul said:
Perhaps the only way to resolve the question is to go ask an SK Innovation engineer at the Seosan battery factory. I am thinking about how best to do this.
Would be great if that was possible :)
 
Elmil said:
There is a very clear difference in the behaviour between the values we now call Module1 and Module2 ... there is always a time frame of several minutes, where the temp value is toggling between the two values, until the higher value is stable This is true for all of the other 8 temp values, but not for "Module1" and "Module2" ..., and that they are probably the max and min values.
Elmil: Okay. I accept that reasoning. There is a clear difference in the behaviour of 2 of the values compared to the other 8, so those 2 are the ones we shall call 'Max' and 'Min'.
We still have the confusion that the 'Min' value is often not the minimum temperature. It is often 1C higher than the lowest value. At least the 'Max' value is always the highest, just that it is often 1C higher than any other value. I will adjust the Torque PID codes accordingly.

I am not sure that we will ever know what they actually represent. If it is just poor programming or a badly designed algorithm then they are unlikely to ever admit it. This is also true for the 'Max Det' and 'Min Det' values. Sometimes the Min is greater than the Max. For now I just accept it as it is.
 
The SoulSpy app has never been released and development seems to have stopped. The code for SoulSpy is here: https://github.com/pemessier/SoulEVSpy
It would be great if someone could keep the SoulSpy project alive.

Other alternatives do already exist:
OVMS is the most powerful - but also quite a pain to install. Search this forum for the OVMS thread.
You probably want the Torque Pro app. - Setting up Torque to show BMS data

de5d815.jpg
 
Status
Not open for further replies.
Back
Top