Foccci integration with OBCs

[johu]

Here I want to start discussion on how to integrate Foccci with existing OBCs.

What we already have:

• Foccci evaluates CP dutycycle and scales it to a current limit which can be put on the CAN bus
• Foccci evaluates PP resistance, also scales it to a current limit
• Foccci can receive an OBC state resulting in connector locking (TBD) and state C switching

So for OBCs that do not evaluate CP and/or PP themselves we already have a working mechanism.
For those that do need an undistorted CP or even PP we have the following options:

1. Do not connect PP to Foccci. It isn't really needed, provided the OBC pulls it up in the correct way
2. Use a change-over relay e.g. controlled by the VCU to connect CP and/or PP to the OBC and disconnect it from Foccci. The VCU can determine e.g. from CP duty cycle that we want to AC charge
3. Re-create the CP signal and spoof the PP resistor to the OBC. This would need an additional output of Foccci and Foccci can only create the positive swing. Seems ok for most chargers
4. Re-create CP with one of the contactor outputs. The contactors can then not be controlled individually but we also don't need an extra pin and it works with existing hardware (at least 4.5 and newer)
5. Spoof PP and CP with some simple circuit (NE555?) and control the charger like one that doesn't read CP and PP
6. connect CP to both. Remove the 2k7 state-B resistor from Foccci, because the 2k7 is present in the OBC

[modellfan]

OK, let’s wrap it up from user perspective. So specific for my project I would like to use a CCS charge port of an ID.4 together with a Nissan Leaf PDM for AC charging and a FOCCCI for DC charging .

Wished behavior: I open the charge door and a switch triggers wake-up for BMS , OBC and FOCCCI. When I plug a connector it gets locked. Type 2 starts PDM , CCS starts FOCCCI. I need to unlock the car to be able to remove the Plug. I can accept to push a button if necessary at the charge port to cancel active charging session before unplugging.

Wiring:
- PDM : L1 - L3 , N , PE , PP , CP
- DC / FOCCCi : DC +,- , PE , PP , CP
PE can just be in parallel. I understand, that PP and CP interfere ?

Energy management:
- Do we want to have foccci running while ac charging? How is it vise versa ?

Usability:
- What is the easiest way for people that don’t program their VCU them self ? Probably foccci as single charge Vcu. Means BMS or ZombieVCU sends charge limits , focci receives it and either control DC or external Charger . Basically all Zombie supported chargers could be taken over . This makes it much simpler from can bus architecture then having a main Vcu as coordinator.
This would also reduce the amount of necessary wiring, as OBC should be close to the ccs as foccci as well.

From Hardware perspective, I would feel like option C . This is how liquid gas ecus handle lambda sensors and injection valves . But we should double check how oem solutions are doing it.

[uhi22]

Another option: combine
- (a.) "do not connect PP to Foccci" with
- (f.) connect CP to both. Remove the 2k7 state-B resistor from Foccci, because the 2k7 is present in the OBC. With this, both the OBC and Foccci are able to change to state C by their individual 1k3 resistors. And both can measure the CP PWM individually and decide each on its own based on the PWM duty cycle whether they should do anything or just sit silently.

This does not solve the lock motor topic. Both, OBC and Foccci want to control the locking and unlocking, and potentially the OBC wants a feedback about the lock status. Needs to be found out, what is necessary to keep the OBC happy regarding the lock. For Foccci we could implement something like "lock as soon as PWM is detected" or "lock/unlock based on a CAN command" or something.

Also to be clarified is the charge port temperature. With latest software, Foccci reduces the DC current with rising temperature. To be found out, what the OBC expects in this direction.

Also the drive-away-protection needs to be decided. Normally the PP should be used to detect that a plug is present.

Option (c.) (spoofing the PP of the OBC) has the issue, that the OBC would need the PP resistance to know the cable current limit. So a simple on/off spoofing would destroy this feature.

[johu]

By spoofing PP I was thinking the charger does not use this as a limit, instead Foccci or the VCU limits the charger by CAN command to obey the PP (and CP) limit. It might also make sense to set EvseCurrentLimit to MIN{EvseCurrentLimit, CableCurrentLimit} to avoid confusion in the first place.

In my MG charge port both DC and AC pins have separate temp sensors. The DC ones can be routed to Foccci the AC ones to the OBC (provided the charge port belongs to that OBC)

Also thought about removing the state-B resistor

Wished behavior: I open the charge door and a switch triggers wake-up for BMS , OBC and FOCCCI. When I plug a connector it gets locked.

I think PP or CP wakeup is more precise here. Less chance of mechanical/corrosive failure inhibiting charging or keeping stuff on all the time

Type 2 starts PDM , CCS starts FOCCCI.

For this you'd need more intelligence somewhere else. Foccci only has one wakeup output. For CCS at least the BMS needs to be woken up by this. It would then be down to e.g. the VCU to also start the OBC and pump when AC charging. Or you could just always start the OBC as fast charging shouldn't take long.

Basically all Zombie supported chargers could be taken over

I do smell a bit of feature creep here. I think as long as the OBC can just be controlled by mapping stuff to CAN this wouldn't add to the code base. I can totally see the Nissan PDM being just controlled with CAN mapping now that Dave added big endian mapping to libopeninv

[tom91]

I do smell a bit of feature creep here. I think as long as the OBC can just be controlled by mapping stuff to CAN this wouldn't add to the code base. I can totally see the Nissan PDM being just controlled with CAN mapping now that Dave added big endian mapping to libopeninv

Do not support the OBC via the FOCCI, use a VCU to manage this, just like it or the bms decides the current limits. It should be a "gateway" ECU ideally.

If you are having to switch lines between various chargers, utilize the ZombieVerter. The FOCCI can be programmed in to be a charge interface, like the LIM and like my EVS-Charge Port Controller.

No idea how compilated the nissan leaf PDM is to keep it happy. Easiest would be if only the CP and PP would need changing to it. **EDIT: PDM just need PP and CP so a simple 2 pole change over relay would work**

@johu and @uhi, what are the current conditions for having the Focci lock the charge plug? Can always just have it commanded over CAN as if the vehicle is locked via the ZombieVerter.

For the outlander charger which requires a CP spoof signal, this is already in the ZombieVerter 1000khz 12V pwm, this is a programmed a bit rough for now but can be modified.

[Bigpie]

I was planning to have focci with a change over relay so the normally closed CP goes to my outlander charger. Zombie detects PP and initiates charge mode.

It sees the CP duty reported by the outlander as 5% and so goes to DC charge mode and powers up focci and the change over relay. No idea of this will work or how the charger will behave with the cp on a relay.

[uhi22]

For the chargers (both the Outlander and the HPC) it's the same like pulling the plug. The Outlander sees "unplugged" for minutes, the HPC sees "unplugged" for some milliseconds. Both should be okay with this.
Sounds like a reasonable concept for basic charging experience. Just the locking and temperature sensing to be sorted.

[uhi22]

@johu and @uhi, what are the current conditions for having the Focci lock the charge plug? Can always just have it commanded over CAN as if the vehicle is locked via the ZombieVerter.

For DC this is "Lock before cable check" and "unlock at session stop". For AC not defined yet.

[bewo]

Maybe it's possible to use the connected AC to switch between two ways of generating the signals. Splitting up the lines of CP and PP and include a simple circuit for generating the signal or do a direct connect to the OBC if needed.
As standard foccci is active. If AC is plugged in a kind of relay or a circuit triggered by AC 230V switches to the alternative generation of the signals. Maybe that's a possible solution.

[Zieg]

The AC won't be live until the car has communicated to the EVSE to close its contactors though, right? Correct me if I'm wrong but I think you need to identify the charge mode before that point?

[Bigpie]

If using Zombieverter, it supports using FOCCCI (or will in the next release) as the charging interface, so foccci deals with the CP and PP signal, and then zombie replicates the CP duty on a pin for the OBC to use. I've been using this setup for a month or so, it works great.

[sirpewe]

Hi.
Is it possible to setup an output from foccci to "mirror" the CP input signal to be used to route to OBC?
Since the connectors are already full, I'm thinging if it's possible to use one of the testpoints for this (and patch in cable)?
And with this I think it should be possible to also limit the current and stop AC charging from Foccci by manipulating the CP signal to the OBC.
What do you think?

[uhi22]

Yes, we could try this route. Some questions are to be clarified. How to generate a stable 12V as PWM supply? Is also -12V necessary (officially yes, but some OBCs may work also with 0V/12V PWM)? Is also measurenent of the PWM voltage necessary (I think yes, we want to know whether the OBC is in state B or C)? Is the STM able to provide the 1kHz PWM in the needed resolution? And is it also necessary to control the PP?

[johu]

I moved your question here.

If you re-read the thread is a possible solution already presented? What is it you want to achieve?

Maybe for your application it's sufficient to remove the state-B resistor from Foccci, provided it is present in your OBC.

Re-creating the signal requires quite some additional hardware as uhi stated.

Simply putting a copy of CP on a test point at 3.3V level wouldn't be hard. Then some external circuit could modify it to +-12V and we don't "pollute" the Foccci design.

I think with CP forwarded to the OBC Foccci can stay passive and leave current control to someone else, i.e. I don't think it's necessary to read anything back from CP.

[celeron55]

It seems to me a 0/12V CP PWM mirror from foccci at one of the contactor outputs would satisfy a lot of the people who aren't using Zombieverter or some other VCU with CP PWM output capability.

• The contactor outputs are already proven to be capable of PWM so that's not an issue (the frequency just needs some managing in software, maybe disable PWM on the contactor output when CP PWM mirroring is in use on the other output)
• It seems like most OBCs are happy without the negative portion of the CP PWM, so that's not an issue
• No extra leads through the enclosure are needed
• No PCB changes are needed, purely a software solution
• When in need of more contactor drive current than one output can handle, one can add an external relay or utilize an auxiliary contact on one of the contactors to control the other. Yes, it's a downside, but it's perfectly manageable

[uhi22]

You mean Foccci produces a 0/12V PWM with a contactor half bridge, and the 1k serial resistor is outside in the cable harness? Could work, if the OBC does not care too much about the voltage. Because the "12V" will be something between 12 and 15V most likely. Any volunteer to give a try?

[tom91]

What I have done in the past, 1K pull up to 12V then pwm it with a nfet. The Outlander charger finds this fine.

Jamie is running a PWM out from zombie into an outlander charger, which is a gate driver.

Also who is the person asking for this? What charger are they running and what other items are in their setup?

[tom91]

• The contactor outputs are already proven to be capable of PWM so that's not an issue (the frequency just needs some managing in software, maybe disable PWM on the contactor output when CP PWM mirroring is in use on the other output)

This defeats using the Foccci to do DCFC. Also not running two separate contactors is not ideal, really need to sort welded contactor detection and propper HV measurement on the Foccci.

[Zieg]

I don't know if this is quite the same scenario, but I am planning to use a physical switch to toggle the cp/pp signals between Foccci and my Thunderstruck BMS which controls the AC charger. Not the most elegant but I think it will work just fine.

The Thunderstruck BMS is meant to work with the Zero EV (Fellten) CCS kit, which does need to send a signal (+12v I think) to the BMS when it detects the DCFC plug. I believe this can be handled by using the wakeup pin as an output?

[tom91]

I don't know if this is quite the same scenario, but I am planning to use a physical switch to toggle the cp/pp signals between Foccci and my Thunderstruck BMS which controls the AC charger. Not the most elegant but I think it will work just fine.

The Thunderstruck BMS is meant to work with the Zero EV (Fellten) CCS kit, which does need to send a signal (+12v I think) to the BMS when it detects the DCFC plug. I believe this can be handled by using the wakeup pin as an output?

Just configure the CAN the same as the Zero EV Felten CCS kit... It sends the CP limit over CAN.

[Zieg]

Right, but there's still a line on the diagram that goes to an input labelled 'plugin' which is separate from the cp/pp input pins. Unsure why it doesn't just signal that via CAN too, maybe it's for waking it up or something?

And the switch will be right by the charge port and then run either to to the foccci or the bms.

After re-reading the bms manual, maybe I don't need the switch? When I first read this I thought it was talking about the actual fast charging side of things, not passing info through for onboard charging.

Although ZEVCCS does not perform onboard charging, it manages the charge plug, and a
special interface is used between the ZEVCCS system and the MCU so the MCU can be notified
of charge plug presence and its ampacity. Charge plug presence, normally provided by the
Proximity input, is instead provided by a new input called plugin. Charge plug ampacity,
normally provided by the pilot signal, is determined by the ZEVCCs system, and communicated
to the MCU by a CAN message.

[johu]

I have checked the pin options of the STM32. On larger variants TIM8 is connected to an appropriate pin but I think our MCU doesn't have TIM8.

There is only TIM3 then and that runs at 17.6 kHz. So specially for replicating PWM we'd have to run it at 1 kHz making the contactors noisy, if Foccci economizing is being used.

- (f.) connect CP to both. Remove the 2k7 state-B resistor from Foccci, because the 2k7 is present in the OBC

If I were to use my CCS inlet for AC charging I'd probably roll with that.

Also not running two separate contactors is not ideal, really need to sort welded contactor detection and propper HV measurement on the Foccci.

There is some welding detection but it is only checked at end of charge and would only trigger if both contactors are welded. HV measurement is "proper" as in you have 3 options:
a) isolated analog voltmeter (e.g. muehlpower board)
b) CAN voltmeter (e.g. ISA shunt)
c) charger voltage report
But actually that's for another topic.

[tom91]

After re-reading the bms manual, maybe I don't need the switch? When I first read this I thought it was talking about the actual fast charging side of things, not passing info through for onboard charging.

https://shop.fellten.com/shop/ccst2fck- ... -kit-13491 have a read of their user guide.

Luckily I worked on this system myself back in the day.

You are using this BMS right: https://www.thunderstruck-ev.com/mcu.html

The MCU also supports onboard charging using the Zero EV CCS; this case is handled
separately: see ZEV CCS Charging, below.
The MCU monitors for charge plug insertion to begin a charge, and once charging has started,
the MCU controls the chargers, typically by using CAN messages.

To find the CAN format just download the orion2 software and rip it from there.

[sirpewe]

Thank you Johu for moving my post to a more appropriate place.

My first idea was to use the FOCCCI as the primary charge controller for DC and also let it handle AC charging by manipulating the CP signal to OBC.
I also had an idea to connect upto 3 OBC in parallel.
So my idea was to get a signal from the FOCCCI which replicates the CP but can be modified and decrease the power allowed.
I thought of a simple PCB with optocouplers like this:

But maybe this is just to complicate things.
I just liked the idea of keeping the EVSE CP signal routing clean by just routing it to one unit (FOCCCI).
And from your last post with timers it sounds as if this is not possible (in a simple way at least).
Perhaps just best to control OBC with CAN commands (if I like to limit output) and route the CP via switch/mux to the different boards/units.

[sirpewe]

What I have done in the past, 1K pull up to 12V then pwm it with a nfet. The Outlander charger finds this fine.

Jamie is running a PWM out from zombie into an outlander charger, which is a gate driver.

Also who is the person asking for this? What charger are they running and what other items are in their setup?

Hi.
I was the one considering this.
I plan to change my PCS to mitsubishi OBC (and possibly connect 2 or three in parallel). But not sure yet.
I would prefer a 3-phase OBC but haven't seen many managed to "hack" chargers except some tesla charger (and they seem to have some issues with these also). A kia/hyundai charger would be cool but don't know if anyone has managed to get them to work? And I'm not good enough with CAN hacking (yet)