Cable check not receive from citroen ec3 Car
Closed this issue · 16 comments
Platform: EVSE
Firmware Version: i.e. V02_01_00
Host Controller Interface: Ethernet
Host: Own Implementation
Dear Team
We are trying to charge the Citroen ec3 Car but it stuck in Cablecheck request. Please find the attached wireshark logs in which 1st session goes failed and another session goes pass so we want to know the reason why the first session has issue?
Please support us quickly to solve this as our end customer got frustrate and now asking to return the charger.
Best Regards,
Nikunj Patel
Hey @nikunjp26,
I checked the log file and on a first glance the communication between the two sessions is exactly the same (except values like session ID, port numbers). For me it seems your charger works as expected, the PEV is just not sending out the CableCheckRequest, although it ACKs the ChargeParameterDiscoveryRepsonse, so it has definitely seen it. I need to have a deeper look into the communication.
Do also have the UART logs of the charger?
Best regards,
lho
Dear Iho,
can you please check the attenuation value during the slac match? does those value impact to this issue? as we are seeing that one module has approx 35 deb attenuation where other has 45+ db attenuation .
best regards,
Nikunj Patel
Hey,
although your attenuation is quite high, from your issue description I would not expect that this is the issue. The communication always works every other session and always fails at the cable check? If it is a attenuation issue I would expect the session to fail more randomly.
Do you have your amplitude map calibrated and uploaded it to the WHITE Beet?
BR,
lho
Dear Iho,
- yes. it always stuck in cable check. Right now we did the different car testing with the charger but did not get any single time success.
- Do you have your amplitude map calibrated and uploaded it to the WHITE Beet?
White beet was pre calibrated. We are not doing any calibration at our side.
Hello, I'm a SECC SW developer(not SevenStax). I don't know much about detail isolation check logic(H/W), but your failure situation might be related with it(EV detects an isolation monitoring failure).
Hey @nikunjp26,
regarding the calibration: To get the best signal strength you need to do a calibration with your custom hardware attached. You are basically doing a channel estimation from the output of the QCA on the WHITE Beet to the output of your outlet/charger gun. The amplitude map is calculated from this channel estimation. Please contact CODICO for more information about the procedure.
Thanks @kwoyhope for contributing. This is also what I would suspect if the charging always fails before cable check. Maybe the EV power electronics sees a HW malfunction not communicated in V2G? What is your host application doing right before the cable check?
Best regards,
lho
Dear Iho,
- We stop the imd checking from our side still facing the issue.
- we removed (power off) the imd device from the charger still facing the issue..
Also same car is charge with other competitors charger without any issue.
So please support us to solve this issue. Let us know if any other things we can check or we are able to update the ota firmware of whitebeet module so if you need any try so we can also perform. Because we need to solve this issue in this week as client is frustrated too much...
Beat regards
Nikunj Patel
Hey,
I would like to have a colleague to have a look at the log file too, he is on PTO and will return on wendesday.
With IMD you mean isolation monitoring device? I don't know if it is a good idea to remove it. I would expect the car to have it's own IMD. Removing the IMD on EVSE side will not affect the IMD in the EV, or? Also the EVSE is not in charge to do anything at the moment the session brakes (at least from a V2G perspective). Does you IMD show any error when the session is failing? Is there any information on the EV side?
Best regards,
lho
Dear Iho,
- Imd removing is Just for test if evse imd hardware may behave something wrong.
- There was no any error found on imd side nor any other evse controller side. Also we check on ev side screen but there was not showing anything on it's screen also
- No don't have any other information for the ev side.
Best regards
Nikunj Patel
Hi,
my colleague agrees that the V2G and framing communication is correct and there is no issue with it.
You are basically stuck before the cable check. Do you have access to the "Design Guide Combined Charging System" from the "Initiative Charging Interface"? There it states the voltage should not exceed 60V prior starting the cable check. Maybe the EV manufacturer is following this guide and the voltage applied prior the cable check is out of range.
Please check other physical values, power electronics, etc. too.
I also got the confirmation by Codico that your attenuation is quite high (the aimed attenuation is about 25 dB), but they agreed on that it is not the cause of the problem. If you want to improve your attenuation, please talk to them.
Unfortunately there is nothing else I can do for you at this point.
Best regards,
lho
Dear Iho,
There was 0 volt on our power module in this state and there was never set the 60v because we start the output relay after that.
best regards
Dear Iho,
There was no any changes we did as There was already 0 volt present on the same setup at hub location from the first day.
can you please do something here as still we are facing too much time failure in cable check.?
best regards,
Hey @nikunjp26,
I misunderstood your message, please apologize. In the DIN and ISO it is stated the EV shall continue with the cable check after the exchange of the charge parameter. Unfortunately there is nothing else you can do from the WHITE Beet EVSE (your message flow is good), the EV is in charge of continuing the message flow or closing the session. Changing the timeout in the EVSE would break the compatibility with the DIN/ISO standard.
But if you want to close the session from EVSE side early (again, this will violate the standard) you can do it from your user application. A possible flow can be:
- start a timer after you send the schedules to the WHITE Beet, basically in the same moment when you start to send the "update DC charging parameters" messages to the WHITE Beet.
- wait until the WHITE Beet sends "Cable check requested" to the host (0x27 0x87)
- if "Cable check requested" is not received within a time window you think is suitable, you can set the CP to error state.
This leads to a hard failure. If the EV already closed its relay (by setting state B), it will force open it again. Again, this will violate the standard and I would advise against it.
If you say the EV is working with other chargers, can you create a wireshark log of such a session? We do not identify any problems in the communication and setting of the WHITE Beet. If the communication is 1:1 the same between your charger and the 3rd party charger, then we know 100% it is hardware related (although we are quite sure).
In addition to this, you can monitor the CP at the charging gun output with an oscilloscope or suitable logic analyzer, maybe the PWM signal is distorted in your custom HW and leads to some issues.
Best regards,
lho
Dear Iho,
- if "Cable check requested" is not received within a time window you think is suitable, you can set the CP to error state.
can you please guide us how to set the CP to Error state?
best regards,
nikunj patel
Hello,
it can be achieved by using the "Set PWM duty cycle" message. You might try to set it to state F (0%). Please have a look into chapter 15.4.5 in the WHITE Beet manual for more information.
Best regards,
lho