openinverter forum

Another improvement: There was confusion regarding the PP variant. Now added a pick-list, which hopefully makes the selection easier. The detailled check revealed, that the former conclusion "ppvariant=1 is fine for Foccci 4.5" is wrong. Because, as long as the solder bridge is not closed, there is NO pull down. So variant 2 is the right one. Updated the wiki regarding this. (And to be precise, in 4.5 there is the additional diode, which would need a small adaption in the calculation to be fully correct.)

And to be even more precise Johannes replaced the 3k pull down with a good enuff standard 3k3

But yeah, precision isn't so important here as the cable current steps are far apart

Got the version 5 boards from JLC. Still the QCAs not soldered, just powered up.
When increasing the supply voltage from 8V to 15V, observed an increasing current. This is not normal, because usually the step-down regulator will draw less current when the voltage increases (constant power). So the question is: Where does the increasing current come from?

Did you measure the supply rails? What changes did we make since 4.5a that tested fine?

Not sure whether 4.5 was better, I did not have a close look to the current, and now all are gone.
The 3.3V and 5V are fine.

Found the reason for increased supply current: The enable pin of the steop-down is specified to be max 7V, and not intended to feed voltage into. When adding a 10k in series to the enable pin, the unexpected current is gone. Even better could be a diode.

Oh!
Good thing you found it before I ordered the new batch. How hard is it to add the series resistor?
Diode would have to be Zener type. Diode to 5V rail would probably inhibit wake up

I think uhi22 meant a diode in series. No? To only allow current to flow out from the EN pin.

Adding the series resistor is just scratching some copper and wiring the resistor, this is no problem for the five parts on my desk. Finding 2: The R52 and R64 are corrected to 1k in the schematic, but not updated in the pcb, so the BOM contained 10k, which leads to unintended wakeup. Need to fix this on the physical boards, and check whether syncing the board to the schematic works without destroying too much.

celeron55 wrote: ↑Tue Jul 09, 2024 7:41 am I think uhi22 meant a diode in series. No? To only allow current to flow out from the EN pin.

Exactly.

Hmm, the wakeup is based around pulling the EN pin to 12V and basically overriding the internal pull-up with the external 100k pull down.
A cleaner solution would be a part with internal pull down and EN pin designed for 12V

Yes, the idea with the diode is exactly this. The diode and the pull-down resistor provide the functionality "low by pull-down, and driving to 12V enables the regulator" The point A is nearly 0V during sleep, because the ~2µA pull-up current inside the IC is not sufficient to over-rule the 100k+diode. When applying anything between 5V and 20V to the supply, the point A follows this, and the diode prevents feeding the 20V to the IC. The internal pull-up current of the TPS pulls the EN to high (no matter whether this is 2V, 5V or 7V). Everything fine.

Now I get it, perfect!
Can you make the change?

Any proposal for a small footprint Schottky diode?

This one is used already: https://jlcpcb.com/partdetail/9093-B5819WSL/C8598
This one is in the smaller SOT-323 https://jlcpcb.com/partdetail/Guangdong ... WS/C191023

Thanks. Used the smaller one. Schematic and board updated (including the R52 and R64). Also fixed the rotation issues.
Still the v5 boards need soldering the QCA and further testing.

Now of course I'm wondering how much of a problem is this for the boards already out there? Will the regulator overheat from this? How many mA go into the pin?

Hi!

On a whim, I ordered 2 populated foccci’s yesterday (I am far from ready to seriously think about CCS - but the project is just too cool )

Anyway, FYI, JLCPCB was picky about the footprint of L13 - see image. They would have placed it, but “without right to complain”

I have not the means to make a pull request - zero skills in that regard - but thought it might be useful info, in case i got lucky and was the first to get that feedback from jlc …

johu wrote: ↑Wed Jul 10, 2024 7:11 pm Will the regulator overheat from this? How many mA go into the pin?

Added a 1 ohm shunt at the enable pin to measure the current, depending on the supply voltage.

supply voltage [V] | current [mA]
7 | 0
8 | 0.4
9 | 0.8
10 | 1.4
12 | 3.4
13 | 19.2
14 | 41
15 | 61 Hot, touch longer than one second hurts. No smoke yet.
Did not further increase to avoid damage.

I see these solution options:
(A) If the DCDC never provides more than 14V, just live with the small heat. (Most likely the DCDC will provide more than 14V.)
(B) If the sleep/wakeup is not needed, just remove the two transistors, the diode and the 100k pull-down. This leads to "always on".
(C) If sleep/wakeup is needed, just live with the heat and hope that the regulator will survive.
(D) If sleep/wakeup is needed, cut the copper to the enable pin, and solder a diode (or a 10k resistor like I did on the V5 boards).

I'd propose B or D, these are the technical clean solutions. For just experimenting also (C) is okay, but no long term recommendation.

Landsi wrote: ↑Wed Jul 10, 2024 8:23 pm JLCPCB was picky about the footprint of L13 - see image. They would have placed it, but “without right to complain”

That's funny. I orderd the V5 two weeks ago, and there was no complaint at that time. I added the topic on the todo list.

Well this post is already superseded by "the Buschtrommel" (aka Signal) which led to this: https://github.com/uhi22/ccs32clara/issues/24

Drove back from holiday today and charged while walking around a lake. Unfortunately when we returned to the car the session had stopped at 66%. So I started again and waited in the car. 18 Minutes later my "neighbor" on the same Alpitronic charger left and a new car plugged in. In that instant my charging session got interrupted again.

Uwe already reproduced it and it is Clara still listening to SLAC while the connection is already established

On other news I briefly charged at 92 kW (250A) but a very metallic burn smell quickly let me dial it back to 180A.

I noticed that Johu had mentioned he flashes the "chademo" can mapping in a different thread: viewtopic.php?p=72966#p72966

I have started to look at the Zombie Implementation so the question around a "standard CAN map" has arisen.

Can you please share the format of these messages? Any inclusions regarding AC charging or charge port related statuses?
Also will probably want to look at agreeing on a format for the control messages toward the Focci.

Yes DC charging is covered by CHAdeMO + BatteryVoltage mapping: https://openinverter.org/wiki/Foccci#Ma ... e_CAN_side

For AC charging nothing is defined on the CAN side yet.
We have values "EvseAcCurrentLimit" that is calculated from CP duty cycle, "CableCurrentLimit" calculate from PP resistance and AcObcState to remote control stateC and connector lock (0 idle, 1 connector lock, 2 state C)

Could be mapped to some unused CHAdeMO bytes for reduced CAN traffic or 1 new message in each direction

johu wrote: ↑Thu Jul 18, 2024 6:32 pm For AC charging nothing is defined on the CAN side yet.
We have values "EvseAcCurrentLimit" that is calculated from CP duty cycle, "CableCurrentLimit" calculate from PP resistance and AcObcState to remote control stateC and connector lock (0 idle, 1 connector lock, 2 state C)
Could be mapped to some unused CHAdeMO bytes for reduced CAN traffic or 1 new message in each direction

Okay will take the info and populate a .DBC and review then add the missing info where possible and suggest a message form the Focci providing the Lockstate, CP ect.

Once I get my own board I will dive into having a play with the charging logic interaction between Clara and the Zombie, should be straight forward as we can copy from the LIM or my own Charge Port Controller.

Why there are two chargers? Well, one for the Ioniq and one for the Cappuccino
Worked with the ABB, but did not for the Wilbert charger. Unfortunately no laptop for logging at hand.