Open source CCS using AR7420

[Timvb]

Hello, I have a same board as yours(TP-PA4010). I have some problem when I try to do the hardware part. Do you remove all the crossed off unit on the board and finally work? Can I take a look at your board and see how do you wire CP and PE on the board? It would be a huge help! Thank you!

I have used the PA4010 As well.
The capacitor i placed at CX2 is 1nF and the resistor is 150 ohms.

I have made a report of the steps we have taken to discharge a vehicle; this is a little snippet on how to flash the PLC adapter:

1. Open-Plc-Utils can be used to flash firmware on modules with an AR7420. This must first be downloaded, compiled and then installed.
   • git clone https://github.com/qca/open-plc-utils
   • cd open-plc-utils
   • make
   • sudo make install
     It is possible a new terminal session has to be started before the installed commands are available.
2. On the raspberry Pi, the LAN port configuration needs to be changed for supporting this adapter. See guide: https://github.com/uhi22/pyPLC/blob/mas ... ernet-port
3. Download the original and customized firmware that is able to route SLAC packets from LAN to RF and vice versa: https://static.tp-link.com/TL-PA4010%28 ... 160316.zip
   https://mega.nz/file/ocNDhYzK#xuSQXd-b6 ... MjZX5WEWHc
4. Find the mac address of the PLC module: plcstat -t -i eth0
5. Take a backup of the original PIB (this is the unique parameter configuration for the module, containing things like the MAC address): plctool -ieth0 -p original.pib <mac address>
6. Copy over the PIB Block: cp original.pib evse.pib
7. Modify the PIB Block:
   • setpib evse.pib 74 hfid "EVSE"
   • setpib evse.pib F4 byte 2
   • setpib evse.pib 1653 byte 2
   • setpib evse.pib 1C98 long 10240 long 102400
8. Write the new firmware to the PLC Adapter:
   plctool -i eth0 -P QCA7420-WallAdapter-HomePlugAV_CE-ClassB_us_401030.pib -N FW-QCA7420-1.5.0.0026-02-CS-20200114.nvm -R <mac address>
9. Write the configuration to the PLC Adapter:
   plctool -ieth0 -P evse.pib <mac address>
   Now the PLC Adapter should route SLAC messages from RF to LAN.

[uhi22]

And from the evse mode manual https://github.com/uhi22/pyPLC/blob/mas ... -is-the-cp

[uhi22]

I have made a report of the steps we have taken to discharge a vehicle

This is great to hear. If you like you could summarize your experiences in the "discharge thread": viewtopic.php?t=3551&start=50

[p477d343]

Final update:
After reflash pib file on EVSE and PEV side. And reboot rasbpery pi on both side. Then running pyPlc.py E and P mode on both side. It finally blink 3 leds on and charging successfully.

So I tear down parts and connect EVSE's modem and PEV modem only. Power by 5V 18650 battery. When I power up. The mid led was not blanking at both side. So I check both with command

Code: Select all

sudo plctool -i eth0 -I

and find out my USR on both side is not EVSE and PEV as it should be. Is this meaning that I not flash the right pib to both modem?

Quick update.
I flash pib again and it shows up EVSE and PEV now. I press the reset long enough to reset. It will show 3 leds light up and I run pyPLC.py E ans P mode on both side will give me following error. And by pressing the reset button. It will reset my the USR from EVSE and PEV to USR tpver_401003_171219_901. And NMK would be different.
My EVSE side:

Code: Select all

pi@raspberrypi:~/project/pyPlc $ sudo python pyPlc.py E
starting in EvseMode
initializing pyPlcWorker
[addressManager] we have local MAC D8:3A:DD:22:F1:82.
[addressManager] Found 1 link-local IPv6 addresses.
fe80::767d:3f18:5b28:8e37
[addressManager] Local IPv6 is fe80::767d:3f18:5b28:8e37
Linux interface is eth0
[addressManager] will give local MAC D8:3A:DD:22:F1:82
[addressManager] will give local MAC D8:3A:DD:22:F1:82
pyPlcIpv6 started with ownMac D8:3A:DD:22:F1:82
[addressManager] will give local MAC D8:3A:DD:22:F1:82
udplog started with ownMac D8:3A:DD:22:F1:82
logging to UDP Syslog is enabled
sniffer created at eth0
[1033ms] [HARDWAREINTERFACE] Auto detection of serial ports. Available serial ports:
[1038ms] [HARDWAREINTERFACE] ERROR: No serial ports found. No hardware interaction possible.
[1161ms] [pyPlcWorker] Software version v0.9-54-gb2d6ec0
[1161ms] [EVSE] initializing fsmEvse
[1173ms] pyPlcTcpSocket listening on port 15118
[1173ms] Hostname is raspberrypi
[1211ms] transmitting SET_KEY.REQ, to configure the EVSE modem with random NMK
[1242ms] received SET_KEY.CNF
[1243ms] SetKeyCnf says 1, this is formally 'rejected', but indeed ok.
[1289ms] received SET_KEY.CNF
[1290ms] SetKeyCnf says 0, this would be a bad sign for local modem, but normal for remote.
[addressManager] pev has IP fe80:0000:0000:0000:4ba6:7b7e:73f8:9ee9
V2GTP (10bytes) = 01 FE 90 00 00 00 00 02 10 00 
Ok, this was a valid SDP request. We are the SECC. Sending SDP response.
SDP payload (20bytes) = FE 80 00 00 00 00 00 00 76 7D 3F 18 5B 28 8E 37 3B 0E 10 00 
V2Gframe (28bytes) = 01 FE 90 01 00 00 00 14 FE 80 00 00 00 00 00 00 76 7D 3F 18 5B 28 8E 37 3B 0E 10 00 
[Testsuite]  received syslog packet: [CONNMGR] ConnectionLevel changed from 20 to 50
[Testsuite]  received syslog packet: [PLCWORKER] Network is established, ready for TCP.
[Testsuite]  received syslog packet: [PEV] re-initializing fsmPev
[Testsuite]  received syslog packet: [HARDWAREINTERFACE] Setting CP line into state B.
[Testsuite]  received syslog packet: [HARDWAREINTERFACE] Switching PowerRelay OFF.
[Testsuite]  received syslog packet: [HARDWAREINTERFACE] Switching Relay2 OFF.
[Testsuite]  received syslog packet: [CONNMGR] 9 0 164 0 148 0 0  --> 50
[Testsuite]  received syslog packet: [PEV] Checkpoint301: connecting
[Testsuite]  received syslog packet: TCP connecting to fe80:0000:0000:0000:767d:3f18:5b28:8e37 port 15118...
[Testsuite]  received syslog packet: [PEV] connected
[Testsuite]  received syslog packet: [PEV] from 1:Connecting entering 2:Connected
[Testsuite]  received syslog packet: [PEV] Checkpoint400: Sending the initial SupportedApplicationProtocolReq
[Testsuite]  received syslog packet: [PEV] from 2:Connected entering 3:WaitForSupportedApplicationProtocolResponse
[Testsuite]  received syslog packet: [CONNMGR] 9 0 131 0 115 0 0  --> 50
[10061ms] Connection from ('fe80::4ba6:7b7e:73f8:9ee9', 56298, 0, 2)
[10097ms] [EVSE] In state WaitForSupportedApplicationProtocolRequest, received (42bytes) = 01 FE 80 01 00 00 00 22 80 00 DB AB 93 71 D3 23 4B 71 D1 B9 81 89 91 89 D1 91 81 89 91 D2 6B 9B 3A 23 2B 30 02 00 00 04 00 40 
[10117ms] [EVSE] {
"msgName": "supportedAppProtocolReq",
"info": "34 bytes to convert", 
"error": "",
"result": "Vehicle supports 1 protocols. ProtocolEntry#1 ProtocolNamespace=urn:din:70121:2012:MsgDef Version=2.0 SchemaID=1 Priority=1 ",
"schema": "appHandshake",
"AppProtocol_arrayLen": "1",
"NameSpace_0": "urn:din:70121:2012:MsgDef",
"Version_0": "2.0",
"SchemaID_0": "1",
"Priority_0": "1",
"debug": ""
}
[10118ms] [EVSE] The car supports 1 schemas.
[10119ms] [EVSE] The NameSpace urn:din:70121:2012:MsgDef has SchemaID 1
[10119ms] [EVSE] Detected DIN
[10121ms] [EVSE] responding (12bytes) = 01 FE 80 01 00 00 00 04 80 40 00 40 
[10163ms] [EVSE] from 0 entering 1
[18610ms] [EVSE] from 1 entering 0
user action space
stopping the charge process
user action Shift_L
user action X
user action x

My PEV side:

Code: Select all

pi@raspberrypi:~/myprogs/pyPlc $ sudo python pyPlc.py P
starting in PevMode
initializing pyPlcWorker
[addressManager] we have local MAC D8:3A:DD:22:F1:CA.
[addressManager] Found 1 link-local IPv6 addresses.
fe80::4ba6:7b7e:73f8:9ee9
[addressManager] Local IPv6 is fe80::4ba6:7b7e:73f8:9ee9
Linux interface is eth0
[addressManager] will give local MAC D8:3A:DD:22:F1:CA
[addressManager] will give local MAC D8:3A:DD:22:F1:CA
pyPlcIpv6 started with ownMac D8:3A:DD:22:F1:CA
[addressManager] will give local MAC D8:3A:DD:22:F1:CA
udplog started with ownMac D8:3A:DD:22:F1:CA
logging to UDP Syslog is enabled
sniffer created at eth0
[1008ms] [HARDWAREINTERFACE] Auto detection of serial ports. Available serial ports:
[1015ms] [HARDWAREINTERFACE] ERROR: No serial ports found. No hardware interaction possible.
[1128ms] [pyPlcWorker] Software version v0.9-57-gbe5ecf9
[1128ms] [PEV] initializing fsmPev
[1162ms] [CONNMGR] ConnectionLevel changed from 0 to 5
[1162ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
[1172ms] [ModemFinder] Starting modem search
[1207ms] [SNIFFER] received GET_SW.CNF
[1207ms] [SNIFFER] For 34:E8:94:07:A4:FB the software version is MAC-QCA7420-1.3.0.2134-00-20151212-CS 
[1207ms] [SNIFFER] received GET_SW.CNF
[1207ms] [SNIFFER] For 34:E8:94:07:86:78 the software version is MAC-QCA7420-1.3.0.2134-00-20151212-CS 
[1716ms] [ModemFinder] Number of modems:2
[1751ms] [CONNMGR] ConnectionLevel changed from 5 to 20
[1764ms] [SDP] Checkpoint200: Starting SDP.
[PEV] initiating SDP request
[2294ms] [CONNMGR] 9 148 313 0 0 0 0  --> 20
[PEV] initiating SDP request
[PEV] initiating SDP request
[3372ms] [CONNMGR] 9 115 280 0 0 0 0  --> 20
[PEV] initiating SDP request
[PEV] initiating SDP request
[PEV] initiating SDP request
[4452ms] [CONNMGR] 9 82 247 0 0 0 0  --> 20
[PEV] initiating SDP request
[PEV] initiating SDP request
[5566ms] [CONNMGR] 9 49 214 0 0 0 0  --> 20
[PEV] initiating SDP request
[PEV] initiating SDP request
[6680ms] [CONNMGR] 9 16 181 0 0 0 0  --> 20
[PEV] initiating SDP request
[PEV] initiating SDP request
[7806ms] [CONNMGR] 9 0 148 0 0 0 0  --> 20
[PEV] initiating SDP request
[PEV] initiating SDP request
[8886ms] [CONNMGR] 9 0 115 0 0 0 0  --> 20
[PEV] initiating SDP request
[PEV] initiating SDP request
[9963ms] [CONNMGR] 9 0 82 0 0 0 0  --> 20
[PEV] initiating SDP request
[PEV] initiating SDP request
[11042ms] [CONNMGR] 9 0 49 0 0 0 0  --> 20
[PEV] initiating SDP request
[PEV] initiating SDP request
[12121ms] [CONNMGR] 9 0 16 0 0 0 0  --> 20
[PEV] initiating SDP request
[12646ms] [CONNMGR] ConnectionLevel changed from 20 to 5
[12648ms] [ModemFinder] Starting modem search
[12684ms] [SNIFFER] received GET_SW.CNF
[12684ms] [SNIFFER] For 34:E8:94:07:A4:FB the software version is MAC-QCA7420-1.3.0.2134-00-20151212-CS 
[12684ms] [SNIFFER] received GET_SW.CNF
[12684ms] [SNIFFER] For 34:E8:94:07:86:78 the software version is MAC-QCA7420-1.3.0.2134-00-20151212-CS 
[13188ms] [ModemFinder] Number of modems:2
[13230ms] [CONNMGR] ConnectionLevel changed from 5 to 20
[13231ms] [CONNMGR] 9 164 329 0 0 0 0  --> 20
[13248ms] [SDP] Checkpoint200: Starting SDP.
[PEV] initiating SDP request
[PEV] initiating SDP request
[14353ms] [CONNMGR] 9 131 296 0 0 0 0  --> 20
[PEV] initiating SDP request
[PEV] initiating SDP request
[PEV] initiating SDP request
[15465ms] [CONNMGR] 9 98 263 0 0 0 0  --> 20
[PEV] initiating SDP request
[PEV] initiating SDP request
[16588ms] [CONNMGR] 9 65 230 0 0 0 0  --> 20
[PEV] initiating SDP request
[PEV] initiating SDP request
[17708ms] [CONNMGR] 9 32 197 0 0 0 0  --> 20
[Testsuite]  received syslog packet: Test message to verify the syslog. pyPlcHomeplug.py is in the init function.
[Testsuite]  received syslog packet: [HARDWAREINTERFACE] Auto detection of serial ports. Available serial ports:
[Testsuite]  received syslog packet: [HARDWAREINTERFACE] ERROR: No serial ports found. No hardware interaction possible.
[Testsuite]  received syslog packet: pyPlcWorker init
[Testsuite]  received syslog packet: [pyPlcWorker] Software version v0.9-54-gb2d6ec0
[Testsuite]  received syslog packet: [EVSE] initializing fsmEvse
[Testsuite]  received syslog packet: pyPlcTcpSocket listening on port 15118
[Testsuite]  received syslog packet: Hostname is raspberrypi
[Testsuite]  received syslog packet: transmitting SET_KEY.REQ, to configure the EVSE modem with random NMK
[Testsuite]  received syslog packet: received SET_KEY.CNF
[Testsuite]  received syslog packet: SetKeyCnf says 1, this is formally 'rejected', but indeed ok.
[Testsuite]  received syslog packet: received SET_KEY.CNF
[Testsuite]  received syslog packet: SetKeyCnf says 0, this would be a bad sign for local modem, but normal for remote.
[PEV] initiating SDP request
V2GTP (28bytes) = 01 FE 90 01 00 00 00 14 FE 80 00 00 00 00 00 00 76 7D 3F 18 5B 28 8E 37 3B 0E 10 00 
[PEV] Checkpoint203: Received SDP response
[addressManager] charger has IP fe80:0000:0000:0000:767d:3f18:5b28:8e37
[addressManager] charger has TCP port 15118
[18314ms] [CONNMGR] ConnectionLevel changed from 20 to 50
[18315ms] [PLCWORKER] Network is established, ready for TCP.
[18315ms] [PEV] re-initializing fsmPev
[18315ms] [HARDWAREINTERFACE] Setting CP line into state B.
[18316ms] [HARDWAREINTERFACE] Switching PowerRelay OFF.
[18316ms] [HARDWAREINTERFACE] Switching Relay2 OFF.
[18856ms] [CONNMGR] 9 0 164 0 148 0 0  --> 50
[19297ms] [PEV] Checkpoint301: connecting
[19297ms] TCP connecting to fe80:0000:0000:0000:767d:3f18:5b28:8e37 port 15118...
[19321ms] [PEV] connected
[19330ms] [PEV] from 1:Connecting entering 2:Connected
[19369ms] [PEV] Checkpoint400: Sending the initial SupportedApplicationProtocolReq
[19370ms] [PEV] from 2:Connected entering 3:WaitForSupportedApplicationProtocolResponse
[20005ms] [CONNMGR] 9 0 131 0 115 0 0  --> 50
[21121ms] [CONNMGR] 9 0 98 0 82 0 0  --> 50
[21629ms] [PEV] from 3:WaitForSupportedApplicationProtocolResponse entering 99:SequenceTimeout
[21670ms] [PEV] Safe-shutdown-sequence: setting state B
[21670ms] [HARDWAREINTERFACE] Setting CP line into state B.
[21670ms] [PEV] from 99:SequenceTimeout entering 111:SafeShutDownWaitForChargerShutdown
[21740ms] [CONNMGR] ConnectionLevel changed from 50 to 100
[22230ms] [CONNMGR] 9 0 65 0 49 0 329  --> 100
[23305ms] [CONNMGR] 9 0 32 0 16 0 329  --> 100
[23860ms] [PEV] Safe-shutdown-sequence: opening contactors
[23860ms] [HARDWAREINTERFACE] Switching PowerRelay OFF.
[23860ms] [HARDWAREINTERFACE] Switching Relay2 OFF.
[23860ms] [PEV] from 111:SafeShutDownWaitForChargerShutdown entering 222:SafeShutDownWaitForContactorsOpen
[24380ms] [CONNMGR] 9 0 0 0 0 0 329  --> 100
[24972ms] [PEV] Safe-shutdown-sequence: unlocking the connector
[24973ms] [HARDWAREINTERFACE] Unocking the connector
[24974ms] [PEV] from 222:SafeShutDownWaitForContactorsOpen entering 1000:End
[25461ms] [CONNMGR] 9 0 0 0 0 0 315  --> 100
[26536ms] [CONNMGR] 9 0 0 0 0 0 282  --> 100
[27637ms] [CONNMGR] 9 0 0 0 0 0 249  --> 100
[28751ms] [CONNMGR] 9 0 0 0 0 0 216  --> 100
[29861ms] [CONNMGR] 9 0 0 0 0 0 183  --> 100
[30970ms] [CONNMGR] 9 0 0 0 0 0 150  --> 100
[32080ms] [CONNMGR] 9 0 0 0 0 0 117  --> 100
[33197ms] [CONNMGR] 9 0 0 0 0 0 84  --> 100
[34313ms] [CONNMGR] 9 0 0 0 0 0 51  --> 100
[35419ms] [CONNMGR] 9 0 0 0 0 0 18  --> 100
[36029ms] [CONNMGR] ConnectionLevel changed from 100 to 5
[36032ms] [ModemFinder] Starting modem search
[36075ms] [SNIFFER] received GET_SW.CNF
[36075ms] [SNIFFER] For 34:E8:94:07:A4:FB the software version is MAC-QCA7420-1.3.0.2134-00-20151212-CS 
[36557ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
[36594ms] [ModemFinder] Number of modems:1
[36631ms] [CONNMGR] ConnectionLevel changed from 5 to 10
[36636ms] [PEVSLAC] from 0 entering 2
[36679ms] [PEVSLAC] Checkpoint100: Sending SLAC_PARAM.REQ...
[36680ms] [PEVSLAC] from 2 entering 4
[37660ms] [CONNMGR] 9 133 0 0 0 0 0  --> 10
[37662ms] [PEVSLAC] Timeout while waiting for SLAC_PARAM.CNF
[37662ms] [PEVSLAC] from 4 entering 0
[37696ms] [PEVSLAC] from 0 entering 2
[37731ms] [PEVSLAC] Checkpoint100: Sending SLAC_PARAM.REQ...
[37732ms] [PEVSLAC] from 2 entering 4
[38711ms] [PEVSLAC] Timeout while waiting for SLAC_PARAM.CNF
[38711ms] [PEVSLAC] from 4 entering 0
[38742ms] [CONNMGR] 9 100 0 0 0 0 0  --> 10
[38746ms] [PEVSLAC] from 0 entering 2
[38783ms] [PEVSLAC] Checkpoint100: Sending SLAC_PARAM.REQ...
[38783ms] [PEVSLAC] from 2 entering 4
[39761ms] [PEVSLAC] Timeout while waiting for SLAC_PARAM.CNF
[39761ms] [PEVSLAC] from 4 entering 0
[39796ms] [PEVSLAC] from 0 entering 2
[39827ms] [CONNMGR] 9 67 0 0 0 0 0  --> 10
[39835ms] [PEVSLAC] Checkpoint100: Sending SLAC_PARAM.REQ...
[39835ms] [PEVSLAC] from 2 entering 4
[40812ms] [PEVSLAC] Timeout while waiting for SLAC_PARAM.CNF
[40813ms] [PEVSLAC] from 4 entering 0
[40847ms] [PEVSLAC] from 0 entering 2
[40886ms] [PEVSLAC] Checkpoint100: Sending SLAC_PARAM.REQ...
[40886ms] [PEVSLAC] from 2 entering 4
[40917ms] [CONNMGR] 9 34 0 0 0 0 0  --> 10
[41874ms] [PEVSLAC] Timeout while waiting for SLAC_PARAM.CNF
[41875ms] [PEVSLAC] from 4 entering 0
[41913ms] [PEVSLAC] from 0 entering 2
[41952ms] [PEVSLAC] Checkpoint100: Sending SLAC_PARAM.REQ...
[41953ms] [PEVSLAC] from 2 entering 4
[42017ms] [CONNMGR] 9 1 0 0 0 0 0  --> 10
[42051ms] [CONNMGR] ConnectionLevel changed from 10 to 5
[42055ms] [ModemFinder] Starting modem search
[42060ms] [PEVSLAC] from 4 entering 0
[42091ms] [SNIFFER] received GET_SW.CNF
[42092ms] [SNIFFER] For 34:E8:94:07:A4:FB the software version is MAC-QCA7420-1.3.0.2134-00-20151212-CS 
[42606ms] [ModemFinder] Number of modems:1
[42649ms] [CONNMGR] ConnectionLevel changed from 5 to 10
[42660ms] [PEVSLAC] from 0 entering 2
[42704ms] [PEVSLAC] Checkpoint100: Sending SLAC_PARAM.REQ...
[42704ms] [PEVSLAC] from 2 entering 4
[43172ms] [CONNMGR] 9 149 0 0 0 0 0  --> 10
[43731ms] [PEVSLAC] Timeout while waiting for SLAC_PARAM.CNF
[43732ms] [PEVSLAC] from 4 entering 0
[43766ms] [PEVSLAC] from 0 entering 2
[43807ms] [PEVSLAC] Checkpoint100: Sending SLAC_PARAM.REQ...
[43807ms] [PEVSLAC] from 2 entering 4
user action space
stopping the charge process
[44313ms] [CONNMGR] 9 116 0 0 0 0 0  --> 10
[44826ms] [PEVSLAC] Timeout while waiting for SLAC_PARAM.CNF
[44826ms] [PEVSLAC] from 4 entering 0
[44861ms] [PEVSLAC] from 0 entering 2
user action space
stopping the charge process
[44904ms] [PEVSLAC] Checkpoint100: Sending SLAC_PARAM.REQ...
[44904ms] [PEVSLAC] from 2 entering 4
[45441ms] [CONNMGR] 9 83 0 0 0 0 0  --> 10
user action space
stopping the charge process
[45924ms] [PEVSLAC] Timeout while waiting for SLAC_PARAM.CNF
[45924ms] [PEVSLAC] from 4 entering 0
[45958ms] [PEVSLAC] from 0 entering 2
[45996ms] [PEVSLAC] Checkpoint100: Sending SLAC_PARAM.REQ...
[45997ms] [PEVSLAC] from 2 entering 4
user action space
stopping the charge process
[46554ms] [CONNMGR] 9 50 0 0 0 0 0  --> 10
[46982ms] [PEVSLAC] Timeout while waiting for SLAC_PARAM.CNF
[46982ms] [PEVSLAC] from 4 entering 0
[47019ms] [PEVSLAC] from 0 entering 2
[47058ms] [PEVSLAC] Checkpoint100: Sending SLAC_PARAM.REQ...
[47059ms] [PEVSLAC] from 2 entering 4
[47644ms] [CONNMGR] 9 17 0 0 0 0 0  --> 10
[48042ms] [PEVSLAC] Timeout while waiting for SLAC_PARAM.CNF
[48043ms] [PEVSLAC] from 4 entering 0
[48076ms] [PEVSLAC] from 0 entering 2
[48113ms] [PEVSLAC] Checkpoint100: Sending SLAC_PARAM.REQ...
[48113ms] [PEVSLAC] from 2 entering 4
[48213ms] [CONNMGR] ConnectionLevel changed from 10 to 5
[48215ms] [ModemFinder] Starting modem search
[48220ms] [PEVSLAC] from 4 entering 0
[48251ms] [SNIFFER] received GET_SW.CNF
[48252ms] [SNIFFER] For 34:E8:94:07:A4:FB the software version is MAC-QCA7420-1.3.0.2134-00-20151212-CS 
[48745ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
[48747ms] [ModemFinder] Number of modems:1
[48786ms] [CONNMGR] ConnectionLevel changed from 5 to 10
[48793ms] [PEVSLAC] from 0 entering 2
[48830ms] [PEVSLAC] Checkpoint100: Sending SLAC_PARAM.REQ...
[48831ms] [PEVSLAC] from 2 entering 4
user action X
user action Shift_L
[49818ms] [PEVSLAC] Timeout while waiting for SLAC_PARAM.CNF
[49819ms] [PEVSLAC] from 4 entering 0
[49853ms] [CONNMGR] 9 132 0 0 0 0 0  --> 10
[49857ms] [PEVSLAC] from 0 entering 2
[49893ms] [PEVSLAC] Checkpoint100: Sending SLAC_PARAM.REQ...
[49893ms] [PEVSLAC] from 2 entering 4
user action X
user action Shift_L
user action x

EVSE modem info after flashing to EVSE.pib

Code: Select all

pi@raspberrypi:~ $ sudo plctool -i eth0 -I
	PIB 0-0 8836 bytes
	MAC 34:E8:94:07:86:78
	DAK D8:94:DD:71:42:68:8B:55:38:22:1E:16:2E:EF:5F:16
	NMK 77:77:B7:5A: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

And EVSE modem info after pressing reset button.

Code: Select all

pi@raspberrypi:~ $ sudo plctool -i eth0 -I
	PIB 0-0 8836 bytes
	MAC 34:E8:94:07:86:78
	DAK D8:94:DD:71:42:68:8B:55:38:22:1E:16:2E:EF:5F:16
	NMK 77:77:94:B3: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 tpver_401003_171219_901
	CCo Auto
	MDU N/A

PEV modem info after flashing to PEV.pib

Code: Select all

pi@raspberrypi:~ $ sudo plctool -i eth0 -I
	PIB 0-0 8836 bytes
	MAC 34:E8:94:07:A4:FB
	DAK 38:31:97:C3:A6:E0:72:09:D5:C8:7E:3A:B3:52:82:BF
	NMK 03:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F:10
	NID 01:02:9D:A9:CA:AE:07
	Security level 0
	NET Qualcomm Atheros Enabled Network
	MFG tpver_401003_171219_901
	USR PEV
	CCo Never
	MDU N/A

And PEV modem info after pressing reset button.

Code: Select all

pi@raspberrypi:~/myprogs/pyPlc $ sudo plctool -i eth0 -I
	PIB 0-0 8836 bytes
	MAC 34:E8:94:07:A4:FB
	DAK 38:31:97:C3:A6:E0:72:09:D5:C8:7E:3A:B3:52:82:BF
	NMK 50:D3:E4:93:3F:85:5B:70:40:78:4D:F8:15:AA:8D:B7 (HomePlugAV)
	NID B0:F2:E6:95:66:6B:03
	Security level 0
	NET Qualcomm Atheros Enabled Network
	MFG tpver_401003_171219_901
	USR tpver_401003_171219_901
	CCo Auto
	MDU N/A

[uhi22]

I never used the button. On my original housing, the button is labelled "Pair", not "Reset". So it seems to set the CentralCoordinator setting to "Auto". This is not what we need here. Just flash the correct PIB on the correct adaptor and do NOT use the button at all. The expected behaviour is:
- PEV has CCo = Never
- EVSE has CCo = Always
These settings are done with downloading the correct PIB. Not with the button.

[p477d343]

I never used the button. On my original housing, the button is labelled "Pair", not "Reset". So it seems to set the CentralCoordinator setting to "Auto". This is not what we need here. Just flash the correct PIB on the correct adaptor and do NOT use the button at all. The expected behaviour is:
- PEV has CCo = Never
- EVSE has CCo = Always
These settings are done with downloading the correct PIB. Not with the button.

Hello, I am now sucessfully connect miniEVSE and miniPEV(modem only), is it possible that I use miniEVSE connected to real EV and miniPEV(modem only) connect to the real CCS on the same wire, but CP, PP, PE are both connected to each machine. And start to negotiate at the same time. Will the real CCS charging real EV? Without doing the PEV hardware part.

[uhi22]

Not sure what you intend to do. Two EVSEs on the same line will destroy the PWM duty and the 12V level. So the real car will not start the communication most likely. And the real charger will most likely detect wrong CP voltage levels and deny charging.

[p477d343]

Two EVSEs on the same line

What I mean is in a j1772 charging cable. The real car and EVSEs will connect N and L1 to send current and starting charging without real communication. And miniEVSE will connect to the real car via CP, PP, PE that I separate manually from the j1772 charging cable. And in the other side. The miniPEV(modem only) will connect to the real EVSE via other CP, PP, PE that I separate from the cable from other side.

So what I intend to do is to use miniPEV identity(EVCCID) that I customize myself to charge my real car(not the same identity in miniPEV).

[uhi22]

Like this?
realEVSE ---(CP1, PP1)----miniPEV----(Ethernet or WLAN or just nothing)---miniEVSE----(CP2, PP2)-----realPEV
realEVSE ---(N,PE,L1)--------------------------------------------------------------------------------------------------realPEV

For this to work, there are some preconditions to fulfull:
1. You are trying AC high level charging. From my experience, most of the cars and chargers do not support this, they use just the PWM for AC charging. So you need to make sure that your car and EVSE both support high level communication for AC.
2. The miniPEV must provide the CP resistors (2k7, 1k3 and diode, to convince the realEVSE to start any communication. (Or you are lucky and your realEVSE does not care for the resistance.) So the "modem only" approach for the miniPEV is most likely too minimal.
3. The pyPLC and OpenV2Gx is at the moment not prepared to support AC charging. This would need some extensions.

[p477d343]

For this to work, there are some preconditions to fulfull:
1. You are trying AC high level charging. From my experience, most of the cars and chargers do not support this, they use just the PWM for AC charging. So you need to make sure that your car and EVSE both support high level communication for AC.
2. The miniPEV must provide the CP resistors (2k7, 1k3 and diode, to convince the realEVSE to start any communication. (Or you are lucky and your realEVSE does not care for the resistance.) So the "modem only" approach for the miniPEV is most likely too minimal.
3. The pyPLC and OpenV2Gx is at the moment not prepared to support AC charging. This would need some extensions.

Assuming the 3 conditions to make this work is ignored. So right now. I am doing the cable wiring stuff. I find out the J1772 AC cable I bought last week has N, L1, PE, CP, CS (Control Status) on male side. So CS is as same as PP and control by the CP/PP button on the charger. Did I need to connect CP wire from the cable to my red female plug and CS or/and PE from the cable to my black female plug? Corresponding to miniEVSE's CP and PE plug.
In that case. How did I connect miniPEV to female plug wiring? The PP wire is empty on the cable. In order to connect miniPEV and female cable. Did the PE needs to be like Male cable side that has two wire to connect to the PE plug?

Male cable side.

Female cable side.

Like this?
realEVSE ---(CP1, PP1(or PE?))----miniPEV----(Ethernet or WLAN or just nothing)---miniEVSE----(CP2, PP2)-----realPEV
realEVSE ---(N,PE,L1)--------------------------------------------------------------------------------------------------realPEV

For this to work, there are some preconditions to fulfull:
1. You are trying AC high level charging. From my experience, most of the cars and chargers do not support this, they use just the PWM for AC charging. So you need to make sure that your car and EVSE both support high level communication for AC.
2. The miniPEV must provide the CP resistors (2k7, 1k3 and diode, to convince the realEVSE to start any communication. (Or you are lucky and your realEVSE does not care for the resistance.) So the "modem only" approach for the miniPEV is most likely too minimal.
3. The pyPLC and OpenV2Gx is at the moment not prepared to support AC charging. This would need some extensions.

So what if first 2 requirements are fulfilled. The 3 condition AC charging is still not support by the project itself. In that case, it means that I need to buy a CCS1 DC charging cable to achieve things that I want to do?

In DC case:
realEVSE ---(CP1, PP1(or PE?))----miniPEV----(Ethernet or WLAN or just nothing)---miniEVSE----(CP2, PP2)-----realPEV
realEVSE ---(N,DC+,DC-)--------------------------------------------------------------------------------------------------realPEV

[uhi22]

Not sure what you want to do. It sounds like a man-in-the-middle setup, where you route all communication via miniPEV and miniEVSE, and connect the power pins directly from the realEV to the realEVSE.
You need to decide whether you want to use this for AC charging or DC charging. Mixing AC and DC does not work physically. So if you want to go the DC way, you need a DC inlet that connects to the real DC EVSE, and you needs a DC plug that plugs into your DC EV inlet.
If you want to go the AC way, you need to extend the state machines and the exi decoder to support the AC specific things, and you need to have an EV and an EVSE which supports AC charging via high level communication.
There is a misunderstanding regarding the PP and PE I guess. The miniEVSE and miniPEV needs their ground tied to PE. This means, the PE (the green/yellow wire) needs to have a connection to the miniEVSE / miniPEV ground. The second 4mm socket of the miniEVSE/miniPEV is the CP, which carries the powerline communication, and ALSO carries the 12V PWM. And there is a third pin, the PP. This needs a 1k5 resistor to PE at the miniEVSE, and needs a pull-up to 5V on the miniPEV.

[p477d343]

Not sure what you want to do. It sounds like a man-in-the-middle setup, where you route all communication via miniPEV and miniEVSE, and connect the power pins directly from the realEV to the realEVSE.

Yes, we are conducting MITM attack testing on one of our country made EV to make sure its security issue. The goal is to use the legit EV's EVCCID to impersonate its identify, which leads to free charging on the attacker's EV.

You need to decide whether you want to use this for AC charging or DC charging. Mixing AC and DC does not work physically. So if you want to go the DC way, you need a DC inlet that connects to the real DC EVSE, and you needs a DC plug that plugs into your DC EV inlet.
If you want to go the AC way, you need to extend the state machines and the exi decoder to support the AC specific things, and you need to have an EV and an EVSE which supports AC charging via high level communication.

So I am not trying to mix AC and DC charging together. It's because I only have an AC plug right now. How can I start if I want to change state machines and the exi decoder to support AC high level charging? If not, does it mean DC charging is practically support by most of the EVs? Then I might have to buy another DC charging cable to do this.

There is a misunderstanding regarding the PP and PE I guess. The miniEVSE and miniPEV needs their ground tied to PE. This means, the PE (the green/yellow wire) needs to have a connection to the miniEVSE / miniPEV ground. The second 4mm socket of the miniEVSE/miniPEV is the CP, which carries the powerline communication, and ALSO carries the 12V PWM. And there is a third pin, the PP. This needs a 1k5 resistor to PE at the miniEVSE, and needs a pull-up to 5V on the miniPEV.

So it might look like this? Both miniPEV and miniEVSE needs to connect their PE wire to cable's PE socket(With origial green/yellow wire). And also the CP wire. And the PE pin need 1k5 resistor to PE on miniEVSE and 1k5 with 5V to PE on miniPEV?

AC charging
realEVSE ---(CP1, PP1(1K5 and 5V from PE), PE)----miniPEV----(Ethernet or WLAN)---miniEVSE----(CP2, PP2(1K5 from PE),PE)-----realPEV
realEVSE ---------------------------------------------------------------(N, PE,L1)----------------------------------------------------------------realPEV (AC Cable)

DC charging
realEVSE ---(CP1, PP1(1K5 and 5V from PE), PE)----miniPEV----(Ethernet or WLAN)---miniEVSE----(CP2, PP2(1K5 from PE),PE)-----realPEV
realEVSE ---------------------------------------------------------------(DC+, PE, DC-)----------------------------------------------------------------realPEV (AC Cable)

[tom91]

PP calcs are broken for some reason.

So the reported AdcProximityPilot updates but it does not change the resistance correctly. Code snippet shows comments for ppvariant 2 like:

Code: Select all

 /* Todo: verify on hardware */

EDIT

Code: Select all

U_meas = U_refAdc * temp/4095 * (47.0+47.0)/47.0; /* The measured voltage on the PP. In this case the ADC gets half the PP voltage. */

The math yields 4.79V

Code: Select all

if (U_meas>(U_pull-0.5))
    {
        /* The voltage on PP is quite high. We do not calculate the R, because this may lead to overflow. Just
           give a high resistance value. */
        R = 10000.0; /* ohms */
    }

And this is why it then fails to update. Upull = 5.0

EDIT 2:

Measure the voltage and it is 4.88V with the 680ohm resistance across it from the plug. I pull it out it goes to 12V. Will get on look at what is going on.

[johu]

It seems the cpu switches off the keep-on pin which has the secondary function of shorting the 12v pullup for wake up. Try supplying 1kHz to CP and check again

[tom91]

It seems the cpu switches off the keep-on pin which has the secondary function of shorting the 12v pullup for wake up. Try supplying 1kHz to CP and check again

Note the EVSE AC current limit filled in this is with an powered on granny lead and 12V into wake up line. Would a constant 12V in on the wake up cause issues?

EDIT:

I guess the wiki about the Wake-Up is not right saying you can have a constant signal.

EDIT 2:

As soon as wake up is not constant 12V this seems to be working better.

[tom91]

Doing more clean up in the AC charging statemachine, got it working again. Will do some clean up and push it to Git

Also going to add a "Stay Awake when there is CAN activity", particularly the idle messages from the VCU regarding the param enable

[tom91]

Button is now up too.

Button functions when AC charging:
1. force Idle state, thus unlocking (yes will look at the allowed to unlock state)
2. If plug is not removed after 10ish seconds restart charging

[uhi22]

Great to see the progress while johu and me just enjoying the summer:-) Maybe later johu can move the discussion into the better thread.

[tom91]

Great to see the progress while johu and me just enjoying the summer:-) Maybe later johu can move the discussion into the better thread.

Have a great summer, this is the beauty of opensource/collabs.

https://github.com/uhi22/ccs32clara/pull/31

I like the compiling checker, did not realise I had new parameters for diagnostics added in param.h

[tom91]

https://github.com/uhi22/ccs32clara/pull/32

Added CAN stay wake, if the CAN watchdog nearly runs out it allows shut down otherwise stay awake.

Due to the wake up methods this will be required for proper functioning when not trying to charge. The VCU (in my applications) will want to know nothing is plugged in and if the charge port controller goes to sleep it will get upset as it is not told we are okay to drive. The VCU cannot know if for example the Focci power supply is down but something is plugged in or CAN is not working.

[tom91]

Got Focci playing along with the Zombieverter. Working out some clean up and more testing before doing a push for that.

On the Focci side its will mainly be how it reports it state in the new param PORTSTAT. Currently no correct implementation that will allow DCFC need to evaluate where in the state machine it should go to 4=ChargingDC, will probally be once TCP is established or after discovery request.



Idea with the Zombie implementation is that the CAN config is one click via the Zombie interface. Rest of hardware config and testing of Focci needs doing via its own interface to keep things clean.

The behaviour of the Zombie controlling the BMW I3 Lim will be the same way it interacts with the Focci.

[johu]

I have added an MQTT backend to pyPLC.
We would now have the possibility to remove all custom hardware interface implementations from pyPLC and run them as a micro service instead. What do you think?

[uhi22]

Well, this would be a clean concept, but also would rise the entry hurdle. The user needs to install an mqtt broker, the related python lib, run multiple services, make sure that each of them restarts if it crashed. Possible, but maybe a lot of headache for beginners.

[lewurm]

Can this MQTT backend be optional? I think it would be great to have it for future development (e.g. to communicate with the battery_emulator), but as uhi22 said, probably too intrusive to force it on everyone.

[johu]

Yes right now MQTT libs are only loaded when it is enabled in the config.

Apart from that it's not much drama

Code: Select all

apt install mosquitto mosquitto-clients python3-paho-mqtt