Asking for a Tutoring/Consultation

[andreishabo]

Dear Martin,

Thanks for the great work provided!

I am trying to build the V2G project on a Raspberry-Pi 3 with QCA7000 and MCP 2515, so it could simulate Vehicle-to-grid connection between two Raspberries.

Are you able to offer any kind of consultation/tutoring/help for this kind of task?

Please let me know if you have any questions!

Thanks,
Andrei

[Martin-P]

Hello Andrei,

Credits are for the original author of the code, I just copied it from https://sourceforge.net/projects/openv2g/ 😉 Just so you know: there is a newer version available on that project page OpenV2G 0.9.4.

I worked with this in 2015 and then I used the INSYS Powerline GP to perform some basic tests. This module can only be used for the EVSE (Electric Vehicle Supply Equipment = charging station) side and can not be used for the EV (Electric Vehicle) side. Inside this INSYS Powerline GP is some hardware and a board from Devolo: dLAN Green PHY Module. I see now that Devolo put some of their code online on GitHub: https://github.com/devolo/dlan-greenphy-sdk

The INSYS Powerline GP can superimpose data on the 1 kHz square wave CP (control pilot) signal, but can also superimpose data on the 230V AC. HomePlug Green PHY is derived from HomePlug AV and therefore you can establish some communication using powerline adapters (e.g. Devolo dLAN 500).

What do you want to use the MCP2515 for? That is a CAN bus controller. If you want to use that for communication between EV and EVSE and that would be used for CHAdeMO. The QCA7000 is used for AC charging or CCS (Combined Charging System) and superimposes the data on the CP signal of the charger (1 kHz square wave with a 5% duty cycle).

I hope this info helps you get started.

[andreishabo]

Hi Martin,

Thanks for the provided information! It is truly useful and very interesting!

We have built an EVCC controller (from V2G) based on Raspberry Pi 3 + QCA7000, and a CP signal generator (1 kHz square wave with a 5% duty cycle). Then we set the QCA7000 module to "charging station" mode.
When connected to a Tesla (Model 3, European version) the car raises a communication error: "New Device Communication Error".

In your opinion, what could be the issue? The QCA7000 might have additional configurations that need to be set, but I am not quite sure which ones.. ;-)
Because when we simulate the Tesla car with an additional QCA7000, the communication works just fine! :)

I look forward to hearing from you!

Thanks,
Andrei

[Martin-P]

Hi Andrei,

What is your use case? Is it an AC charging session or a DC charging session? Do you see any SLAC (Signal Level Attenuation
Characterization) messages?

[andreishabo]

Hi Martin,

We use DC charging session, there are no SLAC messages appearing. Also while connecting to the car there was nothing happening with the tshark (sniffer) and we were getting communication error message.

[Martin-P]

Hi Andrei,

Do you see any changes in the CP voltage? Can you monitor your CP signal to see if the CP square wave is okay on the EV side? Perhaps the quare wave is distorted?

[andreishabo]

Hi Martin,

We have connected it successfully to the car and getting SLACK messages and a short connection notification following a disconnection in 10 seconds. Then we realized that the car (BMW Europe) was using DIN standard (we had ISO 15118 in V2G).
My question is: Do you have any advice for us on how to switch to DIN standard in the openV2G code? Did you have any similar tasks before?

Thanks!
Andrei

[Martin-P]

Hi Andrei,

Good to hear you were able to establish the connection.

According to the README.txt it looks like DIN 70121 support can be activated by changing a #define in src/din/dinEXIDatatypes.h line 47 to:

#define DEPLOY_DIN_CODEC SUPPORT_YES

Looking at the code you might also need to change line 48 too:

#define DEPLOY_DIN_CODEC_FRAGMENT SUPPORT_YES

Did you have any similar tasks before?

At the time it was an extra part for my graduation project. It was not the main focus, so it was limited to research about the technical background of HomePlug Green PHY and some basic tests. After the graduation project my job activities inside the company changed and my collegue took over the project several years later when it became more relevant for the company.

[Martin-P]

Just so you know:
I updated the repository and it is up-to-date with the original SVN version (https://sourceforge.net/p/openv2g/code/HEAD/tree/trunk/) now.

• release_0.9.4 seems to have some fixes
• master is ahead of release_0.9.4 and has some additional updates

It looks like the SVN version will not receive anymore updates: https://sourceforge.net/projects/openv2g/

Note: the V2G implementation for the upcoming 15118-2-2016 standard (ISO Edition 2) will not be available as Open Source. If you are interested in a solution, please contact us via [email protected]

[andreishabo]

Dear Martin,

Thanks for the provided update and information!
We will try to configure this thoroughly.

We were able to connect to BMW I3 DIN 70121. Currently, we have a problem with Tesla Model 3 (EU) CCS TYPE2 ISO15118. When connecting and starting SLAC, the car shows "Communication error". The CP signal is applied to the CP connector, a 1500 Ohm PE resistor is connected to PP. What could be wrong? Do I need to send an additional signal to PP? There was no such problem with BMW and the SLAC procedure was successful there.

Please let me know if you need any additional details.

Cheers,
Andrei

[Martin-P]

Hello Andrei,

The "Communication error" seems to indicate a CP issue. Do you receive any messages at all from the car? Perhaps you can compare the BMW I3 data to the data you see now? Does the Tesla Model 3 support/use DIN 70121?

PP looks fine, 1500 Ohm is a 13A cable.

[andreishabo]

Hello Martin,

I am sorry for the late reply. I have gone through COVID during my vacation recently.

However, as for the project. I decided to use [RISE V2G Clarity] (https://github.com/SwitchEV/RISE-V2G) for further work to connect to an EV on ISO. But as for BMW on DIN 70121, RISE V2G requires some changes in code that I cannot figure out yet.

I appreciate your help very much. I would appreciate also if you could advise me on where I could find some information (or connect to someone) that I could use DIN 70121 with RISE V2G if that is possible.

Thanks again, I look forward to hearing form you. Let me know if you have any questions or concerns.

Best regards,
Andrei

[andreishabo]

Martin,

I have found that Open V2G is a tool somewhat similar to EXIficienet codec that is used in RISE V2G.
Instead of EXIficienet codec, we can use OpenV2G to exchange XML data. Am I right?

Is there any documentation available to Implement RISE V2G with OpenV2G?

Thanks!

[Martin-P]

Hello Andrei,

Sorry for the late response. I must make the GitHub e-mail notifications more visible in my mailbox.

I have gone through COVID during my vacation recently.

Sorry to hear that, hope you are feeling better again.

Instead of EXIficienet codec, we can use OpenV2G to exchange XML data. Am I right?

As far as I see EXIficient only encodes/decodes the data, it does not transport and analyze the data. For communication between EV and EVSE you need software like OpenV2G.

Is there any documentation available to Implement RISE V2G with OpenV2G?

I am not aware of any documentation for this. I am afraid it comes down to analyzing RISE V2G and OpenV2G and port everything to Java code or port everything everything to C code. I do see there is a YouTube video where RISE V2G/V2G Clarity provides some information about the process: Meet ISO 15118 - Open Communication Protocols for Electric Vehicles Smart Charging. I hope this info helps.

[andreishabo]

Hello Martin!

Thanks for the response and provided information with the video! To update you, we have reconfigured RISE V2G code to DIN standard and tested it on BMW car again. The communication was (almost!) successful, even though we didn't use OpenV2G codec and kept with EXIficient.
Currently we recieve error in messaging sequence at 'WaitForCableCheckReq' and get instead 'PowerDeliveryReq', so I'm trying to figure this point out...

I provided the messaging sequence we recieve below.

(line 574)
> 2021-08-11T18:28:18,332 FATAL [ConnectionThread fe80:0:0:0:f27f:cff:fe02:ee5%4] WaitForCableCheckReq: Invalid message (PowerDeliveryReqType) at this state (WaitForCableCheckReq)
> 2021-08-11T18:28:18,335 ERROR [ConnectionThread fe80:0:0:0:f27f:cff:fe02:ee5%4] WaitForCableCheckReq: Response code 'FAILED_SequenceError' will be sent.
> 2021-08-11T18:28:18,338 DEBUG [ConnectionThread fe80:0:0:0:f27f:cff:fe02:ee5%4] WaitForCableCheckReq: Preparing to send PowerDeliveryRes

full communication sequence is here:
https://pastebin.com/JbFxLsAn

Best,
Andrei

[Martin-P]

Hello Andrei,

Issue seems to be the cable check. I think this comment in WaitForCableCheckReq.java explains it:

/*
 * TODO we need a timeout mechanism here so that a response can be sent within 2s
 * the DCEVSEStatus should be generated according to already available values
 * (if EVSEProcessing == ONGOING, maybe because of EVSE_IsolationMonitoringActive,
 * within a certain timeout, then the status must be different)
 */
setEvseProcessingFinished(true);

The processing is set to "finished" without checking the actual status. The java code continues executing the code and excutes
the next step which has another comment in WaitForPreChargeReq.java:

// TODO how to react to failure status of DCEVStatus of cableCheckReq?

Next step is WaitForPowerDeliveryReq and there is where you encounter the error status FAILED_ChargerConnectorLockFault, because previous checks are not present in the java code.

Perhaps you can use the OpenV2G code as an example to implement the checks, see this part of main_example.c.

[andreishabo]

Hello Martin!

Thanks for your advice!

In ChargeParameterDiscoveryReq we already get the error status FAILED_ChargerConnectorLockFault.

After ChargeParameterDiscoveryRes we recieve PowerDeliveryReq with FAILED_ChargerConnectorLockFault instead of CableCheckReq. Then the vehicle sends SessionStop and terminates the connection. I am not quite sure why, but we don't even reach to CableCheckReq...

        <ns5:ChargeParameterDiscoveryReq>
            <ns5:EVRequestedEnergyTransferType>DC_extended</ns5:EVRequestedEnergyTransferType>
            <ns6:DC_EVChargeParameter>
                <ns6:DC_EVStatus>
                    <ns6:EVReady>false</ns6:EVReady>
                    <ns6:EVCabinConditioning>true</ns6:EVCabinConditioning>
                    <ns6:EVErrorCode>FAILED_ChargerConnectorLockFault</ns6:EVErrorCode>
                    <ns6:EVRESSSOC>68</ns6:EVRESSSOC>
                </ns6:DC_EVStatus>
lines 408-415 
https://pastebin.com/JbFxLsAn

It would be great to read your opinion on whether this issue comes from the code or the physical connector.

Cheers!

[Martin-P]

Hello Andrei,

It is a received EXI stream, so it must come from the EV. Does the car actually perform the cable lock?

If the OpenV2G code works for the BMW I3 it might be useful to use that code as a working example. If you add some debugging code and print all sent and received messages it might give some insights in the actual communication for a successful transaction. You can use that to check for differences in communication.

[andreishabo]

Hi Martin! I hope you are doing well!

Does the car actually perform the cable lock?

Actually not really. Let me explain: When I plug the cable into the vehicle, it start initializing, and during the first 2 seconds I see the the lock moving to block the cable (stays blocked for another ~2 seconds) and then moving back (unlocking the cable) when we get the session terminated.

If the OpenV2G code works for the BMW I3 it might be useful to use that code as a working example

Thanks for this advice, I might try it. I do have few other options to try first and will get back to you if I get any updates : )

Cheers,

[goRaspy]

Hi Martin,

Thanks for the provided information! It is truly useful and very interesting!

We have built an EVCC controller (from V2G) based on Raspberry Pi 3 + QCA7000, and a CP signal generator (1 kHz square wave with a 5% duty cycle). Then we set the QCA7000 module to "charging station" mode. When connected to a Tesla (Model 3, European version) the car raises a communication error: "New Device Communication Error".

In your opinion, what could be the issue? The QCA7000 might have additional configurations that need to be set, but I am not quite sure which ones.. ;-) Because when we simulate the Tesla car with an additional QCA7000, the communication works just fine! :)

I look forward to hearing from you!

Thanks, Andrei

Hello @andreishabo , did you finally success to obtain a SLAC with TM3 ? I am in a similar situation. The SLAC works fine with a Kia Niro and not with Tesla.