Closed Livante closed 9 months ago
Hey @Livante,
thank you using the issue template. There may be several problems and I need some more information in order to help you. Can you please create wireshark log of the communication (please refer to the wiki). because the puttylog does not has the information I need.
I also have questions regarding your setup. It is looking like this, correct?
FreeV2G <-- ETH --> Whitebeet <-- PLC --> Development Board <-- ??? --> Diagnostic Tool
Thank you, lho
Hello,
Yes. The setup is connected in the following order:
FreeV2G <-- ETH --> Whitebeet <-- PLC --> Development Board <-- CANCase --> Diagnostic Tool
The Codico is connected on the J15 with Eth cable is in an ethernet USB adaptor and connected to the PC. J11 UART is connected with the PC and J12 is also connected with the PC. Also CP +PE is connected to the Codico
Hello @Livante,
ok the setup is ok for me! Please create the log files I asked for, so I can have a closer look into this!
Best regards, lho
Hello,
Attached you can find the log from the Wireshark. codicoLog.csv The second log is together with the diagnostic tool from the target. codicolog2.csv
I hope that this is enough for you. If you need any other logs please let me know. Best regards, Levente Gergelyfi
Hey @Livante,
thank you for the logs, but unfortunately this log file is not usable for me. I need the complete pcap/pcapng file in order to inspect the data packets.
Please check https://github.com/Sevenstax/FreeV2G/wiki/guide-creating-log-files for how to create the log files.
Best regards, lho
Here is the new log. I hope that this will be helpful for you. I archived the file for you. CodicoTargetIsNotPerformingSlacHandshake.zip
Yes, almost. Please also enable the port mirror by adding the '-p' parameter.
Best regards, lho
Where I have to add the '-p' parameter?
I am sorry, when starting FreeV2G.
CodicoTargetIsNotPerformingSlacHandshake 1.zip I added the '-p' parameter.
Hey @Livante,
yes, the port mirror is on now, still now SLAC messages. Normally the application waits for state B and then starts the slac matchign process, here it is the other way around. This should be no issue, because there is enough time for receiving SLAC requests. I do not see any SLAC messages and I think your PEV does not send out SLAC param requests. Please double check of the SLAC messages are send out!
Best regards, lho
Hello again,
I checked with the team. It seems that our development board is not changing any signal voltages from 12V to 9V to change from State A to State B.
As we already removed from the first part as described in the first message the 8V checker to see if the Vehicle is connected, can you show us how to remove the state checker from the Python code?
In this case we will suppose that the State is equal to state B in every case.
Best regards, Levente Gergelyfi
Hey @Livante,
thank you for double checking.
When FreeV2G/EVSE reads state B it is setting the PWM duty cycle to 5% and starts listening for SLAC messages. When teh PEV reads the 5% duty cycle it should start the SLAC process.
You by-passed the state check in FreeV2G and hardcoded it to always be connected. This is ok, I also use it this way sometimes. I think problem is not in the EVSE but in the PEV side. Although connected and PWM duty cycle at 5%, the PEV does not send out the SLAC parameter requests (from what I see in the logfiles). Are you sure the PEV (development board) does actually starts SLAC? You can start SLAC matching before starting FreeV2G, there should be no problem.
Or did I misunderstood your setup again? Is the development board doing the SLAC process, or do you let it join a predefined SLAC network?
Best regards, lho
Can you tell me if the setup is complete on the Codico board?
Yes, this setup is complete!
How can we remove from the Python script the state checker? On our target it is highly possible that the CP+PE is not having the right Voltage value. In this case with the current Python script we cannot reach the folliwing part:
SLAC matching successful Set V2G mode to EVSE Start V2G "Session started" received Protocol: 2 Session ID: f3976451aedd64ce EVCC ID: 000101637730 "Request EVSE ID" received Set EVSE ID: DEABCE0000101 "Request Authorization" received Authorize the vehicle? Type "yes" or "no" in the next 59s:
Hey @Livante,
you already disabled the state checking by setting cp_state = 1
in your imaged you send me:
Because you did this and the PEV is charge of initiating the communication I think the problem is on the PEV side of the setup and not in the Whitebeet/FreeV2G side of the setup. The PEV needs to start SLAC probing as soon as it sees 5% duty cycle or (in your case) immediately when not PWM detection shall be used.
Please double check, that the PEV actually is (capable of) sending out SLAC parameter requests!
Thank you and best regards, lho
Is there any chance that we need to move any Jumper on the board?
We unmounted the plastic cover from the Codico board and found 2 other jumpers which are responsible for the PWM and PLC communication. We tried with every possible combination and nothing else is happening.
Maybe there are other jumpers that needs to be changed to work properly?
Hey @Livante,
no. Like I said, the EVSE setup is fine. It is not the problem of the EVSE, the PEV needs to start the SLAC probing. Are you 100% sure the PEV actually sends out the SLAC parameter requests? If it does not send out the requests although you are disabled the CP state check in FreeV2G EVSE there is nothing else the EVSE can do, the PEV is in charge of initiating the communication.
To test this setup further you might use the open-plc-utils. It contains a utility called 'evse' and you can do SLAC matching with it.
Please Note: Issues and support for open-plc-utils is not in scope of this issue tracker
If you start the utility and give it the interface name where the Whitbeet is connected to it will use the qca700x on the Whitebeet to listen for SLAC requests. So when the Whitebeet is connected to eth42
you start the utility like so:
evse -i eth42
Note: Do not start FreeV2G in this scenario
You can then start SLAC probing of your PEV. If the EVSE still sees no SLAC requests, the problem lies in the PEV. I am quite sure the problem is related to the PEV, because there are no SLAC messages in the log files. When you set the PEV to ignore CP states and start SLAC probing you should see SLAC parameter requests in the log files regardless of the configuration of FreeV2G.
If the "evse" utility works there is a problem with the FreeV2G setup. Maybe you can also create a patch file, so I can see your changes? Please go into your local FreeV2G copy and run
git diff > issue_276.patch
Please send me the issue_276.patch
file.
Thank you and best regards, lho
Another question. What is the difference between the EIM and PNC software type?
Hey, EIM stands for "External Identification Means". This mode is used e.g. when user authenticates for charging with a NFC card. PnC stands for "Plug and Charge". In this mode the charging is authenticated via certificates. Also the traffic is encrypted with TLS for PnC, for EIM encryption it is optional.
The difference between SW versions is that the PnC labeled software has added PnC functionality. PnC labeled software can also use EIM, please make sure to always use latest software!
Best regards, lho
Hello! I want to thank you for the support you gave to us. We finally were able to make the Codico board to communicate with our target. Thank you also for confirming us that the by-pass for the voltage checker(EV Connection). This way everything will work more smooth.
Have a nice day, Levente Gergelyfi
Hey @Livante,
thank you for the feedback, highly appreciated!
Good luck with your further development!
Best regads, lho
Your Setup Platform: EVSE Firmware Version: i.e. V02_01_00 Host Controller Interface: Ethernet Host: FreeV2G (EV_v2.1.0.1)
Describe the bug We are trying to start the slac between codico a development board that has the SLAC protocol implemented. we can see that, after a start request from a diagnostic tool, the start function from slac is reached(Breakpoint is hit), but the protocol is hanging somewhere.
we have set the correct MAC address like below:
With the diagnostic tool with we are using we tried to set the MAC address for the development Board in 3 different manners:
Random MAC Address MAC Address which is present in the picture from the terminal MAC Address which is present in the picture from the terminal + 2 (Whitebeet MAC Addr) We changed the one of your Python script as we saw that for the connection we need to have 8V on the CP+PE, but when we measured them we only had 0.43V, so now the Voltage check is ignored We also used Putty to see all the transmitted messages and we see that PARM.CNF is missing. I also attach here the log file:
To Reproduce Write the Firmware on the development board, ensure that the board is up and running. Download the QCA on the board, set the correct MAC Address. After these preconditons are completed we start the FreeV2G, first we use the activate.bat script from the cmd, and we use the command as it can be seen in the next picture: When we see the Start SLAC matching message on the terminal we start the Initialization process with the Diagnostic tool and right after that we are starting the SLAC matching RID(Routine control).
Expected behavior SLAC matching successful Set V2G mode to EVSE Start V2G "Session started" received Protocol: 2 Session ID: f3976451aedd64ce EVCC ID: 000101637730 "Request EVSE ID" received Set EVSE ID: DEABCE0000101 "Request Authorization" received Authorize the vehicle? Type "yes" or "no" in the next 59s:
Logs In the logs we saw that PARM.CNF is missing. All the necessary information is in the Putty log. puttylog.txt
Additional context Please try to reach us ASAP as we are in time crisis with the project.