Develop a QCA7000 board?

[johu]

Why do we require two contactor outputs?

[tom91]

Why do we require two contactor outputs?

Stuck contactor testing I would say. And possibility of monitoring them on the drive side.

[johu]

Oh yes.
Coming to think deploying another 1€ motor driver IC seems to be the most versatile way of doing this. All other options add to the extended component list, are more limited and end up being more expensive.

With that you can choose between high or low side switching, can work at reasonable frequencies and also have all the protection built in

[celeron55]

That makes a lot of sense. This use case is mentioned on DRV8874's datasheet at 8.2.2 Alternative Application

Certainly it is much better value for money compared to the NCV8402.

[johu]

Got a new batch of boards. Always very satisfying when getting into the charge loop. Took some re-reflowing of the QCA chip, still doing that one by hand.

Anyway, the wakeup circuit doesn't work at all. The TL431 shunt never pulls it's output below 1.8V and 1.2V is the threshold for shutting down the 5V reg. So will remove the PP wakeup for the next revision and just roll with CP and external wakeup for now.

Might patch in just the new wakeup input to have a bit of functionality

[johu]

Played with the economizer a bit more. First, when HardwareVariant <= 4003 (I changed unknown to 999) PWM frequency is reduced to 500 Hz.
So yeah, it certainly doesn't limit turn off voltage very much.

With a freewheeling diode added it looks like it should

This was just with a tiny relay. Then I replaced the relay with a larger inductor and set the duty cycle to obtain an inductor current of 600 mA. Already then the NCV chip became painfully hot after little time.

I reckon the inductor had entered saturation because of the low frequency. Dialed back to 10% or 470 mA:

Looks better, but the edges really aren't very steep. Tempted to say we disallow economizing completely with the NCV8402 variants

[uhi22]

Pooohh, this really looks ugly. But the times are according to the data sheet roughly:

I'd agree, that with these conditions the PWM does not make sense. It would need to be faster, to avoid saturating, but the faster the PWM the more heat is produced due to the slow transitions. Will only work if the inductance is much higher than in your test. Maybe adding an additional inductance in series, as workaround?

[johu]

Maybe adding an additional inductance in series, as workaround?

That or an economized relay in the first place. Only affects a couple of boards so I'm not too eager about it. I myself use economized relays

EDIT: decided to go for it https://openinverter.org/shop/index.php ... duct_id=79

[evMacGyver]

EDIT: decided to go for it https://openinverter.org/shop/index.php ... duct_id=79

How much is 12v current consumption of these versions if keeping wake all the time?

[uhi22]

Around 90mA at 13V. This is a lot of heat for just doing nothing, we should look to possibilities to safe some current. Maybe half the stm clock frequency is a simple measure.

[Edit]
- Putting the STM core into sleep until the next interrupt comes, using __asm("wfe"); in the main loop, safes ~8mA at 14V, not much.
- The data sheet of the QCA7000 talks about power safing modes, but does not explain how to enter these. Most likely using a certain SPI command, but which?

[evMacGyver]

Around 90mA at 13V. This is a lot of heat for just doing nothing, we should look to possibilities to safe some current.

I see 5V low iq SMPS and 3V3 LDO, one option is put uC controlled P-fet switch on 3V3_D line to shut QCA completely. This could be tested by removing R43.
QCA datasheet seems to require registration so I don't have its current consumption, but I think its not much for this.

[uhi22]

A copy of the data sheet is linked on the first page of this thread. In chapter 5.3 it says max 243mA on the 3.3V rail. So yes, a P-fet with 250mA rating, where R43 sits, is a solution. I measured the difference with R43 populated and removed, this is ~70mA on the 5V rail, or sayed with other words: it reduced the consumption on the 5V line from 147mA to 76mA. Quite good.

[johu]

The QCA chip also has standby modes. Reading up on it now and will do some experiments later

EDIT: well said, but I found absolutely no documentation on this.

But then we have the possibility to hold the chip in reset.

I'm testing with a very early board (before Deutsch header) and 12V

- Everything powered: 72 mA/850 mW
- QCA in reset: 53 mA/630 mW
- STM and QCA in reset: 35 mA/400 mW

The remaining consumption must be caused by a combination of CAN transceiver, flash memory, LDO/switcher and perhaps motor driver.

Tried again supplying just the 5V line
- Everything powered: 150 mA/740 mW
- QCA in reset: 110 mA/550 mW
- STM and QCA in reset: 73 mA/360 mW

And a final test with a v4.3 board where I messed up the QCA and removed it
- QCA removed: 88 mA/440 mW
- STM in reset: 49 mA/230 mW (30 mA when using 12V)

Personally I wouldn't want any of this to permanently suckle my 12V battery. On the other hand if it's just for a few hours e.g. when waiting for the sun to produce sufficient power I think even the initial 72 mA is low enough (1 Ah per 13 hours)

[uhi22]

If I remember correctly, holding the QCA in reset saves not so much current as I thought. Something like
Running ~70mA
In reset ~40mA
not powered 0mA
I also did only find the power modes in the data sheet, but not the SPI command how to enter the sleep.
So from my point of view cutting the QCAs power with a PMOS looks like the best way.
And clocking-down the STM, it is anyway much too powerful.

[johu]

Yes, similar observation above.
Question is, why go through the effort? 30 mA is too much for always on and 72 mA is sufficiently low for "wait a few days for sunlight"

When the car is off and not plugged in with the current architecture it will draw no current at all. If you leave it plugged in for 14 days you will find your 12V battery depleted, no matter what local devices are powered down.

If we want to be able to fully power down despite PP/CP being connected we need some different measures. E.g. the PP/CP enable needs to be a pulse rather than a level. I think that's for a future hardware version as it's a rather corner case requirement

EDIT: alright, alright it isn't that hard

This gives the µC 2s to keep the power supply on by itself and then fades away.
So now you can program how long Foccci should stay on with a cable connected but no charge session running (i.e. CP duty cycle==0)

EDIT2: hard to keep the topics separated. Should I move the last 7 posts to the sleep discussion?

[uhi22]

There are two separate topics: the sleep/wakeup (other thread), and the high consumption during "just sitting around" or driving. Hm, maybe they cannot be separated, difficult.
One idea: If no CP 5% PWM is present, the QCA can be powered down. This is easy and cheap. And the rest belongs into the other thread.

[johu]

So the only point to power the board when starting to drive is to report some error that was detected on the last charging session and to report that no cable is plugged in. Once that is all reported Foccci can power down. It means the wakeup signal also needs to be a pulse, not a level.

Apart from that, even if it stays on while driving 72 mA doesn't sound like a major consumption from the DC/DC converter.
I get your point though, it's unnecessary. That's why I only power it when something is plugged in. Reported errors can also be remembered by the VCU. And no 12V/CAN messages from Foccci means nothing is plugged in. I don't think it needs to be complicated beyond that. Besides, I wouldn't want a broken CCS controller to immobilize my car because it doesn't send its "nothing is plugged in" message.

[MoonUnit]

Apologies for the interruption - I looked at the FOCCCI schematics for CANbus termination to see if FOCCCI can exist as an unterminated node on the network.

There's a 1K resistor on the CAN lines and some text saying this aids with setup on the desk.

I think this means that FOCCCI can exist happily unterminated as a node in an otherwise correctly terminated network, but ought to be terminated if there are only two nodes (one terminated, one FOCCCI)?

[uhi22]

It depends. The theory says you need 120 Ohms on each end. So yes, add an external resistor if foccci is at the end of the line.
But in practice there is more flexibility, because the exact termination is only relevant for "long" lines. Half a meter is extremly short compared to the wave length at 1MHz (300m), it works perfect with the 1k, and even 5meters will work even if there is only one termination of 60 to 120ohm, no matter whether at an end or in the middle. If you have more than 10m, I'd recommend to follow the official rule.

[uhi22]

Is the board shipped plug-and-play (software and hardware components/on-board connections).

Yes, the boards contain all hardware components, and the controller is flashed with the clara software. Also the SPI flash contains the software for the modem chip.
But not all boards are offered with the Deutsch connectors and housing, so read the description before ordering.

Does it have Clara installed and I just need to connect the esp32 interface and the charger hardware and get going through the web interface or do I have to upload Clara and do other setup tasks?

Clara is installed, the CAN is configured to 500kBaud, so you can connect the webinterface via CAN and configure the mode and the CAN mappings as needed.

Also, is controlling the board from my own dashboard software as simple as interfacing with the board over the built-in UART interface or am I missing something here?

I do not understand the question. The Focccis UART is just for logging, it provides a lot of internal data, which may be helpful for finding the root cause of issues. For normal operation the UART is not needed. The UART is not intended to control the Foccci. All control should happen via CAN. If you need the control via UART, this needs to be implemented additionally in the Clara software.

Lastly, Johannes Hübner's lab update with the new CCS control board and he mentioned that certain upgrades were not working properly. Does this prevent regular operation and/or are there fixes I need to implement before using the board?

The not properly working updates are related to sleep/wakeup functionality of the v4.3 board. These are already sold. The v4.2 boards in the shop do not support sleep/wakeup at all. They need to be either powered by a separate switch or by ignition, or by any other circuit which turn them on when needed and off during parking.

[serh270]

Thank you again for the speedy reply. One more set of questions that might have an obvious answer:
On the board, the SW1 and SW2 pinouts are for in-vehicle contactors?
IN_U_HV does what?
I had built into my design a leak detection system that would have communicated with the EV control PC and from there with the charger. I will most likely continue to build this system, but is it necessary in some way to the board's function?

These seem like questions that are probably found in documentation but I haven't been able to locate it (if it exists, I understand this project is still early days), so any help with that would also be great! You guys seems to make a really incredible and accessible bit of open-source tech so thank you for sharing all your guys' knowledge!

[uhi22]

Very good points. The documentation is still growing. Now started the pinout description here:
https://openinverter.org/wiki/Fully_Ope ... r_(FOCCCI)
Please feel free to add further questions to the pins directly there, and also descriptions from your point of view. This helps to come to clear descriptions in the end.

Regarding leak detection: The Foccci/Clara do not need this. Nevertheless it is useful, and you need to decide who to deal with the situation if the leak detection sees an issue. You could disable the supply from Foccci, or sent a CAN signal "charging forbidden", or just do nothing. An other important point is: During charging, the EVSE performs isolation checks. To avoid false detection, the car side leak detection most likely needs to be disabled.

[dougyip]

I’m finally at the point of being able to test my Focci/Clara setup. I have one of the 5 original V4.1 boards. I’ve reflashed the STM32 with the “stm32_canloader.hex” (Version dated June 23, 2023) and the latest “stm32_ccs.hex” file I could find on the website (1st Release Clara Software dated Dec 13, 2023). I have an ESP32 Wi-Fi board purchased from the store. I can connect to Node 22 and can see some parameters and spot values. I am using contactors with economizers, do not have a lock actuator, and am using the EVCreate Voltage Sense Board. I will conduct my testing with an offshore (PhiPhong) CCS1 charger with Max Power of 120kW. I have many questions:

1) Is there a more recent stm32_cccx.hex file available for download? I do not have the tools/skills to build from a Make file.
2) I do not see all the Parameters and Spot Values that are listed in the Wiki. Will these appear when I upgrade the hex file?
3) Are there any hardware changes I need to do to my V4.1 board? I have seen the discussions regarding pull-up resistors for PP. I will not be attempting to charge on a Tesla station in the near term. I have checked that the contactor transistors are the correct version.
4) If I’m using a HV Voltage Sense board, I assume I connect it to the battery side of the contactors so it can read the pack voltage at all times? Can I also use my Orion 2 BMS system to send this same information via CAN? If so, what address do I send it to and what should the message format be?
5) Is there a simple way to close the contactors for testing? I would like to verify the connections up to my CCS connector.
6) After the initial setup, to initiate a charging session, do I just enter “Target Voltage”, “ChargeCurrent” then set “Enable” to 1? To Stop, set “Enable” to 0? Do I need to enter or transmit the SOC? If I want, can I ramp down the charge current during a session by changing the “ChargeCurrent”? Eventually, I will have a supervisory controller send CAN commands, but initially everything will be manual.

Thanks!

[johu]

1) Is there a more recent stm32_cccx.hex file available for download? I do not have the tools/skills to build from a Make file.

Yes, every commit is compiled by github. It is a bit hidden under actions: https://github.com/uhi22/ccs32clara/actions. You click on a commit name and will find the binaries under "Artifacts"

Will these appear when I upgrade the hex file?

Yes

If I’m using a HV Voltage Sense board, I assume I connect it to the battery side of the contactors so it can read the pack voltage at all times?

No, you want it to measure charge port voltage

Can I also use my Orion 2 BMS system to send this same information via CAN?

In fact you have to. Configure Orion to send it and configure Clara to receive it in "BatteryVoltage". In fact there are more items that need to be communicated from Orion to Clara. Easiest done by activating the CHAdeMO mapping in Orion, then adding BatteryVoltage and then map like this: https://openinverter.org/wiki/CCS32Clar ... e_CAN_side

Is there a simple way to close the contactors for testing?

Yes there is an ActuatorTest paramter

After the initial setup

Theoretically yes, but Clara wants at least the ChargeCurrent parameter mapped to CAN and receive it periodically, otherwise it shuts down the session.

[uhi22]

Could we move this to the QCA-Thread? Because off-topic here.

For the first test without CAN communication you could also use the Demo mode. The only important thing is to set the demovoltage to the actual battery voltage (within 10V tolerance). And as soon as the contactors are closed, you can adjust the voltage a little bit higher and adjust the target current, both via the web interface. For stopping you press the button for 1second.