Torque Pro on the Kona - overview and setup for interested owners

Discussion in 'Hyundai Kona Electric' started by KiwiME, Sep 26, 2019.

To remove this ad click here.

  1. davidtm

    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
     
  2. To remove this ad click here.

  3. 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
     
  4. hieronymous

    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...
     
  5. Screenshot_20200305-181454[2].png Screenshot_20200305-181454[2].png Screenshot_20200305-181454[2].png
    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.
     
  6. hieronymous

    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%...
     
  7. To remove this ad click here.

  8. Thanks
     
  9. Do we have a PID for distance driven? I can't find it and it would be great to have. Either total or trip, doesn't matter which.
     
  10. Thanks
     
  11. hieronymous

    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,.
     
  12. To remove this ad click here.

  13. hobbit

    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.

    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 time
    
    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*
     
    KiwiME likes this.
  14. 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
     
  15. hieronymous

    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.
     
  16. OK Thanks
     
  17. FloridaSun

    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.
     
  18. This might do that but I've never used it:
    000_Available Charge Power Max REGEN 0x220101 ((f<8)+g)/100 0 98 kW 7E4
     
  19. Well, that night be Max Regen which is higher than DC charging. Max Regen can be up to 170kW!
     
  20. FloridaSun

    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.
     
  21. It reads 143.4 kW on my Kona at 83% SoC.
     
  22. hobbit

    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*
     
  23. FloridaSun

    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.
     
    milesian likes this.

Share This Page