Issues with Unstable Data Transmission Between PEV and EVSE Using Yellow Beet Boards Based on Qualcomm QCA7K

[ngoctoan]

I am researching about electric vehicle charging station (EVSE), I bought 2 Yellow beet boards from Codico (https://www.codico.com/en/yellow-beet-e-1-1) These 2 boards are based on Qualcomm QCA7K, actually I had problems with them because both boards have the role of EVSE, but after sending a mail to Codico, I converted the role of 1 board to PEV role. I connected the PEV board to Raspberry and Esp32 to EVSE, I just connected the 2 CP, PP wires on the 2 boards together and I transmitted data from PEV to EVSE (but it was unstable, sometimes it transmitted well but sometimes not). Then I replaced Raspberry with STM32, I could also transmit but still had the unstable situation. Based on CCS2/IEC 61851, I added +-12v 1kHz power to 2 pins as shown but still can't get stable transmission. Can anyone tell me where I went wrong? Sorry if it's confusing because I'm using google translate. I'm from Vietnam.

[johu]

Are the two modules on a common GND / PE?

EDIT: took the liberty to replace your google doc with an attachment. Linked docs have a tendency to disappear

[ngoctoan]

Are the two modules on a common GND / PE?

EDIT: took the liberty to replace your google doc with an attachment. Linked docs have a tendency to disappear

Yes, I use the power supply for the microcontroller from my computer

[uhi22]

Hi, in your picture, the "PP" means most likely "PE", which is the protective earth, and the ground of both modules. According to the data sheet (https://www.codico.com/de/yellow-beet-e-1-1) the yellow beet does not have a PP (proximity pilote).
So I assume you connected the ground to ground, and the CP to CP. This is perfect. Just make sure that these wires are running together, in best case as twisted pair, to avoid disturbances from other devices.

You do not need the 1kHz for your double-yellow-beet setup. The yellow beets do not care for the 1kHz, they are pure PLC (=radio frequency) devices. The 1kHz generator comes into the game when you want to connect to a real vehicle.

In your hex message dumps I see homeplug messages and also IPv6 message, so it seems that the pairing worked. If the connection is not stable, this can have many root causes. For example:
- The breadboard wires have not good connections. I had some issues with such wires, and prefer soldering.
- The PLC communication is disturbed by other devices. Use twisted pair for CP+PE.
- The software has problems to read the data from SPI at the needed speed, which could lead to buffer overrun in the QCA.
- The software has no re-try in case of lost messages.
- The power for the modems is not stable so they get resets or lose data.
You could try an other software, e.g. pyPLC on the Raspberry to see whether it makes a difference. The raspberry comes with an QCA7000 driver, so this is an easy road to go.

[ngoctoan]

Hi, in your picture, the "PP" means most likely "PE", which is the protective earth, and the ground of both modules. According to the data sheet (https://www.codico.com/de/yellow-beet-e-1-1) the yellow beet does not have a PP (proximity pilote).
So I assume you connected the ground to ground, and the CP to CP. This is perfect. Just make sure that these wires are running together, in best case as twisted pair, to avoid disturbances from other devices.

You do not need the 1kHz for your double-yellow-beet setup. The yellow beets do not care for the 1kHz, they are pure PLC (=radio frequency) devices. The 1kHz generator comes into the game when you want to connect to a real vehicle.

In your hex message dumps I see homeplug messages and also IPv6 message, so it seems that the pairing worked. If the connection is not stable, this can have many root causes. For example:
- The breadboard wires have not good connections. I had some issues with such wires, and prefer soldering.
- The PLC communication is disturbed by other devices. Use twisted pair for CP+PE.
- The software has problems to read the data from SPI at the needed speed, which could lead to buffer overrun in the QCA.
- The software has no re-try in case of lost messages.
- The power for the modems is not stable so they get resets or lose data.
You could try an other software, e.g. pyPLC on the Raspberry to see whether it makes a difference. The raspberry comes with an QCA7000 driver, so this is an easy road to go.

Thank u for your help