QCA7000 Foccci+Clara User thread

[uhi22]

The parameter EVMaximumVoltageLimit is explained here: https://openinverter.org/wiki/Foccci#Parameters

But before changing this parameter, could you please test whether with the latest fix now Foccci tells correctly what went wrong? The software is available here: https://github.com/uhi22/ccs32clara/act ... 0247825798

[evMacGyver]

Thank you for investigation! Zombie adds 10 volts over Voltspnt and I did not think that, so it got over the set maximum. Just thinking this request over maximum voltage problem, are there any cases where it would be needed to send higher request, because Clara could just limit request voltage to maximum voltage?

Upgraded to latest git version and did few charger tests, battery was quite full. 0608-kempower-neste.txt should still be maximum 330v and set point 333v, but not 100% sure anymore after long day. It gives "[19380] Charger reported EVSE_Malfunction. A reason could be hitting the EVSEMaximumVoltageLimit.". EVSE is 400/800v so should not hit the limit.

Another log from different station with similar Kempower EVSE 0608-kempower-abc-350v is maximum set to 350v and charge set point lower. Same malfunction and timeout after that. Evse said on both cases "charging is ended" and basically nothing more.

On the bright side, Tesla supercharger first try today and successful. Hypercharger HYC300 and Lidl ABB has been the most reliable one for me. Both chargers + TeslaSC been fine even maximum voltage was set too low.

One note for Lidl ABB which does not like plug inserted before authentication or it goes "out of service" very quickly and EVSE needs to be booted remotely, which is strange. I'll try this again some day.

[uhi22]

My first thought was: No, we do not add additional plausibilization into Clara, because this makes trouble shooting more complicated and just is a workaround to live with wrong parametrization.
But yes, let's make the life a bit easier. I now added a limitation of the voltage request, which is one volt lower than the parametrized MaxVoltage. Why one volt? Choosing zero tolerance would immediate trip the overvoltage detector. Choosing too much would irritate the people. So the 1V is a (ugly) compromize. It leads also to a warning in the log, so the user is aware of the wrong parametrization.
Basically if Zombie decides for a certain voltage, I would assume that this is based on the BMS or whatever, and is BELOW the overvoltage threshold. So the clean way would be, to parametrize Zombie (or BMS or whatever) to a highest normal operation voltage, which is requested to Clara, and in Clara set the overvoltage threshold 5V above the highest normal voltage.

"[19380] Charger reported EVSE_Malfunction. A reason could be hitting the EVSEMaximumVoltageLimit.". EVSE is 400/800v so should not hit the limit.

Thanks for testing. Yes, this is the message I expected. But the wrong text, I wanted to write "EVMaximumVoltageLimit". Corrected now and mentioned both possiblities, because we do not know which criteria the charger has to report this malfunction.
There may be even a real malfunction, which is not caused by Foccci/Clara. Do you know whether the kempower works with other cars reliably?

[uhi22]

In the 0608-kempower-abc-350v log we see:
- EVMaximumVoltageLimit is now parametrized to 350V, as expected.
- PreCharging to 306V works. Is this a plausible voltage for 79% SOC?
- charging loop runs, with EVTargetCurrent=44A and EVTargetVoltage=336V.
- after ~6 loops, the charger seems to try to deliver power, and the EVSEPresentVoltage jumps from 306V to 324V. With zero current, and EVSEStatusCode saying EVSE_Malfunction.

This looks like the charger does not see the battery, because jumping by 20V should for sure lead to a significant current. Maybe the charger has an issue with its output contactors, or the car with the CCS contactors. I guess you have not connected a voltage measuring board at the CCS inlet, this would help to see whether the inlet voltage also rises or stays at 306V, so we would know whether to search inside the charger or inside the car.

Or: The real battery was at 324V, and the precharge target was wrong. So the charger precharged to 306V, then the contactors closed and the voltage jumped, driven by the battery, to 324V, so the charger saw an unexpected jump and ran into error.

[PoloLbricolo]

I finally got arround to making my CCS2 and type 2 work with orion BMS.

I just got one last issue with locking the plug in the socket when charging in AC, it simply doesn't lock at all. for now the BMS sends OBCState to 2 as soon as a plug is plugged.

What am i missing ?

[evMacGyver]

Precharge 306v sounds about right for 79% SOC.

Before this log I did long CCS on another station, I highly doubt car contactor fault. I'll check from logs where you found this 324V, so I can see is same jump problem with all Kempower stations, as I just posted one log and tried yesterday two different stations. This log was taken just after previous car charged successfully and that was quite busy station on the same day.

I think today I'll switch back from EVSE voltage reading back to voltage board reading. Needed to switch EVSE source while playing pyPLC in EVSE mode, but impossible to remember was this switch before Kempower problems started as these stations did work before. If voltage source gets successfully charging then there is a big mystery why.

[evMacGyver]

What am i missing ?

Enable? Just to notice, current code does read button while AC charge, so without mod lock won't release.

[tom91]

I just got one last issue with locking the plug in the socket when charging in AC, it simply doesn't lock at all. for now the BMS sends OBCState to 2 as soon as a plug is plugged.

What am i missing ?

Note coded in right now, I am working on adding it for its integration into ZombieVerter.

[uhi22]

I just got one last issue with locking the plug in the socket when charging in AC, it simply doesn't lock at all. for now the BMS sends OBCState to 2 as soon as a plug is plugged.

What am i missing ?

There is the concept missing, in which cases the AC cable shall be locked and unlocked. Could you list the requirements from your point of view, and we look how this can be implemented.

[tom91]

There is the concept missing, in which cases the AC cable shall be locked and unlocked. Could you list the requirements from your point of view, and we look how this can be implemented.

I can provide my code Not yet fully verified yet.

Nevermind, for some reason I am behind the updated that Johu did 3 weeks ago... So my code is now irrelavant as he overhauled the whole acOBC.cpp and for some reason when doing my pull on July 25th it did not take these.

He added the locking and unlocking code though so it should work.

[uhi22]

Well, still the concept discussion is important. At the current implementation, we see:
* Clara locks and unlocks the connector based on the Param::AcObcState. It needs to be defined, under which conditions in the car this value is set to which value.
* The implementation in https://github.com/uhi22/ccs32clara/blo ... C.cpp#L171 looks not really complete.
- OBC_IDLE leads to unlocking. Ok. But what if the user wants to be a permantent locked cable to avoid stealing it?
- OBC_LOCK, OBC_PAUSE, OBC_ERROR and OBC_COMPLETE leads to locking, when coming from OBC_IDLE. From my PoV only the OBC_LOCK is the relevant case.
- OBC_CHARGE has the comment "lock connector here..." but calls "Unlocking" function. Not sure what was the plan.

So a lot of improvement possible, in best case while doing a real car integration, so that a single person has a concept in mind how it all shall play together. Most likely other persons have other concepts in mind, and multiple concepts make sense, so in the end there could be a parameter which makes it possible to select between different approaches.

[tom91]

Well, still the concept discussion is important. At the current implementation, we see:
* Clara locks and unlocks the connector based on the Param::AcObcState. It needs to be defined, under which conditions in the car this value is set to which value.
* The implementation in https://github.com/uhi22/ccs32clara/blo ... C.cpp#L171 looks not really complete.
- OBC_IDLE leads to unlocking. Ok. But what if the user wants to be a permantent locked cable to avoid stealing it?
- OBC_LOCK, OBC_PAUSE, OBC_ERROR and OBC_COMPLETE leads to locking, when coming from OBC_IDLE. From my PoV only the OBC_LOCK is the relevant case.
- OBC_CHARGE has the comment "lock connector here..." but calls "Unlocking" function. Not sure what was the plan.

So a lot of improvement possible, in best case while doing a real car integration, so that a single person has a concept in mind how it all shall play together. Most likely other persons have other concepts in mind, and multiple concepts make sense, so in the end there could be a parameter which makes it possible to select between different approaches.

The unlocking when finishing a charge is a challange, only way to set it from not unlocking would be a parameter that can then be mapped to CAN. like Unlock Inhibit.

It does indeed seem Johu has not done this cleanly, and there is a few mistakes.

I believe currently the push button does not impact the AC charging? I will have a look if I have time this afternoon to do some work on the AC charging side of things.

[tom91]

https://github.com/uhi22/ccs32clara/com ... ee2cd35b7f

Here we go my interpretation of how to clean it.
-Clean up of deciding to lock only when actuator states not locked
-Only go into State C if the actuator is Locked
-Implemented a push button to stop AC charging with a 30s window to unplug before resuming charge.
-Added param to block unlocking, currently only in AC charging.

Push looks messy due to formatting different, how to best align this?

[uhi22]

Great, thanks. Regarding the formatting, I do not want to start the "formatting war", so everybody can just use the formatting he/she wants. I would wish to not mix big formatting changes with functional changes in one commit, because the review effort is increased. Just for the future, no need to split your recent changes into two commits.
The case when Param::AllowUnlock is false needs to be further improved, because at the moment I understand the connector is locked "forever". It could be necessary to create a separate unlock command variable, which could be mapped to e.g. the unlock command of the central lock.

In case you have a certain stable state which we could integrate into the main branch, just create a pull request. Or, we discuss, test and improve the AC topic on your branch for a certain time and the other interested folks can take the software from there. Both is fine for me.

[evMacGyver]

EDIT: SUCCESS!! Edited hwIf_handleContactorRequest by commenting out contactor 2 delay:
ContactorOnTimer2=0;//-CONTACTOR_CYCLES_SEQUENTIAL;

And Kempower seems to ramp quite fast actually, so I would say these worked before there came contactor delay.

---older thinking---

Did not work before:

Code: Select all

[19200] Turning on charge port contactor 1
[19210] In state PowerDelivery. TcpRetries 0
[19260] ETH rx IP: 02351380244360fab144913386dd6005928800140640fe8000000000000062fab1fffe449133fe80000000000000c69083f3fbcb981ed431e7542a621d50000002d1501001fa27ee0000
[19290] ETH rx IP: 02351380244360fab144913386dd60059288002e0640fe8000000000000062fab1fffe449133fe80000000000000c69083f3fbcb981ed431e7542a621d50000002d1501801fa3530000001fe800100000012809a023a6e13472338295011400420405000
[19290] [TCP] sending ACK
[19290] ETH will transmit: 60fab144913302351380244386dd600000000014060afe80000000000000c69083f3fbcb981efe8000000000000062fab1fffe449133e754d431000002d12a621d6a501003e825e60000
[19290] Data received:  01fe800100000012809a023a6e13472338295011400420405000
[19300] Checkpoint700: Starting the charging loop with CurrentDemandReq
[19300] TCP will transmit: 01fe800100000023809a023a6e13472338295010d1401280c0c0b06001810580480c08360100c143580800
[19300] In state CurrentDemand. TcpRetries 0
[19380] [TCP] sending ACK
[19380] Data received:  01fe800100000028809a023a6e13472338295010e0004080a0018280001818000000060a1e806030303e028386e05800
[19380] TCP will transmit: 01fe800100000023809a023a6e13472338295010d1401280c0c0b06001810580480c08360100c143580800
[19410] [TCP] sending ACK
[19410] Data received:  01fe800100000028809a023a6e13472338295010e0004080a0018280001818000000060a1e806030303e028386e05800
[19410] TCP will transmit: 01fe800100000023809a023a6e13472338295010d1401280c0c0b06001810580480c08360100c143580800
[19440] [TCP] sending ACK
[19440] Data received:  01fe800100000028809a023a6e13472338295010e0004080a0018280001818000000060a1e806030303e028386e05800
[19440] TCP will transmit: 01fe800100000023809a023a6e13472338295010d1401280c0c0b06001810580480c08360100c143580800
[19470] [TCP] sending ACK
[19470] Data received:  01fe800100000028809a023a6e13472338295010e0004080a0018280001818000000060a1e806030303e028386e05800
[19470] TCP will transmit: 01fe800100000023809a023a6e13472338295010d1401280c0c0b06001810580480c08360100c143580800
[19500] [TCP] sending ACK
[19500] Data received:  01fe800100000028809a023a6e13472338295010e0004080a0018280001818000000060a1e806030303e028386e05800
[19500] TCP will transmit: 01fe800100000023809a023a6e13472338295010d1401280c0c0b06001810580480c08360100c143580800
[19530] [TCP] sending ACK
[19530] Data received:  01fe800100000028809a023a6e13472338295010e0004080a0018280001818000000060a1e806030303e028386e05800
[19530] TCP will transmit: 01fe800100000023809a023a6e13472338295010d1401280c0c0b06001810580480c08360100c143580800
[19530] Turning on charge port contactor 2
[19560] [TCP] sending ACK
[19560] Data received:  01fe800100000028809a023a6e13472338295010e0004080a0018280001818000000060a1e806030303e028386e05800
[19560] TCP will transmit: 01fe800100000023809a023a6e13472338295010d1401280c0c0b06001810580480c08360100c143580800
[19650] [TCP] sending ACK
[19650] Data received:  01fe800100000029809a023a6e13472338295010e000c300a081828608101818000000060a1e806030303e028386e05800
[19650] Charger reported EVSE_Malfunction. A reason could be hitting the EVMaximumVoltageLimit or EVSEMaximumVoltageLimit.

Just wondering why contactor 2 is turned on so late after current demand begins? With working chargers Contactor 2 was closed late but maybe chargers are just bit slower to ramp up its output.

[tom91]

The case when Param::AllowUnlock is false needs to be further improved, because at the moment I understand the connector is locked "forever". It could be necessary to create a separate unlock command variable, which could be mapped to e.g. the unlock command of the central lock.

This Param is defaulted to ON in the parameters, so it will always allow unlocking unless you change the parameter via the CAN or user interface. This way it does not change base function upon updating.

Is the formatting standard saved anywhere on the git? I can change my codeblocks to use it no problem, I am quite format agnostic.

[uhi22]

No, we have no formatting information saved. I do not even know what is possible in this direction, if everybody uses a different editor (VSCode, Notepad++, Codeblocks, vim). The only rule is: Avoid to combine big format changes together with functional changes. And do not auto-format if this leads to massive changes.

I think now I got the idea param:AllowUnlock. It can be mapped to CAN, so eg if the car is locked it can be set to 0 and if the car is unlocked it can be set to 1.

[uhi22]

Just wondering why contactor 2 is turned on so late after current demand begins?

Well, this is a clear design fail. We introduced the interleaved contactor switching, but did not consider that we must delay the PowerDeliveryRequest and the CurrentDemandRequest accordingly. I'll have a look how to fix this.

EDIT: Ready for testing. Added a time-based delay for the PowerDeliveryOn, and this will delay the CurrentDemand, so that both contactors have time to close now. https://github.com/uhi22/ccs32clara/com ... f621c33ad9

[xvyDFatih]

Is this focci board can use in realworld electric vehicle. Is is need any test or standard?

[uhi22]

Sorry, what is the question? Yes, the Foccci is used in some real world home converted electric vehicles. Some of them are in the gallery: viewtopic.php?t=5077

[xvyDFatih]

Sorry, what is the question? Yes, the Foccci is used in some real world home converted electric vehicles. Some of them are in the gallery: viewtopic.php?t=5077

I mean is is need pcb tests like emc, electric vehicle standards?

[tom91]

I mean is is need pcb tests like emc, electric vehicle standards?

Depends on in which jurisdiction you do your conversion. Some example info on the wiki https://openinverter.org/wiki/Category:Legalities

[evMacGyver]

My home EVSE is Tesla Wallbox gen 2. Does anyone know is there something tricky with these, does it try to communicate using 5% CP?

This mystery is now solved also. Wallbox plug temperature sensor must haev failed about the same time as I moved to Foccci, I didn't notice Wallbox red LED flashing once in about 3 seconds, now replaced sensor with a resistor and EVSE is working fine.

There is also Legacy mode for communication which is more for type 2, tried both modes with success and kept Standard or whatever mode it was earlier.

[davefiddes]

Is the formatting standard saved anywhere on the git? I can change my codeblocks to use it no problem, I am quite format agnostic.

I reverse engineered johu's formatting rules as best as I could from stm32-sine and created a .clang-format definition:
https://github.com/davefiddes/c2000-inv ... ang-format

clang-format is a very common formatting engine for C++ and integrates with pretty much any IDE/editor. I apply it to the regions of code I'm modifying before submitting a PR. For my own projects I apply it to the whole file as I save it which means I never need to think about formatting.

[Zieg]

Oh man, I had been assuming implementing something like this wasn't possible with my setup (Thunderstruck/Dilithium MCU), but the latest MCU documentation does go over some fast charge options, including Chademo and the Zero EV CCS controller. Is it easy to tell from this documentation if my BMS would give Foccci everything it needs? I think I could set it up for Chademo but would need Foccci to get the pack voltage via an OBDII protocol (unsure if possible), or could I just set it to ZEVCCS mode and configure Foccci to accept/return these CAN messages?

If anyone sees any issues or reasons it wouldn't work I'd appreciate hearing. Here's the relevant section of the PDF screenshotted and stitched:

This is really exciting if it would work! Especially after how long I had to sit at a public station charging at 3kW yesterday, haha.