openinverter forum

I've got boards in process at JLCPCB. Will post to GH after I verify that that the smoke stays inside.

Very nice design! Having all on one dedicated board!
CCS inlet temp (usually PT1000 or NTC) and a stop charge button input would be nice to add for a more universal design.

Are those 15 ohm resistors (R21, R22) actually capable of handling constantly 12W (~900mA @ 13.4V)?

bitterandreal wrote: ↑Sun Sep 26, 2021 8:32 am Are those 15 ohm resistors (R21, R22) actually capable of handling constantly 12W (~900mA @ 13.4V)?

They’re rated at 25w

bitterandreal wrote: ↑Sun Sep 26, 2021 8:32 amAre those 15 ohm resistors (R21, R22) actually capable of handling constantly 12W (~900mA @ 13.4V)?

Assuming BMW followed the datasheet of the TE contactors they will be PWM fed with a 50% dutycycle, so dissipation will be half that. But anyway, 2x6W will generate quite some heat on the PCB..

The last couple boards I did were small for motors pulling 150-200w. I’m not really worried about heat rise of 12w combined in this one.

jon volk wrote: ↑Sun Sep 26, 2021 11:50 am

bitterandreal wrote: ↑Sun Sep 26, 2021 8:32 am Are those 15 ohm resistors (R21, R22) actually capable of handling constantly 12W (~900mA @ 13.4V)?

They’re rated at 25w

Resistor power ratings are pretty meaningless on their own. The heat has to go somewhere - in real conditions, 25W is a pulse rating only.
For example this 25W one quotes 25W rating at a 25 deg.C case temp, which it won't be after dissipating 25w for any length of time - thermal resistance quoted is 5 deg.C/W, so 125 deg.C internal rise above ambient on an infinite heatsink.
https://www.vishay.com/docs/51054/dto25.pdf
The calculations they give for PCB mounting ( though they don't spec the size of PCB or copper area) suggest about 36 deg.C/W, which would be over 400 degrees at 12W!

That board apppears to have no thermal plane or thermal vias to spread the heat out. At 12V they're going to unsolder themselves.
I'd suggest pushing everything else as close as possible to the connector end, and putting the resistors towards the opposite age, far apart, with thermal vias to as much copper as you can get, and cutouts to isolate the heating from the rest of the components, and make provision for additional heatsinking, like solder-down heatsinks.
Maybe replace the D-paks with a large number of smaller resistors to spread the dissipation more evenly over a large area.

viewtopic.php?p=28239#p28239
duty cycle generated by the LIM

There are 8 vias in each pad tied to the ground plane for dissipation. It was still a WIP when that shot was posted.

jon volk wrote: ↑Sun Sep 26, 2021 1:33 pm The last couple boards I did were small for motors pulling 150-200w. I’m not really worried about heat rise of 12w combined in this one.

But the H-bridge drivers are very efficient, they only have to switch the power for the motors not dissipate the power.
I would just avoid to place the resistors in the ECU housing.

That’s the joy of JLCPCB. If changes need to be made, it’s cheap enough to throw mistakes in the trash. It’ll be easy enough to bench test with a power supply and see if upgrades are necessary.

jon volk wrote: ↑Sun Sep 19, 2021 6:55 pm

muehlpower wrote: ↑Sun Sep 19, 2021 1:42 pm

jon volk wrote: ↑Sun Sep 19, 2021 11:40 am Ahh good catch on the HGND.

Aside from that, sounds like it will work. Thanks for the added explanation on yours.

Posting the final(?) updated schematics below.

VOLT_DET-HV_ISOLATION.pdf

i don't think it will work. OUTP and OUTN are not 0V with an input of 0V, its 1.44V. At 500V OUTP = 2.44V and OUTN = .44V approx

Got it, 1.44 centered common mode. Re-doing doing the calculations just needed to replace my R28 with the same 6080 ohm value. Values seem to align close enough and with the parallel resistor circuit, that gives me plenty of options for tweaking in the future. Without this change, it seems values would have been 0HVDC @ ~2.3v and 500HVDC @ ~5v

Thanks for the help.

I’ll post the final files to my GitHub after I’m done. It’s going on a board with an STM32F413 to handle two Volt BMS systems and any other battery related needs. Have the BMS code generally done but untested. Need to port the necessary CCS from Damien over to c/st-hal.

C8F07AA0-BC5D-49E7-82FB-AF89CADC7E57.jpeg

FF4BF179-1399-4566-AAE2-CEF20018B548.jpeg

Excellent work!
What's you GitHub? Cannot wait to see it...

I think a separate controller for the ccs with the CAN interface would be ideal. Then others can easily adapt it to their own chargers, inverters, BMS, vcu etc....

I think a separate controller for the ccs with the CAN interface would be ideal. Then others can easily adapt it to their own chargers, inverters, BMS, vcu etc....

Yeah; i agree the current VCU controller would be usable because it has 2 CAN interfaces. One for the LIM and one for the vehicle integration.
So that's covered.

EV_Builder wrote: ↑Sat Oct 02, 2021 1:07 pm

I think a separate controller for the ccs with the CAN interface would be ideal. Then others can easily adapt it to their own chargers, inverters, BMS, vcu etc....

Yeah; i agree the current VCU controller would be usable because it has 2 CAN interfaces. One for the LIM and one for the vehicle integration.
So that's covered.

In my setup there is a DUE that communicates with the LIM and my Tesla GEN3 charger via CAN 1. It also has the necessary 6 hardware lines for the charger and a simulation for the fuel filler flap for the LIM. It also queries the temperature at the CP and a button to cancel charging. The connection to the car, especially with the BMS, current sensor and cooling system is via CAN 0. This DUE is only in operation during charging, AC or DC, and also controls precharge and main contactors, which are switched by Damien's LDU board while driving.

muehlpower wrote: ↑Sat Oct 02, 2021 2:29 pm

EV_Builder wrote: ↑Sat Oct 02, 2021 1:07 pm

I think a separate controller for the ccs with the CAN interface would be ideal. Then others can easily adapt it to their own chargers, inverters, BMS, vcu etc....

Yeah; i agree the current VCU controller would be usable because it has 2 CAN interfaces. One for the LIM and one for the vehicle integration.
So that's covered.

In my setup there is a DUE that communicates with the LIM and my Tesla GEN3 charger via CAN 1. It also has the necessary 6 hardware lines for the charger and a simulation for the fuel filler flap for the LIM. It also queries the temperature at the CP and a button to cancel charging. The connection to the car, especially with the BMS, current sensor and cooling system is via CAN 0. This DUE is only in operation during charging, AC or DC, and also controls precharge and main contactors, which are switched by Damien's LDU board while driving.

Yeah that's what i meant a two legged controller.

muehlpower wrote: ↑Sat Oct 02, 2021 2:29 pm

EV_Builder wrote: ↑Sat Oct 02, 2021 1:07 pm

I think a separate controller for the ccs with the CAN interface would be ideal. Then others can easily adapt it to their own chargers, inverters, BMS, vcu etc....

Yeah; i agree the current VCU controller would be usable because it has 2 CAN interfaces. One for the LIM and one for the vehicle integration.
So that's covered.

In my setup there is a DUE that communicates with the LIM and my Tesla GEN3 charger via CAN 1. It also has the necessary 6 hardware lines for the charger and a simulation for the fuel filler flap for the LIM. It also queries the temperature at the CP and a button to cancel charging. The connection to the car, especially with the BMS, current sensor and cooling system is via CAN 0. This DUE is only in operation during charging, AC or DC, and also controls precharge and main contactors, which are switched by Damien's LDU board while driving.

I'm also planning to use a separate charge controller as a gateway between the vehicle CAN bus and the charging CAN bus. How is your DUE code comparable with Damien's LIM code for the zombieVerter? And is it open source?
Jon volk's hardware would also be a perfect fit to have the voltage measure board and contactor driver included.
muehlpower uses Arduino the zombieVerter VCU uses libopencm3 and Jon volk wants to use STM HAL/FreeRTOS.
What are your considerations to chose one HAL/ framework above the other?

I use STs HAL due to the simplicity of project setup with Mxcube. It saves quite a bit of time for me and if I run into a problem there hasn’t been an instance where I didn’t find the solution with some time on google. I’m also a newbie to code and want to stick with the C to not confuse myself further.

jon volk wrote: ↑Mon Sep 20, 2021 5:30 pm In my particular use case, this is in a sealed enclosure next to contactor box ~12" from the charge port.
I may look to try breaking this out as another board that isnt specific my vehicle afterward. I am also using an actual i3 charge port.

Did you figure out the part numbers for the mating sockets to all those harnesses on the original i3 charge port cable or you cut off the connectors and using hard wiring?

jon volk wrote: ↑Mon Oct 04, 2021 11:22 am I use STs HAL due to the simplicity of project setup with Mxcube. It saves quite a bit of time for me and if I run into a problem there hasn’t been an instance where I didn’t find the solution with some time on google. I’m also a newbie to code and want to stick with the C to not confuse myself further.

Jon I'm in was in the same boat. Do you have an empty project setup for that?

I went in the end with VSCode debugging and nice IDE

jon volk wrote: ↑Mon Oct 04, 2021 11:22 am I use STs HAL due to the simplicity of project setup with Mxcube. It saves quite a bit of time for me and if I run into a problem there hasn’t been an instance where I didn’t find the solution with some time on google. I’m also a newbie to code and want to stick with the C to not confuse myself further.

I agree.
Has someone started to port the code?

I plan on starting that in a week or so. I started with getting the Chevy Volt BMS stuff going first. I should have the first boards tomorrow so should be able to do some initial testing soon. Once I get a board built and do an insulation resistance test for the HV isolation, I’ll post the project to GitHub.

Boards arrived so hopefully some initial testing after an insulation resistance test and wrapping up some code. I did end up adding a big heat sink as those resistors did heat up quick by themselves on the bench. I guess never underestimate power dissipation.

jon volk wrote: ↑Thu Oct 07, 2021 9:21 pm Boards arrived so hopefully some initial testing after an insulation resistance test and wrapping up some code. I did end up adding a big heat sink as those resistors did heat up quick by themselves on the bench. I guess never underestimate power dissipation.

looks great!

Assembled, mcu takes a flash and the hottest spot after an hour of supplying 8v to the contactor resistors was 110F directly behind them on the board and quickly drops to around 80F in 70 ambient moving away from the backside of the pad. So far so good.

Waiting to see your GitHub!

really showing off your modICE clear enclosures. makes me jealous !