Drawing power out of CCS port (V2x, inverse charging, bidirectional CCS)

[uhi22]

This thread is intended to exchange the experiences regarding drawing energy out of a vehicle via the CCS port.

Key words: V2H, V2x, CCS, bidirectional, bidi
Original discussion started here: viewtopic.php?p=40604#p40604

Background: The "official" CCS does not provide the possibility to draw energy out of the car. This is in contrast to the CHAdeMO, which prepared this topic from the beginning.

Goal: For having an overview, what is possible, let's collect the following information:
- Which car model was tested? -> Hyundai Ioniq model year 2016, built 2018.
- Does the car close the contactors to provide voltage on the CCS inlet pins? -> Yes.
- What is necessary to achive this? -> EVSE with simulated precharging, from github.com/uhi22/pyPlc
- (Edit) How long does the car keep the contactors closed? -> For ten minutes.
- How does the car react when current is flowing out of the CCS inlet? -> (Edit) 50W for 10 Minutes works fine.

[mikeselectricstuff]

Very keen to try this on my Kona, too busy atm, but already have the Aliexpress QCA borads and a CCS plug.

An additional question to the above - once contactors are closed, is there a timeout, or do they stay closed indefinitely?

By "simulated precharging", does that mean you need to actually supply voltage to match the battery voltage, or just trick the car into thinking the "charger" has done this?

[uhi22]

I have let it run for some minutes, there was no timeout. Will run longer tests hopefully soon.
The "simulated precharging" means: THe charger sends EVSEPresentVoltage with the same value which the car wants as target voltage. This makes the car thinking, that precharging is successfully finished. I did not provide any voltage to the DC pins. Only the EVSE pretends in the communication that there is a voltage.

[mikeselectricstuff]

Any chance you could document the exact setup you used ?
I'm OK with the electronics side of things, and not scared of the HV side of things, but not so familiar with Linux/Rpi/Python/whatever...

[uhi22]

Depending on what feels more familiar, instead of the Linux also Windows10 works fine. Documented the setup here: https://github.com/uhi22/pyPLC/blob/mas ... vseMode.md as a first draft. I guess there will be more detailled questions, maybe it makes sense to create a Wiki so that everybody could improve the descriptions based on the own experiences.

[johu]

Here's one that can be extended: https://openinverter.org/wiki/CCS_EVCC_using_AR7420

[uhi22]

How is the process to get write permissions to the wiki? Seems I do not have.

[johu]

Log in with same credentials as forum

[uhi22]

Thanks, now it works.

[peternooy]

I have let it run for some minutes, there was no timeout. Will run longer tests hopefully soon.
The "simulated precharging" means: THe charger sends EVSEPresentVoltage with the same value which the car wants as target voltage. This makes the car thinking, that precharging is successfully finished. I did not provide any voltage to the DC pins. Only the EVSE pretends in the communication that there is a voltage.

I did a similar experiment on Tesla model Y, BYD-ATTO3, MG-EP they seem to measurement actual voltage at the charging port and send SessionStopReq, if the require pre-charge voltage of the chare port does not meet what have been requested for pre-charge. (In the experiment, I set the EVSEPresentVoltage in the PreChargeRes to be equal to EVTargetVoltage of the PreChargeReq message, but left the DC pin of the charge port unconnected). This is what is look like for Tesla model Y:

Code: Select all

2023-04-24T14:12:46,126 INFO EXIficientCodec: PreChargeReq
<ns6:V2G_Message xmlns:ns6="urn:din:70121:2012:MsgDef" xmlns:ns5="http://www.w3.org/2000/09/xmldsig#" xmlns:ns7="urn:din:70121:2012:MsgBody" xmlns:ns2="urn:iso:15118:2:2010:AppProtocol" xmlns:ns4="urn:din:70121:2012:MsgDataTypes" xmlns:ns3="urn:din:70121:2012:MsgHeader">
  <ns6:Header>
    <ns3:SessionID>B7BF4D5939E29500</ns3:SessionID>
  </ns6:Header>
  <ns6:Body>
    <ns7:PreChargeReq>
      <ns7:DC_EVStatus>
        <ns4:EVReady>true</ns4:EVReady>
        <ns4:EVErrorCode>NO_ERROR</ns4:EVErrorCode>
        <ns4:EVRESSSOC>81</ns4:EVRESSSOC>
      </ns7:DC_EVStatus>
      <ns7:EVTargetVoltage>
        <ns4:Multiplier>-1</ns4:Multiplier>
        <ns4:Unit>V</ns4:Unit>
        <ns4:Value>3890</ns4:Value>
      </ns7:EVTargetVoltage>
      <ns7:EVTargetCurrent>
        <ns4:Multiplier>-1</ns4:Multiplier>
        <ns4:Unit>A</ns4:Unit>
        <ns4:Value>0</ns4:Value>
      </ns7:EVTargetCurrent>
    </ns7:PreChargeReq>
  </ns6:Body>
</ns6:V2G_Message>
2023-04-24T14:12:46,143 INFO EXIficientCodec: PreChargeRes
<ns6:V2G_Message xmlns:ns6="urn:din:70121:2012:MsgDef" xmlns:ns5="http://www.w3.org/2000/09/xmldsig#" xmlns:ns7="urn:din:70121:2012:MsgBody" xmlns:ns2="urn:iso:15118:2:2010:AppProtocol" xmlns:ns4="urn:din:70121:2012:MsgDataTypes" xmlns:ns3="urn:din:70121:2012:MsgHeader">
  <ns6:Header>
    <ns3:SessionID>B7BF4D5939E29500</ns3:SessionID>
  </ns6:Header>
  <ns6:Body>
    <ns7:PreChargeRes>
      <ns7:ResponseCode>OK</ns7:ResponseCode>
      <ns7:DC_EVSEStatus>
        <ns4:EVSEIsolationStatus>Valid</ns4:EVSEIsolationStatus>
        <ns4:EVSEStatusCode>EVSE_Ready</ns4:EVSEStatusCode>
        <ns4:NotificationMaxDelay>0</ns4:NotificationMaxDelay>
        <ns4:EVSENotification>None</ns4:EVSENotification>
      </ns7:DC_EVSEStatus>
      <ns7:EVSEPresentVoltage>
        <ns4:Multiplier>-1</ns4:Multiplier>
        <ns4:Unit>V</ns4:Unit>
        <ns4:Value>3890</ns4:Value>
      </ns7:EVSEPresentVoltage>
    </ns7:PreChargeRes>
  </ns6:Body>
</ns6:V2G_Message>
2023-04-24T14:12:46,174 INFO DIN-SECC: ----- Loop -----
2023-04-24T14:12:46,205 INFO SECC: State: C2 (4,182), charging in progress.
2023-04-24T14:12:58,121 INFO EXIficientCodec: SessionStopReq
<ns6:V2G_Message xmlns:ns6="urn:din:70121:2012:MsgDef" xmlns:ns5="http://www.w3.org/2000/09/xmldsig#" xmlns:ns7="urn:din:70121:2012:MsgBody" xmlns:ns2="urn:iso:15118:2:2010:AppProtocol" xmlns:ns4="urn:din:70121:2012:MsgDataTypes" xmlns:ns3="urn:din:70121:2012:MsgHeader">
  <ns6:Header>
    <ns3:SessionID>B7BF4D5939E29500</ns3:SessionID>
  </ns6:Header>
  <ns6:Body>
    <ns7:SessionStopReq/>
  </ns6:Body>
</ns6:V2G_Message>

On BYD-ATTO3 it send SessionStopReq immediately upon receieve a very first PreChargeRes with EVSEPresentVoltage with some value and zero voltage measured. On MG-EP, the PrechargeReq loop time out after 7 sec and Tesla moel Y after 12 sec. After that the car send SessionStopReq.

[uhi22]

Luckily, the Ioniq does not timeout such fast. Latest results: Without drawing energy from the port, it keeps the contactors on for 10 minutes. Then it turns off, but a new session can be established after disconnecting and re-connecting the plug.
Did a session where I connected two bulbs with 230V/60W in series, and also here, the car shuts down after 10 minutes.

Edit: After the 10 minutes, the car reports
CurrentDemandReq DC_EVStatus.EVErrorCode 5, which is FAILED_ChargingCurrentdifferential.
Maybe it helps to better simulate; at the moment my EVSE mode reports too much voltage and too much current in the CurrentDemandResponse.

[mikeselectricstuff]

I wonder if you could use an external capacitor to give it an occasional "charge" to reset the timeout.

[peternooy]

Luckily, the Ioniq does not timeout such fast. Latest results: Without drawing energy from the port, it keeps the contactors on for 10 minutes. Then it turns off, but a new session can be established after disconnecting and re-connecting the plug.
Did a session where I connected two bulbs with 230V/60W in series, and also here, the car shuts down after 10 minutes.
image.png

Edit: After the 10 minutes, the car reports
CurrentDemandReq DC_EVStatus.EVErrorCode 5, which is FAILED_ChargingCurrentdifferential.
Maybe it helps to better simulate; at the moment my EVSE mode reports too much voltage and too much current in the CurrentDemandResponse.

Today I have a chance to revisit this again, this time with MG4 electric (2023). The set up same as before, CCS2 with only communication protocol runing. The car stay connected in the charging session, with no power transfer and without any complaint. II run the test for 15 miniutes, before stop it.
Set up:


Session screen, show with no power:


Next step is to draw some heavy current out of this car and see if it trigger any alrm or HV fault,
EDIT 1: Latest test, I run the session for 2 hours without any complaint, DC pin voltage 355 v (without load)

EDIT 2: Tested with 2 ligh bulb in series (60+60w), run the session run for 2 hours no complaint, the MG4 seem to be OK with the fact that SoC reduced rom 43% to 42% in 2 hours while fast charging.


EDIT 3: Confirmed with 5kW heater, test only for 5 minutes. SoC reduced about 4% during discharged. I can observe a lots of energy has been transfer out from MG4 battery during this 5 minute. No error reported, the car operate as normal.


Edit 4: Tesla & BYD Atto3 also OK now



Edit 5: 5kw V2L with MG4


Edit 6: 5kW V2L with Tesla-Y

[uhi22]

For the people who want to do similar things, extended the documentation by a block diagram and added an FAQ. https://github.com/uhi22/pyPLC/blob/mas ... vseMode.md
More questions and improvement ideas welcome.

[theTester]

Hi, I also face the problem of timeout on two different cars. VW ID.4 times out after exactly one minute and the BMW IX4 times out after 5 minutes. Is there any way to reset the timeout so that the car keeps the switches closed? PS - I'm responing with the exact voltage on the DC pins and zero amps as reply to the currentDemandReq, and both cars stop the simulated charging session without an error on the powerDeliveryReq followed by the sessionStopRequest

[CCSknowitall]

No real way to keep those switches closed. Could try 1 or 2 amps of current value in your currentdemandres EVSE actual current. Not actual current flow, just the reported value. There’s a chance the vehicle timer only fires due to your value staying at 0A for so long, and non zero might defeat it. Worth a shot, I think. Don’t go too crazy and follow the vehicle requests though, with both those brands I think you’ll fault out faster because they actually look at what you send and compare to what they see going into the car and trip on some threshold.

[theTester]

Ok I have already tried the scenario with 2 amps in the response but no difference. And if I actually follow the requested values from the car both timeout pretty quick after about 20 seconds.

[peternooy]

Ok I have already tried the scenario with 2 amps in the response but no difference. And if I actually follow the requested values from the car both timeout pretty quick after about 20 seconds.

Hmm...it does not check during pre-charge, but instead does this during charging.
Can you post the pcap file for your new test?

[theTester]

Hmm...it does not check during pre-charge, but instead does this during charging.
Can you post the pcap file for your new test?

No it doesn't during pre-charge. I have set the 2A at the currentDemandRes while it was already charging. But the car then stopped the session at the same time as with the 0A in the currentDemandRes. I also tried to alternate the current in the communication so that there is a change while charging, but also the same behavior from the car. It seems that it is not possible that the car keeps the switches closed.
Sorry I cannot provide any pcap files on this, forgot to record it.

[mhpev]

I did a similar experiment on Tesla model Y, BYD-ATTO3, MG-EP they seem to measurement actual voltage at the charging port and send SessionStopReq, if the require pre-charge voltage of the chare port does not meet what have been requested for pre-charge. (In the experiment, I set the EVSEPresentVoltage in the PreChargeRes to be equal to EVTargetVoltage of the PreChargeReq message, but left the DC pin of the charge port unconnected). This is what is look like for Tesla model Y:

Code: Select all

2023-04-24T14:12:46,126 INFO EXIficientCodec: PreChargeReq
<ns6:V2G_Message xmlns:ns6="urn:din:70121:2012:MsgDef" xmlns:ns5="http://www.w3.org/2000/09/xmldsig#" xmlns:ns7="urn:din:70121:2012:MsgBody" xmlns:ns2="urn:iso:15118:2:2010:AppProtocol" xmlns:ns4="urn:din:70121:2012:MsgDataTypes" xmlns:ns3="urn:din:70121:2012:MsgHeader">
  <ns6:Header>
    <ns3:SessionID>B7BF4D5939E29500</ns3:SessionID>
  </ns6:Header>
  <ns6:Body>
    <ns7:PreChargeReq>
      <ns7:DC_EVStatus>
        <ns4:EVReady>true</ns4:EVReady>
        <ns4:EVErrorCode>NO_ERROR</ns4:EVErrorCode>
        <ns4:EVRESSSOC>81</ns4:EVRESSSOC>
      </ns7:DC_EVStatus>
      <ns7:EVTargetVoltage>
        <ns4:Multiplier>-1</ns4:Multiplier>
        <ns4:Unit>V</ns4:Unit>
        <ns4:Value>3890</ns4:Value>
      </ns7:EVTargetVoltage>
      <ns7:EVTargetCurrent>
        <ns4:Multiplier>-1</ns4:Multiplier>
        <ns4:Unit>A</ns4:Unit>
        <ns4:Value>0</ns4:Value>
      </ns7:EVTargetCurrent>
    </ns7:PreChargeReq>
  </ns6:Body>
</ns6:V2G_Message>
2023-04-24T14:12:46,143 INFO EXIficientCodec: PreChargeRes
<ns6:V2G_Message xmlns:ns6="urn:din:70121:2012:MsgDef" xmlns:ns5="http://www.w3.org/2000/09/xmldsig#" xmlns:ns7="urn:din:70121:2012:MsgBody" xmlns:ns2="urn:iso:15118:2:2010:AppProtocol" xmlns:ns4="urn:din:70121:2012:MsgDataTypes" xmlns:ns3="urn:din:70121:2012:MsgHeader">
  <ns6:Header>
    <ns3:SessionID>B7BF4D5939E29500</ns3:SessionID>
  </ns6:Header>
  <ns6:Body>
    <ns7:PreChargeRes>
      <ns7:ResponseCode>OK</ns7:ResponseCode>
      <ns7:DC_EVSEStatus>
        <ns4:EVSEIsolationStatus>Valid</ns4:EVSEIsolationStatus>
        <ns4:EVSEStatusCode>EVSE_Ready</ns4:EVSEStatusCode>
        <ns4:NotificationMaxDelay>0</ns4:NotificationMaxDelay>
        <ns4:EVSENotification>None</ns4:EVSENotification>
      </ns7:DC_EVSEStatus>
      <ns7:EVSEPresentVoltage>
        <ns4:Multiplier>-1</ns4:Multiplier>
        <ns4:Unit>V</ns4:Unit>
        <ns4:Value>3890</ns4:Value>
      </ns7:EVSEPresentVoltage>
    </ns7:PreChargeRes>
  </ns6:Body>
</ns6:V2G_Message>
2023-04-24T14:12:46,174 INFO DIN-SECC: ----- Loop -----
2023-04-24T14:12:46,205 INFO SECC: State: C2 (4,182), charging in progress.
2023-04-24T14:12:58,121 INFO EXIficientCodec: SessionStopReq
<ns6:V2G_Message xmlns:ns6="urn:din:70121:2012:MsgDef" xmlns:ns5="http://www.w3.org/2000/09/xmldsig#" xmlns:ns7="urn:din:70121:2012:MsgBody" xmlns:ns2="urn:iso:15118:2:2010:AppProtocol" xmlns:ns4="urn:din:70121:2012:MsgDataTypes" xmlns:ns3="urn:din:70121:2012:MsgHeader">
  <ns6:Header>
    <ns3:SessionID>B7BF4D5939E29500</ns3:SessionID>
  </ns6:Header>
  <ns6:Body>
    <ns7:SessionStopReq/>
  </ns6:Body>
</ns6:V2G_Message>

On BYD-ATTO3 it send SessionStopReq immediately upon receieve a very first PreChargeRes with EVSEPresentVoltage with some value and zero voltage measured. On MG-EP, the PrechargeReq loop time out after 7 sec and Tesla moel Y after 12 sec. After that the car send SessionStopReq.

Hi - I am repeating some part of my message - but i'm trying to connect using pyPLC and my contraption supporting CCS1/CCS2 electrical (which is also similar in the NACS std) on a 2018 Tesla model S that's updated to the CCS protocol. But after connecting on the electrical side and the pin etc gets locked with the handle - I apply a 5% PWM duty cycle to let the EV know I'm interested in performing DC charging. But on the wireshark of my PLC GreenPHY modem I don't see any messaging from the PEV side (I've this comm working for 2 other cars - Chevy Bolt and Kia EV6). I saw your post above related to Tesla model Y. If you could share some details also is your Model Y outside of US and has a CCS1/CCS2 type charger? or is it per the new NACS spec in US (which is using ISO15118/DIN spec underneath it)? My relevant posts are at:
viewtopic.php?p=61613#p61613
viewtopic.php?p=61676#p61676
viewtopic.php?p=61678#p61678

[peternooy]

It is a model Y, with CCS2 charge port. I use my own SECC in my test, so the detail in SLAC timing and CP signal could be different here.

From what you described it look like PEV does not go into sounding state, possible cause could be EVSE pwm signal is out of spec, check the timing and voltage level make sure it is with in specification as described in ISO 15118-3

[theTester]

Hello, I have a problem with my friends mercedes eqa300. It seems that the vehicle does not accept my ChargeParameterDiscoveryRes message. It just does not answer anymore. Does anyone have some suggestions what the problem might be? The PCAP is in the appendix.

[CCSknowitall]

In your charge parameter discovery response I see the following issues:
Your minimum current limit is 20A - check your multiplier, you probably meant 2A.
Your peak current ripple is 40A, probably meant 4A.
Your PMax is 0 in SAScheduleList. Most EVs ignore this though.

[uhi22]

The topic with the ChargeParameterResponse and especially the empty SAScheduleList is also discussed here: https://github.com/uhi22/pyPLC/issues/1 ... 1895891875 and a first improvement is implemented. Would be nice to get a test result also from the Mercedes EQA300.

Edit: The improvement was successfully tested on a Togg vehicle today.

[MustafaEmbedded]

I encountered the same problem with the togg tool. The tool did not accept my hargeParameterDiscoveryRes answer. After the update was made as shown in the image below, I moved on to the precharge phase. For this, I compiled main_commandlineinterface.c in its updated version. You need to type cd OpenV2Gx/Release make all on the command line.