1. Attachments are working again! Check out this thread for more details and to report any other bugs.

Decoding CAN messages 0x348 & 0x3C8 as described by pEEF

Discussion in 'Gen 2 Prius Technical Discussion' started by lopezjm2001, Jun 1, 2012.

Page 1 of 4
  1. lopezjm2001

    lopezjm2001 Senior Member

    Joined:
    Apr 14, 2009
    1,146
    407
    5
    Location:
    Sydney Australia
    Vehicle:
    Other Electric Vehicle
    Model:
    N/A
    I am starting this new thread in an attempt to decode the 0x348 and 0x3C8 as described by pEEF at this post - Update and technical details on my PHEV project | Page 2 | PriusChat

    This should help JDH2550 in his attempt to recreate pEEF's PHEV project at this post - YAPiP - recreating pEEf's approach | PriusChat

    I have been doing some work to try to find out what the two can frames 0x0348 and 0x03C8 do as described by pEEF. I used my Canview V4 serial output which downloads 80 raw CANbus frame messages roughly about once per second at 115kps to my Notebook and using the Realterm program the data is captured and stored into a file. The data file is attached.
    I then used a simple hexedit program. Also attached.
    I used the find function in the hexedit program to find these two can messages as shown below. They have the same data all the time due to my Prius being in OutOfGas mode so my ECM was disabled due to a DTC so communications would be very limited, if any at all.
    Forced EV is a term used where the ECM is disabled by a DTC and is also referred as OutOfGas mode or ICE kill mode.

    Byte 0, 1 ,2 ,3 ,4 ,5 ,6 ,7 ,8
    Hex ......03 ,48 ,06, 00, 01, 00, 00, 00, 52 _______ Forced EV

    Just looking at the control data bits (bytes 3 - 7) :

    Hex........00,01,00,00,00

    Binary......0000, 0000, 0000, 0001, 0000, 0000, 0000, 0000, 0000, 0000 ______Forced EV

    HV ECU >>>>> ECM, warm up request, RPM request, ice allowed to run...

    Byte 0, 1 ,2, 3, 4, 5, 6, 7

    Hex......03, C8, 05, 04, 34, 00, 00, 08, ________ Forced EV

    Just looking at the control data bits (bytes 3 - 6 ) :

    Hex........04,34,00,00

    Binary.......0000, 0100, 0011, 0100, 0000, 0000, 0000, 0000, 0000, 1000 _______Forced EV

    ECM >>>>>> HV ECU, How to warm up.....

    The first two bytes are the frame identifier or the ECU id. sending the message onto the CANbus. The third byte is the number of bytes of control data which follow. It is this control data (minus the check sum byte) that we are interested in. The last byte is the checksum which is an data error detection for the complete message. I am planning to collect these two can messages whilst the ICE is enabled. Collect data for EV, stealth mode and Ice spin and warm up. Hopefully we can find which bits do what. This will take time and I will post as I go.

    Hex...........03, 48, 06, FF, FF, RPMr, TT, TT, Checksum

    FF-Flag bytes
    RPMr - RPM requested (PID)
    TT - Torque as measured by MG1 (PID)

    Flag bytes (FF0,FF1)-
    0C,60 - ICE run/spin (HV battery charge request) heavy deceleration
    04, 60 - ICE run/spin with acceleration gas pedal position < 60%
    04, 62 - ICE run/spin (ICE idling Request) no acceleration
    04, 70 - ICE RUN when gas pedal position => 60% then not 70 until pedal position <50 giving a 10% differential.
    04, 21 - seen just before 00,21
    00, 21 - seen just before 00,01
    00, 01 - EV/Stealth mode/forced EV (No ICE Request)
    00, 42 - seen once only right after 00,01 (ICE idling request)

    FF1 bit 0 - ICE stop request
    FF1 bit 1 - ICE idle request
    FF0 bit3 - HV battery charge request


    Hex............03, C8, 05, FF, (28-34), RPMa, 00, Checksum

    FF - Flag bytes -

    06 - ICE running & ICE warm-up request until ECT = 50degC, then not again until ICE =< 40degC or less giving 10degC differential.
    00 - ICE running or spinning or stopped & ICE has warmed up
    04 - ICE warm-up request (ICE is cold)

    bit 2 - ICE warm-up request

    ICE SPIN MODE

    Hex............03,48,06,04,60,RPMr,TT,TT,Checksum, ICE rpm requested = 975

    RPMr -Requested RPM
    TT - Torque As measured by MG1

    Hex ...........03,c8,05,00,(28-40),RPMa,00,Checksum

    (28-40) - This value increases from 28 to 40, S4 = 28
    RPMa - Actual RPM
     

    Attached Files:

    #1 lopezjm2001, Jun 1, 2012
    NortTexSalv04Prius likes this.
  2. jdh2550

    jdh2550 Co-Founder, Current Motor Company

    Joined:
    Nov 16, 2010
    317
    249
    0
    Location:
    Ann Arbor
    Vehicle:
    2005 Prius
    Model:
    N/A
    Thanks! I look forward to seeing those other data files. This is exactly the sort of investigation I'll be doing when I get my dev board up and working (yes, I could simply use other, already developed hardware, to do that capture - but I want to use my dev board in preparation for writing the "bECU+" code). :)

    Thanks again for taking the time to do this :)
     
    #2 jdh2550, Jun 1, 2012
  3. jdh2550

    jdh2550 Co-Founder, Current Motor Company

    Joined:
    Nov 16, 2010
    317
    249
    0
    Location:
    Ann Arbor
    Vehicle:
    2005 Prius
    Model:
    N/A
    BTW, I'm looking at that graph you included and I'm a bit confused...

    Here's my assumptions as to channel definitions:
    • "Max Charge Current" could be more accurately described as "max allowed charge current". Same for "Max Discharge Charge Current". The actual current going in and out is the green Amps line.
    • No ICE RPM because we're in EV only mode.
    Now here's the confusing thing...

    How can SOC% go up and down so much? Is this a result of how your spoofing the system? Look at the data around the 400 second mark (I presume it's seconds?). You're accelerating around the 50kph mark and as expected you're drawing down amps. That matches the real world - however SOC goes *UP* during that period. And not only does it go up but there's a big step change from around 75% ti 100%. From a physical battery charging perspective that's impossible.

    There's probably no need to explain this because I'm guessing it's more to do with whatever spoofing is going on.

    I'm assuming that the graph was generated in excel? For grins you could calculate EV power (current * voltage) and integrate these readings to find your EV efficiency in Wh/Mile (integrate speed to get distance).

    BTW, for my system I don't know whether I'll need to spoof the battery messages because I'm acting as gatekeeper between hECU and eECU and that might be enough. On the other hand the hECU is expecting that it's connected to a small NiMH pack with an even smaller limited available energy region - so I might have to spoof it. However, if I do spoof it I'll also be able to add a set of my own messages to give the real data.

    Anyways, it's a fascinating graph - thanks for sharing (yes, I'm that geeky that I find graphs like this "fascinating" :) ).
     
    #3 jdh2550, Jun 1, 2012
  4. jdh2550

    jdh2550 Co-Founder, Current Motor Company

    Joined:
    Nov 16, 2010
    317
    249
    0
    Location:
    Ann Arbor
    Vehicle:
    2005 Prius
    Model:
    N/A
    Oh hang on a sec. I assumed that "Current" is "Battery Current" - that's a common assumption in the B.E.V world.

    However "Current" in this case could be any number of mesaurements:
    - input / output from MG1 or MG2
    - input / output from inverter
    - input / output from HV battery pack (that's what I was assuming - but now I'm guessing that was an incorrect assumption)

    In which case none of my previous comments really apply (or at least they need rethinking dependent on what "current" we're measuring).
     
    #4 jdh2550, Jun 1, 2012
    dave77 likes this.
  5. lopezjm2001

    lopezjm2001 Senior Member

    Joined:
    Apr 14, 2009
    1,146
    407
    5
    Location:
    Sydney Australia
    Vehicle:
    Other Electric Vehicle
    Model:
    N/A
    Norm's BMSplus is designed to spoof the SoC. The high modified SoC tricks the HV ECU into allowing more electric assist and maybe less ICE.

    Your own home made Battery ECU will have to send these CAN messages to the Canbus. Voltage, current, CCL (current charge limit), DCL (current discharge limit), four battery temperature readings and SoC and pack delta value, internal HV battery cell values. These PIDs are well documented. See Prius PHEV TechInfo - EAA-PHEV

    Obviously you will have to adapt from NiMH chemistry to LifePo4. Normally NiMH battery temperature had a bearing on the SoC value. The SoC would be higher if the battery temperature was higher to a point. A high temp also decreased CCL and maybe DCL. A high SoC near or above 80% will start the ICE. You may want to experiment just for fun with your existing dodgy NiMH pack before removing it. See what happens when temperature sensors go high by heating them up with a heat gun. See what happens when you place the temp sensors inside ice water.
     
    #5 lopezjm2001, Jun 1, 2012
  6. lopezjm2001

    lopezjm2001 Senior Member

    Joined:
    Apr 14, 2009
    1,146
    407
    5
    Location:
    Sydney Australia
    Vehicle:
    Other Electric Vehicle
    Model:
    N/A
    Just figured out that my Canview V4 shows these two CANframes on the raw data screen as they are being updated live. Thanks Norm. The updating is so fast. I will make a video of it later and post it on YouTube.

    UPDATE: I have now recorded data for the only two ICE rpm I could get to be constant whilst in park. Despite the accelerator pedal position I could only get two target RPMs. At 1500RPM and 2500RPM(maximum). I also recorded one data file of a warm up in park until ICE reached 50degC and the ICE just stopped by itself, accelerator pedal position 0. The RPM values steps in lots of 25.
    ___________________________________________________________
    Hex.. .... 03, 48, 06, 44, 60, 3C, 00, 00, 31_________Park,1500RPM

    Control data. 44,60,3C,00,00

    Third control byte = (hex)3C = (dec)60 x 25 = 1500RPM - requested RPM - PID

    The fourth and fifth byte is supposed to be the target torque requested. Since the Prius is in Park no torque is required hence 00,00.

    Binary........ 01000100, 01110000, 00111100, 00000000, 00000000

    The second byte bit 4 goes high when accelerator pedal position is aprox. between 60% and 100%, it seems that this bit tells the ICE to start.

    The second byte bit 0 goes high when ICE is disabled

    __________________________________________________________

    Hex............ 03, C8, 05, 00, 34, 2e, 00, 32____________Park, 1500RPM

    Control data. 00, 34, 2e, 00

    Hex(00) - Always zero

    Hex(34) appears to be a PID that is temperature related.

    The third byte = (hex)2e = (dec)46 x 32 = 1475RPM - actual RPM - PID

    Binary....... 00000000, 00110100, 00101110, 00000000
    _________________________________________________________
    Hex.......... 03, 48, 06 , 44, 70, 64, 00, 00, 69____________park, 2500RPM

    Control data 44, 70, 64, 00, 00

    The third control byte is (hex)64 = (dec)100 x 25 = 2500RPM - requested RPM - PID

    The fourth and fifth byte is supposed to be the target torque requested. Since the Prius is in Park no torque is required hence 00,00.

    Binary....... 01000100, 01110000, 01100100, 00000000, 00000000

    The second byte bit 4 goes high when accelerator pedal position is aprox. between 60% and 100%, it seems that this bit tells the ICE to start.

    The second byte bit 0 goes high when ICE is disabled
    __________________________________________________________

    Hex..........03, C8, 05, 00, 34, 4e, 00, 52_____________park, 2500RPM

    Control data. 00, 34, 4e, 00

    Hex(34) - appears to be a PID that is temperature related.

    The third control byte is (hex)4e = (dec)78 x 32 = 2496RPM - actual RPM - PID

    Binary.......... 00000000, 00110100, 01001110, 00000000

    ____________________________________________________________

    EV MODE (0 - 44 kph) No fuel flow, ICE rpm = 0,

    Conditions to enter and stay in EV mode:

    1. HV battery S0C>40%<80%,
    2. Speed<45kph,
    3. Engine>40degC unless entered EV mode immediately at start up,
    4. Throttle position <aprox. 60%, limit probably determined by HV ECU
    5. Battery temperature too cold or too hot (CCL/DCL).

    EV mode will draw a lot more battery power than Stealth mode until SoC = 40% whilst all conditions are met. Whilst Stealth mode a SoC of 65% is targeted.

    Hex......... ..03, 48, 06, 00, 01, 00, 00, 00, 52

    Hex............03, c8, 05, 00, 34, 00, 00, 04


    STEALTH MODE (aprox. <64kph), No fuel flow, ICE rpm = 0,

    Conditions:

    1. HV battery S0C>40%<80%,
    2. Speed<64kph,
    3. Engine>40degC
    4. Throttle position <aprox. 60%, limit probably determined by HV ECU
    5. Battery temperature too cold or too hot (CCL/DCL).


    Hex............03, 48, 06, 00, 01, 00, 00, 00, 52

    Hex............03, c8, 05, 00, 34, 00, 00, 04


    ICE SPIN MODE (>aprox. 64kph), No fuel flow, ICE rpm requested = 975

    Conditions:

    1. HV battery S0C>40%<80%,
    2. Speed>64kph,
    3. Engine>40degC
    4. Throttle position <aprox. 60%, limit probably determined by HV ECU
    5. Battery temperature too cold or too hot (CCL/DCL).


    ICE SPIN MODE

    Hex............0348060460XXXXXXChecksum

    Hex ...........03c80500(28-40)XX00Checksum

    (28-40) - This value increases from 28 to 40 - Unknown flag/PID?

    XX - PID


    ICE RUN, fuel flow >0, ICE rpm >0

    Condition exists when none of the above is valid.

    Hex.. .... 03, 48, 06, 44, 60, XX, XX, XX, checksum

    Hex............ 03, C8, 05, 00, 34, XX, 00, checksum



    _____________________________________________________________

    Dropping out of EV mode after cold startup (speed >= 45kph or 28MPH) ICE=16degC, SoC=65%, CCL=125,I=8amps

    Hex......... ..03, 48, 06, 00, 01, 00, 00, 00, 52 ..........EV Mode

    00000000, 00000001 (flag bytes only)

    Hex............03, c8, 05, 00, (28-40), XX, 00,Checksum

    00000000 (flag bytes only)

    Hex......... ..03, 48, 06, 04, 60, XX, XX, XX, Checksum ..........EV Cancelled

    00000100, 01100000 (flag bytes only)

    Hex............03, c8, 05, 06, (28-40), XX, 00, Checksum

    00000110 (flag bytes only)

    XX - PID(Parameter IDentity)

    ____________________________________________________________
     

    Attached Files:

    #6 lopezjm2001, Jun 2, 2012
    chenyj likes this.
  7. 2009Prius

    2009Prius A Wimpy DIYer

    Joined:
    Mar 25, 2009
    2,705
    510
    63
    Location:
    USA
    Vehicle:
    2009 Prius
    #7 2009Prius, Jun 6, 2012
    lopezjm2001, dave77 and jdh2550 like this.
  8. jdh2550

    jdh2550 Co-Founder, Current Motor Company

    Joined:
    Nov 16, 2010
    317
    249
    0
    Location:
    Ann Arbor
    Vehicle:
    2005 Prius
    Model:
    N/A
    Yes to the first link, but no to the second. Thanks for the info!
     
    #8 jdh2550, Jun 6, 2012
  9. lopezjm2001

    lopezjm2001 Senior Member

    Joined:
    Apr 14, 2009
    1,146
    407
    5
    Location:
    Sydney Australia
    Vehicle:
    Other Electric Vehicle
    Model:
    N/A
    That is correct however we need to decode the remainder that Vass did not decode. I am not reinventing the wheel. JDH is reinventing the wheel and I am just trying to help him. JDH is reinventing the ECM spoofer that we presume had already been done by Kiettty. Although technically JDH is recreating the pEEF project. The way I see it, it was pEEF who invented the wheel. Kiety invented it again and JDH is recreating it and unlike the the other two is open sourcing the project so PHEV users have other options other than paying through the nose. The only thing that differs is how the project is implemented.

    Maybe I should start a new thread "Who invented the wheel?" , this euphemism is getting out of hand.
     
    #9 lopezjm2001, Jun 6, 2012
    jdh2550 likes this.
  10. jdh2550

    jdh2550 Co-Founder, Current Motor Company

    Joined:
    Nov 16, 2010
    317
    249
    0
    Location:
    Ann Arbor
    Vehicle:
    2005 Prius
    Model:
    N/A
    Yup - that's about it. Although rather than ECM spoofer I'd call it a replacement "battery ECU with alternative ECM control algorithms appropriate for high capacity battery packs." bECU+ for short. "Spoofer" just sounds so bad ;-) (just kidding, it's a spoofer!)
     
    #10 jdh2550, Jun 6, 2012
    lopezjm2001 and dave77 like this.
  11. jdh2550

    jdh2550 Co-Founder, Current Motor Company

    Joined:
    Nov 16, 2010
    317
    249
    0
    Location:
    Ann Arbor
    Vehicle:
    2005 Prius
    Model:
    N/A
    Nah, don't worry about it. My wheel's the shiniest... ;)
     
    #11 jdh2550, Jun 6, 2012
    lopezjm2001 likes this.
  12. 2009Prius

    2009Prius A Wimpy DIYer

    Joined:
    Mar 25, 2009
    2,705
    510
    63
    Location:
    USA
    Vehicle:
    2009 Prius
    Glad to know it's going to be open source. I had hoped that pEEF would open source his work but now guess not. Another good source of info is
    Prius PHEV TechInfo - EAA-PHEV
    but I guess you guys already know about it. Good luck to the project and look forward to the open source! :)
     
    #12 2009Prius, Jun 6, 2012
    lopezjm2001 and dave77 like this.
  13. jdh2550

    jdh2550 Co-Founder, Current Motor Company

    Joined:
    Nov 16, 2010
    317
    249
    0
    Location:
    Ann Arbor
    Vehicle:
    2005 Prius
    Model:
    N/A
    I checked in with pEEf via email last night. He sends good vibes but he's too busy to help out. From what I've seen of his other projects he's a seriously smart innovator who likes to keep moving forward on to other cool projects. I kind of feel like I don't even want to distract him onto this "old project".

    Also, reading between the lines of his original posts on this, he's gun-shy about support and liability issues. I can't say I blame him - when you start writing software that controls things (as opposed to monitoring) then there's more chance of letting the magic smoke out of some very expensive equipment. I guess I'm a little less risk-averse and you better believe I'm going to plaster my work with dire warnings to help warn the unwary.

    On the question of providing extra info - please keep it coming. Yes, I know about that site - but I'd rather get duplicated info than no info at all.

    Peace, love & plug-ins...
     
    #13 jdh2550, Jun 7, 2012
    2009Prius and dave77 like this.
  14. jdh2550

    jdh2550 Co-Founder, Current Motor Company

    Joined:
    Nov 16, 2010
    317
    249
    0
    Location:
    Ann Arbor
    Vehicle:
    2005 Prius
    Model:
    N/A
    BTW, thanks for open-sourcing your work! I just downloaded a copy :)
     
    #14 jdh2550, Jun 7, 2012
    2009Prius likes this.
  15. lopezjm2001

    lopezjm2001 Senior Member

    Joined:
    Apr 14, 2009
    1,146
    407
    5
    Location:
    Sydney Australia
    Vehicle:
    Other Electric Vehicle
    Model:
    N/A
    There is nothing new with the PID bytes. These had already been decoded by the Vass family. However I am just scratching the surface with the flag bytes. There has to be some kind of handshaking going on between these two CAN messages. At the moment I am using a better hex editing program to filter out these two messages and the particular variations of the flag bytes and then try and figure out how they talk by doing further raw data collecting for different situatipns. The secrets lays in the flag bytes.
     
    #15 lopezjm2001, Jun 7, 2012
  16. jdh2550

    jdh2550 Co-Founder, Current Motor Company

    Joined:
    Nov 16, 2010
    317
    249
    0
    Location:
    Ann Arbor
    Vehicle:
    2005 Prius
    Model:
    N/A
    I think it will help a lot to have a two port monitor that sits between the ECM and the hECU. That way we'll know the dire tion of thedata flows + we can intercept messages and see what happens. After I get logging working I'll work on a two port systsm
     
    #16 jdh2550, Jun 7, 2012
    dave77 likes this.
  17. kinetik

    kinetik New Member

    Joined:
    Jun 8, 2012
    1
    2
    0
    Vehicle:
    2007 Prius
    Model:
    N/A
    Strange, my PID 3C8 has one byte more (always null however)
    What is you ICE ECU 1 version ? Mine is 9.1
    You will find (I hope) this version value reading the data bytes 2 and 3 of PID 4C1
    My 4C1 data bytes are "01 00 09 01 00 00 00 00".

    If you can read or translate french, you can find some a couple of new informations here: CAN<sub>NHW20</sub>
     
    #17 kinetik, Jun 8, 2012
    jdh2550 and 2009Prius like this.
  18. lopezjm2001

    lopezjm2001 Senior Member

    Joined:
    Apr 14, 2009
    1,146
    407
    5
    Location:
    Sydney Australia
    Vehicle:
    Other Electric Vehicle
    Model:
    N/A
    I think that you may be referring to the last data byte before the checksum. It is always 00. I have no idea what purpose it has. I will check the ICE ECU version later when I get into my Prius. Thanks for the short cut.

    I have attached a compressed copy of your file.
     

    Attached Files:

    #18 lopezjm2001, Jun 8, 2012
  19. 2009Prius

    2009Prius A Wimpy DIYer

    Joined:
    Mar 25, 2009
    2,705
    510
    63
    Location:
    USA
    Vehicle:
    2009 Prius
    Thank you kinetik for kindly sharing your treasure trove of new knowledge - "a couple of new info" is definitely an understatement. :)

    Google can translate for anyone (including myself) who can't read French. It also adds a healthy dose of daily laughter - Google insists on the translation to "August" whenever it sees an "08" (and there are many).
     
    #19 2009Prius, Jun 8, 2012
  20. 2009Prius

    2009Prius A Wimpy DIYer

    Joined:
    Mar 25, 2009
    2,705
    510
    63
    Location:
    USA
    Vehicle:
    2009 Prius
    Having been thinking about this liability issue a bit more, I think in some sense you are safer than someone who merely provides a monitoring software. An end user of your disclosure has to go in and modify the wiring of the car. Once that's done the liability ends up on the end user, who did the modification in the first place and only has himself to blame if the modification fails. Just my 2 cents.
     
    #20 2009Prius, Jun 8, 2012
(You must log in or sign up to post here.)
Page 1 of 4