Open source CCS using AR7420

uhi22 · Post by **uhi22** » Thu Sep 21, 2023 8:25 pm

Thanks for the detailed reports, this looks promising, but also challenging. Need to dig into the recordings, too busy at the moment. Just a small correction for now: I did not test with Ioniq5, but with the good/old/small/economical original Ioniq from 2016.

Edit: Had a look to the EV6 trace. What I see so far:
- It announces a max voltage of 825.6 volts. Ok, it is a 800V car. And 350A max current. Impressive.
- After the charge parameter exchange, it says directly PowerDeliveryRequest with "ReadyToChargeState": "0", this means it says: I do not want to be charged by this charger. That's why it does not even try the cable check and precharge phase. Afterwards it stops the session.

The question is, why it is not happy with the exchanged charge parameters. Maybe the announced power limit of 10kW looks too bad. Or something else, difficult to guess.

Edit 2: Could you check, whether you have the latest version of OpenV2Gx, including https://github.com/uhi22/OpenV2Gx/commi ... 0ea65211a9? I do not see valid units in your ChargeParameterDiscoveryRes, but this should have been fixed in August this year, and discussed here: https://github.com/SmartEVSE/SmartEVSE- ... 1666218352

mhpev · Post by **mhpev** » Fri Sep 22, 2023 11:59 am

Thank you for your detailed explanation and spending time to go over the messages. I think you're correct on the kia side, I noticed some of those fields in the req/resp and the resp had values which may need to be tweaked to something higher. Also I'll update my v2g code. How do I update the code to send out a higher response than 450 volts in the response. I couldn't find it in any configuration so I'm thinking it's somewhere in the code. Appreciate you taking the time to go over and respond. Any idea where I could find values that should be changed to reflect this vehicle or should I just increase the numbers accordingly for voltage, current, power and see if the car responds with the cable che check req/resp etc.
Thx again. May need to do dive into your code and understand better.

uhi22 · Post by **uhi22** » Fri Sep 22, 2023 12:39 pm

The values of the ChargeParameterResponse are not configurable at the moment. They are hardcoded here: https://github.com/uhi22/OpenV2Gx/blob/ ... ce.c#L1304
So you could try to change some of these values, re-compile the OpenV2Gx, and test whether this makes a difference.

mhpev · Post by **mhpev** » Fri Sep 22, 2023 1:47 pm

uhi22 wrote: ↑Fri Sep 22, 2023 12:39 pm The values of the ChargeParameterResponse are not configurable at the moment. They are hardcoded here: https://github.com/uhi22/OpenV2Gx/blob/ ... ce.c#L1304
So you could try to change some of these values, re-compile the OpenV2Gx, and test whether this makes a difference.

That makes sense - I did a param by param comparison for the EV6 and will try and tweak these values to match up or advertise a bit higher than what the vehicle has advertised on its side... if you have any recommendations of values based on your experience or expertise it would be greatly appreciated. Also what does the multiplier of 0 and -1 mean? In the req I see most of these as -1 while the response had either 0 or 3 (for power)? I will also update my v3g code seems I am having a version prior to the Aug updates..

uhi22 · Post by **uhi22** » Fri Sep 22, 2023 2:27 pm

The multiplier means "Exponent to the base of ten". E.g. if value is 8000 and multiplier is -1, this means physically 800.

uhi22 · Post by **uhi22** » Fri Sep 22, 2023 4:10 pm

BTW: Which plugin do you use in Wireshark to decode the EXI?

CCSknowitall · Post by **CCSknowitall** » Sat Sep 23, 2023 4:59 am

Hyundai/Kia HV vehicles run at 450V when dealing with “low voltage” chargers (typically 500v max). If charge parameter discovery response EVSE max voltage is below 450v, you’ll very likely fail out. Newer model S and X are ~450v as well, so your likely faulting out for the same reason for both vehicles.

I suggest hard coding a 500v evse max voltage for now.

mhpev · Post by **mhpev** » Sat Sep 23, 2023 6:52 pm

uhi22 wrote: ↑Fri Sep 22, 2023 4:10 pm BTW: Which plugin do you use in Wireshark to decode the EXI?

https://github.com/ChargePoint/wireshark-v2g

mhpev · Post by **mhpev** » Sat Sep 23, 2023 7:09 pm

CCSknowitall wrote: ↑Sat Sep 23, 2023 4:59 am Hyundai/Kia HV vehicles run at 450V when dealing with “low voltage” chargers (typically 500v max). If charge parameter discovery response EVSE max voltage is below 450v, you’ll very likely fail out. Newer model S and X are ~450v as well, so your likely faulting out for the same reason for both vehicles.

I suggest hard coding a 500v evse max voltage for now.

Thank you this is good. Any recommendations for what I should set for other values. I went thru some Kia EV6 forums and seems the power is 240-250 kWh - there's no real charger associated I am trying to get it to a point where it would close contactors and if I could use it to discharge or at least get it to a point of closing contactors for some time.

Also, you mentioned Tesla Model S/X - I tried to connect my setup to a Tesla model S 2018 (that has been converted to support NACS/CCS charging) but couldn't see any PLC comm on the wire from the EV after plugging in and setting the PWM to 5% duty cycle etc. Do I need to do anything different for Teslas v/s other CCSx vehicles? I am able to get it at least to a point of PLC comm with my setup but not for Teslas

any advice is appreciated.

uhi22 · Post by **uhi22** » Sat Sep 23, 2023 7:37 pm

I understood that the Kia/Hyundai 800V cars have to modes:

1. A "legacy mode", in which they are able to charge on 400V chargers, and use an internal step-up-converter to boost the 400 (or up to 500V) of a "old" charger to the internal battery charger. In this mode, I guess pulling energy out of the car does not work at all, because this would require backwards operation of the step-up-converter. Quite unlikely. But to try out, it should be find to just emulate a standard 50kW charger, so lets say upper limit 500V, lower limit 200V, max power 50kW, max current 150A.
2. The true 800V mode. In this mode the accu voltage is on the CCS. So the charger must announce that is able to deliver such a voltage, so upper limit 1000V, lower limit 200V, max power 200kW and max current 200A should do. But: I understood, that the "good old" DIN spec, which we use, is limited to 500V. So if this is true, and the car makes a good plausibilization, it would reject the "implausible" combination of DIN spec and 1000V. Nevertheless, it is worth a try. If nothing works, this would be a good trigger to implement the ISO additional to the DIN in OpenV2Gx and pyPLC. Quite an effort, but possible.

Edit: Regarding the Tesla: May it be that the PP resistances are different for NACS? At least they are different between CCS1 and CCS2. Or there is a special detection of the connector lock, which is not fulfilled by your test equipment? If you have an oscilloscope, you could check whether the car correctly pulls the 12V to 9V and the EVSE starts the 5% PWM. May it be that the Tesla needs an internal trigger (some user interaction, what ever) to start the charging?

mhpev · Post by **mhpev** » Sat Sep 23, 2023 8:09 pm

uhi22 wrote: ↑Sat Sep 23, 2023 7:37 pm I understood that the Kia/Hyundai 800V cars have to modes:

1. A "legacy mode", in which they are able to charge on 400V chargers, and use an internal step-up-converter to boost the 400 (or up to 500V) of a "old" charger to the internal battery charger. In this mode, I guess pulling energy out of the car does not work at all, because this would require backwards operation of the step-up-converter. Quite unlikely. But to try out, it should be find to just emulate a standard 50kW charger, so lets say upper limit 500V, lower limit 200V, max power 50kW, max current 150A.
2. The true 800V mode. In this mode the accu voltage is on the CCS. So the charger must announce that is able to deliver such a voltage, so upper limit 1000V, lower limit 200V, max power 200kW and max current 200A should do. But: I understood, that the "good old" DIN spec, which we use, is limited to 500V. So if this is true, and the car makes a good plausibilization, it would reject the "implausible" combination of DIN spec and 1000V. Nevertheless, it is worth a try. If nothing works, this would be a good trigger to implement the ISO additional to the DIN in OpenV2Gx and pyPLC. Quite an effort, but possible.

Edit: Regarding the Tesla: May it be that the PP resistances are different for NACS? At least they are different between CCS1 and CCS2. Or there is a special detection of the connector lock, which is not fulfilled by your test equipment? If you have an oscilloscope, you could check whether the car correctly pulls the 12V to 9V and the EVSE starts the 5% PWM. May it be that the Tesla needs an internal trigger (some user interaction, what ever) to start the charging?

Thank you great leads! I'll surely give it a shot with the lower 400V limits and then if it doesn't work as expected, will try the higher levels (implementing the additional stuff is feasible but something I would try to avoid for now if possible... but long term it may be beneficial..

As for the Tesla - NACS/CCS compatible port will try to see if anyone else has got any luck or insights... I saw some folks on this forum mentioning those hence thought if there are some things to try I could surely give it a try... your idea to run some probes is a good idea for sure! Thx.

uhi22 · Post by **uhi22** » Sat Sep 23, 2023 8:29 pm

You could also put the Tesla question into https://github.com/SmartEVSE/SmartEVSE-3/issues/25 , maybe there is somebody who has experience with it. For other cars they had success reading the SOC.

YouTube · Post by **johu** » Sat Sep 23, 2023 8:30 pm

I didn't test recently but I remember I was not able to charge on SUC while celeron was charging right next to me. I wonder can they detect the lack of the connector lock?

CCSknowitall · Post by **CCSknowitall** » Sun Sep 24, 2023 3:54 pm

For the Tesla issue- make sure your modem is ready to start SLAC as soon as you switch to 5% duty cycle. Teslas (and a few others) will almost immediately try to start communicating after 5% starts. Stay in 100% duty for a few seconds beforehand if needed to verify the modem is ready before switching to 5%. Note some vehicles will actually try starting SLAC in 100% duty as well, but those that do, will still try again once you switch to 5%.

DIN 70121 was written before high voltage charging was a thing. Vehicles can and do use DIN 70121 in with high voltage batteries. ISO 15118 support is not required for just charging. The limit sent by the vehicle (EV Maximum Voltage) will be above 500V in such cases, there’s no issues protocol wise conveying such.

I recommend 125A/500V/50kW for EVSE side limits to start. There’s many 50kW machines out there that advertise this. Current and power don’t need to be high value for charging to work.

mhpev · Post by **mhpev** » Mon Sep 25, 2023 12:42 pm

CCSknowitall wrote: ↑Sun Sep 24, 2023 3:54 pm For the Tesla issue- make sure your modem is ready to start SLAC as soon as you switch to 5% duty cycle. Teslas (and a few others) will almost immediately try to start communicating after 5% starts. Stay in 100% duty for a few seconds beforehand if needed to verify the modem is ready before switching to 5%. Note some vehicles will actually try starting SLAC in 100% duty as well, but those that do, will still try again once you switch to 5%.

DIN 70121 was written before high voltage charging was a thing. Vehicles can and do use DIN 70121 in with high voltage batteries. ISO 15118 support is not required for just charging. The limit sent by the vehicle (EV Maximum Voltage) will be above 500V in such cases, there’s no issues protocol wise conveying such.

I recommend 125A/500V/50kW for EVSE side limits to start. There’s many 50kW machines out there that advertise this. Current and power don’t need to be high value for charging to work.

Thank you - I will also give the above recommendations a shot. My current setup is somewhat semi-automated. So I was going thru the states on the electrical side one at a time and then once the 5% PWM was init I was starting my modem side of things pyPLC script (I will change the order and have it running just prior to moving to the 5% duty cycle) that way I'll ensure that the comm is available on L1/L2 side from the modem.
But I already had my setup connected but was only monitoring the messages on wireshark - wouldn't I see any inbound messages from the client/PEV in this case the moment the 5% duty cycle starts? although I have nothing going on the PLC side from the EVSE side yet?
I was expecting to at least see some greenPHY messages on the wire from the PEV trying to establish the connection... this is the same I am seeing with other PEVs (Bolt, EV6, etc)...

mhpev · Post by **mhpev** » Wed Sep 27, 2023 9:55 pm

Hi all - I tried the above suggestions - updated my params etc but no luck yet

So for now I am focusing on one car Chevy Bolt (where I am still stuck at the CableCheckResp and the PEV stops sending anything and then times out).
As I was going over the req/resp messages between I see in the CableCheckResp the EVSE sends from a real charger trace uploaded on the forum - and some params looked different so I am changing them in the OpenV2Gx codebase @uhi22 has (thx I've now migrated to the latest codebase and see some of the errors in units etc updated - not that it helped in my case

)
Here's the diff in traces for the response:

based on the param diff I thought of updating the code as follows (added the right elements in the structs to keep the code happy and build)

But still I don't see any difference when I run it and the response field is still showing the same values as EVSEStatusCode: EVSE NotReady

Do I need to change anything on pyPlc side to have the message encode something differently? or just changing on OpenV2Gx side in encoding the response allow me to change it - because somehow something else seems to be overriding the values...

Any help/insight is appreciated. I want to try and match the response to an actual charger and see if it tricks the car to move to the next step which is preCharge and hopefully close contactors etc..

EVSE_Chevy_Bolt_20230926.zip: (2.78 KiB) Downloaded 53 times

uhi22 · Post by **uhi22** » Thu Sep 28, 2023 5:43 am

No, nothing to change on pyPLC side, the encode function creates the stream and nothing overwrites it. The code looks ok for me. Did you compile it before use? And did you compile it in the path where pyPLC searches it? (Sorry, stupid questions, but no better idea at the moment

)

mhpev · Post by **mhpev** » Sat Sep 30, 2023 4:27 pm

uhi22 wrote: ↑Thu Sep 28, 2023 5:43 am No, nothing to change on pyPLC side, the encode function creates the stream and nothing overwrites it. The code looks ok for me. Did you compile it before use? And did you compile it in the path where pyPLC searches it? (Sorry, stupid questions, but no better idea at the moment )

I found the issue - I was trying to add info elements under the wrong struct. Looking at the trace more closely figured out it was under another structure. I've done the changes and do see the IE and correct values matching a real charger CableCheckResp message. Will attempt to connect with my Bolt next week and if it works will send out the appropriate changes.

Thx again for your help. Will also try to see if I can match up other responses to be more in-line with real charger fields and attribute values.

mhpev · Post by **mhpev** » Wed Oct 04, 2023 11:02 pm

I updated the code in Openv2gx related to the encoding of CableCheckRes to match the real charger and the the Chevy Bolt was able to transition to the PreChargeReq/PreChargeRes state. I see the pyPLC calculating the EV Present Voltage based on the target sent in the Req and the logic seems to be working correctly plus the messages compare almost identically to ones see in real charger traces. But after a minute or so the PEV side times out and sends a SessionStopReq to the EVSE side. Please see attached trace for more details. I am not sure if the car is checking the voltage and/or current on the DC terminals prior to moving the PowerDeliverReq/PowerDeliveryRes state. Any thoughts or insights welcome.

I've attached the complete trace of the transaction so far...

EVSE_Chevy_Bolt_20231003.zip: (7.5 KiB) Downloaded 58 times

Hoping to get past this message transaction...

mhpev · Post by **mhpev** » Sat Oct 07, 2023 6:01 pm

ListenMode in pyPLC. Does it work with TPlink modems - based on the release updates it seems it doesn't as the modem is dropping pkts not addressed to it? but works with Devolo modem? If so can you provide me with details on what h/w to use for this (I found this h/w on ebay - is this the one or different?

https://www.ebay.com/itm/133893970160?_ ... %3A4429486

and changes/updates to it to make it work? I am trying to see if i can somehow get this sniffer working as a passive man-in-the-middle between a real charger and PEV/Bolt and sniff out the exact traffic and try to replicate it byte by byte as compared to a real EVSE/Charger. Appreciate your help.

uhi22 · Post by **uhi22** » Sat Oct 07, 2023 7:39 pm

I did not find a modem which routes the singlecast traffic to its ethernet port. The devolo has the good feature, that it is transparent for the complete SLAC, so it is perfect for sniffing the SLAC. But for the IP traffic it doesn't help.

Bigpie · Post by **Bigpie** » Thu Oct 12, 2023 6:41 pm

This has been on the backburner, but i've picked up again. I've got it running on the Raspberry Pi with an SPI canbus module, and a 'hat' with the outputs for State C and Contactors. I'm intending to just use the EVSE reported voltage for precharge.

I'm going to be heading to the CCS charger at the weekend to grab a log without HV connected before moving on to connecting up the HV to the contactors.

Anyone care to have a quick look over my patch to see if I've missed some obvious parameter?

mhpev · Post by **mhpev** » Tue Oct 17, 2023 1:53 pm

I was able to finally get a charge (fake) session going with the Chevy Bolt using the pyPLC EVSESim (did some changes to messages and attributes to match up real charger traces. Also the EV expects to see voltage and current at the terminals once the preCharge is complete. So I put a small DC voltage/current gen and was able to trick the car to close contactors. Once it went thru it kept the contactors closed for 50 sec before sending the sessionStop (as it didn't sense the expected voltage/current as promised

)

Please find the trace attached showing this successful run.. any suggestions/feedback is appreciated or ideas how to keep the contactors closed for longer.

EVSE_Chevy_Bolt_20231011.zip: (22.5 KiB) Downloaded 47 times

mhpev · Post by **mhpev** » Thu Oct 26, 2023 9:14 pm

Hi @uhi22 had a quick question, on pyPLC side when using it in EVSE mode if I enable the serial port config in the pyPlc.ini

# Added by celeron55
# The serial port and baud rate used for communication. Used
# for serial devices like Dieter, OLED-Display and
# celeron55's measuring and switching device
# Examples:
# /dev/ttyS1
# auto
serial_port = auto
serial_baud = 19200

will the script expect me to have some device connected to the serial port on the other side. In this case I want to connect an arduino to send out status related to charging progress or more like where in the flow it is at. Reason being I am trying to have a compact DC charger/PS that talks over serial and want to send out the correct tgt voltage to the DC+/- terminals as per what's requested by the PEV. This is mainly to keep it happy and allow closing contactors - so mainly during the preCharge cycle and then once it's done to stop this PS or switch it off..

OR

Is the below a better entrypoint to get the data and then have another app send it out after any translations over serial or any other connection?

# REST callback for SoC states. Comment out to disable. Do not leave a trailing slash
# This parameter is used in EvseMode, to configure where the data which is retrieved
# from the vehicle shall go to. Discussed
# here: https://github.com/SmartEVSE/SmartEVSE- ... 1563519025
soc_callback_enabled = False
soc_callback_endpoint = http://1.1.1.1
# Fallback value to use if the vehicle does not support the EVEnergyCapacity.Value
soc_fallback_energy_capacity = 2700

Any details would be appreciated.

uhi22 · Post by **uhi22** » Fri Oct 27, 2023 5:59 am

So we are talking about EVSE mode, and the possibility to control the power supply. Well, this use case is at the moment not implemented at all. The existing hardwareInterface.py is handling only the PEV side.

My proposal would be:
1. Create a new module hardwareInterfaceEvse.py, to avoid confusion by mixing PEV and EVSE. (Alternatively, use and extend the existing hardwareInterface.py)
2. In fsmEvse.py, in the init function (https://github.com/uhi22/pyPLC/blob/c26 ... se.py#L365), store the reference to the hardwareInterfaceEvse. In the state functions, e.g. https://github.com/uhi22/pyPLC/blob/c26 ... se.py#L210 call something like self.hardwareInterfaceEvse.setPowerSupplyVoltage(uTarget)
3. Give the new hardwareInteraceEvse to the init of the evse state machine, in https://github.com/uhi22/pyPLC/blob/c26 ... ker.py#L44
4. In hardwareInterfaceEvse.py, handle the serial communication, similar to the Dieter or Celeron device.

Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420