Open source CCS using AR7420

[uhi22]

Regarding the capacitor and resistor, added in the FAQ: https://github.com/uhi22/pyPLC#q6-how-t ... -cp-and-pe

[mhpev]

If it says that it expects CAN, then the ChaDeMo is enabled in the ini file. Just change this setting. And If you do not have serial devices, then remove the Dieter or Celeron devices from the ini.

Excellent! This helped me move forward. I updated the config/ini file to reflect the changes mentioned above and was able to get past these errors. Now at the next step where the EVSE (simulated is trying to query the hostname and then determine the IPv6 address from it)
In my RPi setup the /eth/hosts:
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

127.0.1.1 evse

This throws the error as below:
pi@evse:~/CCS/pyPlc $ python evseNoGui.py E S
starting in EVSE_MODE
press Ctrl-C to exit
initializing pyPlcWorker
[addressManager] we have local MAC E4:5F:01:FD:F7:CD.
[addressManager] Found 1 link-local IPv6 addresses.
fe80::57ef:bab4fc2c
[addressManager] Local IPv6 is fe80::57ef:bab4fc2c
Linux interface is eth0
[addressManager] will give local MAC E4:5F:01:FD:F7:CD
[addressManager] will give local MAC E4:5F:01:FD:F7:CD
pyPlcIpv6 started with ownMac E4:5F:01:FD:F7:CD
[addressManager] will give local MAC E4:5F:01:FD:F7:CD
udplog started with ownMac E4:5F:01:FD:F7:CD
logging to UDP Syslog is enabled
sniffer created at eth0
[36ms] [HARDWAREINTERFACE] Auto detection of serial ports. Available serial ports:
[43ms] [HARDWAREINTERFACE] ignoring /dev/ttyAMA0, because this is not an USB serial port
[44ms] [HARDWAREINTERFACE] ERROR: No serial ports found. No hardware interaction possible.
[129ms] [pyPlcWorker] Software version v0.9-12-g14c166d
[130ms] [EVSE] initializing fsmEvse
[130ms] pyPlcTcpSocket listening on port 15118
evse
[130ms] evse
127.0.1.1
Traceback (most recent call last):
File "/home/pi/CCS/pyPlc/evseNoGui.py", line 62, in <module>
worker=pyPlcWorker.pyPlcWorker(cbAddToTrace, cbShowStatus, myMode, 0, socStatusCallback)
File "/home/pi/CCS/pyPlc/pyPlcWorker.py", line 44, in __init__
self.evse = fsmEvse.fsmEvse(self.addressManager, self.workerAddToTrace, self.hardwareInterface, self.showStatus, self.callbackSoC)
File "/home/pi/CCS/pyPlc/fsmEvse.py", line 371, in __init__
self.Tcp = pyPlcTcpSocket.pyPlcTcpServerSocket(self.callbackAddToTrace, self.socketStateNotification)
File "/home/pi/CCS/pyPlc/pyPlcTcpSocket.py", line 175, in __init__
addressInfo = socket.getaddrinfo(hostname, None, socket.AF_INET6)
File "/usr/lib/python3.9/socket.py", line 953, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -2] Name or service not known

And I can see (from additional prints and debugging) that there's no IPv6 address tied to the hostname of this RPi only an IPv4 address tied to
evse -> 127.0.1.1 as can be seen.
One way to resolve this would be to add an IPv6 address to the hosts file mapping to a link local addr of the eth0 interface to hostname or better option would be to use the IP address that the process already identified in above steps:
[addressManager] we have local MAC E4:5F:01:FD:F7:CD.
[addressManager] Found 1 link-local IPv6 addresses.
fe80::57ef:bab4fc2c
[addressManager] Local IPv6 is fe80::57ef:bab4fc2c
Linux interface is eth0

when it identifies the correct Eth interface as well as the link local IPv6 address mapped to it... so not sure why this hostname to IP mapping is done in lines ( pyPlcTcpSocket.py) 160-176

# Later in the cyclic loop, we use the "select" to wait for activity on this socket.
# In case there is a connection request, we create a NEW socket, which will handle the
# data exchange. The original socket is still listening for further incoming connections.
# This would allow to handle multiple connections.
self.ourSocket = socket.socket(socket.AF_INET6, socket.SOCK_STREAM, 0)
self.ourSocket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
self.ourSocket.bind((self.ipAdress, self.tcpPort))
self.ourSocket.listen(1)
self.callbackStateNotification(1) # inform the higher level state machines, that TCP is listening
self.addToTrace("pyPlcTcpSocket listening on port " + str(self.tcpPort))
hostname=socket.gethostname()
print(hostname)
self.addToTrace(hostname)
IPAddr=socket.gethostbyname(hostname)
print(IPAddr)
addressInfo = socket.getaddrinfo(hostname, None, socket.AF_INET6)
print(addressInfo)
#print("Your Computer Name is:"+hostname)
self.addToTrace("The socket is linked the following IP addresses:")

Any recommendations @uwi22 or other on how you have it in your working setups if using Pi? I can get it to work by hacking it up but would like to use the correct approach that can work once I have it connected to a real Green PHY/PLC modem to a PEV.

Thank you again - as I am doing these changes I am saving it and will post a working config/changes so that it's useful for others following this procedure.

[asavage]

Question about the FAQ: regarding https://github.com/uhi22/pyPLC/blob/mas ... connect-it

Q1: What is the purpose of the PP pin, and do I need to connect it?

The car uses the ProximityPilot (or PlugPresent) to detect, that a plug has been inserted. We need to connect a 1.5kohms resistor between the PP and the ProtectiveEarth (PE) [ . . . ]

This seems to be a CCS2-centric statement?

Borrowing a diagram from the BMW i3 LIM CCS Wiki:





For our testing, would we CCS1-folk need a 150 ohms resistor?

Our CCS1 nozzles have an integral switch on the nozzle, which -- if the charge inlet's nozzle lock is disengaged -- the user can depress to both physically release the nozzle and signal both entities that the nozzle is about to be removed from the charge inlet: PP-to-PE changes from 150 ohms to 480.

[uhi22]

... so not sure why this hostname to IP mapping is done in lines ( pyPlcTcpSocket.py) 160-176

Good point. These lines are a left-over of some experiments, and not needed. I kicked them out now: https://github.com/uhi22/pyPLC/commit/7 ... 866ace461a

Does this solve the issue?

[uhi22]

Question about the FAQ: regarding https://github.com/uhi22/pyPLC/blob/mas ... -is-the-cp

This seems to be a CCS2-centric statement?

Good point. I was not aware of the differences in CCS1, and updated the FAQ now.

[mhpev]

Good point. These lines are a left-over of some experiments, and not needed. I kicked them out now: https://github.com/uhi22/pyPLC/commit/7 ... 866ace461a

Does this solve the issue?

Sure does! Thanks. The EVSE (simulated) was able to open a listener on the port and the conn to PEV (simulated) was established as seen in the snapshot below.

One thing to note - I am using a real TP Link modem connected to the Ethernet port of the Pi and *once these messages get exchanged I notice my modems lose connectivity (based on the LED light status of the link). I've not yet updated the firmware and PIB files so these modems are in their normal modes HomePlug AV mode, as they're not rewired yet but connected to my home network and going over the home electrical/powerline network.

But this is good progress. I am going to start working on the modem rewiring and moving to DC as well as update their PIDs to reflect the EVSE and PEV sides using the open PLC utils. Then will retry getting the 2 sides up and running again. Please let me know if you want me to try something else in the meantime.
Thank you again. Attaching my working pyPlc.ini file

PS one more thing I was thinking if we want to have both PEV and EVSE sides running from the same m/c one way would be to consume specific .ini files maybe as a command line argument when starting the processes. That way each side can read specific configs and come up on the same m/c with different configs (just a thought).

pyPlc.ini

(6.08 KiB) Downloaded 78 times

[mhpev]

Good point. I was not aware of the differences in CCS1, and updated the FAQ now.

I was able to move much further and also config 2 TP link modems from the 4010 kit - one as EVSE and other as PEV using the docs and links from your github as well as detailed post from @asavage.

I've still not moved the modems to DC but that's the next step. For now I was able to get the PEV and EVSE sides working fine across the modems.
I hit one error after the simulated PEV side reached 100% SoC and stopped the session - the modem conn on EVSE side dropped and when the script tried to reconnect the EVSE code threw and exception and crashed - cause was same as above. So I updated the code to reflect changes you mentioned above in the reconnect section as below:

def resetTheConnection(self):
# in case of a broken connection, here we try to start it again
self.addToTrace("Trying to reset the TCP socket")
# Todo: how to "reset" the socket?
try:
self.ourSocket.close()
except:
pass
self.ourSocket = socket.socket(socket.AF_INET6, socket.SOCK_STREAM, 0)
self.ourSocket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
self.ourSocket.bind((self.ipAdress, self.tcpPort))
self.ourSocket.listen(1)
self.callbackStateNotification(1) # inform the higher level state machines, that TCP is listening
self.addToTrace("pyPlcTcpSocket listening on port " + str(self.tcpPort))
hostname=socket.gethostname()
# IPAddr=socket.gethostbyname(hostname)
# addressInfo = socket.getaddrinfo(hostname, None, socket.AF_INET6)
# #print("Your Computer Name is:"+hostname)
# self.addToTrace("The socket is linked the following IP addresses:")
# for i in range(0, len(addressInfo)):
# #fe80::4c46:fea5:b6c9:25a9
# IPv6Addr = addressInfo[4][0]
# self.addToTrace(IPv6Addr)
self.addToTrace("Hostname is " + hostname)
self.read_list = [self.ourSocket]
self.rxData = []


and now the code works fine without crashing or throwing an exception.

Thx again.

[uhi22]

Perfect, thanks for testing and proposing the bugfix. I pushed an update: https://github.com/uhi22/pyPLC/commit/c ... 307c556c13

[mhpev]

Perfect, thanks for testing and proposing the bugfix. I pushed an update: https://github.com/uhi22/pyPLC/commit/c ... 307c556c13

thank you! I was also able to validate across 2 TPlink modems and they did come up, all 3 LEDs on both the modems were on. How do I ensure that the modems are config correctly? and the correct PIBs for EVSE and PEV mode are loaded up. Because next step would be to remove the AC ckts from the modems and power them via DC (5-12V) and if there's no issue hacking up the h/w will move to validating with the real EV/Chevy Bolt that supports CCS1 charger (and pyPlc in EVSE mode).

Any other things i need to take into consideration?

appreciate all the help from the forum members and especially all the code you've developed/maintained for this! I am attaching the wireshark trace that shows all the pkts from both sides if it helps anyone going forward.

simulated_evse_pev.zip

(8.76 KiB) Downloaded 86 times

[johu]

Had a good test drive in Audi yesterday until it stopped being good...

6 successful sessions and I also observed that pyPLC handshakes faster than an Audi E-Tron GT/Porsche Taycan Was helping a guy who couldn't authenticate and then it took ages until it actually started. Like a minute, ridiculous!

Towards the end of our 350 km journey the battery had warmed up and allowed 100A charge current. We were using an Aral Pulse (HyperCharger) and it would build up power then after some seconds interrupt. We went to an Aldi charger (again Hypercharger) and that worked ok. Until suddenly there was no current flow and voltage just stayed at the preset 401V. By then I reckoned the "hammered" Nissan charge port relay might have given up the ghost. So we shorted it and retried.

Now a shockwave went through the car. ABS light came on, the 5V regulator of "pyPLC" started smoking and of course there was no charging. Keep in mind pyPLC is NOT hooked up the CAN bus, just 12V.
We then tried AC charging which faulted out with a ground fault. We took out the entire quick charge assembly but the ground fault was still there. Took out the AC port of the charging station, oops...
We also noticed a Airbag fault.
Managed to drive 70 km with 50% of the quite battered 24 kWh Nissan battery, just 10 km short of out destination

Checked for obvious isolation faults between HV and GND this morning and found none. And consequently AC charging is now working again. Weird.
Also checked the "pyPLC". BeagleBone still powers up via USB, also the modem powers up but the 3V3 regulator becomes super hot.

[uhi22]

Ooops, this sounds like massive overvoltage on the 12V. Reminds me to look for heavy TVS. Hopefully not too much is broken...

[induzer]

First things first - many thanks for what you established to this point. Pure awesomeness.

Might be able to test pyPLC against a "to-be-released" beta charger, based on some Siemens hardware, in a few days time.

Our test rig is just hard to get hold of these days, they also got a firmware update lately.

Update is something about not taking some aspect in communication between EVSE <-> PEV to stricly in future.
Sounds SIE had gotten some constructive customer feedback lately, regading failing charge session attempts.

Keep you updated, TL-PA4010 already acquired yet ...

Also how well some CCS chargers are eventually willing to deliver power to my Citroen Saxo electrique - reason being the battery just quit on edge of what is commonly specified as lowest DC output capability.

[CCSknowitall]

def resetTheConnection(self):
# in case of a broken connection, here we try to start it again

FYI if the tcp connection is broken (closed or reset) at any point during a session, the session will end. You can try to reconnect, but should start at the beginning.

Stations that support also CHAdeMO are more likely to go down to ~150V. I wouldn’t trust anything below 100V despite CHAdeMO “requiring” to 50V.

[crasbe]

Ooops, this sounds like massive overvoltage on the 12V. Reminds me to look for heavy TVS. Hopefully not too much is broken...

In a former project we had good success with Bourns Gas Discharge Tubes (GDTs) for IEC 61000-4-5 surge tests. The TVS diodes alone did not provide sufficient protection and we found that in overvoltage situations, they'd just get reeeeeeeally hot and eventually start to smoke.
However GDTs are mostly good for big spikes with limited duration.

However I wonder how the 12V system in the Audi got to THAT level of overvoltage. It wouldn't start smoking after a single spike but rather extended overvoltage. In a situation like that, other ECUs might get damage as well.

[mhpev]

FYI if the tcp connection is broken (closed or reset) at any point during a session, the session will end. You can try to reconnect, but should start at the beginning.

Stations that support also CHAdeMO are more likely to go down to ~150V. I wouldn’t trust anything below 100V despite CHAdeMO “requiring” to 50V.

That's what seems to be happening. I've not yet tried it with a real EV but with the simulator I've stopped the session in between to create failure scenarios that the EVSE side restarted the conn and goes back to listen mode. Underlying handshaking needs to be redone completely anyways at L1 and L2 but since the EV/client side is initiation the conn it would get back to restart per my understanding. The issue was the server side was throwing an exception hence the EVSE side was abruptly ending this small change will allow it to keep it running, waiting for new connections.
Not sure if that's your concern or something else.

[mhpev]

Moved one step further today. Hacked 2 TP-Link modems from the kit and removed all the A/C xformers and related electronics working using 12V DC PS for now.
Used the approach described in this thread to connect 2 cables back2back from the PEV <-> EVSE. after some initial issues was finally able to get all 3 lights on the modem and comm going from/to EVSE/PEV.

next step get the conn to gen 5% PWM constant to keep EV side tricked and to establish comm (as a DC charger/discharger) ... thanks to all especially @uhi22

[mhpev]

I am continuing to use the pyPlc to make both the sides comm EVSE with PEV (with 2 RPi having the ini config and 2 mod TP Link modems as mentioned above).
Before I connect to a real EV (my goal is to mainly act as an EVSE using the EVSEmode doc as my blueprint) - I was checking some of the params on both the EVSE as well as PEV side - mainly the changes to PIB side for both and ensure nothing is incorrect.

Here my config for EVSE side:
eth0 98:48:27:73:86:7B Fetch Network Information
eth0 98:48:27:73:86:7B Found 1 Network(s)

source address = 98:48:27:73:86:7B

network->NID = 01:02:03:04:05:06:07
network->SNID = 4
network->TEI = 1
network->ROLE = 0x02 (CCO)
network->CCO_DA = 98:48:27:73:86:7B
network->CCO_TEI = 1
network->STATIONS = 1

station->MAC = 98:48:27:73:85:20
station->TEI = 6
station->BDA = E4:5F:01:91:47:97
station->AvgPHYDR_TX = 222 mbps Primary
station->AvgPHYDR_RX = 019 mbps Primary

PIB 0-0 8836 bytes
MAC 98:48:27:73:86:7B
DAK 26:AF:9B:B7:85:B3:EB:2C:0F:79:E4:F1:B0:4E:18:76
NMK 77:77:20:10:77:77:77:77:77:77:77:77:77:77:77:77
NID 01:02:03:04:05:06:07
Security level 0
NET Qualcomm Atheros Enabled Network
MFG tpver_401003_171219_901
USR EVSE
CCo Always
MDU N/A

Chipset: QCA7420


Here my config for PEV side:

eth0 98:48:27:73:85:20 Fetch Network Information
eth0 98:48:27:73:85:20 Found 1 Network(s)

source address = 98:48:27:73:85:20

network->NID = 01:02:03:04:05:06:07
network->SNID = 4
network->TEI = 6
network->ROLE = 0x00 (STA)
network->CCO_DA = 98:48:27:73:86:7B
network->CCO_TEI = 1
network->STATIONS = 1

station->MAC = 98:48:27:73:86:7B
station->TEI = 1
station->BDA = 00:E0:4C:36:01:6C
station->AvgPHYDR_TX = 019 mbps Primary
station->AvgPHYDR_RX = 222 mbps Primary

PIB 0-0 8836 bytes
MAC 98:48:27:73:85:20
DAK 23:0F:0C:C3:9F:E1:4F:05:71:00:D2:62:88:36:1A:15
NMK 77:77:20:10:77:77:77:77:77:77:77:77:77:77:77:77
NID 01:02:03:04:05:06:07
Security level 0
NET Qualcomm Atheros Enabled Network
MFG tpver_401003_171219_901
USR PEV
CCo Never
MDU N/A

Chipset: QCA7420


I went back on some of the posts and tried to use the vanilla QCA slac evse and pev utils against each other - but for some reason when I use it the 2 sides are not able to get to the point I see in an earlier post from @catphish where he shows that both sides are able to get to charging...
But in another post he provides diff where he has done some changes to slac code and some keys as well as sounding messages etc... do we need to do those to make the QCA evse and pev working?

One other thing I noticed on the Tk windows the PEV and EVSE Mac addr are diff from what we see in the above - mainly the mac addr of the modems.
eg on PEV side:

and on EVSE side it has the same PEV side eth0 addr (shown above)

shouldn't the PEV mac be the modem's MAC and not the eth0 interface mac on Linux of PEV?

Just trying to eliminate any issues before I connect to the actual EV.

[mhpev]

One more data point - I was able to use the pyPLC code with PEV/EVSE based on QCA7005 - from Aliexpress. next step is to make sure the CP has the correct voltage/duty cycle etc using open EVSE/instructible and then final showdown with an EV. So far the messages etc seem to be matching to the ISO 15118 specification.

BTW @uhi22 I found a spec sheet for a GreenPHY sniffer from IoTecha https://www.iotecha.com/pilot-shark/ not sure if it does passive listening on the wire... seems to suggest that from the product page. If anyone has any experience.

[CCSknowitall]

The iotecha tool is a professional device and costs professional device money. Low five figures. It is only a passive sniffer, but a mostly good one. A true bargain compared to the Keysight stuff (which can do a lot more, but also costs an order of magnitude more).

[CCSknowitall]

I thought the QCA7420 couldn’t measure the sounding messages from the PEV? If that’s true, you are probably failing to send CM_ATTEN_CHAR.IND or sending nonsense values. You can certainly fake the measurements and send a value that the PEV side will accept.

[uhi22]

Cross-linking to another forum with same topic: https://www.diyelectriccar.com/threads/ ... st-1115264

[mhpev]

Hi I have finally got to a point where I was able to get the 5% PWM signal and rest of the wallbox related ckt to connect to the Bolt CCS1 charger - after that I manually started the pyPLC in EVSE mode and was able to see most of the messages between the Bolt <-> EVSE/pyPLC. The point where the messaging stopped is at the CableCheckReq/CableCheckResp transaction as shown in the snapshot below. And the PEV didn't respond and seems the messaging timed out. I am not seeing any errors but if someone can point me to something that needs to change. For this exercise I don't have any pack/actual DC charger and terminal voltage/current on the DC terminals - so not sure if the PEV doesn't like that and hence stopping the transaction - but I don't see any error on the PEV or messaging hence a bit confused or it's something diff I could try - the Bolt doesn't support V2X hence only charging function is supported
Relevant messaging on EVSE side are shown below:

12386ms] [EVSE] Received ChargeParameterDiscoveryReq. Extracting SoC parameters via DC
[12399ms] [EVSE] responding (49bytes) = 01 FE 80 01 00 00 00 29 80 9A 02 00 40 80 C1 01 41 81 C2 10 80 00 48 20 40 00 00 C9 90 02 06 20 50 19 30 80 C0 C8 02 06 4C 80 10 19 01 40 C8 0A 20
[12402ms] [EVSE] from 4 entering 4
[SNIFFER] EXI from 57421 to 15118 (46bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 71 90 00 00 0A 60 40 61 B8 16 05 07 08 40 70 20 50 94 23 00 C2 42 42 C8 04 03 09 0C 0A 20 10 64 0A 00
[SNIFFER] EXI from 15118 to 57421 (41bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 80 00 48 20 40 00 00 C9 90 02 06 20 50 19 30 80 C0 C8 02 06 4C 80 10 19 01 40 C8 0A 20
[13191ms] [CONNMGR] 9 0 0 364 0 0 0 --> 15
[SNIFFER] EXI from 57421 to 15118 (17bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 11 00 00 0A 60
[15403ms] [EVSE] In state WaitForFlexibleRequest, received (25bytes) = 01 FE 80 01 00 00 00 11 80 9A 02 00 40 80 C1 01 41 81 C2 10 11 00 00 0A 60
[15419ms] [EVSE] {
"msgName": "CableCheckReq",
"info": "17 bytes to convert",
"error": "",
"result": "",
"schema": "DIN",
"g_errn": "0",
"header.SessionID": "0102030405060708",
"header.Notification_isUsed": "0",
"header.Signature_isUsed": "0",
"DC_EVStatus.EVRESSSOC": "83",
"DC_EVStatus.EVReady": "1",
"debug": "Line9057Line9090Line9169Line9226Line9260Line364"
}
[15420ms] [EVSE] Received CableCheckReq. Extracting SoC parameters via DC
[15438ms] [EVSE] responding (26bytes) = 01 FE 80 01 00 00 00 12 80 9A 02 00 40 80 C1 01 41 81 C2 10 20 02 00 00 00 00
[15443ms] [EVSE] from 4 entering 4
[SNIFFER] EXI from 15118 to 57421 (18bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 20 02 00 00 00 00
[15999ms] [CONNMGR] 9 0 0 331 0 0 0 --> 15
[18789ms] [CONNMGR] 9 0 0 298 0 0 0 --> 15
[21578ms] [CONNMGR] 9 0 0 265 0 0 0 --> 15
[23987ms] [EVSE] from 4 entering 0

Also attaching a snapshot of diff of EVSE logs on left side is transaction with simulated pyPLC PEV and right side is with the Bolt. Some deltas I've tried to highlight but nothing major seen. Also, on both sides the EVSE sends out the CableCheckResponse message which is identical in both cases.

If you can help point what could be modified to get past this and move to the next state PreChargeReq would be helpful. Else if it's tied to not having actual DC voltage/current on the terminals then it would be a bummer...
Thx in advance...

chevy_bolt_pev_230919.log

(11.75 KiB) Downloaded 55 times

[uhi22]

Interesting, could you record the Ethernet traffic using wireshark or tcpdump?

[mhpev]

Interesting, could you record the Ethernet traffic using wireshark or tcpdump?

Sure, I'll do another run later today/tomorrow and get that data out. Have also asked some friends if I could use their Tesla Model S and Kia EV6 to try this same experiment. Will send out the logs/results in next couple of days...

[mhpev]

Hi @uhi22 - have some more updates from integrations with Chevy Bolt 2018, Kia EV6 2023, and Telsa Model S (with NACS/CCS adapter).
1. Chevy Bolt - transaction stuck at CableCheckReq/CableCheckResp and the EV doesn't send anything back and the transaction times out... and the EVSE goes back to listening mode (while PEV never reattempts and conn until I remove the connector and restart everything)

Bolt.zip

(6.6 KiB) Downloaded 62 times

2. Tesla Model S - supplied the correct voltage/PWM of 5% etc but no messages seen in the wireshark capture from the PEV side so need to dig in and see if something else is expected. This Tesla has the charger ported to NACS/CCS1 for DC fast charging. I thought it would be similar as the protocol is the same unless they have a different PWM or other mechanism to initiate the PLC messaging (and advice/insight is appreciated).

3. Kia EV6 - this vehicle seemed like one that is closest to Hyundai Ioniq 5 and I may have some success with but here the transaction gets completed and the EV sends a session stop request, so it goes much further but not seeing any voltage on the DC terminals (I am trying to use this similar to what @uhi22 did for his Ioniq 5 with EVSEmode - without actual voltage at the vehicle.. do i need to do something at EV side to enable V2X or diff voltage to get discharge v/s normal charging at the dashboard?
The messages go in this fashion where some critical ones are skipped by the PEV -
ChargeParameterDiscoveryReq/ChargeParameterDiscoveryResp
then skipping other intermediate messages, it jumps directly to:
PowerDeliveryReq/PowerDeliveryResp
and then the PEV/Kia EV6 sends out the:
SessionStopReq/SessionStopResp

Kia_EV6.zip

(5.97 KiB) Downloaded 58 times

There are no errors but surely skipped states/messaging. if you can provide any help/insights it would help, Goal is to connect this device and attempt to read DC voltage at the terminals and close contactors on the pack inside EV side using the pyPlc in EVSE mode. This is mimicking the draw out of power/energy from the pack without needing a charger functionality (EV6 claims V2L so hopefully it would be similar Ioniq 5 unless there is some major issue in message structure

Thanks again in advance.


hope this helps!