Develop a QCA7000 board?

[uhi22]

Regarding the parameter which turns-on the logging to serial:
1. In the web-interface I can choose from the dropdown list only single-bit-values. How to set multiple (or all) bits?
2. Save to flash does not work. I propose to safe this parameter to flash, otherwise the risk is high to do tests and in the end see: oh, there is no data logged
3. I do not see drawbacks due to the logging, so I propose to set the default to "everything logged". This makes it more like to find issues fast.

[uhi22]

Would be good to see both direction of the traffic. Maybe the charger does not announce its physical limits, but instead announces a combination of its own limits and the limits which clara sent in the ChargeParameterDiscoveryRequest. Exactly our values:

And yes, it says "EVSE_Malfunction". Maybe some combination of the parameters are not plausible enough. But which?

image.png (11.26 KiB) Viewed 303185 times

[uhi22]

How do I get the parameters to the console?

First precondition is: You need to flash the latest firmware and bootloader with STlink. I tried to describe this here: https://github.com/uhi22/ccs32clara/blo ... uild-chain You do not need to build by your own if you just use the two hex files attached above.

If your board talks with 900kbaud on serial, you have the correct firmware. If it talks with 115k, it is the old one without web interface support.

Second thing: You need to select nodeID 22 in the web interface.
Third thing: usually I also see just no parameters after first startup. Than, after some playing around with the sliders for autoreload and beta functions, suddenly the parameters and spot values are perfectly there. No idea whether waiting some seconds would also solve this.

[johu]

Hmm, I remember Damien said the maximum voltage shouldn't be too close to the target voltage as he got false over voltage triggers. Will set this higher and retry.
I think I will add a parameter category "Limits" that lets you set these.

Try using the console "set logging 511" would enable everything. Just add flags. Could also add pre-defined combinations to the enum. Like 511=All.
It does increase runtime dramatically even at 921k and I think only knowledgeable users will take logs who can be told how to turn it on.

[johu]

Third thing: usually I also see just no parameters after first startup. Than, after some playing around with the sliders for autoreload and beta functions, suddenly the parameters and spot values are perfectly there. No idea whether waiting some seconds would also solve this.

When you connect for the very first time it downloads the parameter info which takes a second or so. That's why the first refresh fails. But the file is cached - until a new version is flashed.

Auto-refresh defaults to off. Turning it on will start polling. If it is on sometimes you need to turn it off and on again (ever heard that one? )

[muehlpower]

I think flashing worked, but I don't get any parameters. The serial port is sending something, but I think my ttl to rs232 (no usb) is too slow. If I change the nude ID, I can observe a CAN message. 0x614 for ID20, 0x615 for ID21 etc. Only for ID22 do I get a response on 0x596.

[uhi22]

If you see the responses at 0x596 everything is fine with clara and the CAN connection, maybe just refresh the web page?

[uhi22]

I'm struggling with the version number. If I add a new parameter in param_prj.h and increase the version number in the VER macro, I see the new parameter and the version in the webinterface. If I revert the change (remove the parameter), and increase the version number again (because I changed something in the code), the web interface again shows the OLD version, no matter what I do with the VER macro. Is this intended? Is the VER a kind of "parameter list version", which only changes if the parameters are changing? Or is it a software version, which I shall change everytime when something on the software is changed?

EDIT: Pushed an update which prints the TCP traffic (both directions) and the state machine reaction per default.

[johu]

There is a sum across all UIDs that is supposed to track changes to the parameter list. But of course this won't track if you rename a parameter or change the unit name. Version is kept in the unit name.

To fource reload the list you need to delete all <some_hex>.json files on the esp32 then select some random node ID and then 22 again and shortly wait for the download.

I didn't think it was relevant for normal users as new releases usually contain significant parameter changes. But for development it's a bit dodgy of course. You could randomly change the ID of an unimportant (i.e. not mapped to CAN) spot value to for an ID sum change

[johu]

I changed precharge a bit. When batvtg < EVSEMinimumVoltage then precharge never finishes. At the same time I default batvtg=0

Probably would be more appropriate to handle this during ParameterDiscovery. Later...

UPDATE: the latest pyPLC gives me error "Could not decode the supportedAppProtocolReq"

UPDATE2: needed to update OpenV2Gx as well, now all working

[johu]

Ionity now works!

It must have been the 398V over voltage limit together with 393V battery voltage that made it conk out. I have now retried with 410V and it worked flawlessly. All limits are now parameters.

[uhi22]

Progress: adapted the state machine to support the correct handling of the end of the charging session. Tested this with improved pyPLC/OpenV2Gx, which now simulates the decreasing voltage during WeldingDetection.
New feature: The parameter demovtg (Demo voltage) can be set for situations, where no voltage information comes from outside, e.g. for the light bulb demo or kettle. If this parameter is zero (or unplausible), the battery voltage and target voltage is expected from outside via CAN-mapping.

[f0ld]

The information I have leads to an other solution. Had a look to the Ioniq trace and to the specification. Added the analysis here: https://github.com/uhi22/pyPLC#detaille ... ng-session

The summary:
- PowerDeliveryReq(Stop) is fired under full current.
- The charger needs 1.5s until it confirms with PowerDeliveryRes. Maybe already here, it turns-off the current.
- The car sets stateB, and this is the "fast trigger" to the charger to turn-off the current (I have read somewhere this should be in 20ms, but cannot find this information anymore).
- Here we can simply wait for half a second (conditionless), to give the current some time to fall.
- Open the contactors.
- Wait again 0.5s to give the contactors time to move.
- Send a WeldingDetection. Depending on the charger it will wait (in example 1s, according spec below 1.5s), measure the voltage and report it back in the WeldingDetectionResponse.
- We need to repeat the WeldingDetection loop, until the voltage is not dangerous anymore.
- Then unlocking the connector and send the SessionStop.

Since you cross referenced it in the pyPLC Thread I did a little digging in the IEC 61851-23 regarding the normal end of a charging session.
Heres what my understanding of it is and some comments (also relating to the github link):

[charging]

- EV reduces current request. Charger follows with time delay and reduces output current to less then 1A before disabling its output [so apparently its our job to make sure to reduce the current to less then 1A before continuing in the sequence. Which makes sense since the charger should follow our request and our side is coordinating the sequence]

- EV sends message to charger to disable power output. After current is below 1A the EV opens contactors (in the spec called "disconnecting device")

- Charger disables output & opens contactors

- Charger reports status "not ready" with message to indicate it disabled its output (DC_EVSEStatus.EVSEStatusCode = 2 EVSE_Shutdown) [comment to github: this does not contain voltage or current because the EVs HV should already be disconnected]

- After receiving the above message (or after timout) EV changes CP state to B. This is also where the EV may perform welded contactor check [I personally like the placement of the CP change, since we can (under normal circumstances) confirm that both sides have opened the contactors succesfully. The timout here is crucial to continue in the sequence so we dont stay locked in forever if the charger crashed. If I remember correctly this should be 2s. Welding checks are also defined (especially regarding time) but its mainly a loop until time limit is reached or weld detected. Comment to the 40s: Some OEMs e.g. BMW use multiple contactors for CCS and "cycle" which they use. So Welding checks sometime need that time . If I understand it correctly it currently is not a priority on the ToDo List to implement welding checks. So we can ignore this for now and leave it as a todo for later? (I at least want to use it at some point in the future)]

- EV sends Session Stop Req, terminates PLC and unlocks connector after DC Output has dropped below 60V or energy is below 0,2J. [Till the end of this (with the exception of isolation monitoring during welding checks) the Isolation and lock monitoring is still active]

- Unplugging. CP state from B to A.



This is only my understanding and I am more then open for discussion but from my perspective this makes sense for "normal" operation.

Some questions that also came to my mind:
- It might be usefull to write down the whole cycle (not only the Power Down Sequence) in a structered way. At least what is implemented in Clara. Would have the additional benefit of lowering the entry barrier for new contributors to the project. With the permission of johannes and uhi I would like to make a wiki page for clara and fill it with this information. Maybe even with our own diagramms that we can reference to.

- We currently have no Emergeny Exit procedures implemented correct? Might be worth a point on the ToDo List for sometime down the road. With some mods on PyPLC we could also add tests to confirm they are working...

- Since a lot of people now know and see that Clara + Focci is able to initiate a charging session wouldnt it be usefull to add a Disclaimer to the github repo that this is still WIP and use is on own risk. I dont want to scare people away but at this point people should know that this is not a finished product and be handled with care or give them a realistic expectation (didnt finished watching Johannes newest yt video but from the first opening it seems like this is the same tenor. Congrats on the Ionity success btw ).



And lastly I want to thank Uhi. My Focci Board arrived today and I am excited to play with it over the christmas holidays

[uhi22]

Very valuable inputs, many thanks for these. Brings me a little bit back on the feets: We are not at end of the road, we are just in the middle of the run

[johu]

I published a pre-release now to avoid spilling binaries via the forum (will delete it from my earlier post): https://github.com/uhi22/ccs32clara/rel ... ag/v0.22.B

On other news I added poor mans enable logic to my foccci (now the weird random vias make sense!):

I will be supplying permanent 12V via one of the unused pins. Then there is a PMOS connected to it with its gate pulled to 12V via a 10k resistor. I have completely disconnected PP from the controller. When PP is plugged in it will pull the gate to GND and the PMOS will supply 12V to foccci and also out the normal 12V input. With that I can supply BMS and VCU.

I might start migrating Touran from CHAdeMO to CCS in the coming days.

- It might be usefull to write down the whole cycle (not only the Power Down Sequence) in a structered way. At least what is implemented in Clara. Would have the additional benefit of lowering the entry barrier for new contributors to the project. With the permission of johannes and uhi I would like to make a wiki page for clara and fill it with this information. Maybe even with our own diagramms that we can reference to.

Yes please do start a wiki page. Not sure about a meaningful name - just Open CCS or "OI CCS"? Anyway, can still be changed later.

[f0ld]

Yes please do start a wiki page. Not sure about a meaningful name - just Open CCS or "OI CCS"? Anyway, can still be changed later.

Done.
I thought about the naming as well and then decided the logical thing would be to name the projects as what we currently refer them to when we are talking about it. This makes sure, that the entry boundary for future contributors that read this thread is low.


Additionally I decided in order to prevent clutter to make one page for the Software and one for the Hardware. They are both full sized projects (although connected) and putting them both at one page is (at least at the moment) not helping with readability.
As long as we cross reference the relevant section this also enables us to go more into detail regarding documentation. Also this is just forward thinking to a future where they might be multiple implementations of hardware (or software) for example if we decide to switch one of the two to something new/different.

Also I thought about where generell CCS Explanations, Overview of projects, hardware, etc. fit. I think it makes sense to remove generell explanations how the CCS Standard works from pages like I3 LIM or Clara. This reduces the pages to the relevant information.
So I created a third page named "CCS Fast Charging (Overview)"


Contributions and Feedback as usal more then welcome


Edit: Obviously this is just a first draft and I will add more content in the next weeks

[uhi22]

Really good and totally necessary that someone thinks about a structured way of documentation, because with the developers eyes I often do not see the needs of the "fresh" readers. Thanks for this contribution.

[Bigpie]

Also I thought about where generell CCS Explanations, Overview of projects, hardware, etc. fit. I think it makes sense to remove generell explanations how the CCS Standard works from pages like I3 LIM or Clara. This reduces the pages to the relevant information.
So I created a third page named "CCS Fast Charging (Overview)"

https://openinverter.org/wiki/Rapid_Charging There's a page for the overview of the 2 standards, we should try to avoid duplication on the wiki, but also keep things organised and easy to find.

I would suggest starting from this page, add a link to your overview of the protocol page, and create a new page for the stm32 variant board.

[f0ld]

https://openinverter.org/wiki/Rapid_Charging There's a page for the overview of the 2 standards, we should try to avoid duplication on the wiki, but also keep things organised and easy to find.

I would suggest starting from this page, add a link to your overview of the protocol page, and create a new page for the stm32 variant board.

I saw that page but forget about it in the process. Thanks for the reminder and feedback
I fully agree with you. The linked page is a generell overview of the 2 standards (as you mentioned) so it wouldnt make sense to go too much into detail over there.

I now linked it on there like you suggested. Although the exact wording could use some fine tuning. (Feel free to change as you like)

What do you think about the List of CCS Controllers on the linked page? Wouldnt it make sense (once the CCS Overview page has evolved to something that can be used) to list them there and just reference it on the Rapid Charging page via Link to the CCS Overview page?

Alternativly there could be a mix of both like "most used controllers are: x,y,z. More Details [...] on CCS Overview Page (with Link)".
I aswell dont like duplication but removing the Controller Quick Links completly or only leaving a reference in the rapid charging site doesnt seem great too.
Would the above be a good compromise?

[Bigpie]

Don't suppose it matters as long as there's no duplication where one could go out of date.

[muehlpower]

delete all <some_hex>.json files on the esp32 then select some random node ID and then 22 again and shortly wait for the download.

that makes the difference. Now I can switch back and forth between LDU board with 5.32R.sine and CCS. Only from node 1 to node 22 is quite far. Can I change that, to 1 and 2 for example?

edit: With 5.32R.sine I have node as a parameter, with ccs not.

[uhi22]

You can type the 22 and press enter. No need to use the up/down arrows.

[johu]

I made can speed and node id configurable.
But can make it a parameter anyway. We need to start to keep track of these, perhaps on the https://openinverter.org/wiki/CAN_communication site
So far:
- Inverter 1
- Tesla OBC 2
- Zombie 3
- BMS 3-x (first clash)
- Clara 22

So need to move the BMS somewhere else. It needs one node id per 16 cell module

uhi you said you couldn't save parameters. Is that resolved? Note that most charge parameters are intentionally not saved to avoid stale values (The ones declared as TPARM)

[uhi22]

Yes, everything fine with parameter safing. I was just no aware that there are two classes, the saved and the unsafed.

[johu]

Ok cool.

On other news I charged 5 kWh from a HyperCharger with 30 kW/80A (the CHAdeMO pins were rather warm afterwards). I think with that we've got the major brands covered.

Concerning wiki I found we also have this page: https://openinverter.org/wiki/CCS_EVCC_using_AR7420 . Maybe should be merged into the new pages