davidtm
Active Member
Thanks, KiwiME. As usual, raises more questions than answers. Any idea where I can find such a diagram for the Niro?
Sent from my Pixel 3a using Tapatalk
Torque Pro on the Kona - overview and setup for interested owners
- Thread starter KiwiME
- Start date
- Replies 237
- Views 80K
Thanks, KiwiME. As usual, raises more questions than answers. Any idea where I can find such a diagram for the Niro?
Sent from my Pixel 3a using Tapatalk
janusz Grabon
Member
I don't thing we are on the same page. I have Kona EV 2020 ultimate install 003_Kona & Niro_EV_BMS.csv and 004 .My battery currents shows when is changing only wrong Charging Current !!!!!! Every thing else is correct charging from 120 Volt show 1.2 A instead 12 Amps. Level 2 240 Volts shows 50% value of current from power calculations .So far nobody have practical solution? J. Grabon USA New York
hieronymous
Active Member
OK, lack of information from your end isn't helpful. Provide full details of your charging setup, including EVSE /wall charger, charge rate etc, time to fully charge, plus photos of running gauges/dials which show the problem as you see it...
janusz Grabon
Member
![Screenshot_20200305-181454[2].webp](https://www.insideevsforum.com/community/data/attachments/7/7721-84b71697d58d3906e395ad4dbbe81049.jpg?hash=KIUgAqdX_L "Screenshot_20200305-181454[2].webp")
![Screenshot_20200305-181454[2].webp](https://www.insideevsforum.com/community/data/attachments/7/7722-84b71697d58d3906e395ad4dbbe81049.jpg?hash=KIUgAqdX_L "Screenshot_20200305-181454[2].webp")
I'm using original Kona charger 120 Volt 12 Amps energy Draw 1.3 KW (changing current show -1.2 Amp ) I will attach screen display.
hieronymous
Active Member
Don't see anything amiss with your screenshot - the car charger conversion to DC gives 1.7kW, 407V x 4.1A.
When charging, you are only getting about 1.1kW max (60 hours for 64kWh battery). Worse for cold weather, much slower when nearly 100%...
When charging, you are only getting about 1.1kW max (60 hours for 64kWh battery). Worse for cold weather, much slower when nearly 100%...
janusz Grabon
Member
Thanks
janusz Grabon
Member
Thanks
hieronymous
Active Member
Try these. They are Ign On / Ign Off. I leave you to modify them for mph:
006_Speedometer_Check,Speed,,((VAL{000_Drive Motor Speed 1}*60)/7.981))/484.4,0,200,kph,
006_Average_Speed,AvgSpeed,,tavg(3600:VAL{006_Speedometer_Check}),0,100,kph,
006_Trip_Distance Trip,Trip/km,,TOT(3600:VAL{006_Speedometer_Check}),0,500,kms,.
hobbit
Well-Known Member
With reference to my thread on CAN scoping, this gets into packet contents
and is more appropriate for over here. My DSO has some basic bus-protocol
analysis capability, which is really handy for getting a quick look at CAN
without having to set up a whole sniffing system. The effort in this case was
to see if the OBD2 queries sent into the tiny network behind the diagnostic
connector would make it through the gateway module to the powertrain P-CAN
unmolested. Having a generous "dashboard" full of fun stuff to watch by now,
I figured that bringing it up would supply plenty of high-ID traffic and I
might be able to see all of the answers.
I wasn't disappointed. Not only do the queries appear verbatim, they get sent
back on the P-CAN, and I could now see all of the ISO-TP multi-packet response
blocks if I got lucky and captured a sample with all of it inside. Once I
started peering at the response headers I realized that which sample the parts
came out of really didn't matter, the overall construction was the same every
time. Looking at this along with Jeju's google-spreadsheet really brings
home a better understanding of how OBD2 is encapsulated into the CAN layer,
as screwed-up as the "standard" for it is with all the byte changing and
sequencing and which length covers what. This page offers a rather
lengthy explanation, and it's also worth searching for "ISO-TP" in the
Car Hacker's Handbook for more. It *is* confusing, but I think
I understand it somewhat better now.
The packet analysis stuff on the scope isn't smart enough to do filtering, but
with a little post-extraction work and patching together lines from a handful
of captures, data from my car looks remarkably like Jeju's dumps. Since
my dashboard is asking most heavily on ids 7E2 and 7E4, I looked for those and
the replies. I left the timing fields in the .csv data because it gives some
idea of how fast the responses come back -- on average, seems to be about
10 ms/packet amid everything else screaming across in between, so on the order
of every fortieth packet where a responding ECU can get an appropriate word in
edgewise. Again, OBD2 traffic is about the lowest priority on the bus, but it
eventually gets there. Sure, it would have been easier to just look at the
DLC bus and see only my stuff, but then I wouldn't get such a clear idea of
the traffic density.
The LDC emphasis points out the previously unknown fields I believe to have
determined are the DC/DC converter current, described in this thread.
Given the timing observations, one full query/response cycle for a big block
like BMS data takes about a tenth of a second. I'm pondering if there's a way
to determine whether any given scantool that asks for a bunch of data with the
same mode/pid is intelligent enough to batch them up, e.g. send ONE query and
pick the different answers out of ONE reply block, or if it sends a whole
'nother Q&A transaction for each little item. I'd really hope for the former
method, for Torque Pro and OBDlink and EVOBD2 and Dr.Prius and other notable
tools, but maybe in some their designers didn't consider that or just assumed
buses are fast enough that they can be sloppy.
What I would love to have is dumps of all the *actuation* commands that a
dealer GDS can issue to the car, such as running coolant pumps and changing
valve positions to assist coolant bleeding or brake work, recalibrate sensors,
and whatever. Where's our right to repair?! What we need is someone with
a pump recall and a small CAN logger they can hang off the DLC bus and let it
run over the duration of a service visit, and/or a friendly dealer tech willing
to help the community. The ones I've talked to are VERY cagey about their
diagnostic systems, and generally have only one on site and keep it in a
special bay. Ridiculous, because it's supposed to be *portable*.
_H*
and is more appropriate for over here. My DSO has some basic bus-protocol
analysis capability, which is really handy for getting a quick look at CAN
without having to set up a whole sniffing system. The effort in this case was
to see if the OBD2 queries sent into the tiny network behind the diagnostic
connector would make it through the gateway module to the powertrain P-CAN
unmolested. Having a generous "dashboard" full of fun stuff to watch by now,
I figured that bringing it up would supply plenty of high-ID traffic and I
might be able to see all of the answers.
I wasn't disappointed. Not only do the queries appear verbatim, they get sent
back on the P-CAN, and I could now see all of the ISO-TP multi-packet response
blocks if I got lucky and captured a sample with all of it inside. Once I
started peering at the response headers I realized that which sample the parts
came out of really didn't matter, the overall construction was the same every
time. Looking at this along with Jeju's google-spreadsheet really brings
home a better understanding of how OBD2 is encapsulated into the CAN layer,
as screwed-up as the "standard" for it is with all the byte changing and
sequencing and which length covers what. This page offers a rather
lengthy explanation, and it's also worth searching for "ISO-TP" in the
Car Hacker's Handbook for more. It *is* confusing, but I think
I understand it somewhat better now.
The packet analysis stuff on the scope isn't smart enough to do filtering, but
with a little post-extraction work and patching together lines from a handful
of captures, data from my car looks remarkably like Jeju's dumps. Since
my dashboard is asking most heavily on ids 7E2 and 7E4, I looked for those and
the replies. I left the timing fields in the .csv data because it gives some
idea of how fast the responses come back -- on average, seems to be about
10 ms/packet amid everything else screaming across in between, so on the order
of every fortieth packet where a responding ECU can get an appropriate word in
edgewise. Again, OBD2 traffic is about the lowest priority on the bus, but it
eventually gets there. Sure, it would have been easier to just look at the
DLC bus and see only my stuff, but then I wouldn't get such a clear idea of
the traffic density.
Code:
# good 7e4 block : BMS
33.17ms, 7E4, 8, 0322 0101 0000 0000 # len=03, mode=22, pid=0101, pad*4
38.82ms, 7EC, 8, 103E 6201 01FF F7E7 # seq 0 of 3Eh bytes, M/P=620101, "a" - "c"
48.83ms, 7EC, 8, 21FF 8742 6842 6803 # seq 1, bytes "d" thru "j"
58.82ms, 7EC, 8, 2200 030E A50E 0D0D # seq 2, bytes "k" thru "q"
68.82ms, 7EC, 8, 230C 0D0E 0000 0EBF # seq 3, bytes "r" - "x"
78.82ms, 7EC, 8, 2401 BF54 0000 9300 # seq 4, bytes "y" - "ae"
89.66ms, 7EC, 8, 2500 65E9 0000 6403 # seq 5, bytes "af" - "al"
# from diff response packet group but same contents:
53.93ms, 7EC, 8, 2600 0025 7A00 0023 # seq 6, bytes "am" - "as"
63.93ms, 7EC, 8, 2774 0013 FAE1 0D01 # seq 7, bytes "at" - "az"
79.41ms, 7EC, 8, 2876 0000 0000 03E8 # seq 8, bytes "ba" - "bg"
# total 62 = 3Eh bytes: 3 of mode/pid confirm + 59 bytes of answer data
# good 7e2 block : EPCU / VCU
-5.93ms, 7E2, 8, 0221 0200 0000 0000 # len=02, mode=21, pid=02, pad*5
3.917ms, 7EA, 8, 1027 6102 F8FF FC00 # seq 0 of 27h bytes, M/P=6102, "a" - "d"
10.91ms, 7EA, 8, 2101 0100 0000 950A # seq 1, bytes "e" thru "k"
27.01ms, 7EA, 8, 22BB 80F1 39A0 033E # seq 2, bytes "l" - "r" <-- LDC
30.91ms, 7EA, 8, 2392 7039 2080 514C # seq 3, bytes "s" - "y"
43.90ms, 7EA, 8, 2422 6B00 0001 0101 # seq 4, bytes "z" - "af"
53.07ms, 7EA, 8, 2500 0000 0700 0000 # seq 5, bytes "ag" - "ak", pad*2
# total 39 = 27h bytes: 2 of mode/pid confirm + 37 of answer data
# LDC current: q,,p = 0x03A0, or 928, /100 --> 9.28 amps at the timeThe LDC emphasis points out the previously unknown fields I believe to have
determined are the DC/DC converter current, described in this thread.
Given the timing observations, one full query/response cycle for a big block
like BMS data takes about a tenth of a second. I'm pondering if there's a way
to determine whether any given scantool that asks for a bunch of data with the
same mode/pid is intelligent enough to batch them up, e.g. send ONE query and
pick the different answers out of ONE reply block, or if it sends a whole
'nother Q&A transaction for each little item. I'd really hope for the former
method, for Torque Pro and OBDlink and EVOBD2 and Dr.Prius and other notable
tools, but maybe in some their designers didn't consider that or just assumed
buses are fast enough that they can be sloppy.
What I would love to have is dumps of all the *actuation* commands that a
dealer GDS can issue to the car, such as running coolant pumps and changing
valve positions to assist coolant bleeding or brake work, recalibrate sensors,
and whatever. Where's our right to repair?! What we need is someone with
a pump recall and a small CAN logger they can hang off the DLC bus and let it
run over the duration of a service visit, and/or a friendly dealer tech willing
to help the community. The ones I've talked to are VERY cagey about their
diagnostic systems, and generally have only one on site and keep it in a
special bay. Ridiculous, because it's supposed to be *portable*.
_H*
janusz Grabon
Member
My to Torque pro My Kona EV 2020 Ultimate Status :charging L2 240 Volts AC charging current (Batt Current on my android display shows 16.7 Amps ) I did measure with AC amp on my Current meter is 27 Amps is correct. Discovered Torque pro is calculating charging current from Battery voltage not a charging. Energy draw is 6500 Watts. Simple 6500 Watts divided 240 Volts =27 Amps. L1 charger same thing incorrect reading 120 Volt AC. L3 is almost correct because charging Voltage is very close to Battery Voltage. Other then everything else is display is correct .Pls help me solutions Thank JG
hieronymous
Active Member
Why should TP know anything about your wall supply? It’s reading HV data from the ECU, which is all downstream from the car charger conversion, so is at approx. 400v.
janusz Grabon
Member
OK Thanks
FloridaSun
Well-Known Member
I wonder if there is a PID that shows max DC charge rate? I believe that this would be a fixed value of 83 or 84.. Not sure.
FloridaSun
Well-Known Member
Wouldn't that just yield max charge rate at the current SoC? I'm interested in the number that the car communicates to the charger as the max rate.
Once I know how to access the number, I will try to find a way to somehow alter it.
hobbit
Well-Known Member
At a middling SOC, maybe between 30% and 70%, both of these figures
will be somewhere near 160 kW in reasonable temperatures. That
doesn't mean anything with regard to how much regen you can
actually get, or acceleration power, or DC charging rate. Other factors
that the car's systems pay attention to influence what happens in the
real world.
_H*
will be somewhere near 160 kW in reasonable temperatures. That
doesn't mean anything with regard to how much regen you can
actually get, or acceleration power, or DC charging rate. Other factors
that the car's systems pay attention to influence what happens in the
real world.
_H*
FloridaSun
Well-Known Member
Does anyone have a PID for energy use of different systems?? I can only see total energy draw or charge but not broken down like for example on the dash where it breaks down the energy use by component.. Specifically, I would like to see the energy draw from battery management while charging. The car does not let me get to the screen on the center display that shows the power use while charging, so I would like to do it via Torque Pro but unfortunately, with the PIDS that I have, I can only see net energy flow while charging.