Ioniq EV lacks a lot of data points

[kinnison]

Hi,

The Ioniq EV entry in this repo lacks a lot of information about the car. In an attempt to make it possible to work things out, I have done a basic test set in my Ioniq and recorded the CAN traces.

My CAN probe program takes a sample every 50ms from 11 different queryable points (ECU/query) so there's a lot of data, but it should be easy to filter.

I did a basic drive, from the hackspace where I soldered my probe to the charger, and then a charge at a stand which seems to only ever offer me 15a, a charge at a stand which should do more (since it does 43kw AC) and then CCS.

I also did a standing-test where I toggled things like drive mode, VESS, etc. A rough plan is listed in the zip file, and each CAN log is in candump format.

If you need more information, please ask. I'm happy to do a variety of tests in the car.

logs-for-jejusoul.zip

D.

[migle]

Can you tell me what does your global odometer read, more or less? I would really like to be logging odometer data... EDIT: I'm "migle" in ioniqforum.com.

[kinnison]

The information is in the zip file, including odo reading, external temperature, etc.

[kinnison]

The tests were done in the order of the test log file, so the drive from the hack space to the charger was before the odo reading in the file.

[migle]

Uf... couldn't find it. This should be the easiest number to find in the logs, because being big, it's not easily mistakable. I was looking only for the most significant digits, which would repeat more. I tried, in miles, 5572 (0x15C4), 55720 (0xD9A8), 557200 (0x88090) and 5572000 (0x5505A0). Then, in km, 8931 (0x22E3), 89319 (0x15CE7), 893190 (0xDA106) and 8931900 (0x884A3C).

I see nothing regular. I thought I would find something this way, but I'm not very experienced with cars.

[kinnison]

It may be split across packets remember. Also there's no guarantee I'm querying the right ECU/message combo for getting it yet.

[migle]

I don't know anything about CAN bus. Are you getting the entire frame? I understand that the data we see in Torque comes mostly from "extended" frames.

For that reason, it's frequent that cheap ELM-327 clones don't read a big part of the data. Say, they can read "BMS SoC" but they read garbage in "Display SoC". Often the real ELM-327 gets a bit confused too (I have one). EDIT: "BMS SoC" comes from octet 14 in the frame, and "Display SoC" comes from octet 41.

[kinnison]

The CAN trace shows the full frame set. OBD-II and by extension, the car-specific PIDs we're querying, is built on UDS (unified diagnostics) which is built atop ISO-TP atop CAN. My probe supports ISO-TP and so the full ISO-TP packets are available in the trace, they simply span multiple CAN frames.

If you look you'll see frames which start 1 followed by one starting 3 followed by a number of 21, 22, 23, etc frames. This is the ISO-TP on top of CAN. the frames starting 0 are 'stand alone' where 1 is "here's the start of a long packet" 3 is "flow-control, send me more please" and 2x are the continuation frames in the packet.

If we look near the top of the basic drive log, we see:

7E2#0221010000000000
7EA#10166101FFE00000
7E2#3010000000000000
7EA#21092180A505E402
7EA#2200000000776330
7EA#2304200000000000

1. The first frame there 02 21 01 ... is the request to 7E2
2. The second frame is the 'first frame' response saying there are 0x016 bytes in the packet (24)
3. The third frame is the flow control saying "Send me up to 16 more frames please"
4. The fourth, fifth, and sixth frames are the continuation of the response.

If we decode this, we get the full ISO-TP packet for the response as being: 61 01 FF E0 00 00 09 21 80 A5 05 E4 02 00 00 00 00 77 63 30 04 20 with the final zeroes in the last frame being padding.

UDS tells us that the 61 01 at the start is a positive response to the 21 01 request. All of Hyundai's ECUs seem to fill the rest of the first frame wth some constant values (FF E0 00 00 in this case) and then the rest tends to be decodeable as data. The FF is, I think, value a, the E0 is b etc. in Torque's equations.

I hope that helps you understand the log files a little more.

[migle]

Ok. Thanks for the tutorial. So, I don't really gain anything by looking at the CAN frames. I'd better just use obd terminal and just ask 21 01 and read the response...

So, maybe in this dialog (this is from your CCS charge, where I could look for the current value which is kept constant at -125A):

(1523991329.589631) slcan0 7E4#0221010000000000
(1523991329.605233) slcan0 7EC#103D6101FFFFFFFF
(1523991329.605782) slcan0 7E4#3010000000000000
(1523991329.618291) slcan0 7EC#213E26482648C3FB // FB is K in Torque
(1523991329.628476) slcan0 7EC#222C0DCC0E0E0D0D // 2C is L, 0DCC are M and N
(1523991329.638360) slcan0 7EC#230D0D0D000FB82C
(1523991329.648413) slcan0 7EC#24B7270000910000
(1523991329.658270) slcan0 7EC#259D5B00009DFE00
(1523991329.670142) slcan0 7EC#260039E200003784
(1523991329.678149) slcan0 7EC#270013251B090161
(1523991329.688333) slcan0 7EC#280000000003E800

So, FB2C could be the current in 0.1A units, -123.6A, and 0DCC could be the voltage in 0.1V units (353.2V), if you actually were on such low state of charge. Actually, if this is true, SoC BMS would be byte e, so 3E in 0.5% units, so you would be at 31.0% SoC BMS.

[kinnison]

Yep, my charge level was around that (to my memory) so those numbers all match up with what we expect from the BMS entries in this repository :-D

[migle]

You must be careful. There's a lot of garbage there, as frequently happens with ELM-327 and Torque as well. Sometimes you ask 21 01 and get B2B2B2B2... as answer (or B4B4B4... or B6B6B6...).

Also, when reading your voltage (I was looking for a number that was rising on lines with 7EC#22), correct voltage values alternate with D0D (fgrep 7EC#22 charger-CCS.log | less). We also sometimes see correct values in Torque alternating with constant garbage values.

So, now that we found the known, we must head for the unknown, right?

[kinnison]

Can you give me an example, I would have thought that those were the different requests for the cell voltages.

[migle]

You're right. I was reading fgrep 7EC#22 and stupidly assumed that I was always reading the answer to 2101 which I was not. B6 is 3.64V (in 0.02V units).

[kinnison]

If you're comfortable with Linux, and have a CAN interface for your Linux system, then I can point you at my diagnostics program and you can fiddle :-)

[migle]

If you're comfortable with Linux,

I am.

and have a CAN interface for your Linux system,

I don't. Do I? I've no idea.

But look: I'm not going below the ELM-327. On top of that, for asking something and getting the answer, I have my own program, if needed. (Because Torque is not very clever in that it asks all PIDs with the same frequency, there's no point asking for a temperature as often as you ask for RPM).

Is there a strategy to find out what to ask? I tried Torque Scan on a trip while my wife was driving. It took a lot of time, then it didn't save the results...

[kinnison]

At one point, a chap on the German forum which sparked all this had done a scan and identified the ECU endpoints which responded to 2101 requests etc. I'm afraid I'm not very well versed in the "how to discover stuff in the car" bit, because normally I'm working on an ECU, not a scanner ;-)

I bypassed the ELM327 and went straight to a USB-attached CAN interface because the ELMs are so slow and the bluetooth ones at least are quite lossy.

The input to my program is at https://git.gitano.org.uk/canopied.git/tree/definitions/raw.yaml and from there you can see the request packet (sendto address and packet contents) of what I'm aware of so far. That's all raw stuff of course, I've not written up the conversions to real values yet. Those for the BMS are in this repo already though.

[migle]

because normally I'm working on an ECU

You work on an ECU?? You're well placed for this, then! I'll try another round of scanning the car, or checking your findings soon.

[JejuSoul]

Wow - that is a lot of data you have recorded. I will have a proper look at this over the weekend when I have time. After a brief glance from the first few lines I see that the BMS codes are as expected.

7E4#0221010000000000 7EC#103D6101FFFFFFFF 7EC#213E264826480300 7EC#22080D6E0D0D0D0D 7EC#230D0D0D000DB326 7EC#24B2270000920000 7EC#259D5600009DF800 7EC#260039E100003782 7EC#2700131FEE0D0157 7EC#280000000003E800 7E4#0221050000000000 7EC#102D6105FFFFFFFF 7EC#2100000000000D0D 7EC#220D0D0D0D0D2648 7EC#2326480001550D0D 7EC#2403E85003E8273F 7EC#2500290000000000 7EC#2600000000000000

What is new to me for the Ioniq EV is what I hope are the OBC codes at 7E5 I've picked out a couple of data points from the charger-32A-capable.log

7E5#0221010000000000 7ED#102C6101FFFFF800 7ED#2100793F0293040B 7ED#22001377003401BD 7ED#2305B04100000000 7ED#2400040000680017 7ED#25000D01F4867B03 7ED#263B001200000000 and

7E5#0221010000000000 7ED#102C6101FFFFF800 7ED#210192FD871060E6 7ED#2207747B0245006E 7ED#2305A443102000C8 7ED#240AD1037776001A 7ED#25000C01F4879584 7ED#26A9001400000000

[kinnison]

Yeah, I'm both sorry and not-sorry that the logs are quite verbose :-) I'm glad that the BMS looks sane to you :-)

If you want me to do any tests with specific cases, let me know. I'll be able to make recordings of charge sessions etc, add requests, change cadences, etc as you require.

[migle]

Using cut, paste and friends, I merged the ISO-TL packets and got rid of the CAN frames, separated by request type and endpoint, sorted by timestamp. With one response packet per line and only responses of the same kind in one file, it's easier (for me) to spot patterns.

user-friendly-logs.zip

I don't think the odometer is there, the one I would like to find. If it were there should be numbers changing monotonically, some faster, some slower, and I don't see that. One suspect would be octet 21 in the response of 7D5/7DD to 2101. It goes slowly from C4 to C7 and could form a team with any of the octets around. But I don't think it is, I would expect the entire number to be there in sequence, many non-zero digits.

[JejuSoul]

Hi migle, I didn't expect to find the odometer in these requests. I am assuming much of the coding is similar to the Kia Soul EV We can see that data analysed here - https://docs.google.com/spreadsheets/d/1YYlZ-IcTQlz-LzaYkHO-7a4SFM8QYs2BGNXiSU5_EwI/edit?pref=2&pli=1#gid=0 The odometer value is on the C_Can in 24bit Little Endian format. LE (km * 10)

kinnison - your BMS data is good. but I don't think it is the OBC at 7E5 -> 7ED Am assuming that most values from the OBC will be zero when the car is not charging.

State of Charge of Battery(BMS) 31.00 % Available Charge Power 98.00 kW Available Discharge Power 98.00 kW Battery Current 8.00 A Battery DC Voltage 343.80 V Battery Max Temperature 13.00 °C Battery Min Temperature 13.00 °C Battery Module 01 Temperature 13.00 °C Battery Module 02 Temperature 13.00 °C Battery Module 03 Temperature 13.00 °C Battery Module 04 Temperature 13.00 °C Battery Module 05 Temperature 13.00 °C Battery Inlet Temperature 13.00 °C Max Cell Voltage 3.58 V Max Cell Voltage No. 38
Min Cell Voltage 3.56 V Min Cell Voltage No. 39
Auxiliary Battery Voltage 14.60 V Cumulative Charge Current 4027.80 A Cumulative Discharge Current 4044.00 A Cumulative Charge Energy 1481.70 kWh Cumulative Discharge Energy 1421.00 kWh Cumulative Operating Time 348.16 hours Inverter Capacitor Voltage 34.30 V Isolation Resistance 1000.00 kOhm Battery Module 06 Temperature 13.00 °C Battery Module 07 Temperature 13.00 °C Battery Module 08 Temperature 13.00 °C Battery Module 09 Temperature 13.00 °C Battery Module 10 Temperature 13.00 °C Battery Module 11 Temperature 13.00 °C Battery Module 12 Temperature 13.00 °C Available Charge Power 98.00 kW Available Discharge Power 98.00 kW Airbag H/wire Duty 85.00 % Battery Heater 1 Temperature 13.00 °C Battery Heater 2 Temperature 13.00 °C State of Health SOH 100.00 % Max Deterioration Cell No 80
Min Deterioration 100.00 % Min Deterioration Cell No 39
SOC Display 31.50 %

[kinnison]

Nice to have the BMS confirmed. Okay, so the extra thing is likely not the OBC. Fair enough. The VMCU decodes which were previously provided do seem sane (brake pedal switch, brake light indicator, P/D/R/N indicator at least).

So, currently I'm requesting:

 BMS - 7E4 - 2101 2102 2103 2104 2105
VMCU - 7E2 - 2101 2102
???? - 7E5 - 2101
???? - 7E3 - 2101
???? - 7D5 - 2101

We thought 7E5 was the OBC mostly because it responds to an 090A with BCCM-B+ChargerCtrl as its name (similarly to how 7E4 responds BECM-B+EnergyCtrl

None of 7E2, 7E3, or 7D5 respond usefully to 090A.

I remember there was a non-trivial number more of CAN IDs listed which responded to 2101, perhaps I should try doing a sweep/scan?

I am attempting to book my Ioniq in to the dealer for a firmware update (I was told there should be one this month) and when I do, I'll ask if they have any printouts they could provide of ECU checks.

In the meantime I guess we're poking about trying to find patterns in what we already know about.

[migle]

The odometer value is on the C_Can in 24bit Little Endian format. LE (km * 10)

How does one query those values over the OBD port? Or it's not available through that?

[kinnison]

How does one query those values over the OBD port? Or it's not available through that?

If I have understood correctly, the Kia Soul EV has 2 CAN busses exposed on its OBD-II port. Sadly the Ioniq appears to only have the one port exposed. There is a diagnostics port in the "engine bay", but that isn't a standard shape/interface and I've not found any docs on its wiring yet.

[JejuSoul]

It is the C_Can data we are looking at here. The other data bus on the Soul EV OBD-II port is the M_Can, which I believe is the Multimedia controller. When I said it is 'on' the C_Can I was trying to say that it is one of the values that is always there. You don't request it. The problem for me is that Torque Pro only handles the responses from actual requests, which is why I can't show the odometer. Unless someone can explain to me how this could be done.

[kinnison]

I'm afraid that whatever CAN is on the OBD-II connector on the Ioniq is silent except when queries are sent. There is no background chatter like you describe there :/

[kinnison]

Unless there's commands I should be sending to turn it on which I just don't know, of course :-D

[JejuSoul]

I looked up what the acronym BCCM means when talking about an EV: Two possibilities (these may be the same thing) 'Battery Charger Control Module ' used by Ford 'Battery Charger Converter Module ' used by Magna Steyr

Looking here - http://www.freepatentsonline.com/y2017/0028857.html for the Ford meaning and here - http://www.energy.gov/sites/prod/files/2014/03/f13/arravt027_ape_peaslee_2013_p.pdf for the Magna meaning Neither of these is an OBC.

[kinnison]

If you have a Soul, are you able to issue 090A to the OBC and see what it responds? Even if it's not a full name it returns, we might be able to match the kind of error code it generates to one of the other EMUs in the Ioniq.

[migle]

BMS - 7E4 - 2101 2102 2103 2104 2105 VMCU - 7E2 - 2101 2102 ???? - 7E5 - 2101 ???? - 7E3 - 2101 ???? - 7D5 - 2101

7E3 responds to 2101, 2102 and 2103. 7E5 responds to 2101 and 2102. 7D* appears to always get a response, didn't see if it's equal...

I remember there was a non-trivial number more of CAN IDs listed which responded to 2101, perhaps I should try doing a sweep/scan?

Here's how Torque Scan does a scan: it asks all between 2400 and 241f, then 2100 to 21?? and then lots of things between 220000 to 22???? (2279a9? 227a09?).... But all this software is so rough, it looses data (the responses) after some scrolling, it broadcasts and not all ECUs respond (unless we specifically enter an ECU address), and it fails sending the logs somewhere and everything gets lost...

'Battery Charger Control Module ' used by Ford ... Neither of these is an OBC.

For a layman, it sounds the same... as well as from the block diagram in the patent you found.

[JejuSoul]

If you have a Soul, are you able to issue 090A to the OBC and see what it responds?

I tested all the known ECUs from the Soul EV. Only the BMS gives a useful response - BECM-B+ChargerCtrl The VMCU does respond in the same way - but the 23 bytes are all zero.

The OBC response I assume is an error code - 03 7F 09 11

All the other ECUs did not respond.

[kinnison]

The OBC response I assume is an error code - 03 7F 09 11

Yeah, that's an error code. Oh well, it was worth a go. So we can guess that an ECU which returns an explicit error code might be the OBC. I shall have a go at finding any such ECUs as soon as I can (likely tomorrow)

[JejuSoul]

There's a typo in my comment above. On the Soul EV the BMS responds to 090A with BECM-B+EnergyCtrl.

Could you try logging a couple of different ECUs. Finding the OBC and LDC really should be fairly easy once you can spot a temperature variable. The temperature of these 3 parts rise and fall in sync during driving or AC charging. The temps are static when parked or DC charging.

I've had another look at the responses from the 7E5 requests, and still have no idea what they are.

I'll look next at the VMCU codes. Try and see why ITStromer deleted his temperature data.

[kinnison]

I will see what I can discover this evening. If I can find an ECU responding to 090A with 03 7F 09 11 then we might have a candidate for the OBC.

[kinnison]

Several ECUs respond that way sadly. None of them seem to produce useful stuff on 2100/2101/2102/2103 excepting 7e5 which we've discounted, 7e3 which you didn't hilight before but seems to respond to 2101 2102 and 2103 (I've added 2102 and 2103 to my tester app and will post a new log) and 7d5 which you didn't hilight before either.

I'll get an AC charger log with 7e3's 2102 and 2103 results too and we can look at those.

[kinnison]

One other thing, the brake switch vs. brake lamp always seem to be opposites. Even if the brake lamp is on because of auto-hold, the value is false unless the brake pedal is pressed.

[kinnison]

I have taken some new logs with the extra PIDs included.

logs-for-jejusoul2.zip

Sorry it's quite so huge, but it's 41ish minutes long covering a charge session from 89% to 100% using an AC charger. If any of these PIDs are involved, hopefully you can spot them this time.

If you think you've found anything, let me know and I'll add the equations and re-play the log to see

[kinnison]

From a brief look, I'd guess that the new PIDs don't help much, the 2102 doesn't seem to respond (or if it does, it's super slow) and the 2103 seems to always be zeroes.

[JejuSoul]

Neither of these is an OBC. - For a layman, it sounds the same.

Have been thinking more about whether the BCCM could be the same as the OBC. I said no earlier because the BCCM is something to do with opening the DC connectors for fast charging. The OBC is only for AC slower charging.

But the OBC in the Ioniq is integrated with the DC-DC converter . And this may be the BCCM. The Soul EV has an OBC by a Korean company Mando, whereas the Ioniq has an OBC by another Korean company Mobis.

I've written about this here - http://www.mykiasoulev.com/forum/viewtopic.php?t=455&start=110#p5062

There's a newer version that supports V2G - http://www.greencarcongress.com/2017/08/20170816-mobis.html

[JejuSoul]

I really wish we had the PID code to pull the ROM ID from each ECU. see my comment here - http://myioniq.com/forum/viewtopic.php?f=8&t=73&p=484#p484

[JejuSoul]

One other thing, the brake switch vs. brake lamp always seem to be opposites. Even if the brake lamp is on because of auto-hold, the value is false unless the brake pedal is pressed.

Can you explain the auto-hold feature.

The brake switch seems to be the opposite of a common sense value. 1 = brake not pressed, 0 = pressed. I think we should inverse this value, but Torque lacks the bitwise NOT operator ! Maybe I'll use the equation {J:1} * -1 +1 Anyone got any thoughts on this.

Perhaps the brake lamp PID should just be renamed brake pedal pushed. Does the PID goto 1 when the brake lamp comes on due to regen?

[kinnison]

Auto-hold is the feature where once you reach a stop with the brake pedal, you can take your foot off the pedal and it continues to hold the brakes for you until you press the accelerator (or shift gear). This effectively annuls the 'creep' which automatics often have, but to do that it leaves the brake on and thus the brake light lit.

I shall replay some of my logs later and see if I can see a correlation between high regeneration and the brake light.

[JejuSoul]

One other thing, the brake switch vs. brake lamp always seem to be opposites. Even if the brake lamp is on because of auto-hold, the value is false unless the brake pedal is pressed.

Thanks for explaining the auto-hold. I don't have that on the Soul EV. I wish I did. I hate the stupid creep they added to keep newly transitioned ICE drivers happy.

But I am still not clear on your comments about the value for the 'Brake Switch'. To me your two sentences are contradictory. 1/ - the brake switch vs. brake lamp always seem to be opposites -- this seems clear. 2/ - because of autohold the brake lamp can be on when the brake pedal is not pressed. Both of the values will be 1. -- it is this part that is unclear and I am trying to understand.

I want to rename 'Brake Switch'. to 'Brakes On' I've been testing equations on my car and one that seems to work is {J:1} -1 * -1 When 'Brakes On' is on you are pushing the brake pedal or getting regen braking, zero otherwise.

Also see this report I forgot about - http://www.mykiasoulev.com/forum/viewtopic.php?f=6&t=471&p=3404#p3404 The 'Brake Switch' responds both to the brake pedal and regen braking.

Note - On the Ray EV we have the PID 003_VMCU Brake Pedal Depth,Brake Pedal,2102,e,0,100,%,7E2 This code is far more useful but we have never found it on the other cars.

[JejuSoul]

I just did a test of the renamed 'Brakes On' PID on my Soul EV. 30 minutes driving in B mode and 30 minutes in D mode. (equivalent to regen 2 and regen 1 on the Ioniq) In B mode the brake lamp is on when the brakes on switch is on and vice versa. But In D mode there were 8 occurrences of a few seconds each where The car is doing regen but not slowing down, the brake lamp is off and the brakes on switch is on.

[ITStromer]

So, currently I'm requesting: BMS - 7E4 - 2101 2102 2103 2104 2105 VMCU - 7E2 - 2101 2102 ???? - 7E5 - 2101 ???? - 7E3 - 2101 ???? - 7D5 - 2101

7D5 seem not to be existent in my german version of the Ioniq EV. Could it be part of bluelink? I thought only the american versions have one, right?

But additionally we have another ECU: 7E6 responds to 2180 and 2181

We are working on my google sheet to find more PIDs. Who is interested can have a look on it and may comment: https://docs.google.com/spreadsheets/d/1R2dW_4-ANg04TQdkHH52-8wdYItBkWDfppcsqOc-m1M/edit?usp=sharing

If you want to contribute directly into the document, contact me.

[kinnison]

I'll try adding 7E6/2180/2181 to my program and see if I can get anything useful out of it.

If you want any particular recordings to improve your research @ITStromer then let me know.

I don't have bluelink (UK version of the car), so I have no idea what 7D5 might be. I have the "top trim" for the UK, (Premium SE) which lacks things like a sunroof (dunno why I don't get that :-)

[asmaps]

any news on how to get the ODO value from Ioniq BEV? I programmed my own app, so I'm maybe a little more flexible but going into listening mode normally doesn't work well with the cheap dongles. Anyone found a PID/Command to issue to get the odo?

[migle]

No, not me. I think there are other things more easily discoverable, such as the OBC. My hope is low for the odometer...

Listening mode has been pointless with my non-cheap ELM-327 and my non-cheap OBDLink LX. Other users here were using generic CAN devices, so unless you find another plug in the car, listening is pointless.

[ITStromer]

I found the outside temp sensor at ECU 7e6! But I'm unsure how to name the ECU. There are more temperature sensors. One seems to be the VMCU heat sink another maybe the heating element temp sensor.

In my fork I included the outside temp sensor into Hyundai_Ioniq_EV_VMCU_data.csv like this: 003_VMCU outside temp outside temp 2180 (m-80)/2) -40 80 C 7E6

What do you think, should I pull it so back into JeJuSouls main branch or should we use another file? I would prefer to not open too much file for so few values - maybe later if we find more.

[joaand]

I added a file for Odometer in my fork.

004_Odometer,Odo,22b002,INT24(G:H:I),0,16777215,km,7c6

[migle]

Thanks! What a breakthrough! The odometer was the most important information missing.