Open source CCS using AR7420

[johu]

Happy second-contactor-installation

Has Damien open-sourced this?

Here's my second attempt, had to return to the desk to check if it handles a second contactor.

The former inverter board has become sort of a motherboard. PLC modem is soldered right in to receive power, likewise the beaglebone. Also can transceiver and an infamous uln2003 is on there. It handles CP switching and the contactors. Gets up to 50°C as discovered with my borrowed thermal camera

[johu]

Seems that wasn't it

Second contactor in and verified there is absolutely no voltage between GND and the power pins or between the power pins. Even unplugged my setup from the socket completely.

Only thing I can spot is that we start with a current request of 50A right in the beginning because my gateway script is stateless. Is that relevant? What are common reasons of failed CableCheck?

Some additions:
- just checked that CP switching works with my granny cable
- It was the same Compleo charger that worked last time (in the video)

[uhi22]

The difference between the good case with the Chademo-Test and the todays it, that the charger feels not well and seems to need more time. In the ChargeParameterDiscoveryRes, the good case is
"ResponseCode": "OK", "EVSEProcessing": "Finished", "EVSEStatusCode_text": "EVSE_Ready"
and the bad case
"ResponseCode": "OK", "EVSEProcessing": "Finished", "EVSEStatusCode_text": "EVSE_NotReady".

Somehow the protocol leaves much room, to interpret the "Finished" as finished and go to the next step (cable check), but obviously it may be that the charger says "Finished, but not ready". So we need to add an additional check, before jumping to the cable check.

[johu]

I wonder if they ran a software update on the chargers since ladt time. One was hanging, according to a fellow EVer not for the first time. Now both were fine, so someone must have been there.

[uhi22]

At least this avoids that it will be too boring Pushed an improvement: https://github.com/uhi22/pyPLC/commit/7 ... 554872eb56

[johu]

Hmm, nothing worked.
Tried the Compleo again, a couple of ABB triple chargers (log2, log3) and a super fancy high power charger at Porsche.

The Compleo is now in and endless loop, the triple chargers didn't seem to communicate at all and the Porsche one had a failed CableCheck.

Would it be at all helpful to have the pcaps? I haven't recorded them so far.

[uhi22]

Hm, it could be that the conclusion above regarding the "EVSEStatusCode_text": "EVSE_NotReady" was wrong. I think I compared apples (alpitronic hypercharger) with pines (compleo). Just looked in an old compleo log (2023-04-05), also here we see EVSE_NotReady, but the cablecheck works fine afterwards. With the todays "fix", we hang in the ChargeParameterDiscovery until the timeout comes, this seems not to be a solution. I will roll this back. [Edit: Done, https://github.com/uhi22/pyPLC/commit/b ... 7cf94af40d ]
The Porsche is stuck at the same position, as the Compleo was before: CableCheck reports "FAILED".
One more idea: Before the cable check, we must signalize StateC. Maybe this is broken or connected to a wrong pin or something.

The ABB have a different issue, the modem pairing seems to work only half-way, the modem does not respond to the GetKey request, which I use to find out, whether the modems are present. Maybe here a better strategy is necessary. [Edit: Now starting the SDP requests even if the GetKey does not work, https://github.com/uhi22/pyPLC/commit/f ... 5216e88746 ]

Yes, the pcaps would make sense, hopefully celerons concept with the starter script also runs on the beaglebone.

[CCSknowitall]

Make sure you are in state C before you send your first cable check request.

[CCSknowitall]

The difference between the good case with the Chademo-Test and the todays it, that the charger feels not well and seems to need more time. In the ChargeParameterDiscoveryRes, the good case is
"ResponseCode": "OK", "EVSEProcessing": "Finished", "EVSEStatusCode_text": "EVSE_Ready"
and the bad case
"ResponseCode": "OK", "EVSEProcessing": "Finished", "EVSEStatusCode_text": "EVSE_NotReady".

Somehow the protocol leaves much room, to interpret the "Finished" as finished and go to the next step (cable check), but obviously it may be that the charger says "Finished, but not ready". So we need to add an additional check, before jumping to the cable check.

EVSEProcessing finished means move on to cable check. EVSE_NotReafy shouldn’t matter. I would not send another charge parameter discovery request on this combo.

You sure the charger isn’t just broken?

[peternooy]

EVSEProcessing finished means move on to cable check. EVSE_NotReafy shouldn’t matter. I would not send another charge parameter discovery request on this combo.

Confirmed this should be the correct protocol behaviour, the snipped below is from Tesla session.

Code: Select all

INFO EXIficientCodec: ChargeParameterDiscoveryReq
<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>EFC3586D69BB51B2</ns3:SessionID>
  </ns6:Header>
  <ns6:Body>
    <ns7:ChargeParameterDiscoveryReq>
      <ns7:EVRequestedEnergyTransferType>DC_extended</ns7:EVRequestedEnergyTransferType>
      <ns4:DC_EVChargeParameter>
        <ns4:DC_EVStatus>
          <ns4:EVReady>true</ns4:EVReady>
          <ns4:EVErrorCode>NO_ERROR</ns4:EVErrorCode>
          <ns4:EVRESSSOC>81</ns4:EVRESSSOC>
        </ns4:DC_EVStatus>
        <ns4:EVMaximumCurrentLimit>
          <ns4:Multiplier>-1</ns4:Multiplier>
          <ns4:Unit>A</ns4:Unit>
          <ns4:Value>7990</ns4:Value>
        </ns4:EVMaximumCurrentLimit>
        <ns4:EVMaximumPowerLimit>
          <ns4:Multiplier>2</ns4:Multiplier>
          <ns4:Unit>W</ns4:Unit>
          <ns4:Value>3260</ns4:Value>
        </ns4:EVMaximumPowerLimit>
        <ns4:EVMaximumVoltageLimit>
          <ns4:Multiplier>-1</ns4:Multiplier>
          <ns4:Unit>V</ns4:Unit>
          <ns4:Value>4230</ns4:Value>
        </ns4:EVMaximumVoltageLimit>
      </ns4:DC_EVChargeParameter>
    </ns7:ChargeParameterDiscoveryReq>
  </ns6:Body>
</ns6:V2G_Message>
INFO EXIficientCodec: ChargeParameterDiscoveryRes
<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>EFC3586D69BB51B2</ns3:SessionID>
  </ns6:Header>
  <ns6:Body>
    <ns7:ChargeParameterDiscoveryRes>
      <ns7:ResponseCode>OK</ns7:ResponseCode>
      <ns7:EVSEProcessing>Finished</ns7:EVSEProcessing>
      <ns4:SAScheduleList>
        <ns4:SAScheduleTuple>
          <ns4:SAScheduleTupleID>1</ns4:SAScheduleTupleID>
          <ns4:PMaxSchedule>
            <ns4:PMaxScheduleID>0</ns4:PMaxScheduleID>
            <ns4:PMaxScheduleEntry>
              <ns4:RelativeTimeInterval>
                <ns4:start>0</ns4:start>
                <ns4:duration>86400</ns4:duration>
              </ns4:RelativeTimeInterval>
              <ns4:PMax>11</ns4:PMax>
            </ns4:PMaxScheduleEntry>
          </ns4:PMaxSchedule>
        </ns4:SAScheduleTuple>
      </ns4:SAScheduleList>
      <ns4:DC_EVSEChargeParameter>
        <ns4:DC_EVSEStatus>
          <ns4:EVSEIsolationStatus>Invalid</ns4:EVSEIsolationStatus>
          <ns4:EVSEStatusCode>EVSE_NotReady</ns4:EVSEStatusCode>
          <ns4:NotificationMaxDelay>0</ns4:NotificationMaxDelay>
          <ns4:EVSENotification>None</ns4:EVSENotification>
        </ns4:DC_EVSEStatus>
        <ns4:EVSEMaximumCurrentLimit>
          <ns4:Multiplier>0</ns4:Multiplier>
          <ns4:Unit>A</ns4:Unit>
          <ns4:Value>100</ns4:Value>
        </ns4:EVSEMaximumCurrentLimit>
        <ns4:EVSEMaximumPowerLimit>
          <ns4:Multiplier>3</ns4:Multiplier>
          <ns4:Unit>W</ns4:Unit>
          <ns4:Value>30</ns4:Value>
        </ns4:EVSEMaximumPowerLimit>
        <ns4:EVSEMaximumVoltageLimit>
          <ns4:Multiplier>0</ns4:Multiplier>
          <ns4:Unit>V</ns4:Unit>
          <ns4:Value>1000</ns4:Value>
        </ns4:EVSEMaximumVoltageLimit>
        <ns4:EVSEMinimumCurrentLimit>
          <ns4:Multiplier>0</ns4:Multiplier>
          <ns4:Unit>A</ns4:Unit>
          <ns4:Value>1</ns4:Value>
        </ns4:EVSEMinimumCurrentLimit>
        <ns4:EVSEMinimumVoltageLimit>
          <ns4:Multiplier>0</ns4:Multiplier>
          <ns4:Unit>V</ns4:Unit>
          <ns4:Value>150</ns4:Value>
        </ns4:EVSEMinimumVoltageLimit>
        <ns4:EVSEPeakCurrentRipple>
          <ns4:Multiplier>0</ns4:Multiplier>
          <ns4:Unit>A</ns4:Unit>
          <ns4:Value>1</ns4:Value>
        </ns4:EVSEPeakCurrentRipple>
      </ns4:DC_EVSEChargeParameter>
    </ns7:ChargeParameterDiscoveryRes>
  </ns6:Body>
</ns6:V2G_Message>
INFO EXIficientCodec: CableCheckReq
<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>EFC3586D69BB51B2</ns3:SessionID>
  </ns6:Header>
  <ns6:Body>
    <ns7:CableCheckReq>
      <ns7:DC_EVStatus>
        <ns4:EVReady>true</ns4:EVReady>
        <ns4:EVErrorCode>NO_ERROR</ns4:EVErrorCode>
        <ns4:EVRESSSOC>81</ns4:EVRESSSOC>
      </ns7:DC_EVStatus>
    </ns7:CableCheckReq>
  </ns6:Body>
</ns6:V2G_Message>
INFO EXIficientCodec: CableCheckRes
<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>EFC3586D69BB51B2</ns3:SessionID>
  </ns6:Header>
  <ns6:Body>
    <ns7:CableCheckRes>
      <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:EVSEProcessing>Finished</ns7:EVSEProcessing>
    </ns7:CableCheckRes>
  </ns6:Body>
</ns6:V2G_Message>
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>EFC3586D69BB51B2</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>

[johu]

Make sure you are in state C before you send your first cable check request.

The code says it changed to state C before sending the cable check and I verified this actually works with my granny cable. Maybe the level is sufficient for the granny cable but not the CCS charger? Difference between the working CHAdeMO adapter and the non-working Audi installation is the switching element. The former uses a simple NPN transistor while the latter uses a Darlington pair in the ULN2003 to pull CP down via a 1k2 resistor. 2k7 is always there.

You sure the charger isn’t just broken?

Can't be sure, but it is two chargers side by side. Could test if CHAdeMO still works?

[uhi22]

The ULN has significant U_CE_sat even with nearly no load. This may lead to instable state C, e.g. 7V instead of 6V.

[johu]

I have checked this now. Supplying 12V via a 1k resistor to the CP pin. In state B I see 8.8V and in state C 5.8V. I use 1k2 instead of 1k3, that probably makes up for the higher voltage drop of the ULN2003. Also measured its Vce and it is 0.7V

EDIT: Also scoped it:

I'm suspecting the noise comes from the PLC modem. Now waiting for it to shut down.

UPDATE: it did shut down now, noise level drops to about half. When I cut power to the modem noise goes away

[uhi22]

Hm, the 5.8V are hopefully good enough to make the charger happy. Two more ideas: The diode in the CP is installed? And the diode is fast enough, to follow the 5% PWM? And the coupling to the PLC modem uses not more than 1nF, to avoid lowpass-filtering the PWM?

[uhi22]

Two more ideas into the same direction: The modem is on the right side of the diode (charger side, not resistors side)? And the series resistor in the modem path is installed, to avoid that it applies several volts in addition to the intended +6V/-12V? Is it possible to make a scope picture when connected to the charger?

[johu]

Yes, I use the same diode, 180R resistor and 1nF capacitor as on the working version. 180R from one transformer end to GND, 1nF from the other transformer end to CP. From CP diode to 2k7 resistor to GND and in parallel 1k2 resistor to ULN to GND. Can try the scope thing later.

I now went to the Compleo charger again with the CCS->Chademo and it worked as it did before. Log attached.

There are differences in cableCheckReponse, working vs. non-working:
"ResponseCode": "OK" vs. "ResponseCode": "FAILED"
"DC_EVSEStatus.EVSEIsolationStatus_isUsed": "1" vs. "DC_EVSEStatus.EVSEIsolationStatus_isUsed": "0"
"DC_EVSEStatus.EVSEStatusCode": "4" vs. "DC_EVSEStatus.EVSEStatusCode": "0"
"EVSEStatusCode_text": "EVSE_IsolationMonitoringActive" vs. "EVSEStatusCode_text": "EVSE_NotReady"
"EVSEProcessing": "Ongoing" vs. "EVSEProcessing": "Finished"

[johu]

And here is a scope shot with my granny cable in state C

[uhi22]

Really strange. Everything perfect, the levels, the edges, the schematic. Somehow I get the impression that the charger does not complain about the CP, but what else could be a reason to fail the cable check?
But, this noise looks strange:

The PEV modem, if there is no central coordinator (=EVSE or other, non-pev modem) near to it, does not send anything on the line. So I would expect perfect silence. What we see looks like ripples from a switch mode power supply. This could point to a ground issue (missing ground or ground loop or something). Just to be sure: The PE of the CCS inlet, the ground of the Beaglebone, modem, ULN and power supply are all connected together?

[johu]

Well erm.... I'd forgotten to change the interface from Dieter to BeagleBone in the ini file

So now Audi received its first rapid charge
Worked well on Compleo

The Porsche charger I crashed. After receiving a good CableCheckRes it suddenly stopped communicating and then the status LED changed from green to red and the display said "charger not available" oops.

[uhi22]

At least one good news
The Porsche log above is from "afterwards" I guess. It does not respond at all. The original crash log would be more interesting.

[uhi22]

Just to exclude one reason for the fail on the Porsche: If in the ini file we have udp_syslog_enable = Yes, the pyPlc will broadcast many debug messages into the network. This may irritate the charger. For normal cases I propose to set udp_syslog_enable = No.

[johu]

Yes, the debug was on, now it's off. Didn't go back to the Porsche one yet. I found my negative contactor doesn't always engage, need to fix that first.

Went back to ABB but it still doesn't work (has some excess stuff in the log file. the end is ABB). pyPLC complains about wrong repsonse code in this:

Code: Select all

{
"msgName": "SessionSetupRes",
"info": "17 bytes to convert", 
"error": "",
"result": "",
"schema": "DIN",
"g_errn": "0",
"header.SessionID": "4142423030303131",
"header.Notification_isUsed": "0",
"header.Signature_isUsed": "0",
"ResponseCode": "OK",
"EVSEID.bytesLen": "1",
"EVSEID": "00",
"debug": "Line538"
}

Then went to Ionity and was even able to charge. But only for a few seconds. Then it would shut off and cycle through the whole handshake again.

[CCSknowitall]

You might be choking on the response code. ABB appears to send “ok” but they should send “OK_NewSessionEstablished”.

Work around it.

[johu]

What a wonderful standard

[uhi22]

Thanks, added the workaround: https://github.com/uhi22/pyPLC/commit/5 ... b43ddcfa4f
It's a pity, the session setup on ABB worked since November, and in May I added the reaction on wrong status codes, to make the implementation more compliant to the standard. And now we find out: It's better to NOT stick to the standard, but be more flexible. Nice example of daily development challenges