Closed lho-stx closed 1 year ago
lho-stx
commented
2 years ago Hey @IonelFratila,
i have a hard time to reproduce your setup. I kindly ask you to provide the debug log of WB of a session, where a sequence error occurs, SLAC service is restarted, SLAC matching is ok, but the EV does not start with service discovery.
As we have internal events this week, i will get back to you in the beginning of next week.
Thank you, lho
IonelFratila
commented
2 years ago Hi @lho-stx , It was quite difficult to find a USB-TTL interface capable to communicate at 1Mbps (my WB module transmits data on serial debug port at 1Mbps, even in DataSheet 115200bps is specifid for EVSE!?). Here are the log files for a charging session where a "sequence error" occurs (please notice again that I consider this "sequence error" to be absolutely normal during real operation), SLAC service is restarted, SLAC matching is OK and nothing happens further. The file 20220715_WB.txt is captured on the serial debug port of WB module, and 20220715_Host.txt is the log file for the comunication between Host Controller and WB module (I tried to have the two files sincronized, but there is a delay of about 0.033 seconds in the WB log file). As I said, I simulated a CP voltage reading error so that CPState = B is detected (at timestamp [0 00:01:36.0830] in the Host file). 20220715_WB.txt 20220715_Host.txt
Also I have one remark regarding the logs: It seems that WB sends response messages to EV after the Performance timeout is reached. According to the standards (both DIN and ISO), the performance criteria is met only if the response messages are received by EV before Performance Timeout is reached, so I think that WB should send answer messages earlier (for example during Cable Check, WB sends response messages at 1550ms, but EV waits for an answer up to 1500ms). This issue is the same in all stages of the charging process. This is not triggering an error from EV, but the performance criteria is not met.
Hope this logs will help you to solve the problem. Thank you, Ionel Fratila
lho-stx
commented
2 years ago Hey @IonelFratila,
thank you for the decent log files, I highly appreciate your effort! I will have a look and will come back to you when i have news. I also have a look into the timing issues.
Regarding the documentation: This is an error on our side. I apologize for the inconvenience! Indeed, both PEV and EVSE are using 1 Mbps, not 115200 Baud.
Nevertheless, actually there is no need for an external USB-TTL Interface. There is an USB-C connector which is labeld as J11 / UART on the Whitebeet, which is connected to an USB-TTL interface. Therefore the debug logs can be accessed via this USB-C connector.
Thank you, lho
lho-stx
commented
2 years ago Hey @IonelFratila,
due to illness i was not able to work on this, but i am back at the office and did not forget your issue!
Thank you for your patience, lho
IonelFratila
commented
2 years ago Hi @lho-stx , Please tell me if you have some conclusions about the log files I have sent. Thank You, Ionel Fratila
lho-stx
commented
2 years ago Hey @IonelFratila ,
from the files i can not see what the problem is, but we will fix the problem or find a workaround. We are a short staffed at the moment due to illness and vacation. Next week colleagues will return and I we will look into this issue.
I will reach out, when i have any news.
Best regards, lho
IonelFratila
commented
2 years ago Hi @lho-stx , Thanks for the good news about the solution to the problem. I hope it will solve this issue. However, given that the problem is quite old and that this is the only problem preventing me from finalizing the host controller software, please let me know if you have an estimate (at least rough) of the schedule for the next software version release. Thank You, Ionel Fratila
lho-stx
commented
2 years ago Hey @IonelFratila,
We are just looking into this. Tomorrow I can give you an estimation, hopefully!
Best regards, lho
jpo-stx
commented
2 years ago Hello @IonelFratila ,
there seems to be nothing wrong in the communication, EV and EVSE do SLAC matching and the EV assigns itself an IPv6 address. Therefore, it should be able to send an SECCDP Request next to acquire the details for the TCP connection.
My guess is that the EV detected that there was something strange happening on the CP (statechange to state B during charging) and will not continue to charge.
BR Jan
IonelFratila
commented
2 years ago Hi @jpo-stx , @lho-stx ,
First regarding your questions: If you remember, the last time I presented in detail the test I did was on June 15 this year, in issue https://github.com/Sevenstax/FreeV2G/issues/61#issue-1222881874. Also there we had detailed discussions about V2G session ending with sequence error and changing NID and NMK parameters at SLAC Matching success.
1.There is no message or any other indication on EV, except for the lamp near the charging connector: the lamp lights up green during charging, lights up yellow when charging stops (with sequence error), stays lit yellow until the SLAC Matching process is restarted and successfully completed, after which it lights up red. After that, EV keeps the connector latched for another 15 seconds, after which it is released.
2.As for whitebeet reseting, I would have to modify the host controller software and I can't say now how complicated that would be. I am already restarting the SLAC and V2G services to try to resume communication with EV. Maybe you can explain to me what the complete reset of the module and reinitialization of the CP service would solve additionally.
3.As I explained in issue https://github.com/Sevenstax/FreeV2G/issues/61#issuecomment-1156418243, I did not make the EV to set CPState=B, but instead I simulated to the EVSE a transition to state B by briefly inserting an additional resistance in the CP circuit (as if the EV had opened S2) . This situation can happen at any time in reality, if the total resistance of the CP circuit (between Whitebeet and EV) is close to the upper limit, so that a short disturbance appearing on the CP makes the Whitebeet to detect a higher voltage value (above the threshold corresponding to the CPState=B). So nothing abnormal so far. To be noticed, I started this test because I have encountered in reality situations where the EV asks to stop the V2G communication session apparently for no reason, and the charging process could not be resumed. This is what happens as a result of the simulation:
I have to remind you again about the NID and NMK parameters that the WB sends to the EV when the SLAC Matching process is successfully completed. I still believe that, according to the requirements of the standards, these parameters MUST remain unchanged until the EV is disconnected, which WB does not respect. Since these parameters change at SLAC Matching confirmation, EV does not continue communication with EVSE (it does not know if it communicates with the same EVSE to which it was and is still connected).
To confirm this, I did a new simulation: - when the sequence error occurs, while CPState=F is being transmitted to EV, I briefly disconnected the PP signal from the connector inserted in the EV. In this way EV saw that it was disconnected from EVSE (even if at the same time EVSE did not detect CPState=A). At next successful completion of the SLAC Matching process (with different NID and NMK, no changes are made on EVSE - WB side), EV now continues normal communication and charging process. So my conclusion is that EV does not accept changed NID and NMK unless it is disconnected from EVSE.
Regarding NID and NMK change, there are some inconsistencies in the arguments sent by you on June 21 (see issue 61), which I did not comment on at that time: _"Requirement [V2G2-717] in the ISO 15118-2 states, that the EVCC shall terminate the Data-Link (with a D-LINKTERMINATE.REQ) after receiving SessionStopRes, when the EVCC send a SessionStopReq. (See [V2G2-724] for the SECC respectively) Therefore the NID and NMK are set to default values." a. According to [V2G2-717], indeed EVCC shall terminate the Data-Link after receiving SessionStopRes. But in our case WB does not send SessionStopRes (sequence error?!), so what EV should do ? According to [V2G2-720] it shall continue with [V2G2-014]. b. Similarly, [V2G2-724] states indeed that when receiving SessionStopReq with parameter "Terminate", "SECC shall terminate Data-Link after sending the message SessionStopRes". But WB does not send SessionStopRes message, so something is wrong for sure: it shall transmit first the message (which it does not) or it shall not terminate Data-Link (which is not possible)! What is your opinion? c. I've seen other discussions on this forum about resuming the upload process after suspension or other causes of interruption. Do you have any clear information if anyone managed to restore communication without disconnecting and reconnecting the EV? According to the standard, this problem with NID and NMK should affect any resumption of communication, regardless of the causes.
So these are my conclusions:
I hope this story will end soon, Thank you, Best Regards, Ionel Fratila
IonelFratila
commented
1 year ago Hi @jpo-stx , @lho-stx , Almost 2 months have passed since my last message, during which time I did not receive any reply or comment on the last remarks I sent on August 14. So allow me to ask again: do you have any estimate regarding the release of the next SW version for the White-Beet module (following v.2.0.1, which was released in April 2022)? Please let me know if you managed to fix the problem or to find a workaround, as you promised. Thank You, Ionel Fratila
ttu-stx
commented
1 year ago Hi @jpo-stx , @lho-stx , Almost 2 months have passed since my last message, during which time I did not receive any reply or comment on the last remarks I sent on August 14. So allow me to ask again: do you have any estimate regarding the release of the next SW version for the White-Beet module (following v.2.0.1, which was released in April 2022)? Please let me know if you managed to fix the problem or to find a workaround, as you promised. Thank You, Ionel Fratila
We have limited availibility this week due to illness and holidays. We will come back to you next week. BR
jpo-stx
commented
1 year ago Hello @IonelFratila ,
Regarding NID and NMK change, there are some inconsistencies in the arguments sent by you on June 21 (see issue https://github.com/Sevenstax/FreeV2G/issues/61#issuecomment-1161731680), which I did not comment on at that time: "Requirement [V2G2-717] in the ISO 15118-2 states, that the EVCC shall terminate the Data-Link (with a D-LINK_TERMINATE.REQ) after receiving SessionStopRes, when the EVCC send a SessionStopReq. (See [V2G2-724] for the SECC respectively) Therefore the NID and NMK are set to default values." a. According to [V2G2-717], indeed EVCC shall terminate the Data-Link after receiving SessionStopRes. But in our case WB does not send SessionStopRes (sequence error?!), so what EV should do ? According to [V2G2-720] it shall continue with [V2G2-014].
Correct, I was wrong. Whitebeet was expecting CurrentDemandReq or PowerDeliveryReq. What applies for the WB in this case is:
_[V2G2-538] The SECC shall respond with the corresponding response message containing a “ResponseCode = FAILED_SequenceError' within V2G_SECC_Msg_PerformanceTime according to Table 109, if request message was received that the SECC does not expect in the wait state.
[V2G2-539] After the SECC sent a "ResponseCode = FAILED" it shall terminate the communication by applying [V2G2-034].
[V2G2-034] The SECC shall terminate the TLS or TCP connection after stopping the V2G Communication Session.
This indicates that the data link terminate should be requested at the lower layer:
_[V2G3-M09-17] With receiving a D-LINK_TERMINATE.request from HLE, the communication node shall leave the logical network within TP_matchleave. All parameters related to the current link shall be set to the default value and shall change to the status “Unmatched”.
b. Similarly, [V2G2-724] states indeed that when receiving SessionStopReq with parameter "Terminate", "SECC shall terminate Data-Link after sending the message SessionStopRes". But WB does not send SessionStopRes message, so something is wrong for sure: it shall transmit first the message (which it does not) or it shall not terminate Data-Link (which is not possible)! What is your opinion?
WB is sending the SessionStopRes with response code FAILED_SequenceError because it is in the wait state "Wait for CurrentDemandReq or PowerDeliveryReq". As you can see in a. above, in the end it leads to the data link being terminated.
c. I've seen other discussions on this forum about resuming the upload process after suspension or other causes of interruption. Do you have any clear information if anyone managed to restore communication without disconnecting and reconnecting the EV? According to the standard, this problem with NID and NMK should affect any resumption of communication, regardless of the causes.
I think we first need to align on whether or not the NID and NMK should be reset in this case. The behavior of the WB is correct when you check the requirement from the specification listed above. The NID and NMK should only be reused when the data link was paused:
_[V2G3-M07-20] With receiving a D-LINKPAUSE.request, the EVSE shall switch to control pilot state X1 and may switch the low-layer communication module into low-power mode. The logical network parameter set shall be stored for continuing the data link after the sleeping phase.
This is only the case when the session was stopped gracefully with the "Pause" parameter in the SessionStopReq message.
So these are my conclusions: Even the requirements are that "All parameters related to the current link shall be set to the default value and shall change to the status “Unmatched”" when Data_Link is terminated, there are other requirements that especially require the NID and NMK parameters to remain unchanged until CPState=A is detected. CPState=E,F are used only by EV to determine Data_Link termination, in case of EVSE these states are not actually detected (are not determined by EV) but are determined by EVSE (EVSE even set CPState=F intentionally in order to resume the communication with the connected EV, so this cannot be a reason to reset NID and NMK). BTW, NID and NMK are parameters related to the current Data-Link, or are Network-related parameters and are not covered by [V2G3-M09-17] requirement?
There is a requirement that states that NMK is reset in case the data link terminates:
_[V2G3-A09-121] With receiving a D-LINKTERMINATE.request from HLE, the low-layer commu- nication module shall leave the logical network, reset the NMK, and switch to matching state “Unmatched”. The low-layer communciation module shall follow the Clause “Leaving an AVLN” defined in the [HPGP].
Once again, PLEASE modify WB firmware to keep NID and NMK unchanged until CPState=A is detected (even SLAC service is restarted). I'm pretty sure that this will solve the problem with the communication and charging resume.
We are still on this topic and are planning a test with a charging station and an EV, where we want to recreate your setup.
In the mean time I would propose that before you set the CP to 100% when you detect state change to B, try to inform the EV that it should stop charging by setting the EVSE status to "EVSE_Shutdown" or "EVSE_Malfunction" and use the message "Send Notification" (0x75) to send a stop charging notification. Try to stop the session on high level before stopping it on the low level. You can go to 100% if the EV is not acting accordingly
IonelFratila
commented
1 year ago Hi @jpo-stx , Please tell me if you have any update on the issue. Did you succeeded to test it on a EV? Can you give an estimate for the next SW update? Regarding the "EVSE_Shutdown" status or other stop charging notification to send, let me remind you that I do not want to stop the charging process, I want to continue charging after it is accidentally stopped by EV, without user intervention (without plugging the EV out and then plug in again).
Thank you, Ionel Fratila
jpo-stx
commented
1 year ago Hi @IonelFratila , have you tested what the EV does when you send the stop charging notification? Setting the duty cycle to 100% also indicates that the EV should stop charging.
jpo-stx
commented
1 year ago We had a test session last week, where we were able to reproduce the issue you had with the ID.4.
The vehicle wasn't starting the SLAC process without the whitebeet SLAC service being stopped and started again. And even stopping and starting the SLAC service did not lead to a V2G session. Here we also tried with the same credentials as in the previous session, which resulted in the same outcome.
When we reset the QCA the EV was starting the SLAC process, open a V2G session and started to charge. For the SLAC process new credentials were used.
So you should be able to do the same by restarting the whitebeet in this case.
We are currently working on a solution and make it available in the next firmware version. However, we do not have an exact date for the release.
IonelFratila
commented
1 year ago Hi @jpo-stx , Regarding the proposed workaround for restarting SLAC process when the charging process and the communication with EV is accidentally stopped:
You suggested that I should restart the WB module, but you did not mentioned how to do this. I supposed that a solution using HW reset is out of the question, even for a trial solution using this workaround (anyway I have no reset signal from my host controller to the WB module, I only have the Ethernet interface available on my module, as CODICO advised me since from the beginning of our development (2 years ago) that Eth it is the only available (and needed) interface.
I have struggled for the last 3 days to implement the WhiteBeet module software reset command (Restart System command 0x10:0x48) in my host controller software, but without success, at least for now. I've got all kind of errors after sending the restart command to the device, and after many working hours I have discovered now the WhiteBeet module behavior in this case, which is totally undocumented in the User Manual (and I think it is not as designed): -after issuing restart command (and accepted by the module) everything seems to work well (the module accepts and executes further commands), but after around 5 seconds from reset command the Eth interface of the module is deactivated and is reactivated after about 7 seconds from reset. Also the PWM output by the module after this 7 seconds interval is reset to 0%, regardless of the previous value of PWM set after restart (or even without a Set PWM command after restart). -after around 13 seconds from SW restart, WB module transmits an Interface Up status message (0x05:0x81) with parameter 0x00 -Because any Link Down on the Eth interface is monitored in my host controller application and causes the Eth interface and the WB module to be reset/reinitialized, all configuration commands sent to the WB module during this interval are lost. Even the correct PWM value is set again right after WB restart, after around 7 seconds PWM=0% is output until the next Set PWM command is issued. So I suppose I should wait at least 7 seconds (a huge time interval for reestablishing the communication with EV) after module restart and after that send all configuration command to module.
After clarifying this behavior of the module, I will now have to resume the implementation of the command to reset and reinitialize the module and test the entire workaround. We must not forget that the entire sequence of commands required to reset and reinitialize the module must be carried out when the accidental interruption of communication with the EV occurs, before the EV decide that the communication cannot be resumed, and under the conditions that the communication with the OCPP server is online and there is a charging transaction in progress, which must not be closed. So I hope to have a final conclusion regarding the proposed workaround in the next few days.
Questions: 1.Please confirm that you can reproduce the described module behavior after SW restart command. 2.This is the normal behavior after SW restart you intended? 3.Also please tell me if you have any remarks about the software reset behavior of the WB module, other that I have already discovered myself. 4.There is a maximum value of the software restart time, after which the module is fully functional again (and the desired PWM value can be set again)?
Thank you, Best Regards, Ionel Fratila
IonelFratila
commented
1 year ago Hi @jpo-stx , Again about the proposed workaround for restarting SLAC process when the charging process and the communication with EV is accidentally stopped: I have tried again to restart WhiteBeet module functionality using module software reset command (Restart System command 0x10:0x48), this time just with EV connected but without trying to start SLAC Matching and HLC communication with EV, just to see in more details how WB works after SW restart command. This is the log of the commands issued to module and the results obtained:
-here EV is connected, CPService started and CPState=B was reported [00:32.728] Tx: C493002150B5 143456789ABC 6003 00040009 C0284B0B0001 01FC C1 ;Set Validation (Enabled) command sent [00:32.728] Rx: 143456789ABC C493002150B5 6003 00040009 C0284B0B0001 00FD C1 ;Set Validation Response (OK)
[00:32.736] Tx: C493002150B5 143456789ABC 6003 00040009 C028420C0001 0105 C1 ;Start SLAC Service (EVSE Mode) [00:32.736] Rx: 143456789ABC C493002150B5 6003 00040009 C028420C0001 0006 C1 ;Start SLAC Service response (OK)
[00:32.744] Tx: C493002150B5 143456789ABC 6003 00040009 C027400D0001 0107 C1 ;V2G Service Set Mode (EVSE) [00:32.744] Rx: 143456789ABC C493002150B5 6003 00040009 C027400D0001 0008 C1 ;V2G Set Mode response (OK)
[00:32.752] Tx: C493002150B5 143456789ABC 6003 00040036 C027600E002E 0F2B34302A3132332A3435362A3030 3114524F2A454D472A453435422A313035303030303102000101000101010145 C1 ;V2G Set Configuration command [00:32.760] Rx: 143456789ABC C493002150B5 6003 00040009 C027600E0001 00E6 C1 ;V2G Se Configuration Response (OK)
[00:32.768] Tx: C493002150B5 143456789ABC 6003 00040020 C027620F0018 0200C80000010001F40030D4FE0032 030100010000040000CB C1 ;Set DC Charging Parameters command [00:32.768] Rx: 143456789ABC C493002150B5 6003 00040009 C027620F0001 00E3 C1 ;Set DC Charging Parameters Response (OK)
[00:32.776] Tx: C493002150B5 143456789ABC 6003 0004000C C02768100004 01E92700C7 C1 ;Set SDP config command [00:32.780] Rx: 143456789ABC C493002150B5 6003 00040009 C02768100001 00DC C1 ;Set SDP config Response (OK)
[00:32.784] Tx: C493002150B5 143456789ABC 6003 00040008 C0276A110000 DA C1 ;V2G Start Listen command [00:32.788] Rx: 143456789ABC C493002150B5 6003 00040009 C0276A110001 00D9 C1 ;V2G Start Listen Response (OK)
-here everything is set for starting SLAC Matching Process, but I skeep Start SLAC matching command (I don't want to start SLAC Matching, I only want to restart the module) [00:32.992] Tx: C493002150B5 143456789ABC 6003 0004000A C02944120002 0032C9 C1 ;Set PWM=5% command [00:32.996] Rx: 143456789ABC C493002150B5 6003 00040009 C02944120001 00FC C1 ;Set PWM=5% Response (OK)
[00:33.000] Tx: C493002150B5 143456789ABC 6003 0004000A C02944130002 03E80F C1 ;Set PWM=100% command [00:33.004] Rx: 143456789ABC C493002150B5 6003 00040009 C02944130001 00FB C1 ;Set PWM=100% Response (OK)
-after another 3.3 seconds restart the WB module [00:36.328] Tx: C493002150B5 143456789ABC 6003 00040008 C01048140000 11 C1 ;Restart System command issued [00:36.328] Rx: 143456789ABC C493002150B5 6003 00040009 C01048140001 0010 C1 ;Restart System Reponse (OK)
-right after Restart System command confirmed, check the communication synchronization with WB and restart CP Service [00:36.332] Tx: C493002150B5 143456789ABC 6003 00040008 C00E00150000 5A C1 ;PING message sent [00:36.332] Rx: 143456789ABC C493002150B5 6003 00040008 C00E01150000 59 C1 ;PING reply (OK)
[00:36.332] Tx: C493002150B5 143456789ABC 6003 00040008 C02941160000 FC C1 ;CP Service Get Mode command [00:36.336] Rx: 143456789ABC C493002150B5 6003 0004000A C02941160002 0001F9 C1 ;CP Service Get Mode Response (OK, EVSE)
[00:36.336] Tx: C493002150B5 143456789ABC 6003 00040008 C02942170000 FA C1 ;CP Service Start [00:36.340] Rx: 143456789ABC C493002150B5 6003 00040009 C02942170001 05F4 C1 ;CP Service Start Restart Response (Unexpected message, CP Service already started ?)
-set PWM=100% (back to the value before Restart System, even the module will output PWM=100% after restart, according to the User Manual) [00:36.340] Tx: C493002150B5 143456789ABC 6003 0004000A C02944180002 03E80A C1 ;Set PWM=100% command [00:36.340] Rx: 143456789ABC C493002150B5 6003 00040009 C02944180001 00F6 C1 ;Set PWM=100% Response (OK)
-after 8.4 seconds from module restart, restart Eth interface of the host Controller and check again module synchronization (I know now that there is a Link Down up to 7 seconds from Restart System!) [00:44.688] Tx: C493002150B5 143456789ABC 6003 00040008 C00E00000000 6F C1 ;first PING message sent
-No PING reply in 64ms, so retry!!! [00:44.752] Tx: C493002150B5 143456789ABC 6003 00040008 C00E00010000 6E C1 ;second PING message sent
[00:44.792] Rx: 143456789ABC C493002150B5 6003 00040008 C00E01000000 6E C1 ;first PING reply (OK) with 104ms latency!!!
[00:44.796] Rx: 8C00 4000C000 143456789ABC C493002150B5 6003 00040008 C00E01010000 6D C1 ;second PING reply (OK) with 44ms latency!!!
-PING replies with latency, so check again!!! [00:44.952] Tx: C493002150B5 143456789ABC 6003 00040008 C00E00020000 6D C1 ;third PING message sent [00:45.104] Rx: 143456789ABC C493002150B5 6003 00040008 C00E01020000 6C C1 ;third PING reply (OK) with 52ms latency!!!
-PING replies with latency, so check again!!! [00:45.156] Tx: C493002150B5 143456789ABC 6003 00040008 C00E00030000 6C C1 ;fourth PING message sent [00:45.288] Rx: 143456789ABC C493002150B5 93002150B5 60 C00E01030000 6B C1 ;fourth PING reply (OK) with 132ms latency!!!
-PING replies with latency, so check again!!! [00:45.360] Tx: C493002150B5 143456789ABC 6003 00040008 C00E00040000 6B C1 ;fifth PING message sent [00:45.512] Rx: 143456789ABC C493002150B5 6003 00040008 C00E01040000 6A C1 ;fifth PING reply (OK) with 152ms latency!!!
-PING replies with latency, so check again!!! [00:45.564] Tx: C493002150B5 143456789ABC 6003 00040008 C00E00050000 6A C1 ;sixth PING message sent [00:45.696] Rx: 143456789ABC C493002150B5 6003 00040008 C00E01050000 69 C1 ;sixth PING reply (OK) with 132ms latency!!!
-PING replies with latency (something is wrong ?!), so restart Eth interface of the host Controller and check again module synchronization!!! [00:45.824] Tx: C493002150B5 143456789ABC 6003 00040008 C00E00060000 69 C1 ;first PING (in second group) message sent [00:45.860] Rx: 143456789ABC C493002150B5 6003 00040008 C00E01060000 68 C1 ;first PING reply (OK) with 36ms latency!!!
-PING replies with latency, so check again!!! [00:46.028] Tx: C493002150B5 143456789ABC 6003 00040008 C00E00070000 68 C1 ;second PING (in second group) message sent [00:46.164] Rx: 143456789ABC C493002150B5 6003 00040008 C00E01070000 67 C1 ;second PING reply (OK) with 136ms latency!!!
-PING replies with latency, so check again!!! [00:46.232] Tx: C493002150B5 143456789ABC 6003 00040008 C00E00080000 67 C1 ;third PING (in second group) message sent [00:46.384] Rx: 143456789ABC C493002150B5 6003 00040008 C00E01080000 66 C1 ;third PING reply (OK) with 152ms latency!!!
[00:46.436] Tx: C493002150B5 143456789ABC 6003 00040008 C00E00090000 66 C1 ;fourth PING (in second group) message sent [00:46.436] Rx: 143456789ABC C493002150B5 6003 00040008 C00E01090000 65 C1 ;fourth PING reply (OK) with 0ms latency!!!
-so here WB module starts to reply PINGs with no latency (10.1 seconds from Restart System command) -now check again if CP Service is started [00:46.440] Tx: C493002150B5 143456789ABC 6003 00040008 C029410A0000 09 C1 ;CP Service Get Mode command sent [00:46.440] Rx: 143456789ABC C493002150B5 6003 00040009 C029410A0001 FF08 C1 ;CP Service Get Mode Response (Internal Error!!!)
-cannot read CP Service Mode, so set again! [00:46.444] Tx: C493002150B5 143456789ABC 6003 00040009 C029400B0001 0107 C1 ;CP Service Set Mode (EVSE) command sent [00:46.448] Rx: 143456789ABC C493002150B5 6003 00040009 C029400B0001 0008 C1 ;CP Service Set Mode Response (OK) -the command is accepted, so CP Service was indeed stopped (why???), so try to restart CP Service [00:46.448] Tx: C493002150B5 143456789ABC 6003 00040008 C029420C0000 06 C1 ;CP Service Start command sent [00:46.452] Rx: 143456789ABC C493002150B5 6003 00040009 C029420C0001 0005 C1 ;CP Service Start Response (OK)
-set PWM=0% [00:46.452] Tx: C493002150B5 143456789ABC 6003 0004000A C029440D0002 000001 C1 ;Set PWM=0% command sent [00:46.456] Rx: 143456789ABC C493002150B5 6003 00040009 C029440D0001 0002 C1 ;Set PWM=0% Response (OK)
[00:46.656] Rx: 143456789ABC C493002150B5 6003 00040009 C02981FF0001 06CB C1 ;CPState=0x06 notification (invalid value!!!) -the module send this invalid CPState value around 10.3 seconds from restart system command!!!
[00:48.968] Rx: 143456789ABC C493002150B5 6003 00040009 C00581FF0001 00F5 C1 ;Interface Up Notification received -this notification is received around 12.6 seconds from restart system command!!!
[00:49.728] Tx: C493002150B5 143456789ABC 6003 0004000A C029440E0002 03E814 C1 ;Set PWM=100% command sent [00:49.728] Rx: 143456789ABC C493002150B5 6003 00040009 C029440E0001 0001 C1 ;Set PWM=100% Response (OK)
[00:49.860] Rx: 143456789ABC C493002150B5 6003 00040009 C02981FF0001 01D0 C1 ;CPState=B notification received -this notification is received around 13.5 seconds from Restart System command -for this 13.5 seconds interval we don't have any information about the CP State (we don't know if the EV was disconnected and then reconnected or if it is the same EV!!!)
So my conclusion is that the Restart System command (0x10:0x48) doesn't work as it should and it cannot be used in order to restart the module. Taking this into account, I cannot continue testing the proposed workaround for restoring communication with EV. Please see also my questions from the previous message. Please advise how do you intend to continue the tests in order to identify a solution for the issue.
Thank You, Ionel Fratila
jpo-stx
commented
1 year ago Hello @IonelFratila ,
there would have been the option to ask on how to use the reset command beforehand. The information that the reset is triggered 5 seconds after sending the reset command is missing in the manual. Therefore, every command you send in these 5 seconds has no effect after the reset.
1.Please confirm that you can reproduce the described module behavior after SW restart command.
What I can oberve on the control pilot is that we get 100% duty cycle for ~200ms when the reset happens.
2.This is the normal behavior after SW restart you intended?
It is intended that the Whitebeet resets after 5s and is ready as soon as it responds to a frame.
3.Also please tell me if you have any remarks about the software reset behavior of the WB module, other that I have already discovered myself.
I did some testing.
The first outcome is that the Whitebeet is fully functional (no delay for sending responses to frames) 10s after triggering the reset. In the screenshot you can see that the reset commonad is triggered at 10:27:56.357 and the response time normalizes at 10:28:05.891. The high response time is caused by the upload of the firmware of the QCA.
Then I did a test where I triggered a reset, waited 5s and then until a response was received, stared slac and set control pilot to 5%. Everything was working fine.
The next test is the same as before, but I waited for 10s after reset. The whole duration until SLAC succeeded is the same as before.
4.There is a maximum value of the software restart time, after which the module is fully functional again (and the desired PWM value can be set again)?
Whitebeet should answer frames after ~7s after reset was triggered.
What I found during testing is that the command to stop and start the PLC interface ends in the QCA being reset.
The command to reset the interface is described in "13.3.8 Set Interface State".
I would kindly ask you to try this instead of a reset of the Whitebeet.
IonelFratila
commented
1 year ago Hi @jpo-stx ,
I have re-run all the tests trying to reestablish the communication with EV after Session Error [Sequence Error]message, without plugging out the EV. The results are as follow: A. This part is common for all tests: 1.When in charge loop simulate CPState=B (just to force host Controller to stop the PWM) 2.CPState=B received and Set PWM=100% 3.The message Session Error Sequence Error is received from WB 0.5 seconds after (2) 4.The message Session Stopped (0x27:0x8C) is received after another 2.0 seconds (total 2.5 seconds from CPState=B)
B. From this point I have run following tests:
I. Try to re-establish communication according to ISO15118-3 5.Wait 3 more seconds after CPState=B message received (just to receive Session Stopped message from WB) 6.Set PWM=0% 7.The message CPState=F received 8.After 3 seconds from (6) Set again PWM=100% 9.CPState=B received 10.Wait 200ms, Start SLAC Matching process and Set PWM=5% 11.Wait for SLAC Match successful message - nu answer, instead SLAC process failed received
II. Try to re-establish communication according to ISO15118-3, but with SLAC Service restart 5.Wait 3 more seconds after CPState=B message received 6.Set PWM=0% 7.The message CPState=F received 8.After 3 seconds from (6) Set again PWM=100% 9.CPState=B received 10.Restart SLAC Service (Stop SLAC 0x28:0x43, Set Validation Configuration 0x28:0x4B and then Start SLAC 0x28:0x42) 11.Wait 200ms, Start SLAC Matching process and Set PWM=5% 12.Wait for SLAC Match successful message - OK, 0x28:0x80 message received 13.Wait for Session Started message (0x27:0x80) - no message after TT_match_Join = 12seconds (the same result even V2G Service is restarted also)
III. Try to reset WB module (workaround from December 05, 2022) 5.Wait 3 more seconds after CPState=B message received 6.Send Restart System command (0x10:0x48) -accepted OK 7.Right after restart command, (re)start CP Service and Set PWM=100% again 8.Wait for 10 seconds and then check synchronization with WB (WB module answer without latency) and Set PWM=0% 9.The message CPState=F received 10.After 3 seconds from (8) Set again PWM=100% 11.CPState=B received 12.Restart SLAC Service (Stop SLAC 0x28:0x43, Set Validation Configuration 0x28:0x4B and then Start SLAC 0x28:0x42) and restart V2G Service 13.Wait 200ms, Start SLAC Matching process and Set PWM=5% 14.Wait for SLAC Match successful message - OK, 0x28:0x80 message received 15.Wait for Session Started message (0x27:0x80) - no message after TT_match_Join = 12seconds
IV. Try to reset QCA (workaround from January 19, 2023) 5.Wait 3 more seconds after Session Stopped message received 6.Send Set Interface State=OFF command (0x05:0x51 with Index=0x00 and State=0x00) -accepted OK 7.Wait for 0.1 seconds and Set PWM=0% 8.The message CPState=F received 9.Send Set Interface State=ON command (0x05:0x51 with Index=0x00 and State=0x01) -accepted OK 10.After 3 seconds from (7) Set again PWM=100% 11.CPState=B received 12.Restart SLAC Service (Stop SLAC 0x28:0x43, Set Validation Configuration 0x28:0x4B and then Start SLAC 0x28:0x42) and restart V2G Service 13.Wait 200ms, Start SLAC Matching process and Set PWM=5% 14.Wait for SLAC Match successful message - OK, 0x28:0x80 message received 15.Wait for Session Started message (0x27:0x80) - no message after TT_match_Join = 12seconds
V. Try to reset QCA (workaround from January 19, 2023), but without restarting SLAC Service 5.Wait 3 more seconds after Session Stopped message received 6.Send Set Interface State=OFF command (0x05:0x51 with Index=0x00 and State=0x00) -accepted OK 7.Wait for 0.1 seconds and Set PWM=0% 8.The message CPState=F received 9.Send Set Interface State=ON command (0x05:0x51 with Index=0x00 and State=0x01) -accepted OK 10.After 3 seconds from (7) Set again PWM=100% 11.CPState=B received 12.Restart V2G Service 13.Wait 200ms, Start SLAC Matching process and Set PWM=5% 14.Wait for SLAC Match successful message - OK, 0x28:0x80 message received 15.Wait for Session Started message (0x27:0x80) - no message after TT_match_Join = 12seconds
VI. Try to reset QCA (workaround from January 19, 2023), but without restarting SLAC Service and V2G Service 5.Wait 3 more seconds after Session Stopped message received 6.Send Set Interface State=OFF command (0x05:0x51 with Index=0x00 and State=0x00) -accepted OK 7.Wait for 0.1 seconds and Set PWM=0% 8.The message CPState=F received 9.Send Set Interface State=ON command (0x05:0x51 with Index=0x00 and State=0x01) -accepted OK 10.After 3 seconds from (7) Set again PWM=100% 11.CPState=B received 12.Wait 200ms, Start SLAC Matching process and Set PWM=5% 13.Wait for SLAC Match successful message - OK, 0x28:0x80 message received 14.Wait for Session Started message (0x27:0x80) - no message after TT_match_Join = 12seconds
Conclusions: 1.There are two distinct problems when trying to reestablish communication with EV, first one regarding SLAC Matching process and the second one regarding HLC (receiving Session Started message after SLAC successful). 2.For the SLAC Matching problem, if either QCA is restarted or SLAC Service is restarted, SLAC Matching process is successful. If not, SLAC Matching process fails (there are some problems in the finalization stage of the first SLAC Matching process, that leads to malfunction of the second SLAC Matching process?!). So if SLAC Service is restarted, there is no need to restart QCA or the entire WB module. 3.After SLAC Matching process is successful, Session Started message is never received (EV does not try to establish the link), with or without restarting V2G Service (this leads me again to NID and NMK parameters, which are changed even EV is not disconnected!?)
Questions: 1.Please check why SLAC Service restart or QCA restart is needed, in order to have a SLAC Matching successful again. 2.Please tell me if you have some more ideas about how can I receive Session Started message from WB? 3.Because both ISO and DIN standards require that NID and NMK parameters remain unchanged until CPState=A (it does not matter if this is the cause for the Session Started message problem), there is no possibility to keep these values unmodified (at least for a test)?
Thank you, Best Regards, Ionel Fratila
vbudko
commented
1 year ago Dear Ionel,
Regarding:
3.Because both ISO and DIN standards require that NID and NMK parameters remain unchanged until CPState=A (it does not matter if this is the cause for the Session Started message problem), there is no possibility to keep these values unmodified (at least for a test)?
Are you aware that for the test purposes you can set what ever NMK/NID required for the test purposes? For example, you can "recover" NMK/NID with "plctool -M" command, it uses CM_SET_KEY/VS_SET_KEY MME.
BR, Vasily
IonelFratila
commented
1 year ago Dear Vasily, I remember that @jpo-stx has suggested the same plctool somewhere in issue #42 : "as a workaround you can try the following with the Open PLC tools (https://github.com/qca/open-plc-utils): • When the V2G session stopped read out the current NMK, replace enp0s3 with the interface name you are using: plctool -i enp0s3 -I • The key will be shown as: NMK xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx (HomePlugAV) • Set the NMK to the default value: plctool -i enp0s3 -M • Set the NMK to the value from the previous session: plctool -i enp0s3 -M -K xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx • Send the Start Matching command to the Whitebeet." Originally posted by @jpo-stx in https://github.com/Sevenstax/FreeV2G/issues/42#issuecomment-1109773580
"I wonder how I can use Open PLC tools you recommend right after session stop is raised, switch the Eth connection from Host Controller to PC, send all this commands manually (including copy the NMK from one response to the next command), switch back Eth to Host Controller and send Start Matching in the time specified in the standard for restarting the communication with EV. And during this time also CP state have to be controlled (by Host Controller, which keep trying to communicate with WB!). May I remind you that I'm not using FreeV2G tool running from PC for testing purposes, but I'm using a Host Controller who is in charge of the entire charging process? And the EV I'm using is a real EV (not a SW simulation I can control), which will not wait indefinitely to restart the communication. I cannot see how to apply the workaround you proposed, unless you have a possibility to set the NMK to a fixed value, used for every communication session. Even so, if this NMK can be set only from PC, I cannot switch the Eth connection from Host Controller to PC and back without resetting the WB module, as I described in issue https://github.com/Sevenstax/FreeV2G/issues/56. Please tell me if you have another idea on how to keep the NMK unchanged after session stop, until EV is plugged-out. Do you have any information about when this will be corrected in WB firmware?" Originally posted by @IonelFratila in https://github.com/Sevenstax/FreeV2G/issues/42#issuecomment-1113087802
As I wrote there, WB module is controlled by a host controller and I cannot mix commands from the host controller and from plctool running on a PC. Also I cannot send manual commands using plctool, because I have no way of knowing the exact time when this tool should be used. Basically I need a method (plctool or other) to set NID/NMK parameters to fixed values, and these values to remain unmodified during all charge process (first and also subsequent SLAC MAtching processes). Can you give more details about how do you think plctool can be used in a real test? I don't know exactly how plctool and WB work. Once NID/NMK values are set using plctool, how long these values will remain unchanged? (indefinitely or are modified at some point in time). Thank you, Best Regards, Ionel Fratila
jpo-stx
commented
1 year ago Hello Ionel,
First, I want to thank you for the detailed description and the effort you have put into these tests.
From the tests you performed, there are two which are applicable in the current situation and where I would have assumed that the EV will start again with HLC. These are tests III and IV. Do you have any Wireshark and UART logs for these tests?
Regarding your conclusions:
Regarding your Questions:
A few more things:
In the tests you write “no message after TT_match_Join = 12seconds”, have you tried to wait longer?
Can you redo the tests III and IV with a slight modification:
III. b) As before until the point where you send the reset command to the Whitebeet.
IV. b) As before until the point where you send the reset command to the Whitebeet.
IonelFratila
commented
1 year ago Hi @jpo-stx , First of all thank you for your message. I will try to redo the tests with the changes you suggested. However, I don't understand why you are interested only on tests III (using WB system restart) and IV (using QCA restart command). The result of these tests are identical with test II (restart SLAC Service), SLAC Matching process OK, no SDP (and Session Start) after that. So restarting SLAC service is enough in order to have SLAC matching.
Some comments about your answers:
"There is no malfunction of the SLAC service, if you do not stop or restart the SLAC service, the Whitebeet still has the link and is not ready to receive a CM_SLAC_PARAM.REQ from EV to start a new matching sequence, because it is still matched." So you suggest that WB and EV are still matched, and the EV should start SDP and a new Session without the need of a new SLAC matching process? In my opinion, we can have two possibilities: 1.WB and EV are still matched and EV should start a new SDP and a new Sessions, but it does not (and we don't know the reason why, it can be the same reason why EV does not start SDP even after a new SLAC matching process) 2.After SLAC Service (or QCA or entire WB) is restarted, WB and EV become unmatched and EV asks for a new SLAC matching, which is successful but still not followed by SDP and a new Session. So I think we should concentrate our efforts first on making the EV to restart the SDP process after SLAC matching successful. What I want to say is I don't think QCA or WB restart is usefull (or needed), the same result is achieved by restarting only SLAC Service (which is more simple and fast).
"The EV started the SLAC matching process, which succeeded. Therefore, it now has a link, but it does not start HLC communication." Why do you consider that after SLAC matching successful, EV and WB have a link? Both standards state that after EVSE sends CM_SLAC_MATCH.CNF message containing NID and NMK parameters to be used in order to establish the link, both EV and EVSE should use these values to configure the Green-Phy nodes. Do you have any confirmation that EV accepts and uses these parameters for the link and also that WB uses these values to configure its Green-Phy node in order to detect a link in its logical network? I think that we have only a confirmation that SLAC matching was successful, but nothing about the link (CM_SLAC_Match.CNF message is not a confirmation on the link established). Maybe this is the first step to check.
" after receiving the error, do not restart V2G service and SLAC service. Just wait if a new HLC connection will be established." I already ran this and, if SLAC Service (or QCA or WB) is not restarted, nothing happens for indefinite time (EV turns OFF his LED lamp).
Regarding NID and NMK values, I'm not sure if they have any influence on starting a new HLC, but I think it can be a reason. Both standards are very unclear on this (ISO15118 is more vague than DIN70121) but there are following statements (in DIN, ISO does not contain these exact statements, even SLAC process description is the same and both standards are based on HPGP specification): "8.3.3.3.2.MME Content for SLAC ... [V2G-DC-574] The EVSE shall generate a random NMK after Power-On and after every plug-out of an EV, and it shall use this random NMK for setting up a logical network. NOTE: NMK and NID should be generated after plug-out instead of plug-in to save time for Data-Link setup. ... 8.3.5.5.2.Requirements on EVSE side [V2G-DC-603] The EVSE shall configure its Green PHY node to the NID and NMK values sent in CM_SLAC_MATCH.CNF at the latest after sending the CM_SLAC_MATCH.CNF. The configuration can also be done at any time before (e.g. when unplugging of previous EV). The configuration shall be done by sending a CM_SET_KEY.REQ."
It is only suggested that NMK should be generated after plug-out of EV, but this can be interpreted also like "if no plug-out of EV, NMK should not be generated again". I know that is not stated as mandatory, but I think it worth to try if this is the reason why we don't have HLC (or even link). Unfortunately, I did not found (until now) a way to use plctools for setting NMK right before the moment when SLAC matching is restarted, but I'm still trying.
Regarding [V2G2-727] and [V2G3-M07-13] you mentioned, earlier you said that "There is no malfunction of the SLAC service, if you do not stop or restart the SLAC service, the Whitebeet still has the link and is not ready to receive a CM_SLAC_PARAM.REQ from EV to start a new matching sequence, because it is still matched." So WB is or not still matched? It has or not Data-Link established? If WB respects [V2G2-727] and [V2G3-M07-13], then it should be already unmatched, so there is a malfunction of the SLAC service, because a new SLAC matching can be started only if SLAC Service is restarted.
Best Regards, Ionel Fratila
IonelFratila
commented
1 year ago Hi @jpo-stx , I ran again the tests IIIb (restart WB), IVb (restart QCA) as you described, and also test II (restart SLAC Service). The results are the same, meaning that SLAC Matching is successful but no Session start (I don't know about data link). I have attached log files for all three tests (packed into an archive, because the forum does not support pcapng files !?): -wireshark log (for the direct communication between WB and EV, not by using port mirroring, because I cannot inspect the communication between WB and Host Controller) -Serial log of the WB module -log for communication between WB and Host Controller (in *.txt files)
1.Test IIIb (restart WB module): 20230206_Restart WB (IIIb).zip
2,Test IVb (restart QCA): 20230206_Restart QCA (IVb).zip
3.Test II (restart SLAC Service): 20230206_Restart SLAC Serv (II).zip
Hope this will help, Best Regards, Ionel Fratila
jpo-stx
commented
1 year ago Hi @IonelFratila ,
thanks for running the modified tests again.
You had some questions in your comment, let me first answer these.
Why do you consider that after SLAC matching successful, EV and WB have a link? Both standards state that after EVSE sends CM_SLAC_MATCH.CNF message containing NID and NMK parameters to be used in order to establish the link, both EV and EVSE should use these values to configure the Green-Phy nodes. Do you have any confirmation that EV accepts and uses these parameters for the link and also that WB uses these values to configure its Green-Phy node in order to detect a link in its logical network? I think that we have only a confirmation that SLAC matching was successful, but nothing about the link (CM_SLAC_Match.CNF message is not a confirmation on the link established). Maybe this is the first step to check.
We see IPv6 frames coming from the EV. Therefore it should have a link. My assumtion is that the lower layer is aware that the link is lost and therefore reestablishes it by doing the SLAC matching again, but the high level application is not.
Regarding [V2G2-727] and [V2G3-M07-13] you mentioned, earlier you said that "There is no malfunction of the SLAC service, if you do not stop or restart the SLAC service, the Whitebeet still has the link and is not ready to receive a CM_SLAC_PARAM.REQ from EV to start a new matching sequence, because it is still matched." So WB is or not still matched? It has or not Data-Link established? If WB respects [V2G2-727] and [V2G3-M07-13], then it should be already unmatched, so there is a malfunction of the SLAC service, because a new SLAC matching can be started only if SLAC Service is restarted.
For the Whitebeet we give the responsibility of handling the SLAC service correctly to the host. Therefore, the host should restart the SLAC service after an HLC error.
Furthermore I want to give you some information about our testing where we were able to get the ID4 charging again without replugging after a session error. In our case the charging station changed the duty cycle to 100% after 1,5s after the state change C -> B caused by the resistor in the CP line. After the session ended the QCA was reset and when it was ready again the duty cycle was changed from 100% -> 5%. Maybe you can consider this and try without going to state F (0% duty cycle).
BR Jan
IonelFratila
commented
1 year ago Hi @jpo-stx , Thank you for your message. I will try also a workaround similar to your test. However, changing PWM to 100% only after 1.5s after the state change from C to B is not according to the standard CEI61851-23 (see DIN70121, 8.3.1.1.1. Note 2). According to ISO15118-3 7.5.1.2 seems to be OK, so I'll try it.
For the Whitebeet we give the responsibility of handling the SLAC service correctly to the host. Therefore, the host should restart the SLAC service after an HLC error.)
Can you be more specific about this, because the User Manual contain nothing about it. When exactly the host controller should restart the SLAC Service? What is the condition that will trigger this and the timing? If this is mandatory after a HLC error (you said that it is host responsibility), QCA reset that we discuss is still needed? It worth talking further about it or to do tests? When I first reset the SLAC Service in order to have SLAC Matching successful again you said that is not needed. I'm confused. Please be more precise. In fact, I think that SLAC Service does not becomes Unmatced when HLC error occured, that's why SLAC Servcie restart (or QCA reset) is needed.
What about the logs I sent? Did you have time to analyze them? Did you find anything that can explain why a new session does not start in any of the cases? Thank you, Best Regards, Ionel Fratila
jpo-stx
commented
1 year ago Hi @IonelFratila ,
Thank you for your message. I will try also a workaround similar to your test. However, changing PWM to 100% only after 1.5s after the state change from C to B is not according to the standard CEI61851-23 (see DIN70121, 8.3.1.1.1. Note 2). According to ISO15118-3 7.5.1.2 seems to be OK, so I'll try it.
I expect you mean ISO15118-3 7.5.1.1 (DC Charging use case). I agree with you. But it seems that following this guideline leads to the ID4 staying calm after SLAC matching. This is what we also observed during our testing.
But during our testing we were able to make the ID4 reestablish the V2G communication after SLAC matching by restarting the QCA (In your case it does not matter if you restart only the SLAC service or restart the QCA or even the Whitebeet). After you have reported that this restart doesn't work in your setup we tried to figure out the difference between your setup and the DC charger we use for testing. The only difference we observed (except timings, etc.) is that our DC charger does not go through state F. So it is worth trying.
But summarized we agree that this behaviour is not complying with the ISO15118-3 7.5.1.1, but on the other hand it seems that the reason for our overall discussion is a wrong behaviour of the ID4.
So the only solution we see is either plugging out the charging cable or trying to find a workaround based on the steps mentioned above. I would really come to a conclusion and close this issue. Maybe it is what it is and we need a user interaction in this case.
Can you be more specific about this, because the User Manual contain nothing about it.
The SLAC service module and the V2G service module are not connected to each other internally, the host needes to take care of the correct handling of the services.
When exactly the host controller should restart the SLAC Service? What is the condition that will trigger this and the timing?
The host should stop the SLAC service whenever a charging session was finished, either successfully or unsuccessfully (Session Stopped message with Closure Type Terminate). The only use case where the service is not stopped is when the charging session was paused (Session Stopped message with Closure Type Pause). Please refer to Figure 22 in the ISO15118-2:2014.
If this is mandatory after a HLC error (you said that it is host responsibility), QCA reset that we discuss is still needed?
Normally, a QCA reset is not needed, this is why it is not implemented as default. We just used it as a workaround, but we are still not sure that this is the root cause why the ID4 was charging again in our test scenario. In your case it does not matter if you restart only the SLAC service or restart the QCA or even the Whitebeet. The outcome is always the same.
It worth talking further about it or to do tests?
Yes without the State F transition. See above.
When I first reset the SLAC Service in order to have SLAC Matching successful again you said that is not needed. I'm confused. Please be more precise. In fact, I think that SLAC Service does not becomes Unmatced when HLC error occured, that's why SLAC Servcie restart (or QCA reset) is needed.
Can you quote me? Maybe I said that in a different context? You can start the matching again without restarting the SLAC service, in this case the NMK and NID are kept the same for the matching process, but I think we already talked about that and you tested it, but the ID4 will not start the matching process in this case. This feature is intended to be used for the session pause.
What about the logs I sent? Did you have time to analyze them? Did you find anything that can explain why a new session does not start in any of the cases?
Unfortunately, I did not find any useful information besides the IPv6 messages that are sent by the ID4 after the second matching.
The only idea I have left is to close the HLC connection from EVSE side, but this is not according to the specification and I cannot predict the behaviour on EV side. What I mean by this is to send the Stop Listen message when you see the state change from B -> C on the CP line.
BR Jan
IonelFratila
commented
1 year ago Hi @jpo-stx , I have tried to restart communication with EV after Session error message following the same method that you used with ID4 (Set PWM=100%, wait for Session Stop, restart QCA, wait for QCA to start and then restart SLAC matching and Set PWM=5%), but with no success. I tried also to restart V2G service before Set PWM=5% again, but the result is always the same: SLAC Matching is successful (and I have the confirmation that NID and NMK remain unchanged if SLAC Service is not restarted). Attached are the logs for the test performed.
My conclusions are: 1.There is a problem in the SLAC Service, that do not performs the un-matching when HLC error occured, as a result the next SLAC Match process is unsuccessful. A QCA reset is needed to solve the problem, without restarting SLAC Service (if the SLAC Service is restarted, the result is that SLAC Matching is successful, but with different NID and NMK). I think this problem with SLAC Service should be corrected in the future, so that the QCA reset to be no longer necessary.
Until new information will be available regarding this issue, I think I have to abandon the tests, so I think you can close this issue. Thank you very much for your efforts, Best Regards, Ionel Fratila
jpo-stx
commented
1 year ago Hi @IonelFratila ,
I see you found a way to keep the NMK the same between SLAC matching processes. The result is as expected, as mentioned many times before, because this is not according to specification.
The warnings in the log are ok. Sending failes, because the PLC link was lost, which is as expected.
BR Jan
Your Setup Platform: EVSE Firmware Version: V02_00_01 Host Controller Interface: Ethernet Host: Own Implementation
Describe the bug
Originally posted by @IonelFratila in https://github.com/Sevenstax/FreeV2G/issues/61#issuecomment-1161973330
To Reproduce
Expected behavior The EV starts to send UDP packages for service discovery.