Develop a QCA7000 board?

[f0ld]

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

I would rename the page to "pyPLC". I would not merge it completly but just merge the generell CCS Stuff to the new page as it would be a duplication. I feel like pyPLC is especially for debugging and testing still important enough to deserve a separate page with instructions on how to set it up. Also makes linking/refering to it more easy if you just want to guide someone to it specificly (e.g. people that want something to test against their i3 lim).

[johu]

Yes, makes sense.

I've created a CCS category and maybe this could contain the contents of https://openinverter.org/wiki/CCS_Fast_ ... (Overview) and make that redundant. It automatically links to all pages in that category.

EDIT: on another note writing the wiki article on CHAdeMO interfacing reminded me that there is not mechanism for CAN timeout. Since there is no such thing as counters e.g. in CHAdeMO I'd simply add a "watchdog" parameter that needs to be mapped to CAN in a way that it is overwritten by 0. Internally it is counted up every 100ms and once it reaches some limit charging would be stopped. For testing this somehow needs to be disabled

[f0ld]

Yes, makes sense.

I've created a CCS category and maybe this could contain the contents of https://openinverter.org/wiki/CCS_Fast_ ... (Overview) and make that redundant. It automatically links to all pages in that category.

My original intention with it was that I wanted to create a page that also explains CCS from a Beginners perspective since currently we only link to different ressources and I havent seen a single source on the internet that has one (free) centralized source where it is explained thorougly. Since the CCS Standard is rather convoluted this creates a high entry barrier. I also noticed that for example on the pyPLC page you need to always explain at least the basics at the top since even for some of the setup instructions a basic understanding is needed.

The category thing would be fine for me, but if its okay for you I would rename the overview page to "How CCS works" or something simmilar. (This then could still be linked on the top of e.g. the pyPLC page and remove the duplications.

EDIT: on another note writing the wiki article on CHAdeMO interfacing reminded me that there is not mechanism for CAN timeout. Since there is no such thing as counters e.g. in CHAdeMO I'd simply add a "watchdog" parameter that needs to be mapped to CAN in a way that it is overwritten by 0. Internally it is counted up every 100ms and once it reaches some limit charging would be stopped. For testing this somehow needs to be disabled

This is a very interesting and important point. I have two larger feature requests/proposals that I want to make regarding interfaces (but need to finish writing those up, since I want to structure them first ). One of them might be connected to this since it is also about the CAN Interface.

But for now: How is the CAN Interface currently implemented? Are there Readbacks of the messages? If not it might be a generell problem we should think about since a CAN-Node might decide to stack up a lot in the TX (if it gets disconnected) and decide to just dump the messages on the bus once it is connected back to the bus (which obviously would be a huge problem).

If there are readbacks it might make sense to implement something like a heartbeat every x seconds or so.
If a heartbeat is not received this works as a "timout". Otherwise I would see a problem to differentiate between plausability or importance of the timings from different nodes. And if you think of a generall interface design there might be nodes that dont need to send that data every x ms since there is nothing changed (e.g. Isolation monitoring, lock, etc. in a seperate Unit).

Regarding the disableing: I am always a fan of giving the user controll. Since this is more of a dev board then a finished product, I would prefer a setting in the software that by default is enabled and can be disabled. Would also make it easy for people implementing the "other" site of what is communicating to focci/clara.


[Site note:
Or from a different perspective it might make sense to implement generall plausability checks for your "saved" Values e.g. Voltage, etc.

I will need to put a CAN Bridge between focci and my car anyway but will for example implement as a safety feature some plausability checks like not going over my (by the cell manufacturer) predefined charging curve. So even if the BMS sends me wrong data or an error occurs at the can segment gateways I dont blow up my battery.
]

[johu]

In all lib OI projects CAN uses the 3 message hardware buffer and if that fills up it uses a 20 message deep stack. I suppose if you disconnect it from the net the hardware buffer never empties because it gets no ACKs. So then the software stack doesn't empty either. Once you reconnect you get 20 stale messages and then new messages. Or new and then 20 stale, not 100% sure.

I have now implemented the simple watchdog for one CAN Id: https://github.com/uhi22/ccs32clara/com ... 60ae3e475d

So say you use CHAdeMO CAN then 0x102 is the most important message containing the current set point. So you'd map in OI lingo "can rx canwatchdog 258 0 1 0 0". So whenever 0x102 arrives it sets canwatchdog to 0 (Because gain=0).

Every 100ms canwatchdog is incremented by Clara and when it reaches 5 (500 ms) this is considered CAN timeout and charging is stopped.

I think chargecur is the single most important item that is continuously updated. batvtg is only important at startup and can then even be not updated anymore. targetvtg also never changes. So I don't think right now not more than one node needs to be watch-dogged. FMEA it

EDIT: just tested with Clara, works (almost) as expected. Only the charge cycle then restarts. We should inhibit that while hardwareInterface_stopCharging() is true

[asavage]

I would rename the page to "pyPLC". I would not merge it completly but just merge the generell CCS Stuff to the new page as it would be a duplication.

The wiki AR7420 page was initially a one stop place to begin the CCS PLC journey with the hardware we had on hand at the time (pre-foccci) and a sort of recipe developed to begin that journey, documenting what had been learned and posted in the forum thread, so that anybody could "jump in" using only the wiki and have a reasonable shot at achieving what had been achieved, without having to read about all the dead ends in the thread.

From the perspective of where open source CCS is now, some of that page probably could be moved to a pyPLC page of its own, but much of that page remains specific to the AR7420 hardware.

[celeron55]

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.

Has focci+clara been tested on Delta chargers? Or, has anyone gotten pyPLC to work on those either? I know I didn't.

I haven't had time to do testing after summer, and even then I was using an old version of pyPLC (which I found to work best at the time).

[johu]

Has focci+clara been tested on Delta chargers? Or, has anyone gotten pyPLC to work on those either? I know I didn't.

I've never seen one around. Do you know which providers typically use them?

On other news I've tidied up the code a bit and defined some error messages and documented stuff at https://openinverter.org/wiki/CCS32Clara

[f0ld]

I've never seen one around. Do you know which providers typically use them?

Comfortcharge (Telekom) uses Delta Chargers (Delta EVC 150; Delta UFC 200).
Also have seen them used scattered by MER and Allego. But I think both replaced them with Alpitronic Units.
Which (from my perspective) makes sense, since the ones I came in contact with were not really the most reliable units.

I had one pretty close to me that was operated by Virta Global. I think they still use it often. The one that was close to me was replaced with a much nicer Siemens SiCharge D. The Delta one had a lot of problems. My sample size is not big enough but from my (limited) experience of a couple units, they are not the best units on the market .

On other news I've tidied up the code a bit and defined some error messages and documented stuff at https://openinverter.org/wiki/CCS32Clara

Nice! The documentation and code cleanup is much appreciated (I really enjoy that we now have a single formatting style. Improves readability a lot!)


Also I noticed that it might be worth to document test results in a central, standardized, ordered manner. I created a PR on Github regarding this.

[P.S.Mangelsdorf]

I've never seen one around. Do you know which providers typically use them?

Here in the southeastern US, EVGo has been installing Deltas almost exclusively. My car is off the road for a bit longer, but I'd be happy to test once its back up.

[uhi22]

Progress with the board: fixed some of the todo items. The most relevant is the transformer:

... I would strongly recommend making some layout improvements here for the next revision of the board. In particular, the current paths for the input and output capacitors are much too long.

Which JLC part number has this inductor? I today changed from
https://jlcpcb.com/parts/componentSearc ... t=C3000379 (which is 12.3 x 12.3mm)
to
https://jlcpcb.com/parts/componentSearc ... t=C5127462 (11.5 x 10mm),
but this still looks bigger than the one in your screenshot, and we do not need the 8A rated current.

[catphish]

Which JLC part number has this inductor? I today changed from
https://jlcpcb.com/parts/componentSearc ... t=C3000379 (which is 12.3 x 12.3mm)
to
https://jlcpcb.com/parts/componentSearc ... t=C5127462 (11.5 x 10mm),
but this still looks bigger than the one in your screenshot, and we do not need the 8A rated current.

The inductor I originally suggested was https://jlcpcb.com/partdetail/Sunlord-M ... MT/C408412
Sorry I didn't get a chance to do these PCB changes for you.

[uhi22]

No worries Thanks for the hints, now it's way better (but still some room for optimizations):

stepdown on foccci, optimized layout and L size

image.png (27.17 KiB) Viewed 467686 times

And each time something new at JLC:
1. The rotation of some components was again wrong, even if two months ago it was perfect, and I did not change anything with these parts. Maybe they had a data base update where they changed the default orientation. Lesson learnt: always check in the jlcs viewer the orientation of all parts.
2. More irritating: The economy service does not populate the big elco anymore. They did the last time, but this time, they give the choice to either not populated it or switch to the expensive service. Any idea how to workaround this?

jlc limits for economy service

[royhen99]

Footprint is for 10x10mm part number is 8x10mm, not sure why error mentions 0201. Works ok with C3445244.

C75 is also incorrect, footprint is 8x10mm part selected is 6.3x5.5mm.

[johu]

2. More irritating: The economy service does not populate the big elco anymore. They did the last time, but this time, they give the choice to either not populated it or switch to the expensive service. Any idea how to workaround this?
image.png

The best way would be to get rid of all elcaps. I've done so by using converters that only need like 10 uF input and output capacitance. Elcaps also have the nasty habit of falling off, at least when JLCPCB populated them. Alternatively do thruhole ones.

Have you added wakeup via PP and a powerful 12V output (say, 5A) for running components needed for fast charging?

EDIT: viewtopic.php?p=64221#p64221
EDIT2: issue created https://github.com/uhi22/foccci/issues/2

[uhi22]

Footprint is for 10x10mm part number is 8x10mm, not sure why error mentions 0201. Works ok with C3445244.

Thanks a lot, this works. Pushed the update.

C75 is also incorrect, footprint is 8x10mm part selected is 6.3x5.5mm.

Yes, this is "a little bit on purpose" (but not really consenquently). I tend to use bigger footprints, to enable hand-soldering with just available parts. Even if the jlc parts are smaller. Yes, I see, it's a bad habbit, to stick to the old things, but I need some more steps until I'm convinced that the time for hand-soldering is over. And if it is, we could move to even smaller sizes for the many 0805 parts.

The best way would be to get rid of all elcaps. I've done so by using converters that only need like 10 uF input and output capacitance. Elcaps also have the nasty habit of falling off, at least when JLCPCB populated them. Alternatively do thruhole ones.

The stepdown is one thing, the switching of loads on the 12V is the other that require some capacitance. I see that the JLC uses a very small amount of tin, nearly nothing I would say. This fails if we have heavy components and vibration. Through-hole would be indeed more reliable. But on the other hand I've seen surface mounted elcaps a lot in the automotive, sometimes glued, often not. Seems to depend on the soldering process, whether this works over years.

Have you added wakeup via PP and a powerful 12V output (say, 5A) for running components needed for fast charging?

EDIT: viewtopic.php?p=64221#p64221
EDIT2: issue created https://github.com/uhi22/foccci/issues/2

No, just stabilizing the "version 4 features", until we start with the sleep/wakeup-things, which are intended for v5 (and this is faaar away). Maybe nearer than I felt
[EDIT] For discussion the wakeup / sleep topics, created a separate thread, to avoid too many topics mixed together here. viewtopic.php?p=65022#p65022

[uhi22]

Regarding the "Demo mode": My personal use case for the foccci/clara is, to be able to make a tea or some waffles during the charging breaks, and in this use case the device shall just give 225V on a socket without grabbing the laptop to parametrize something after each plug-in. That's why I added the parameter demovtg (Demo voltage), which is NOT volatile. The wiki (https://openinverter.org/wiki/CCS32Clara) says that demovtg is volatile. We should align the goal If it comes to safety, we could introduce a redundant non-volatile parameter, so that the two use cases "CAN controlled" and "standalone" cannot be mixed-up by setting one single parameter.

[quentin42]

Off chance, is it possible to include an esp32 chip, in order to run the OI esp32 webinterface ?

[catphish]

2. More irritating: The economy service does not populate the big elco anymore. They did the last time, but this time, they give the choice to either not populated it or switch to the expensive service. Any idea how to workaround this?
image.png

The short answer: don't use it. Use multiple smaller caps that they *will* populate. I don't use electrolytics at all in my designs (I just use 10u ceramics), but if ceramics won't work, then I would hope there are smaller electolytic caps that they can populate.

[johu]

Off chance, is it possible to include an esp32 chip, in order to run the OI esp32 webinterface ?

I think the off board CAN web interface is the better solution here. The ESP module also forces you away from economy PCBA

[olegiv]

Thank you all!
I haven't visited the site in a while. It may be useful to someone - to exclude such problems as:

Finding4: The make does not see if the param_prj.h is changed. Just calling make (or in my case mingw32-make) should see the changed file compile all dependent files. Unfortunately I'm not the make-file expert, but my impression is, that the .h files somehow should mentioned in the dependencies in the makefile.

I would recommend to work with the project https://github.com/uhi22/ccs32clara in Ubuntu and use STM32CubeIDE as IDE.

[johu]

It's fixed already viewtopic.php?p=64622#p64622

[olegiv]

It's fixed already viewtopic.php?p=64622#p64622

Thank you - I've seen that. My point was that it's easier for me to fix errors if I use the IDE

[uhi22]

I used the CubeIDE as starting point, and indeed this made it possible to get fast results without the need to dig into each bit, and the integrated approach of graphical configuration, code generation, build and debugger is nice. Then I noticed that this "perfect world" is a little bit like a dream. There are discussions that the mcal is shit and is better to do the low-level things per hand. Personally I ve seen situation where the debugger just lied, showed totally crap while the software was in fact ok. And since Johannes provided the own "framework", I do not miss the Cube at all. I'm just using notepad++ (also in other Projects) and command line for compiling. If you feel the CubeIDE is your preferred way, you could try to find out how to bring the project back into this and describe this, so that others can do it the same way. Or describe the blocking points and maybe they can be resolved to enable different IDEs in parallel.

[olegiv]

If you feel the CubeIDE is your preferred way, you could try to find out how to bring the project back into this and describe this, so that others can do it the same way. Or describe the blocking points and maybe they can be resolved to enable different IDEs in parallel.

The project does not need to be redesigned.
The procedure for opening the https://github.com/uhi22/ccs32clara project in Ubuntu is as follows:
- Install gcc-arm-none-eabi
- Install STM32CubeIDE
- Install libopencm3 in any way (I did it in terminal).
Then STM32CubeIDE->File->New->Makefile Project with Existing Code. Then select Toolchain-> MCU ARM GCC and select the directory with ccs32clara project.
And then - as usual....
And who likes Code::Blocks better (though I personally don't like it very much) - open the project file in IDE Code::Blocks - stm32-ccs.cbp.

[johu]

Perfect. If you find out which is the eclipse (==cubeide) project file we could add it to the repo so people who prefer eclipse can use it with little hassle