QCA7000 Foccci+Clara User thread

[johu]

Yes the terminalcommands.cpp are linked but only PrintParamsJson() is actually used (for CAN). It didn't seem to make much sense to enable the commands while the terminal is flooded with debug messages. The linker dismisses all unused functions.

[johu]

The problem should be fixed: https://github.com/jsphuebner/libopenin ... 952c91967a

Also integrated this into Clara, new binary in actions https://github.com/uhi22/ccs32clara/act ... 1462827692

[dimonlipko]

Hi! Thanks for that great project!)
I start install Foccci in my DIY EV based on leaf powertrain and my own VCU. I order on JLCPCB Foccci assembled board, but without QCA7005. I buy QCA on ALI (think that it used chip), and solder by myself. Next, i program STM32 (flash + boot) and program SPI Flash memory. Board is alive, I see Foccci parameter in Web interface, and see parameter in serial. Serial log is next, i see QCA response, but not understand is it ok, because not see [modem found] line. Full log attachment.

Have to setting serial log? I see same one have more parameter there.

What minimum parameter i need send from my ECU to Foccci via CAN for launch CCS charger?

P.S. now work on PCB for install ESP32 in OBD2 case like ELM327. I try to transfer ESP32-Web-Interface on ESP32-C3 chip, but still have problem with file system and SD Card read library. Try it next time)

P.S.S. Have idea, what are you think about see serial log at web interface? Or maybe make log file, and download it later from web interface?

[uhi22]

Great progress! The log is fully normal. We see the software version of the modem, this means, the QCA is soldered ok (at least it has power and SPI working), and the SPI flash has the correct firmware. It is normal, that the QCA "disappears" after around 30s after power-on, it goes to a kind of sleep mode. That's why it does not answer the last software version request. Everything as expected. It will wake up, as soon as it sees packages from a "Central Coordinator", this may be a real charging station or even a homeplug modem and Focccis CP line flying around near (2cm) next to the power cord.

For real charging you need to send the actual battery voltage (which Foccci needs during the Precharge phase) and the demands for current and voltage. The details are in the wiki: https://openinverter.org/wiki/Foccci in the section "Integrating Foccci with your car/BMS".

Regarding serial log via web interface: this would indeed be a helpful improvement. Would you plan to connect the serial line between Foccci and ESP? I was trying to send the log directly via CAN, to avoid the serial line completely, but this would cause a lot of CAN traffic, maybe not the best idea.

[axiv]

Hello all!
Does anyone have the opportunity to test Foccci+Clara on a Schneider EVlink CCS charging station? Or do you already have experience charging at this charging station?
If I set

Code: Select all

isLightBulbDemo==1

, I get the error "0x85 OverVoltage" on the station screen, while in the log I see a voltage much higher (~520V) than I request (400V) and "EmergencyShutdown". Reducing the value of

Code: Select all

pev_Delay Cycles = 15;

does not lead to anything.

If I set

Code: Select all

isLightBulbDemo==0

, I get the error "0x23 PEV incoherent pilot state during charge" on the station screen, while in the log I see a smooth decrease in voltage from 400V (while the current is zero) and "EmergencyShutdown". Reducing the value of

Code: Select all

(pev_cyclesLightBulbDelay<=33*2)

does not lead to anything.

More from the observations: the solution https://github.com/uhi22/ccs32clara/issues/22 at some stations, it gives a very strong voltage increase during

Code: Select all

if (pev_DelayCycles>0)
{
pev_DelayCycles--;
      return;
}. 

At one unnamed station, I saw a 750V.

[uhi22]

I guess you are testing without a battery connected, right? I do not know the Schneider station, but observed similar effects on the Ionity, like here: https://github.com/uhi22/pyPLC/blob/mas ... -veefil-pk
Not all chargers are able to handle the case, that there is no load (or no battery) connected. They try to deliver current, and their voltage regulation is not able to react accordingly. The voltage rises far above the demanded voltage, and they shut down due to overvoltage.
This is kind of "normal", the chargers are not designed for this use case. It is no issue if a battery is connected, because then the voltage is mainly given by the battery voltage, and the current regulation will do its job, and the voltage regulation has no hurry.

[axiv]

no, I tried separately and with a load of 8 kW and separately with a real battery.

[axiv]

Maybe it will lead to some thoughts on correcting the code.
Tests with a real battery.
After "PreCharge" we get "[EVSEStatusCode: EVSE Emergency Shutdown (5)]" in the "PowerDeliveryResponce" package.

[axiv]

Into the piggy bank of knowledge. From the data exchange sniff of the charging station with the BMW i3: at the "Precharge" stage, a current of 0A is requested. At the charging stage, the current is requested gradually, with an increase of 1.5-2 A per packet

[axiv]

Victory! Analyzing the data exchange, I found the problem of the Clara state machine. After sending the "PowerDeliveryReq" package, the "PreChargeRes" package arrived from the station (there were repeated shipments of the "PreChargeRes" package). At the same time, the state machine was in the "stateFunctionWaitForPowerDeliveryResponse" state. In fact, the world of high currents with high voltage pulses is not ideal and TCP packets may be lost or re-sent. In a good way, it is necessary to check in each subsequent state of the state machine whether a response packet has arrived from the previous state.
Now I'm in the "stateFunctionWaitForPowerDeliveryResponse" function checking

Code: Select all

if (dinDocDec.V2G_Message.Body.PreChargeRes_isUsed)

and if the packet is from the "PreChage" state, then I resend "pev_sendPowerDeliveryReq"
After the firmware edits are made, it works like a Swiss watch

[axiv]

By the way, not only the Schneider charging station in the "isLightBulbDemo=1" mode, but also some others begin to compensate for the lack of load by increasing the voltage. But not all such stations go into the "OverVoltage" state at the same time

[uhi22]

After sending the "PowerDeliveryReq" package, the "PreChargeRes" package arrived from the station (there were repeated shipments of the "PreChargeRes" package).

I'd like to have a look to the log (clara serial and/or pcap if possible). I would have expected, that just ignoring duplicated packets is sufficient, but obviously we have a situation here which needs an improved handling.

[axiv]

I'd like to have a look to the log (clara serial and/or pcap if possible). I would have expected, that just ignoring duplicated packets is sufficient, but obviously we have a situation here which needs an improved handling.

I replied to you in a private message

[axiv]

I also had unsuccessful charging attempts that "broke down" when exchanging slac data. I assume that this may be related (similarly to UDP exchange) to the re-sending of packets from the station. I will continue to explore, I will share the results

[axiv]

https://github.com/ChargePoint/wireshar ... tag/v0.8.0
It helped a lot to parse the log into WireShark

[uhi22]

The wireshark plugin for decoding the exi is really helpful. In the past I struggled with the installation, but today I managed it and added an instruction chapter (for dummies like me) here: https://github.com/uhi22/pyPLC?tab=read ... der-plugin

Regarding the precharge current, Foccci/Clara are using the 1A because I found this in my OEM Hyundai Ioniq (https://github.com/uhi22/Ioniq28Investi ... k.csv.pcap). Hopefully this will work with all chargers for the next ten years

[LRBen]

Quick note mostly to myself in six months time when I'm searching the forums for this issue, but hopefully it might also help others.

When flashing the SPI chip I found that it wouldn't work when supplying 12v power and wake to the FOCCCI board. I had to supply 3.3v from the raspberry pi rail to the 3.3v header on the Foccci board.

[Bigpie]

My first attempt at CCS charging, having successfully used FOCCCI as a charge interface for AC charging, resulted in failure.
I've attached my params and UART log, if anyone spots anything that might be causing it.
Thanks

[Bigpie]

I've now setup pyPLC on an RPI to investigate further.

So with the scope attached to the EVSE side modem output I see this repeating signal.

Bringing in the PWM with resistor and capacitor this is what I see, this is without FOCCCI connected.

So looks like the EVSE side is working.


On to FOCCCI

We see the PWM, the UART log displays that it's sending SLAC_PARAM.REQ and timing out.

Without the EVSE modem attached the 5% PWM is clean, no sign of any signal modulation.

So looks like I need to look further in to my board. It's a v4.2

EDIT*
so TX_N and TX_P are at 1.6v but 13kohm between them. RX_N and RX_P are at 0.3v and 500ohm between them. Any hints on where the shorts could be?

[johu]

Have you manually placed the QCA? It is super tricky. My faults of the kind you describe were 100% caused by poor soldering.

[Bigpie]

I did and I never want to do it again. I thought because it was reporting modem found I was good, but guess not.

[Bigpie]

Soldering attempt number 9000 did the trick.

My pyPLC now thinks it's charging away

[tom91]

We got our first Zombieverter and Foccci charging event. Thanks @Bigpie

Zombie code base now has the Foccci CCS support. Also added the setting of the DC charging state in the CCS statemachine in the Foccci.
https://github.com/damienmaguire/Stm32- ... 64a5e75d50

[uhi22]

Great, congratulations, and a big thanks Tom and Bigpie
I do not want to be too strict, but since we are still in the beginning maybe it is possible to rename the file and the class to contain the triple c.

[tom91]

the triple c.

Yes will do, caught it late and left it during dev.

https://github.com/damienmaguire/Stm32-vcu/pull/140 pull request done