p477d343 wrote: ↑Wed Jun 19, 2024 10:25 am
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:
Open-Plc-Utils can be used to flash firmware on modules with an AR7420. This must first be downloaded, compiled and then installed.
Find the mac address of the PLC module: plcstat -t -i eth0
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>
Copy over the PIB Block: cp original.pib evse.pib
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
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>
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.
Timvb wrote: ↑Wed Jun 19, 2024 11:20 am
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
Re: Open source CCS using AR7420
Posted: Thu Jul 18, 2024 11:09 am
by 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
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:
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
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
Re: Open source CCS using AR7420
Posted: Mon Jul 22, 2024 4:06 pm
by 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.
Re: Open source CCS using AR7420
Posted: Tue Jul 23, 2024 8:04 am
by p477d343
uhi22 wrote: ↑Mon Jul 22, 2024 4:06 pm
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.
Re: Open source CCS using AR7420
Posted: Tue Jul 23, 2024 4:50 pm
by 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.
Re: Open source CCS using AR7420
Posted: Wed Jul 24, 2024 5:12 pm
by p477d343
uhi22 wrote: ↑Tue Jul 23, 2024 4:50 pm
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).
Re: Open source CCS using AR7420
Posted: Wed Jul 24, 2024 6:29 pm
by 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.
Re: Open source CCS using AR7420
Posted: Mon Aug 12, 2024 10:48 am
by p477d343
uhi22 wrote: ↑Wed Jul 24, 2024 6:29 pm
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.
uhi22 wrote: ↑Wed Jul 24, 2024 6:29 pm
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
Re: Open source CCS using AR7420
Posted: Mon Aug 12, 2024 12:19 pm
by 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.
Re: Open source CCS using AR7420
Posted: Tue Aug 13, 2024 7:36 am
by p477d343
uhi22 wrote: ↑Mon Aug 12, 2024 12:19 pm
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.
uhi22 wrote: ↑Mon Aug 12, 2024 12:19 pm
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.
uhi22 wrote: ↑Mon Aug 12, 2024 12:19 pm
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)
Re: Open source CCS using AR7420
Posted: Wed Aug 14, 2024 4:48 pm
by 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:
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.
Re: Open source CCS using AR7420
Posted: Wed Aug 14, 2024 6:20 pm
by 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
Re: Open source CCS using AR7420
Posted: Wed Aug 14, 2024 6:37 pm
by tom91
johu wrote: ↑Wed Aug 14, 2024 6:20 pm
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.
Re: Open source CCS using AR7420
Posted: Thu Aug 15, 2024 12:19 pm
by 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
Re: Open source CCS using AR7420
Posted: Thu Aug 15, 2024 12:49 pm
by 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
Re: Open source CCS using AR7420
Posted: Thu Aug 15, 2024 1:02 pm
by 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.
Re: Open source CCS using AR7420
Posted: Thu Aug 15, 2024 1:09 pm
by tom91
uhi22 wrote: ↑Thu Aug 15, 2024 1:02 pm
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.
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.
Re: Open source CCS using AR7420
Posted: Thu Aug 15, 2024 2:48 pm
by 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.
Re: Open source CCS using AR7420
Posted: Mon Nov 04, 2024 10:30 pm
by 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?
Re: Open source CCS using AR7420
Posted: Tue Nov 05, 2024 6:50 am
by 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.
Re: Open source CCS using AR7420
Posted: Tue Nov 05, 2024 3:34 pm
by 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.
Re: Open source CCS using AR7420
Posted: Tue Nov 05, 2024 4:42 pm
by johu
Yes right now MQTT libs are only loaded when it is enabled in the config.