openinverter.org wiki - User contributions [en]

16-cell BMS

2026-04-11T11:30:28Z

Johu: /* Communication */

[[Category:BMS]]
[[Category:Battery]]
[[File:16-cell BMS.jpg|thumb|16-cell BMS]]
The goal of this BMS is to use mostly decade old components to create a 16 channel cell voltage meter. It uses a very accurate sigma/delta ADC for superb resolution. It can drain about 100mA from a cell or charge it with 50 mA via the DC/DC converter. The ability to both charge and discharge cells speeds up balancing despite the low balancing current.

When turned off it drains no current from the connected cells at all.

On the low voltage side it features two inputs for temperature sensors and one input for a 5V current sensor, differential or single ended.

It can be cascaded to be used with more than 16 cells and has an automatic addressing scheme to forgo the use of jumpers or DIP switches. All communication is done via CAN. Supply voltage is 12V with about 20 mA draw when not balancing.

The software is not yet finished, see forum for progress <ref>https://openinverter.org/forum/viewtopic.php?t=2338</ref>

The boards can be bought in the [https://openinverter.org/shop/index.php?route=product/product&product_id=74 shop].

== Pinout ==
The pinout is also written to the bottom silkscreen.

On the left side you see 17 inputs. The first one is connected to the negative pole (GND) of your (sub)pack, the subsequent ones to the positive poles of up to 16 cells. At least the lower two cell inputs must be connected. When cascading modules the positive-most input of module n is also the GND of module n+1, so must be spliced to connect to both.

On the top right is the vehicle interfacing or low voltage connector. From top to bottom it is low voltage GND, 12V, enable_in, enable_out, CANH, CANL. GND, 12V, CANH, CANL are connected to all modules in parallel whereas enable_out is chained to enable_in of the next module. The first enable_in must be connected to 12V whenever the BMS should become active, e.g. when charging or driving. The module with 12V on the enable_in auto-detects as "main" module, collects data from the subsequent modules and sends more high level CAN messages

On the bottom right is the temperature sensor and current sensor input. Top to bottom it is tsensor1+, tsensor1- (not silkscreened), tsensor2+ , tsensor2-(not silkscreened), 5V, CUR+, CUR-, GND. A single ended current sensor is just connected to CUR+.

Right now the current sensor is only supported on the main module.

=== Connector part numbers ===
{| class="wikitable"
|+
!Connector
!Manufacturer
!Header
!Counterpart
!Pins
|-
|LV connector (supply, CAN, enable)
|Phoenix Contact
|1803468
|1803617
|
|-
|Temperature and current sensors
|Molex
|640454-8
|1375820-8
|1445336-1
|-
|Cell taps
|Molex
|1-640456-7
|1-1375820-7
|1445336-1
|}

=== Power supply ===
The pins GND and 12V must be connected to a permanent 12V source in order to ensure correct operation. In other words, don't connect 12V for example to your cars ignition 12V that is interrupted whenever you stop the car. The BMS uses the STM32 NVRAM to store some long term process values, most importantly SoH. If you don't care about the latter you might as well interrupt the supply completely.

The enable input of the first (main) module is connected to an interruptable 12V source. This input starts up the BMS. Enable can stay high but even a 1s pulse is enough to start the BMS, as it will then keep itself running as long as needed.

The BMS will then keep running as long as current flows through the battery. 2 hours after it has measured the last current flow it will shut down. It will use these 2 hours to let the cells settle to their open circuit voltage and will do balancing and [[16-cell BMS#State of Health calculation|SoH calculation]]. Afterwards it will shut itself down and consume only a few uA from your 12V source.

== Communication ==
All configuration, queries and firmware updates are done via the CAN bus. There is no independent web interface like known from e.g. the inverter. However there is a solution to connect an ESP32 via CAN and then have the known web interface <ref>https://openinverter.org/forum/viewtopic.php?p=56913#p56913</ref> or you can use Dave Fiddes "oic" tool for the command line<ref>https://openinverter.org/forum/viewtopic.php?t=2907</ref>. It is important to know that the main module has node-id 10 and the subsequent ones 10+i (i index of submodule, so 1st submodule has node-id 11). The base node id can be configured to start at something else than 10.

'''All info given here is preliminary and will likely change!'''

Apart from that the modules output periodic CAN messages depending on their role. The base address for cyclic messages defaults to 0x1F4 and can be changed by modifying pdobase on the main module. pdobase is ignored on the sub modules.

All modules output on ID 501 (0x1F5) + i
{| class="wikitable"
|+
!start
!length
!item
!description
|-
|0
|13
|umin
|minimum cell voltage of module i
|-
|16
|13
|umax
|maximum cell voltage of module i
|-
|30
|2
|counter
|counts from 0-3 (anti-freeze)
|-
|32
|13
|uavg
|average cell voltage of module i
|-
|48
|8
|tempmin
|Minimum temp on module i - signed
|-
|56
|8
|tempmax
|Maximum temp on module i - signed
|}
The main module does not output its local accumulated values but accumulated values over all modules.

In addition the main module outputs on id 500 (0x1F4)
{| class="wikitable"
!start
!length
!item
!description
|-
|0
|11
|chargelim
|maximum charge current in A
|-
|11
|11
|dischargelim
|maximum discharge current in A
|-
|22
|10
|soc
|Pack soc in 0.1%
|-
|32
|16
|idcavg
|Averaged current reading of last 1s in 0.1A - signed!
|-
|48
|10
|utotal
|Total pack voltage in V
|-
|62
|2
|counter
|counts from 0-3 (anti-freeze)
|}

=== Reading individual cell voltages ===
Cell voltages are only available via CAN SDO from the module that measures them. So voltages 1-16 must be queried from the first (main) module, 17-32 from the 2nd (1st submodule) and so on. With Dave Fiddes tool this translates to:<syntaxhighlight lang="bash">
oic -n 10 dumpall #dumps all values including cell voltages from 1st module
oic -n 11 dumpall #same for second module
oic -n 11 read u0 #Read first cell voltage of second module
</syntaxhighlight>For querying voltages say in your arduino sketch you'll need to acquire every voltage separately by sending and receiving SDO messages

<code>0x60A#0x40 idhigh 0x21 idlow 0 0 0 0</code>

idhigh and low are the bytes of the internal ID. The id of the first cell voltage is 2006 (0x7D6) so for querying the 1st cell voltage of the first module you send

<code>0x60A#0x40 0x07 0x21 0xD6 0 0 0 0</code>

And you will receive the reply

<code>0x58A#0x43 0x07 0x21 0xD6 0xD0 0xED 0x01 0</code>

0x0001EDD0 is the voltage value which decodes to mV x 32. So 0x1EDD0/32 = 3950.5 mV.

The next cell would be on 0x7D7 and the last on 0x7E5. The next 16 voltages are then queried from node id 0x60B.

=== Configuration Parameters ===
There is currently a limited set of parameters which will be extended as the software grows. This table always reflects the latest git commit. Check the page history for previous versions.

These are the parameters of v0.20.B
{| class="wikitable"
|+
!Name
!Unit
!Min
!Max
!Default
!Description
|-
| colspan="6" |'''BMS'''
|-
|gain
|uV/dig
|1
|1000
|586
|Scaling factor from ADC digits to mV
|-
|correction0
|ppm
| -10000
|10000
| -1250
|The first two and the last channel have slightly different topology and need their own correction factor
|-
|correction1
|ppm
| -10000
|10000
|1500
|
|-
|correction15
|ppm
| -10000
|10000
|1000
|
|-
|numchan
|
|1
|16
|16
|Number of cells connected to the module, power cycle required following saving parameters to update.
|-
|balmode
|
|0
|3
|0
|Balancing mode
0=No balancing
1=Only bump up low cells
2=Only dissipate high cells
3=Do both

By default balancing starts 60s after power up or in fact 60s after idcavg settled below 1A. You will see opmode changing to RunBalance
|-
|ubalance
|mV
|0
|4500
|4500
|Voltage above which top balancing is started
|-
|idlewait
|s
|0
|100000
|60
|Number of seconds to wait after stop of current flow to measure unloaded cell voltage und start balancing
|-
| colspan="6" |'''Battery Characteristics'''
|-
|dischargemax
|A
|1
|2047
|200
|Maximum discharge current
|-
|nomcap
|Ah
|0
|1000
|100
|Nominal capacity
|-
|icc1
|A
|1
|2000
|50
|Maximum charge current of empty battery
|-
|icc2
|A
|1
|2000
|30
|Maximum charge current of roughly half-charged battery
|-
|icc3
|A
|1
|2000
|20
|Maximum charge current of rather full battery
|-
|ucv1
|mV
|3000
|4500
|3900
|First constant voltage set point. Transition to next one when dropping below icc2
|-
|ucv2
|mV
|3000
|4500
|4000
|Second constant voltage set point. Transition to next one when dropping below icc3
|-
|ucellmax
|mV
|3000
|4500
|4200
|Third constant voltage set point and maximum cell voltage
|-
|ucellmin
|mV
|1000
|4500
|3300
|Minimum loaded cell voltage. Discharge limit is dropped to stay above this value
|-
|chargeXsoc
|%
|0
|100
|
|Percentage of charge current at soc X. In between two points charge current is interpolated
|-
|sohpreset
|%
|10
|100
|100
|This is the starting value for the state of health (SoH) calculation. The value is continuously updated by the BMS as SoH is estimated.
|-
| colspan="6" |'''Sensor Setup'''
|-
|idcgain
|dig/A
| -1000
|1000
|10
|Gain (or actually division factor) of current sensor
|-
|idcofs
|dig
| -4095
|4095
|0
|0A offset
|-
|idcmode
|
|0
|3
|0
|Current sensor mode 0=Off, 1=Single Ended ADC, 2=Differential ADC, 3=ISA current shunt
|-
|tempsns
|
| 0
|3
| 0
|Temperature sensor 0=None, 1=Channel1, 2=Channel3, 3=Both (set tempsns 0 in dashboard if dropdown not availble and value set as -1)
|-
|tempres
|Ohm
|10
|500000
|10000
|Nominal sensor resistance at 25°C
|-
|tempbeta
|
|1
|100000
|3900
|beta factor of Steinhart equation (see data sheet)
|-
| colspan="6" |'''Communication'''
|-
|pdobase
|
|0
|2047
|500
|base COB Id for cyclic messages. Main module uses pdobase and pdobase+1, 1st submodule uses pdobase+2 and so on
|-
|sdobase
|
|0
|63
|10
|base node ID for SDO queries. Main module uses sdobase, 1st submodule sdobase+1 and so on
|}

=== Spot values ===
All values that the BMS either measures or calculates are called spot values. While all modules show all spot values, some only make sense on the main module. The column "scope" denotes that. "M" means the value is only relevant on the main module, "S" means it's relevant on main and sub modules.
{| class="wikitable"
|+
!Name
!Unit
!Scope
!Description
|-
|version
|
|S
|Firmware version
|-
|opmode
|
|S
|State of operation

* BOOT - System starting
* GETADDR - Waiting for address assignment
* SETADDR - Setting address of next node
* REQINFO - Requesting info from sub modules
* RECVINFO - Receiving info
* INIT - Initialize BMS hardware
* SELFTEST - Running hardware self tests
* RUN - normal operation when current flows through battery
* IDLE - battery is idle, i.e. no current through it for a given time
* ERROR - selftests detected a critical error, operation halted
|-
|lasterr
|
|S
|Last detected error, see Errors
|-
|errchan
|
|S
|Cell tap channel causing the error, if applicable
|-
|modaddr
|
|S
|Address of module
|-
|modnum
|
|S
|Total number of modules
|-
|totalcells
|
|M
|Total number of cells
|-
|counter
|
|S
|Revolving counter 0-15 100 ms clock rate
|-
|uptime
|s
|S
|Time in s since power was applied to 12V pin
|-
|chargein
|As
|M
|Charge into the battery
|-
|chargeout
|As
|M
|Charge from the battery to load
|-
|soc
|%
|M
|State of charge, i.e. available charge in percent of fully charged battery
|-
|soh
|%
|M
|State of health, i.e. available total charge in percent of data sheet value when new
|-
|chargelim
|A
|M
|Current limit for charging the battery, see [[16-cell BMS#Charge Curve|Charge Curve]]
|-
|dischargelim
|A
|M
|Current limit for discharging, see [[16-cell BMS#Calculating current limits|Calculating current limits]]
|-
|idc
|A
|M
|Present current through battery, negative for current out of the battery, positive for current into the battery
|-
|idcavg
|A
|M
|Average current of the last second
|-
|power
|W
|M
|Average battery power of the last second
|-
|tempmin
|°C
|M
|Minimum temperature of all modules
|-
|tempmax
|°C
|M
|Maximum temperature of all modules
|-
|uavg
|mV
|M
|average cell voltage over entire pack
|-
|umin
|mV
|M
|Minimum cell voltage of entire pack
|-
|umax
|mV
|M
|Maximum cell voltage of entire pack
|-
|udelta
|mV
|M
|Difference between minimum and maximum cell voltage of entire pack
|-
|utotal
|mV
|M
|Sum of all cell voltages, i.e. pack voltage
|-
|uX
|mV
|S
|Present voltage of cell X of current module, see also [[16-cell BMS#Reading individual cell voltages|Reading individual cell voltages]]
|-
|uavgX, uminX, umaxX, tempminX, tempmaxX
|mV, °C
|M
|Average/Minimum/Maximum cell voltage and temperature of sub module X
|-
|uXcmd
|
|S
|State of balancer
|-
|cpuload
|%
|S
|Time the CPU spends actually doing something
|}

== Operation ==

=== State of Charge calculation ===
The State of Charge (SoC) lets you know how many percent of charge you battery still holds, in percent of a fully charged battery.

Determining SoC is split into two methods: determining the SoC from cell voltage and then tracking it as current flows in or out of the pack.

To estimate the SoC a 10-point lookup table is implemented that maps from cell voltage to SoC. The accuracy of this table is directly related to the accuracy of the estimation. You can edit the lookup table by changing the '''chargeXsoc''' parameters. The voltages you enter are open circuit voltages. These can only be obtained when there was no current flow through the battery for a certain amount of time, typically 10-30 minutes. This time is configured via the '''idlewait''' parameter.

So whenever the BMS has the chance to estimate the SoC it will do so. You can adjust '''idlewait''' to a low value to start estimating quickly. It means the first estimates will be off but it will become more accurate if the pack remains unloaded for longer time.

The subsequent tracking of SoC requires the BMS to know the current through the battery. Right now it supports analog current sensors (e.g. hall effect) with an operating voltage of 5V. Within this class it supports differential and single ended sensors, configurable via '''idcmode'''. The parameters '''idcofs''' and '''idcgain''' are used for calibration. When no current is flowing adjust '''idcofs''' until '''idcavg''' shows 0A. Then put a known current through the sensor and adjust '''idcgain''' until '''idcavg''' shows the correct current.

Lastly the BMS needs to know the energy or charge content of your battery in Ah. This is configured with the '''nomcap''' parameter and can be found in the data sheet.

=== State of Health calculation ===
The State of Health (SoH) lets you know how the remaining fully charged capacity, in percent of the data sheet value, i.e. when the battery was new. Batteries slowly degrade over time and usage cycles.

Whenever we do a SoC estimation as described above, we also update the SoH. If the estimated SoC has changed by more than 20% we compare the energy that we have taken out of the battery to the difference in SoC. If the two match, the SoH is 100%. If we have taken more energy from the battery then the difference in SoC suggests, SoH is above 100% (and you likely configured a wrong '''nomcap'''). Otherwise SoH is < 100%.

As this method comes with certain inaccuracies we only change the long term SoH slowly, i.e. every estimate is slowly averaged onto the long term SoH. This should balance out inaccuracies.

The spot value '''soh''' shows the current long term SoH. The value is also reflected onto '''sohpreset''', a saveable parameter. Whenever you need to interrupt the BMSes power supply you should go should save parameters so that next time it starts up with the correct long term SoH.

=== Calculating current limits ===
Limiting charge and discharge current are the only means of this BMS to protect the battery. It has no means to turn off the current flow by itself but instead relies on the connected components to obey the calculated current limits that are sent out via CAN. The current limits are calculated in a number of steps.

==== Charge Curve ====
The initial approach was to assign a certain charge current to points in the SoC curve. This method can be skewed if the SoC calculation is off for some reason. The new method deploys 3 CC/CV regulators. This was copied from oberving VWs charge curve of the MEB cars. The first regulator has the highest charge current and aims for a voltage typically around 3.9V for many NMC chemistries. When current drops below the CC value of the second regulator then that one is used, aiming for a higher voltage of typically 4V. And finally the 3rd regulator takes over aiming for the charge end voltage of typically 4.2V. When setting all 3 to the same values a simple CC/CV curve is generated.

==== Voltage limits ====
Voltage limits are enforced via a P-regulator. I.e. as we approach the upper or lower voltage limit current is cut back to stay away from the limits until it reaches 0A. The upper and lower limit is configurable

==== Temperature limits ====
High temperature will cut back both charge and discharge current whereas low temperature will only cut back charge current. These limits only work when you've set up your temperature sensors correctly. Please check the readings against a reference before relying on it.

Charge current has a proportional, multi-step temperature derating, i.e. the charge curve defined by iccX and ucvX is scaled with a derating factor the lower the temperature or when the maximum temperature is approached

* Below '''-20°C''' no charging is possible
* Between '''-20°C and 0°C''' charging with 0-30% of the charge curve is allowed
* Between '''0°C and 25°C''' charging with 30% to 100% of the charge curve is allowed
* Between '''43°C and 50°C''' charging with 100% to 0% of the charge curve is allowed, i.e. '''above 50°C''' charging is no longer allowed.

Discharging is not limited at low temperatures as high discharge currents at low temperatures are not known to cause damage. As the battery heats up discharge current is limited, starting at '''46°C''' until discharging is no longer allowed when reaching '''53°C'''.

==== Energy limits ====
Not enforced yet. Some OEM BMSes cut back charge current after a certain amount of energy has been put into the battery. E.g. When starting charge at 50% charge rate will end up higher at 70% than if we start charging at 10%.

== Calibration ==
As every instrument the voltage measurement needs to be calibrated to cancel out tolerances in the involved components. There are 4 parameters for calibration.

* '''gain:''' The translation ration between the ADC digits and mV. This applies to all channels
* '''correction0, 1 and 15''': This allows special tuning of said 3 channels because they use a slightly different current path and thus need a small gain correction

=== Calibration procedure ===
First we determine the general gain. Pick any of the voltages between u2 and u14 which share a common gain factor. Use a good multimeter to measure the physical voltage of your reference channel. Now tune the '''gain''' parameter until your multimeter and the BMS voltage read the same value +-0.5mV. Now all channels from 2-14 should read correctly.

Then for channels 0, 1 and 15 also measure the physical voltage input and tune the respective '''correctionX''' parameter until multimeter and BMS report the same voltage. The correction factors can be negative if a channels reads too high.

Save your parameters to flash to make the calibration permanent.

== Flashing firmware ==
If you have sourced the BMS boards from an alternative source then you will need to flash the bootloader and firmware onto the BMS. This is a relatively straightforward process once understood but took me a while to get it to work.

Firstly you will need an STLink dongle, I used this one <ref>https://www.amazon.co.uk/dp/B07QBLNDPM?psc=1</ref> but I believe any will do.

I used STM32CubeProgrammer <ref>https://www.st.com/en/development-tools/stm32cubeprog.html</ref> on Linux to flash my board and also (prior to flashing) upgrade the STLinkdongle to the latest firmware (might not be necessary but felt it was wise to do so).

Once you've got STM32Cubeprogrammer installed you're probably best erasing the STM32 Chip to ensure you're starting from a clean board. Navigate to the "Erasing & Programming" tab on the left and connect to your STlink dongle (if you havent already). Once connected, (you can also update the firmware on the dongle at this point on the "Memory & File Editing" tab), connect the dongle to the BMS board via the VDCG pins...

(V = Voltage 3.3V, D = SWDIO, C = SWCLK, G = Gnd)

and perform a "full chip erase".

Once thats complete head over to Github to download the Bootloader <ref>https://github.com/jsphuebner/stm32-CANBootloader/releases</ref> and download the hex file (you may need to be logged in to download the files).

Once downloaded, in STM32CubeProgrammer, navigate to the "Memory & File Editing" tab and open the hex file you just downloaded, once opened you can use the "Download" button to flash the bootloader to your BMS board.

You can now repeat the above process of opening the hex file and "downloading" to the BMS board for the main BMS firmware which is available from the BMS Github repository <ref>https://github.com/jsphuebner/FlyingAdcBms/actions</ref> .

Once all that is done, you can move onto the Web interface. You'll need the "Can Backend" version of the ESP32 Web Interface available here <ref>https://github.com/jsphuebner/esp32-web-interface/tree/can-backend</ref> (click the green code button and download zip)

Once downloaded download Arduino IDE 1.8.19 (you'll need this version, nothing beyond version 2 as this does not support SPIFFS flashing as far as I'm aware) and set it up for flashing to ESP32 boards <ref>https://docs.espressif.com/projects/arduino-esp32/en/latest/installing.html</ref> and also flashing ESP32 Spiffs <ref>https://randomnerdtutorials.com/install-esp32-filesystem-uploader-arduino-ide/</ref>.

To setup the Web interface Arduino sketch, you'll want to unzip and (IMPORTANT) RENAME the folder to "esp32-web-interface" to match the ino file within the folder, if you don't do this you'll have problems further down the line. Once unzipped and renamed, open the esp32-web-interface.ino sketch file and upload it to your ESP32 dev board. when this completed you'll also need to upload the SPIFFS image, you can do this by going to Tools and "ESP32 Sketch Data Upload" and choosing SPIFFS. once this is complete, you can connect your ESP32 to your BMS board via CAN and power them and they shuld work (note you'll need the 12V enable in line connected also).

Once on the Web interface, select Node ID 10 and a speed of 500kbps and you'll have all your wonderful BMS spot values and params ready to go.

== Operating Limits==

* Max voltage for the board is 70v
* Max number of cells is 16

==References==
<references />

Bidirectional Charging

2026-03-01T17:09:30Z

Johu: /* Practical implementation with parts list */

Bidirectional charging means, that the car is able to provide power to the outside world, via the charge port.

Tags: bidi, inverse charging, vehicle-to-load, V2L, vehicle-to-home, V2H, vehicle-to-grid, V2G

=== Forum discussions related to bidirectional charging: ===
https://openinverter.org/forum/viewtopic.php?t=5090 Bidirectional charger with PV Hybrid inverter and pyPLC

https://openinverter.org/forum/viewtopic.php?t=3551 Drawing power out of CCS port (V2x, inverse charging, bidirectional CCS) - Collection of experiences with different cars

https://openinverter.org/forum/viewtopic.php?t=6745 Energy Controller including CCS interface, FoccciCape, BeagleBone

=== Bidirectional Charging via AC ===
Some OEM on-board-chargers are able to create AC voltage. Todo: any reverse-engineering ongoing for such chargers? E.g. for Hyundai/Kia E-GMP?

=== Bidirectional Charging via CHAdeMO ===
The CHAdeMO standard was planned for supporting bidirectional power transfer from the beginning. Todo: Any open-source projects in this direction?

=== Bidirectional Charging via CCS ===
The CCS standard did not plan bidirectional power transfer. This means, depending on the implementation details of the cars charge controller, the car may or may not allow to draw energy out of the CCS port. Later versions of the CCS standard, ISO15118 (2020?), are defining special communication procedures for bidirectional power transfer. But it will take some time until this standard is widely adapted.

In the open-source world, however, we do not need to wait until OEMs and charger manufacturers implement the latest ISO15118. We can support bidirectional charging even with the "old" DIN spec. The strategy is: Even if the car is requesting to be charged, it also accepts discharging, without terminating the charging session. It may terminate if the SOC falls below a certain, configurable level, to prevent an empty battery. The car announces the allowed charge current, and the same value, just in opposite direction, can be used as a discharge current limit, too.

== Practical implementation with parts list ==
[[File:CCS bidirectional charger.jpg|thumb|First prototype]]
One way to DIY a bidirectional charger is the use of a hybrid PV inverter with high voltage battery input. The advantage is that these are mass-produced (thus cheap) and conform to the various legal requirements. The inverter then handles power transfer and optionally smart functions such as zero grid import/export and we only need to supply the surrounding logic and electrics.
[[File:CCS bidirectional charger 2.jpg|thumb|Second version]]
This component list is just an example that has proven to work. It is preliminary and has not been tested with OEM cars yet, so it will likely be extended. As always, you are working with high voltage and especially grid voltage. Make sure you are qualified otherwise ask for help.
{| class="wikitable"
|+
!Item
!Approximate cost
!Link/Source
!Remarks
|-
|Sungrow SH5.0RT (or more powerful variant)
|850€
|[https://ger.sungrowpower.com/productDetail/905 Sungrow]
|Pick an inverter that is supported by [https://github.com/dalathegreat/Battery-Emulator/wiki#supported-inverters-list Battery Emulator]
|-
|CCS Connector
|90€
|AliExpress
|Plain connector without cable
|-
|BeagleBone Green
|45€
|[https://www.mouser.de/ProductDetail/Seeed-Studio/102010027?qs=Hlcjo%2FO3pQ5AxSET1oW%252B%252Bg%3D%3D Mouser]
|
|-
|[[FoccciCape]]
|250€
|[https://openinverter.org/shop/index.php?route=product/product&product_id=81 OI shop]
|RS485, CAN comm, 2x relay driver, CCS
|-
|Flexible cable, 4 or 5 pole
|4€/m
|Local hardware store
|Size according to charging current. 5x2.5mm² used for the 5 kW inverter
For DC+, DC-, PE, CP and PP.
PP can optionally be terminated in the plug, then you just need 4 poles
|-
|2 Fuse blocks
|6€ each
|[https://www.mouser.de/ProductDetail/Altech/002540101?qs=rrS6PyfT74edEoVfbnqxvg%3D%3D Mouser]
|
|-
|2 25A fuses
|8€ each
|[https://www.mouser.de/ProductDetail/Eaton-Electronics/EKM10-25-1P?qs=sGAEpiMZZMsIz3CjQ1xegZx2pdJYlyprSptsITKY%2FrCWMtgS7UD2BQ%3D%3D Mouser]
|400V AC rated from your local hardware store suffices as it's 2 in series
|-
|12V 2A DIN rail supply
|18€
|[https://www.mouser.de/ProductDetail/MEAN-WELL/HDR-30-12?qs=pHY8AWQbqIN66yYHZne39A%3D%3D Mouser]
|
|-
|DIN rail cabinet
|20€
|Local hardware store
|
|-
|MC4 connector set
|5€
|
|
|-
|5V to 400V step up converter
|10€
|[https://www.ebay.de/itm/357155751299 ebay]
|Only needed for OEM cars
|}
The CCS connectors + and - is connected to the inverter input via the fuse blocks. I did not deploy additional contactors but rely on the ones that are already in the car and the inverter. The PLC modems output transformer is connected to PE and CP via a capacitor and a resistor, more details in [https://github.com/uhi22/pyPLC/blob/master/doc/hardware.md uhis github].

The BeagleBone is connected to the PLC modem and the inverter Ethernet port, so you will need a small network switch, also for the uplink to your home network. In addition the CAN outputs of the COMPCE cape connects to the inverters battery CAN (pins 3 and 4 on the Sungrow).

More info on the software setup in the development threads linked above, uhis github and [https://github.com/jsphuebner/esp-egycounter Johannes' github].

This setup can also be used with CHAdeMO cars in which case the powerline modem can be omitted.

== Compatible cars ==
This table lists cars where we successfully pulled power OUT of the cars battery via its quick charge port.

More details on [https://github.com/jsphuebner/esp-egycounter forum thread].

First column: Y - works flawlessly with no timeout, P - works partially with long timeout, N - works not at all or quick timeout
{| class="wikitable"
|+
!
!Make
!Model
!Requirements
!Remarks
|-
|P
|Hyundai
|Ioniq Classic 28 kWh
|Simulated precharge
|Timeout after 10 minutes
|-
|Y
|MG
|MG4
|Simulated precharge
|No timeout
|-
|Y
|Tesla
|Model Y
|Physical Precharge voltage
|5 kW tested
|-
|Y
|Tesla
|Model 3
|Physical Precharge voltage
|BMS aborts charging session if more than 15Ah discharge have been detected
|-
|Y
|BYD
|Atto 3
|
|5 kW tested
|-
|Y
|Polestar
|2
|Physical Precharge voltage
|
|-
|Y
|Polestar
|4
|
|Tested with physical precharge voltage (johu in Sweden 2026-02-19)
|-
|N
|VW
|ID.4
|
|Timeout after 1 minute
|-
|Y
|BMW
|i3
|Simulated precharge
|model year 2022, https://openinverter.org/forum/viewtopic.php?p=89894#p89894
|-
|N
|BMW
|IX4
|
|Timeout after 5 minutes
|-
|N
|Chevrolet
|Bolt
|
|Timeout after 50 s
|-
|N
|Kia
|EV6
|
|Timeout after 10 s
|}
Some other car models have been tested by the guys of the Everest project, the results are available on github https://github.com/EVerest/logfiles

== Collection of documents related to bidirectional charging ==
todo

== References ==
todo

[[Category:CCS]]

Bidirectional Charging

2026-03-01T17:08:04Z

Johu: /* Practical implementation with parts list */

Bidirectional charging means, that the car is able to provide power to the outside world, via the charge port.

Tags: bidi, inverse charging, vehicle-to-load, V2L, vehicle-to-home, V2H, vehicle-to-grid, V2G

=== Forum discussions related to bidirectional charging: ===
https://openinverter.org/forum/viewtopic.php?t=5090 Bidirectional charger with PV Hybrid inverter and pyPLC

https://openinverter.org/forum/viewtopic.php?t=3551 Drawing power out of CCS port (V2x, inverse charging, bidirectional CCS) - Collection of experiences with different cars

https://openinverter.org/forum/viewtopic.php?t=6745 Energy Controller including CCS interface, FoccciCape, BeagleBone

=== Bidirectional Charging via AC ===
Some OEM on-board-chargers are able to create AC voltage. Todo: any reverse-engineering ongoing for such chargers? E.g. for Hyundai/Kia E-GMP?

=== Bidirectional Charging via CHAdeMO ===
The CHAdeMO standard was planned for supporting bidirectional power transfer from the beginning. Todo: Any open-source projects in this direction?

=== Bidirectional Charging via CCS ===
The CCS standard did not plan bidirectional power transfer. This means, depending on the implementation details of the cars charge controller, the car may or may not allow to draw energy out of the CCS port. Later versions of the CCS standard, ISO15118 (2020?), are defining special communication procedures for bidirectional power transfer. But it will take some time until this standard is widely adapted.

In the open-source world, however, we do not need to wait until OEMs and charger manufacturers implement the latest ISO15118. We can support bidirectional charging even with the "old" DIN spec. The strategy is: Even if the car is requesting to be charged, it also accepts discharging, without terminating the charging session. It may terminate if the SOC falls below a certain, configurable level, to prevent an empty battery. The car announces the allowed charge current, and the same value, just in opposite direction, can be used as a discharge current limit, too.

== Practical implementation with parts list ==
[[File:CCS bidirectional charger.jpg|thumb|First prototype]]
One way to DIY a bidirectional charger is the use of a hybrid PV inverter with high voltage battery input. The advantage is that these are mass-produced (thus cheap) and conform to the various legal requirements. The inverter then handles power transfer and optionally smart functions such as zero grid import/export and we only need to supply the surrounding logic and electrics.
[[File:CCS bidirectional charger 2.jpg|thumb|Second version]]
This component list is just an example that has proven to work. It is preliminary and has not been tested with OEM cars yet, so it will likely be extended. As always, you are working with high voltage and especially grid voltage. Make sure you are qualified otherwise ask for help.
{| class="wikitable"
|+
!Item
!Approximate cost
!Link/Source
!Remarks
|-
|Sungrow SH5.0RT (or more powerful variant)
|850€
|[https://ger.sungrowpower.com/productDetail/905 Sungrow]
|Pick an inverter that is supported by [https://github.com/dalathegreat/Battery-Emulator/wiki#supported-inverters-list Battery Emulator]
|-
|CCS Connector
|90€
|AliExpress
|Plain connector without cable
|-
|BeagleBone Green
|45€
|[https://www.mouser.de/ProductDetail/Seeed-Studio/102010027?qs=Hlcjo%2FO3pQ5AxSET1oW%252B%252Bg%3D%3D Mouser]
|
|-
|[[FoccciCape]]
|250€
|[https://openinverter.org/shop/index.php?route=product/product&product_id=81 OI shop]
|RS485, CAN comm, 2x relay driver, CCS
|-
|Flexible cable, 4 or 5 pole
|4€/m
|Local hardware store
|Size according to charging current. 5x2.5mm² used for the 5 kW inverter
For DC+, DC-, PE, CP and PP.
PP can optionally be terminated in the plug, then you just need 4 poles
|-
|2 Fuse blocks
|6€ each
|[https://www.mouser.de/ProductDetail/Altech/002540101?qs=rrS6PyfT74edEoVfbnqxvg%3D%3D Mouser]
|
|-
|2 25A fuses
|8€ each
|[https://www.mouser.de/ProductDetail/Eaton-Electronics/EKM10-25-1P?qs=sGAEpiMZZMsIz3CjQ1xegZx2pdJYlyprSptsITKY%2FrCWMtgS7UD2BQ%3D%3D Mouser]
|400V AC rated from your local hardware store suffices as it's 2 in series
|-
|12V 2A DIN rail supply
|18€
|[https://www.mouser.de/ProductDetail/MEAN-WELL/HDR-30-12?qs=pHY8AWQbqIN66yYHZne39A%3D%3D Mouser]
|In case relays are needed later on, otherwise 5V model makes things easier
|-
|12V to 5V step-down converter
|5€
|ebay or ali
|Needed if you chose 12V supply
|-
|DIN rail cabinet
|20€
|Local hardware store
|
|-
|MC4 connector set
|5€
|
|
|-
|5V to 400V step up converter
|10€
|[https://www.ebay.de/itm/357155751299 ebay]
|Only needed for OEM cars
|}
The CCS connectors + and - is connected to the inverter input via the fuse blocks. I did not deploy additional contactors but rely on the ones that are already in the car and the inverter. The PLC modems output transformer is connected to PE and CP via a capacitor and a resistor, more details in [https://github.com/uhi22/pyPLC/blob/master/doc/hardware.md uhis github].

The BeagleBone is connected to the PLC modem and the inverter Ethernet port, so you will need a small network switch, also for the uplink to your home network. In addition the CAN outputs of the COMPCE cape connects to the inverters battery CAN (pins 3 and 4 on the Sungrow).

More info on the software setup in the development threads linked above, uhis github and [https://github.com/jsphuebner/esp-egycounter Johannes' github].

This setup can also be used with CHAdeMO cars in which case the powerline modem can be omitted.

== Compatible cars ==
This table lists cars where we successfully pulled power OUT of the cars battery via its quick charge port.

More details on [https://github.com/jsphuebner/esp-egycounter forum thread].

First column: Y - works flawlessly with no timeout, P - works partially with long timeout, N - works not at all or quick timeout
{| class="wikitable"
|+
!
!Make
!Model
!Requirements
!Remarks
|-
|P
|Hyundai
|Ioniq Classic 28 kWh
|Simulated precharge
|Timeout after 10 minutes
|-
|Y
|MG
|MG4
|Simulated precharge
|No timeout
|-
|Y
|Tesla
|Model Y
|Physical Precharge voltage
|5 kW tested
|-
|Y
|Tesla
|Model 3
|Physical Precharge voltage
|BMS aborts charging session if more than 15Ah discharge have been detected
|-
|Y
|BYD
|Atto 3
|
|5 kW tested
|-
|Y
|Polestar
|2
|Physical Precharge voltage
|
|-
|Y
|Polestar
|4
|
|Tested with physical precharge voltage (johu in Sweden 2026-02-19)
|-
|N
|VW
|ID.4
|
|Timeout after 1 minute
|-
|Y
|BMW
|i3
|Simulated precharge
|model year 2022, https://openinverter.org/forum/viewtopic.php?p=89894#p89894
|-
|N
|BMW
|IX4
|
|Timeout after 5 minutes
|-
|N
|Chevrolet
|Bolt
|
|Timeout after 50 s
|-
|N
|Kia
|EV6
|
|Timeout after 10 s
|}
Some other car models have been tested by the guys of the Everest project, the results are available on github https://github.com/EVerest/logfiles

== Collection of documents related to bidirectional charging ==
todo

== References ==
todo

[[Category:CCS]]

Bidirectional Charging

2026-03-01T17:07:38Z

Johu: /* Practical implementation with parts list */

Bidirectional charging means, that the car is able to provide power to the outside world, via the charge port.

Tags: bidi, inverse charging, vehicle-to-load, V2L, vehicle-to-home, V2H, vehicle-to-grid, V2G

=== Forum discussions related to bidirectional charging: ===
https://openinverter.org/forum/viewtopic.php?t=5090 Bidirectional charger with PV Hybrid inverter and pyPLC

https://openinverter.org/forum/viewtopic.php?t=3551 Drawing power out of CCS port (V2x, inverse charging, bidirectional CCS) - Collection of experiences with different cars

https://openinverter.org/forum/viewtopic.php?t=6745 Energy Controller including CCS interface, FoccciCape, BeagleBone

=== Bidirectional Charging via AC ===
Some OEM on-board-chargers are able to create AC voltage. Todo: any reverse-engineering ongoing for such chargers? E.g. for Hyundai/Kia E-GMP?

=== Bidirectional Charging via CHAdeMO ===
The CHAdeMO standard was planned for supporting bidirectional power transfer from the beginning. Todo: Any open-source projects in this direction?

=== Bidirectional Charging via CCS ===
The CCS standard did not plan bidirectional power transfer. This means, depending on the implementation details of the cars charge controller, the car may or may not allow to draw energy out of the CCS port. Later versions of the CCS standard, ISO15118 (2020?), are defining special communication procedures for bidirectional power transfer. But it will take some time until this standard is widely adapted.

In the open-source world, however, we do not need to wait until OEMs and charger manufacturers implement the latest ISO15118. We can support bidirectional charging even with the "old" DIN spec. The strategy is: Even if the car is requesting to be charged, it also accepts discharging, without terminating the charging session. It may terminate if the SOC falls below a certain, configurable level, to prevent an empty battery. The car announces the allowed charge current, and the same value, just in opposite direction, can be used as a discharge current limit, too.

== Practical implementation with parts list ==
[[File:CCS bidirectional charger.jpg|thumb|First prototype]]
One way to DIY a bidirectional charger is the use of a hybrid PV inverter with high voltage battery input. The advantage is that these are mass-produced (thus cheap) and conform to the various legal requirements. The inverter then handles power transfer and optionally smart functions such as zero grid import/export and we only need to supply the surrounding logic and electrics.
[[File:CCS bidirectional charger 2.jpg|thumb|Second version]]
This component list is just an example that has proven to work. It is preliminary and has not been tested with OEM cars yet, so it will likely be extended. As always, you are working with high voltage and especially grid voltage. Make sure you are qualified otherwise ask for help.
{| class="wikitable"
|+
!Item
!Approximate cost
!Link/Source
!Remarks
|-
|Sungrow SH5.0RT (or more powerful variant)
|850€
|[https://ger.sungrowpower.com/productDetail/905 Sungrow]
|Pick an inverter that is supported by [https://github.com/dalathegreat/Battery-Emulator/wiki#supported-inverters-list Battery Emulator]
|-
|CCS Connector
|90€
|AliExpress
|Plain connector without cable
|-
|BeagleBone Green
|45€
|[https://www.mouser.de/ProductDetail/Seeed-Studio/102010027?qs=Hlcjo%2FO3pQ5AxSET1oW%252B%252Bg%3D%3D Mouser]
|
|-
|[[FoccciCape]]
|t.b.d.
|[https://openinverter.org/shop/index.php?route=product/product&product_id=81 OI shop]
|RS485, CAN comm, 2x relay driver, CCS
|-
|Flexible cable, 4 or 5 pole
|4€/m
|Local hardware store
|Size according to charging current. 5x2.5mm² used for the 5 kW inverter
For DC+, DC-, PE, CP and PP.
PP can optionally be terminated in the plug, then you just need 4 poles
|-
|2 Fuse blocks
|6€ each
|[https://www.mouser.de/ProductDetail/Altech/002540101?qs=rrS6PyfT74edEoVfbnqxvg%3D%3D Mouser]
|
|-
|2 25A fuses
|8€ each
|[https://www.mouser.de/ProductDetail/Eaton-Electronics/EKM10-25-1P?qs=sGAEpiMZZMsIz3CjQ1xegZx2pdJYlyprSptsITKY%2FrCWMtgS7UD2BQ%3D%3D Mouser]
|400V AC rated from your local hardware store suffices as it's 2 in series
|-
|12V 2A DIN rail supply
|18€
|[https://www.mouser.de/ProductDetail/MEAN-WELL/HDR-30-12?qs=pHY8AWQbqIN66yYHZne39A%3D%3D Mouser]
|In case relays are needed later on, otherwise 5V model makes things easier
|-
|12V to 5V step-down converter
|5€
|ebay or ali
|Needed if you chose 12V supply
|-
|DIN rail cabinet
|20€
|Local hardware store
|
|-
|MC4 connector set
|5€
|
|
|-
|5V to 400V step up converter
|10€
|[https://www.ebay.de/itm/357155751299 ebay]
|Only needed for OEM cars
|}
The CCS connectors + and - is connected to the inverter input via the fuse blocks. I did not deploy additional contactors but rely on the ones that are already in the car and the inverter. The PLC modems output transformer is connected to PE and CP via a capacitor and a resistor, more details in [https://github.com/uhi22/pyPLC/blob/master/doc/hardware.md uhis github].

The BeagleBone is connected to the PLC modem and the inverter Ethernet port, so you will need a small network switch, also for the uplink to your home network. In addition the CAN outputs of the COMPCE cape connects to the inverters battery CAN (pins 3 and 4 on the Sungrow).

More info on the software setup in the development threads linked above, uhis github and [https://github.com/jsphuebner/esp-egycounter Johannes' github].

This setup can also be used with CHAdeMO cars in which case the powerline modem can be omitted.

== Compatible cars ==
This table lists cars where we successfully pulled power OUT of the cars battery via its quick charge port.

More details on [https://github.com/jsphuebner/esp-egycounter forum thread].

First column: Y - works flawlessly with no timeout, P - works partially with long timeout, N - works not at all or quick timeout
{| class="wikitable"
|+
!
!Make
!Model
!Requirements
!Remarks
|-
|P
|Hyundai
|Ioniq Classic 28 kWh
|Simulated precharge
|Timeout after 10 minutes
|-
|Y
|MG
|MG4
|Simulated precharge
|No timeout
|-
|Y
|Tesla
|Model Y
|Physical Precharge voltage
|5 kW tested
|-
|Y
|Tesla
|Model 3
|Physical Precharge voltage
|BMS aborts charging session if more than 15Ah discharge have been detected
|-
|Y
|BYD
|Atto 3
|
|5 kW tested
|-
|Y
|Polestar
|2
|Physical Precharge voltage
|
|-
|Y
|Polestar
|4
|
|Tested with physical precharge voltage (johu in Sweden 2026-02-19)
|-
|N
|VW
|ID.4
|
|Timeout after 1 minute
|-
|Y
|BMW
|i3
|Simulated precharge
|model year 2022, https://openinverter.org/forum/viewtopic.php?p=89894#p89894
|-
|N
|BMW
|IX4
|
|Timeout after 5 minutes
|-
|N
|Chevrolet
|Bolt
|
|Timeout after 50 s
|-
|N
|Kia
|EV6
|
|Timeout after 10 s
|}
Some other car models have been tested by the guys of the Everest project, the results are available on github https://github.com/EVerest/logfiles

== Collection of documents related to bidirectional charging ==
todo

== References ==
todo

[[Category:CCS]]

FoccciCape

2026-02-01T09:51:34Z

Johu: LED usage

[[Category:CCS]] [[Category:Rapid Charging]]
[[Category:Charger]]
[[Category:OpenInverter]]
[[File:FoccciCape.jpg|thumb|FoccciCape]]
This is an add-on board for the popular BeagleBone single board computer. It is mainly a communication breakout board but features a very special form of communication: CCS! So with it you can get your EV to close its charge port contactors. At the very least you can then charge your EV with your hybrid PV inverter and if the manufacturer doesn't actively inhibit it you can also draw energy from your vehicles battery to supply your house or even selling it back to the grid.

In addition it has enough communication power to talk to all sorts of PV inverters, BMSes etc. to tie it all together an fully control the flow of energy from a single point.

== Connections ==
The board has a 12-way Phoenix connector or can be equipped with any other 3.81 mm pin pitch terminal. Together with the BeagleBone it offers the following interfaces:

* 1x RS485
* 2x CAN
* 1x CCS PowerLine communication and PWM signalling
* 2x open drain relay outputs
* 1x status LED output combined with button input
* 1x Ethernet (on BeagleBone)
* 1x USB (on BeagleBone)
* 1x HDMI (only BeagleBone Black)
* 1x Grove I2C (only BeagleBone Green)
* 1x Grove UART (only BeagleBone Green)

=== Part numbers and links ===

* Phoenix 12-way connector [https://www.mouser.de/ProductDetail/Phoenix-Contact/1803523?qs=CXo1rOUe%2FWsOGk2v2GZlUQ%3D%3D 1803523]
* Phoenix 12-way screw terminal [https://www.mouser.de/ProductDetail/Phoenix-Contact/1803675?qs=WWq3Ki8dym4RD77JGGq8bA%3D%3D 1803675]
* BeagleBone Green [https://www.mouser.de/ProductDetail/Seeed-Studio/102010027?qs=Hlcjo%2FO3pQ5AxSET1oW%252B%252Bg%3D%3D 102010027]
* DIN rail [https://www.reichelt.de/de/de/shop/produkt/gehaeuse_fuer_beaglbone_black_stahl_schwarz-315121 enclosure] and [https://www.reichelt.de/de/de/shop/produkt/gehaeuse_fuer_beaglbone_black_stahl_schwarz-315121 clip]

=== Pin Mapping ===
The cape uses only pins on P9 as follows
{| class="wikitable"
|+
!Pin
!Function
|-
|P9.3/4
|3.3V
|-
|P9.5/6
|5V
|-
|P9.11
|UART4_RX
|-
|P9.13
|UART4_TX
|-
|P9.14
|RELAY1
|-
|P9.15
|QCA Interrupt
|-
|P9.16
|RELAY2
|-
|P9.17
|QCA_SPI_CS
|-
|P9.18
|QCA_SPI_MOSI
|-
|P9.19
|CAN0_RX
|-
|P9.20
|CAN0_TX
|-
|P9.21
|QCA_SPI_MISO
|-
|P9.22
|QCA_SPI_CLK
|-
|P9.24
|CAN1_RX
|-
|P9.26
|CAN1_TX
|-
|P9.28
|LED_OUT
|-
|P9.30
|BUTTON_IN
|-
|P9.39
|CP_SENSE
|-
|P9.42
|CP_PWM
|-
|P9.43-46
|GND
|}

=== Using the LED/Button pin ===
The script ccscontrol.py uses this pin to indicate status and also reads it back so that the user can stop the CCS session using a button. The pin outputs 3.3V via a 270 Ohm resistor that can be used directly to drive an LED. When the LED is shorted via a button this can be read back and is used as a stop request.

== Software ==
[[File:StorageSystemConfigurationScreen.png|thumb|Storage System Configuration Screen]]
The software is comprised of a bunch of [https://github.com/jsphuebner/esp-egycounter/tree/main/battery-control python scripts] that exchange information via MQTT. The following modules are available:

* Communication via Modbus using [https://github.com/tjhowse/modbus4mqtt Modbus4Mqtt]
* Communication with SoyoSource inverters
* Simulation of BYD battery via CAN
* Communication with Eltek Flatpack chargers
* Reading status from Keba P20 EVSE
* Communication with Manson switch mode power supply
* Communication with openinverter [[16-cell BMS]]
* Retrieval of spot market prices via awattar or Tibber API
* Data logger
* Submission of raw meter data to Tibber
* CCS communication via [[PyPLC]]
* Energy flow controller (Zero Grid Exchange, charge on low spot market price, discharge only on high spot market price)
* Web Interface for configuration and monitoring

== Installation ==
This section is only relevant if you're setting up the BeagleBone yourself. If you buy a preprogrammed one from the shop (not yet available) this has already been done for you. We are also working on an image file that is already set up.

The howto for compiling the QCA kernel module and setting it up can be found on the [https://openinverter.org/forum/viewtopic.php?p=87295#p87295 forum].

Next you need to flash the SPI flash on the cape with QCA firmware, this is also described on the [https://openinverter.org/forum/viewtopic.php?p=87710#p87710 forum].

Finally you enable all relevant peripherals in /boot/uEnv.txt:<syntaxhighlight lang="ini">
uboot_overlay_addr0=/lib/firmware/BB-CAN0-00A0.dtbo
uboot_overlay_addr1=/lib/firmware/BB-CAN1-00A0.dtbo
uboot_overlay_addr2=/lib/firmware/BB-SPI0-QCASPI-00A0.dtbo
uboot_overlay_addr3=/lib/firmware/BB-UART4-00A0.dtbo

</syntaxhighlight>To enable both CAN interfaces at boot you configure systemd-networkd by creating one file per interface, /etc/systemd/network/80-can0.network<syntaxhighlight lang="ini">
[Match]
Name=can0

[CAN]
BitRate=500K
RestartSec=100ms
</syntaxhighlight>And likewise 81-can1.network (Name=can1). Of course you need to pick the baud rate that matches the devices you connect to the port, but 500k is usually your best bet.

FoccciCape

2026-02-01T09:46:23Z

Johu: Added pin mapping

[[Category:CCS]] [[Category:Rapid Charging]]
[[Category:Charger]]
[[Category:OpenInverter]]
[[File:FoccciCape.jpg|thumb|FoccciCape]]
This is an add-on board for the popular BeagleBone single board computer. It is mainly a communication breakout board but features a very special form of communication: CCS! So with it you can get your EV to close its charge port contactors. At the very least you can then charge your EV with your hybrid PV inverter and if the manufacturer doesn't actively inhibit it you can also draw energy from your vehicles battery to supply your house or even selling it back to the grid.

In addition it has enough communication power to talk to all sorts of PV inverters, BMSes etc. to tie it all together an fully control the flow of energy from a single point.

== Connections ==
The board has a 12-way Phoenix connector or can be equipped with any other 3.81 mm pin pitch terminal. Together with the BeagleBone it offers the following interfaces:

* 1x RS485
* 2x CAN
* 1x CCS PowerLine communication and PWM signalling
* 2x open drain relay outputs
* 1x status LED output combined with button input
* 1x Ethernet (on BeagleBone)
* 1x USB (on BeagleBone)
* 1x HDMI (only BeagleBone Black)
* 1x Grove I2C (only BeagleBone Green)
* 1x Grove UART (only BeagleBone Green)

=== Part numbers and links ===

* Phoenix 12-way connector [https://www.mouser.de/ProductDetail/Phoenix-Contact/1803523?qs=CXo1rOUe%2FWsOGk2v2GZlUQ%3D%3D 1803523]
* Phoenix 12-way screw terminal [https://www.mouser.de/ProductDetail/Phoenix-Contact/1803675?qs=WWq3Ki8dym4RD77JGGq8bA%3D%3D 1803675]
* BeagleBone Green [https://www.mouser.de/ProductDetail/Seeed-Studio/102010027?qs=Hlcjo%2FO3pQ5AxSET1oW%252B%252Bg%3D%3D 102010027]
* DIN rail [https://www.reichelt.de/de/de/shop/produkt/gehaeuse_fuer_beaglbone_black_stahl_schwarz-315121 enclosure] and [https://www.reichelt.de/de/de/shop/produkt/gehaeuse_fuer_beaglbone_black_stahl_schwarz-315121 clip]

=== Pin Mapping ===
The cape uses only pins on P9 as follows
{| class="wikitable"
|+
!Pin
!Function
|-
|P9.3/4
|3.3V
|-
|P9.5/6
|5V
|-
|P9.11
|UART4_RX
|-
|P9.13
|UART4_TX
|-
|P9.14
|RELAY1
|-
|P9.15
|QCA Interrupt
|-
|P9.16
|RELAY2
|-
|P9.17
|QCA_SPI_CS
|-
|P9.18
|QCA_SPI_MOSI
|-
|P9.19
|CAN0_RX
|-
|P9.20
|CAN0_TX
|-
|P9.21
|QCA_SPI_MISO
|-
|P9.22
|QCA_SPI_CLK
|-
|P9.24
|CAN1_RX
|-
|P9.26
|CAN1_TX
|-
|P9.28
|LED_OUT
|-
|P9.30
|BUTTON_IN
|-
|P9.39
|CP_SENSE
|-
|P9.42
|CP_PWM
|-
|P9.43-46
|GND
|}

== Software ==
[[File:StorageSystemConfigurationScreen.png|thumb|Storage System Configuration Screen]]
The software is comprised of a bunch of [https://github.com/jsphuebner/esp-egycounter/tree/main/battery-control python scripts] that exchange information via MQTT. The following modules are available:

* Communication via Modbus using [https://github.com/tjhowse/modbus4mqtt Modbus4Mqtt]
* Communication with SoyoSource inverters
* Simulation of BYD battery via CAN
* Communication with Eltek Flatpack chargers
* Reading status from Keba P20 EVSE
* Communication with Manson switch mode power supply
* Communication with openinverter [[16-cell BMS]]
* Retrieval of spot market prices via awattar or Tibber API
* Data logger
* Submission of raw meter data to Tibber
* CCS communication via [[PyPLC]]
* Energy flow controller (Zero Grid Exchange, charge on low spot market price, discharge only on high spot market price)
* Web Interface for configuration and monitoring

== Installation ==
This section is only relevant if you're setting up the BeagleBone yourself. If you buy a preprogrammed one from the shop (not yet available) this has already been done for you. We are also working on an image file that is already set up.

The howto for compiling the QCA kernel module and setting it up can be found on the [https://openinverter.org/forum/viewtopic.php?p=87295#p87295 forum].

Next you need to flash the SPI flash on the cape with QCA firmware, this is also described on the [https://openinverter.org/forum/viewtopic.php?p=87710#p87710 forum].

Finally you enable all relevant peripherals in /boot/uEnv.txt:<syntaxhighlight lang="ini">
uboot_overlay_addr0=/lib/firmware/BB-CAN0-00A0.dtbo
uboot_overlay_addr1=/lib/firmware/BB-CAN1-00A0.dtbo
uboot_overlay_addr2=/lib/firmware/BB-SPI0-QCASPI-00A0.dtbo
uboot_overlay_addr3=/lib/firmware/BB-UART4-00A0.dtbo

</syntaxhighlight>To enable both CAN interfaces at boot you configure systemd-networkd by creating one file per interface, /etc/systemd/network/80-can0.network<syntaxhighlight lang="ini">
[Match]
Name=can0

[CAN]
BitRate=500K
RestartSec=100ms
</syntaxhighlight>And likewise 81-can1.network (Name=can1). Of course you need to pick the baud rate that matches the devices you connect to the port, but 500k is usually your best bet.

CAN communication

2026-01-19T22:25:08Z

Johu: Added start/stop commands

The Revision 2 main board supports CAN communication. The CAN bus can be used for configuration and for obtaining values like voltages, input states etc. The CAN messages are configurable and can be adjusted to be compatible with existing equipment.

Since firmware 3.75 throttle and digital inputs can be controlled via CAN.

After firmware 5.27.R throttle, digital inputs, cruise speed and regen preset '''are no longer freely mappable due to safety concerns,''' see below.

Be aware that all CAN mapping uses decimal numbers. So COB ID 0x123 must be entered as '''291'''

== Inverter control via CAN - new! ==
As discussed here<ref>https://openinverter.org/forum/viewtopic.php?t=3743&start=50</ref> the CAN communication was redesigned to improve operational safety. This will become effective with the first official release after 5.27.R

Now there is a fixed mapping for pot, pot2, canio, cruisespeed and regenpreset along with some alive counters and a CRC.

The COB Id is still freely configurable and defaults to 0x3F. It is advised to use a low ID value as low IDs have priority on the bus over high Ids.

The mapping is as follows [startbit, endbit]:

* pot[0:11]
* pot2[12:23]
* canio[24:29]
** cruise[24]
** start[25]
** brake[26]
** forward[27]
** reverse[28]
** bms[29]
* canrun1[30:31]
* cruisespeed[32:45]
* canrun2[46:47]
* regenpreset[48:55]
* cancrc[56:63]

pot is the value of the first throttle channel and its range is configured with potmin/potmax as before. pot2 is the value of the second throttle channel, its range configured via pot2min/pot2max '''and we strongly recommend to use dual channel throttle pedals''' and setting potmode to CanDual (or DualChannel if you choose to connect the throttle directly to the inverter). We also recommand to set up your throttle in a way that doesn't use the full range from 0-4095 but leaves at least 500 digit at either end (so 500-3600) to be able to detect cable issues between throttle and VCU (short to Vcc, loss of GND and other wire breaks)

cruisespeed is the setpoint for the speed control loop in rpm with a maximum value of 16383 rpm. Only applied if the cruise and forward bit is also set and the brake bit is reset.

regenpreset is a value from 0-100% that controls how much of your configured regen (offthrotregen or brakeregen) is actually applied

canrun1/2 are simple message counters that count from 0-3 and indicate that the message producer doesn't just send the same, stale, content over and over again.

cancrc is an 8-bit CRC, the lowest byte of the STM32 integrated CRC32 generator. It spans over all 8 bytes where the crc byte is set to 0. If you're on a non-STM32 platform you can use this C-implementation<ref>https://github.com/jsphuebner/esp32-web-interface/blob/can-backend/src/oi_can.cpp#L191</ref>. CRC checking is optional to remain compatible with "dumb" CAN converters. It can be disabled with parameter controlcheck=CounterOnly.

== Controlling throttle via CAN - deprecated! ==
'''This no longer works starting v5.32.R! See above!'''

If you want to send the throttle and regen magnitude commands via CAN rather then via analog inputs you have to set "potmode" to "CAN" (=2). Next you have to map a CAN message to pot and optionally pot2. So say you have a digital throttle that sends values from 0 to 1000 for 0 to 100% travel on CAN-Id 100 in the first two bytes.
* Configure potmin=0 and potmax=1000
* Map CAN message to pot: can rx pot 100 0 16 1
CAN messages must be received every 500ms, otherwise throttle times out and is set to 0.

== Controlling Digital IO via CAN - deprecated ==
'''This no longer works starting v5.32.R! See above!'''

6 signals, namely cruise, start, brake, forward, backward and bms can be controlled via CAN. The CAN message is ORed to the physical inputs so you can have mixed signals also. Digital CAN IO doesn't need to be explicitely configured, it works as soon as you map a CAN message to "canio". "canio" is bit-encoded:
* Bit 0: cruise
* Bit 1: start
* Bit 2: brake
* Bit 3: forward
* Bit 4: reverse
* Bit 5: bms
So say you have a BMS that transmits an over/under voltage bit on CAN Id 200, 2nd data bit
can rx canio 200 2 1 1024
Note the 1024x gain that shifts the bit into the correct position (5 fraction bits plus 5th data bit). In this case all other IOs remain traditional, only BMS is controlled via CAN. Note that you cannot map multiple CAN messages onto "canio" as they would overwrite each other.

If you have a managed to mangle all 6 bits into one message, say CAN Id 300, first 6 bits the mapping is done like so
can rx canio 300 0 6 32
The same timeout mechanism is used as for throttle control, so after 500ms with no message the CAN-mapped inputs are assumed off. Traditional inputs remain unaffected.

== Setting and reading parameters via SDO ==
The abbreviation SDO is taken from the CANOpen protocol. It assigns a certain meaning to the 8 data bits of a CAN frame.

Note that SDO semantics (cmd) were changed since version 5.20.R of the inverter firmware. Old cmd value is in ()
{| class="wikitable"
!Purpose
!CAN-Id
!Byte 1 (Cmd)
!Bytes 2-3 (Index)
!Byte 4 (Subindex)
!Bytes 5-8 (Data)
|-
|Set Value
|0x601
|0x23 (0x40)
|0x2000
|Value Index
|Value x 32
|-
|Set Value Reply
|0x581
|0x60 (0x23)
|0x2000
|Value Index
|Value x 32
|-
|Get Value
|0x601
|0x40 (0x22)
|0x2000
|Value Index
|don't care
|-
|Get Value Reply
|0x581
|0x43
|0x2000
|Value Index
|Value x 32
|-
|Abort - invalid index
|0x581
|0x80
|Index of request
|Value Index
|Abort Code = 0x06020000
|-
|Abort - value out of range
|0x581
|0x80
|Index of request
|Value Index
|Abort Code = 0x06090030
|-
|Set Param
|0x601
|0x23 (0x40)
|0x21xx xx=MSB UID
|Param UID LSB
|Value x 32
|-
|Set Param Reply
|0x581
|0x60 (0x23)
|0x21xx xx=MSB UID
|Param UID LSB
|Value x 32
|-
|Get Param
|0x601
|0x40 (0x22)
|0x21xx xx=MSB UID
|Param UID LSB
|don't care
|-
|Get Param Reply
|0x581
|0x43
|0x21xx xx=MSB UID
|Param UID LSB
|Value x 32
|}
The value index must be determined by counting the output of the list command. E.g. "boost" at the very top has index 0, potnom has index 77. The indexes can change over firmware versions as new parameters are added somewhere in between.

The Get/Set Param commands use the unique parameter identifier assigned to each savable parameter. These do not vary between firmware versions. Only savable parameters not spot values can be read and written by these commands.

==== Examples ====
<code>0x601 # 0x40 0x00 0x20 0x00 0 0 0 0</code> Get value of "boost"

<code>0x601 # 0x23 0x00 0x20 0x01 0x80 0x0C 0 0</code> Set "fweak" to 100Hz (0xC80=3200 because scaled by 32)

<code>0x601 # 0x23 0xAA 0x31 0x01 0x08 0x10 1 0</code> Map value of fweak to COB ID 0x1AA, starting at bit 8, stretching 16 bits, scaled by 1

<code>0x601 # 0x40 0x10 0x20 0x0D 0 0 0 0</code> Get value of "pwmfrq" on any firmware version or build (0x0D = 13 from the PARAM_ENTRY() for "pwmfrq" in param_prj.h)

== Mapping values to arbitrary CAN messages ==
Values can be mapped into a certain bit range of the 64 payload bits of a CAN message. They can either be read from the message or sent via a message. To do so enter
can tx udc 123 0 16 10
This maps the value of udc to a CAN message with id 123 bits 0..15 (start at bit 0, span over 16 bits) with a gain of 10.
can tx din_forward 123 24 1 1
would map the pin state of the forward input to bit 24 of CAN message with id 123.

If you want to clear all messages, type
can clear
If you want to remove only a specific signal (starting version 4.18.R) type
can del <name>
To save your can map simply type "save".

[https://openinverter.org/forum/viewtopic.php?t=1468 idcmin, idcmax example]

=== Mapping Values through the web interface ===
Value can also be mapped through the web interface.

[[File:Spot values.png|alt=Spot values|thumb|Spot values]]

* CAN Id
** This is the Can Id assigned to the message. Remember, all CAN mapping uses decimal numbers. So ID 0x123 must be entered as '''291.''' Here is a converter to help: https://www.rapidtables.com/convert/number/hex-to-decimal.html
* Position
** This is where in the 64 bit length of the CAN message the data should start.
* Bits
** How many bits are assigned to send the data. Negative numbers will yield big endian mapping
* Gain
** This applies the internal scaling. Pre FW v5.27 this is fixed point (integers only). FW v5.27 and later is floating point (decimals allowed).
** Your gain needs to be opposite of the receiving end's scaling. For example, the Speedhut EV gauges list a scaling of 0.1, meaning they apply that to incoming messages, so you need to transmit with a gain of 10.
* Map to CAN
** TX to tell the control board to transmit the data onto the CANBUS
** RX to tell the control board to expect to receive this data from the CANBUS

=== Mapping values via SDO ===
Special SDO objects also allow editing the CAN map. See [[CAN communication#Examples|examples]] above on how to send an SDO request.

Adding a mapping requires a sequence of 3 SDO requests:

* Index 0x3000 - Add transmit (TX) mapping
** Subindex 0: CAN Id, data contains 11 or 29-bit CAN Id
** Subindex 1: Parameter Id in bytes 0 and 1, bit position in byte 2, bit length in byte 3
** Subindex 2: Gain * 1000 in bytes 0-2, offset in byte 3
* Index 0x3001 - Add receive (RX) mapping
** Same subindexes as above

For reading the entire CAN map subsequent reads to indexes 0x3100 (TX) or 0x3180 (RX) must be performed. The indexes and subindexes must be incremented between the reads until an SDO abort is received. Each CAN message maps to its own SDO index and the data items within the message map to sub indexes like so

* Index 0x3100 - first transmit (TX) message
** Subindex 0: CAN Id
** Subindex 1: First parameter Id, position and length (see add)
** Subindex 2: First gain and offset (see add)
** Subindex 3: Second parameter Id, position and length
** Subindex 4: Second gain and offset
** Subindex 5: third...
* Index 0x3101 - second TX message
** as first
* Index 0x3180 - First receive (RX) message
** as above
* Index 0x3181 - Second RX message

Once you know the index an sub index of a specific mapping you can also delete it by sending a write request. E.g. writing to Index 0x3181, sub index 3 would delete the second item of the second RX message.

Because the mappings are stored in a dynamic memory structure their order will change when deleting items. So before deleting the next item you have to re-download the entire mapping table to obtain the correct index.

After changing the map you have to send a flash save command to make your changes permanent. See commands below

== SDO commands ==
Write requests to SDO Index 0x5002 trigger various commands

* Subindex 0 - save parameters and CAN mappings to flash
* Subindex 1 - loads parameters from flash
* Subindex 2 - MCU reset
* Subindex 3 - Load parameter defaults
* Subindex 4 - Manuel start (sine firmware only)
* Subindex 5 - Manual stop (inverter firmware only)

== Limits ==
* A maximum of 10 messages can be defined
* Per message a maximum of 8 values can be mapped (50 total over all messages in FW v5.27 and later)
* a value can not span across the 32-bit boundary, i.e. it must be fully contained in the first or second 32 bits of the message. E.g. "can tx udc 123 16 32 10" is not allowed (will change in later versions)
* A value can span maximum 32 bits

== [[wikipedia:Endianness|Endianness]] ==
CAN messages sent to, or received from the inverter are Little-endian.

If you are sending or receiving messages containing multi-byte values then the byte order must be taken into account. Upcoming versions of the CAN module will allow receiving big endian data.

== PC Tool ==
A PC based tool called [https://pypi.org/project/openinverter-can-tool/ openinverter_can_tool] exists to query and control openinverter systems over CAN bus with a supported CAN interface adapter.

[[Category:CAN]] [[Category:OpenInverter]]

Chevrolet Volt Water Heater

2026-01-11T13:41:54Z

Johu: Added connector table

It is 5kW Eberspächer coolant heater that works on 400Vdc. It is found in Chevrolet Volt gen1 and Opel Ampera cars as well as others.
This model is SW CAN controlled. https://leafdriveblog.wordpress.com/2018/12/05/5kw-electric-heater/

3 pin LV connector has GND, SW CAN and ENABLE pins in that order.

Temperature sensor is 3.2Kohm at 21degC. It is NTC type.

This info from EVTV Forum:
The Eberspacher CAN version of their PTC liquid heater used in the Chevrolet Volt will work when used with a 33.33Kb SWCAN.
The data below is what we have found to be the minimum required to turn on and operate this heater.
This capture will operate the heater at approximately 33% of full power.
To command higher power, increase the value of message 0x10720099 byte 1 (it begins with byte 0) which is 3E below.
We saw full power heat when 85 was used as the value for byte 1 and that value will vary based upon inlet temperature. The data below contains an entry for “Bus” and that refers to which CAN Bus of the 2 Buses on the CANDue recorded the original event.

== Temperature sensor ==
Here is code to convert the ADC reading to °C. The pull-up resistor is 3k3 to 3V3 and the ADC has 12 digits.<syntaxhighlight lang="c++">
float AmperaHeater::GetTemperature()
{
const uint16_t lut[] = { 2950, 2600, 2330, 2070, 1850, 1650, 1470, 1280, 1120, 960, 830, 710, 615, 520, 440, 370, 300 };
const uint16_t tabSize = sizeof(lut) / sizeof(lut[0]);
const uint16_t minTemp = 0;
const uint16_t maxTemp = 80;
const uint16_t step = 5;
const uint16_t digit = AnaIn::temp.Get();
uint16_t last;

for (uint32_t i = 0; i < tabSize; i++)
{
uint16_t cur = lut[i];

if (cur <= digit)
{
//if we are outside the lookup table range, return minimum
if (0 == i) return minTemp;
float a = cur - digit;
float b = cur - last;
float c = step * a / b;
float d = (step * i) + minTemp;
return d - c;
}
last = cur;
}
return maxTemp;
}
</syntaxhighlight>

== Connectors ==
There are 3 connectors on the heater: HV, NTC temperature probe and control
{| class="wikitable"
|+
!Purpose
!Pin mapping
!P/N
!Link
|-
|HV
|A: HV+, B: HV-
|13737728 (old, Delphi) 13861584 (new Aptive) 13572764-L (Pins)
|[https://eu.mouser.com/ProductDetail/Aptiv-formerly-Delphi/13861584?qs=JFNnAd7rNk4SXrWmFFOo3Q%3D%3D Housing] [https://eu.mouser.com/ProductDetail/Aptiv-formerly-Delphi/13572764-L?qs=l4Gc20tDgJK4Niw57Y7mGg%3D%3D Pins]
|-
|NTC
|
|1-967644-1 (housing) 5-965906-6 (pins)
|[https://eu.mouser.com/ProductDetail/TE-Connectivity-AMP/1-967644-1?qs=HGBP0O8H0vqNC4k5xF4hWw%3D%3D Housing] [https://eu.mouser.com/ProductDetail/TE-Connectivity-AMP/5-965906-6?qs=QWBbna5I2bYsBVTO46El0Q%3D%3D Pins]
|-
|Control
|A (BLK): GND, B: SWCAN, C: 12V
|13519047 (housing) 12191812-L (pins)
|[https://eu.mouser.com/ProductDetail/Aptiv/13519047?qs=xyz6lfZ1ktIhqycYgOC3Xg%3D%3D Housing] [https://eu.mouser.com/ProductDetail/Aptiv/12191812-L?qs=DlE0rdXB%2FL2cB%252BzgPD8oLg%3D%3D Pins]
|}

== CAN messaging ==
There seem to be a number of variants of the protocol out there.

==== Variant 1 ====
{| class="wikitable"
|+
!ID
! Extended
! LEN
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
!Byte 5
!Byte 6
!Byte 7
|-
|0x100
|False
|0
|0
|0
|0
|0
|0
|0
|0
|0
|-
|0x621
|False
|8
|0
|40
|0
|0
|0
|0
|0
|0
|-
|0x10720099
|True
|5
|02
|Watts/48
|0
|0
|0
|
|
|
|-
|0x13FFE060
|True
|1
|0
|
|
|
|
|
|
|
|-
|0x102CC040
|True
|8
|01
|01
|CF
|0F
|0
|51
|46
|60
|-
|0x10242040
|True
|1
|01
|
|
|
|
|
|
|
|-
|0x102740CB
|True
|3
|2D
|0
|0
|
|
|
|
|
|-
|0x102740CB
|True
|3
|19
|9
|9
|
|
|
|
|
|}

==== Variant 2 ====
{| class="wikitable"
!ID
! Extended
! LEN
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
!Byte 5
!Byte 6
!Byte 7
|-
|0x100
|False
|0
|0
|0
|0
|0
|0
|0
|0
|0
|-
|0x621
|False
|8
|0
|52
|0
|0
|0
|0
|0
|0
|-
|0x10720099
|True
|5
|02
|Watts/48
|0
|0
|0
|
|
|
|-
|0x13FFE060
|True
|0
|
|
|
|
|
|
|
|
|-
|0x102CC040
|True
|8
|01
|01
|CF
|18
|0
|51
|06
|6D
|-
|0x102740CB
|True
|3
|41
|0
|0
|
|
|
|
|
|-
|0x10242040
|True
|1
|02
|
|
|
|
|
|
|
|}

Michael Neuweiler has published this wiring on his blog. http://s80ev.blogspot.com/2016/12/the-heat-is-on.html

https://1.bp.blogspot.com/-osB952BjJFM/V1HAdFRBpfI/AAAAAAAAAlE/3OND1f6nJLMi1ZS8arpRwGWIKpLRF65GwCPcB/s1600/gevcu_ext_layout.gif

Connecting using CAN board and Canalyst II does nothing since it is not normal CAN interface. This heater is supposed to work only with SW CAN transciever. Transciever should output a wake up signal for everything to work.
One such SW transciever is NCV7356.
[[Category:Chevrolet]]
[[Category:Opel]]
[[Category:Heater Coolant]]
[[Category:HVAC]]

Chevrolet Volt Water Heater

2026-01-11T13:03:14Z

Johu: Added info about temp sensor and other CAN variant

It is 5kW Eberspächer coolant heater that works on 400Vdc. It is found in Chevrolet Volt gen1 and Opel Ampera cars as well as others.
This model is SW CAN controlled. https://leafdriveblog.wordpress.com/2018/12/05/5kw-electric-heater/

3 pin LV connector has GND, SW CAN and ENABLE pins in that order.

Temperature sensor is 3.2Kohm at 21degC. It is NTC type.

This info from EVTV Forum:
The Eberspacher CAN version of their PTC liquid heater used in the Chevrolet Volt will work when used with a 33.33Kb SWCAN.
The data below is what we have found to be the minimum required to turn on and operate this heater.
This capture will operate the heater at approximately 33% of full power.
To command higher power, increase the value of message 0x10720099 byte 1 (it begins with byte 0) which is 3E below.
We saw full power heat when 85 was used as the value for byte 1 and that value will vary based upon inlet temperature. The data below contains an entry for “Bus” and that refers to which CAN Bus of the 2 Buses on the CANDue recorded the original event.

== Temperature sensor ==
Here is code to convert the ADC reading to °C. The pull-up resistor is 3k3 to 3V3 and the ADC has 12 digits.<syntaxhighlight lang="c++">
float AmperaHeater::GetTemperature()
{
const uint16_t lut[] = { 2950, 2600, 2330, 2070, 1850, 1650, 1470, 1280, 1120, 960, 830, 710, 615, 520, 440, 370, 300 };
const uint16_t tabSize = sizeof(lut) / sizeof(lut[0]);
const uint16_t minTemp = 0;
const uint16_t maxTemp = 80;
const uint16_t step = 5;
const uint16_t digit = AnaIn::temp.Get();
uint16_t last;

for (uint32_t i = 0; i < tabSize; i++)
{
uint16_t cur = lut[i];

if (cur <= digit)
{
//if we are outside the lookup table range, return minimum
if (0 == i) return minTemp;
float a = cur - digit;
float b = cur - last;
float c = step * a / b;
float d = (step * i) + minTemp;
return d - c;
}
last = cur;
}
return maxTemp;
}
</syntaxhighlight>

== CAN messaging ==
There seem to be a number of variants of the protocol out there.

==== Variant 1 ====
{| class="wikitable"
|+
!ID
! Extended
! LEN
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
!Byte 5
!Byte 6
!Byte 7
|-
|0x100
|False
|0
|0
|0
|0
|0
|0
|0
|0
|0
|-
|0x621
|False
|8
|0
|40
|0
|0
|0
|0
|0
|0
|-
|0x10720099
|True
|5
|02
|Watts/48
|0
|0
|0
|
|
|
|-
|0x13FFE060
|True
|1
|0
|
|
|
|
|
|
|
|-
|0x102CC040
|True
|8
|01
|01
|CF
|0F
|0
|51
|46
|60
|-
|0x10242040
|True
|1
|01
|
|
|
|
|
|
|
|-
|0x102740CB
|True
|3
|2D
|0
|0
|
|
|
|
|
|-
|0x102740CB
|True
|3
|19
|9
|9
|
|
|
|
|
|}

==== Variant 2 ====
{| class="wikitable"
!ID
! Extended
! LEN
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
!Byte 5
!Byte 6
!Byte 7
|-
|0x100
|False
|0
|0
|0
|0
|0
|0
|0
|0
|0
|-
|0x621
|False
|8
|0
|52
|0
|0
|0
|0
|0
|0
|-
|0x10720099
|True
|5
|02
|Watts/48
|0
|0
|0
|
|
|
|-
|0x13FFE060
|True
|0
|
|
|
|
|
|
|
|
|-
|0x102CC040
|True
|8
|01
|01
|CF
|18
|0
|51
|06
|6D
|-
|0x102740CB
|True
|3
|41
|0
|0
|
|
|
|
|
|-
|0x10242040
|True
|1
|02
|
|
|
|
|
|
|
|}

Michael Neuweiler has published this wiring on his blog. http://s80ev.blogspot.com/2016/12/the-heat-is-on.html

https://1.bp.blogspot.com/-osB952BjJFM/V1HAdFRBpfI/AAAAAAAAAlE/3OND1f6nJLMi1ZS8arpRwGWIKpLRF65GwCPcB/s1600/gevcu_ext_layout.gif

Connecting using CAN board and Canalyst II does nothing since it is not normal CAN interface. This heater is supposed to work only with SW CAN transciever. Transciever should output a wake up signal for everything to work.
One such SW transciever is NCV7356.
[[Category:Chevrolet]]
[[Category:Opel]]
[[Category:Heater Coolant]]
[[Category:HVAC]]

Chevrolet Volt Water Heater

2026-01-08T20:24:00Z

Johu: Added to HVAC category

Bidirectional Charging

2025-12-17T16:45:33Z

Johu:

Bidirectional charging means, that the car is able to provide power to the outside world, via the charge port.

Tags: bidi, inverse charging, vehicle-to-load, V2L, vehicle-to-home, V2H, vehicle-to-grid, V2G

=== Forum discussions related to bidirectional charging: ===
https://openinverter.org/forum/viewtopic.php?t=5090

https://openinverter.org/forum/viewtopic.php?t=3551

=== Bidirectional Charging via AC ===
Some OEM on-board-chargers are able to create AC voltage. Todo: any reverse-engineering ongoing for such chargers? E.g. for Hyundai/Kia E-GMP?

=== Bidirectional Charging via CHAdeMO ===
The CHAdeMO standard was planned for supporting bidirectional power transfer from the beginning. Todo: Any open-source projects in this direction?

=== Bidirectional Charging via CCS ===
The CCS standard did not plan bidirectional power transfer. This means, depending on the implementation details of the cars charge controller, the car may or may not allow to draw energy out of the CCS port. Later versions of the CCS standard, ISO15118 (2020?), are defining special communication procedures for bidirectional power transfer. But it will take some time until this standard is widely adapted.

In the open-source world, however, we do not need to wait until OEMs and charger manufacturers implement the latest ISO15118. We can support bidirectional charging even with the "old" DIN spec. The strategy is: Even if the car is requesting to be charged, it also accepts discharging, without terminating the charging session. It may terminate if the SOC falls below a certain, configurable level, to prevent an empty battery. The car announces the allowed charge current, and the same value, just in opposite direction, can be used as a discharge current limit, too.

== Practical implementation with parts list ==
[[File:CCS bidirectional charger.jpg|thumb|First prototype]]
One way to DIY a bidirectional charger is the use of a hybrid PV inverter with high voltage battery input. The advantage is that these are mass-produced (thus cheap) and conform to the various legal requirements. The inverter then handles power transfer and optionally smart functions such as zero grid import/export and we only need to supply the surrounding logic and electrics.
[[File:CCS bidirectional charger 2.jpg|thumb|Second version]]
This component list is just an example that has proven to work. It is preliminary and has not been tested with OEM cars yet, so it will likely be extended. As always, you are working with high voltage and especially grid voltage. Make sure you are qualified otherwise ask for help.
{| class="wikitable"
|+
!Item
!Approximate cost
!Link/Source
!Remarks
|-
|Sungrow SH5.0RT (or more powerful variant)
|850€
|[https://ger.sungrowpower.com/productDetail/905 Sungrow]
|Pick an inverter that is supported by [https://github.com/dalathegreat/Battery-Emulator/wiki#supported-inverters-list Battery Emulator]
|-
|CCS Connector
|90€
|AliExpress
|Plain connector without cable
|-
|BeagleBone Green
|45€
|[https://www.mouser.de/ProductDetail/Seeed-Studio/102010027?qs=Hlcjo%2FO3pQ5AxSET1oW%252B%252Bg%3D%3D Mouser]
|
|-
|[[FoccciCape]]
|t.b.d.
|t.b.d
|RS485, CAN comm, 2x relay driver, CCS
|-
|Flexible cable, 4 or 5 pole
|4€/m
|Local hardware store
|Size according to charging current. 5x2.5mm² used for the 5 kW inverter
For DC+, DC-, PE, CP and PP.
PP can optionally be terminated in the plug, then you just need 4 poles
|-
|2 Fuse blocks
|6€ each
|[https://www.mouser.de/ProductDetail/Altech/002540101?qs=rrS6PyfT74edEoVfbnqxvg%3D%3D Mouser]
|
|-
|2 25A fuses
|8€ each
|[https://www.mouser.de/ProductDetail/Eaton-Electronics/EKM10-25-1P?qs=sGAEpiMZZMsIz3CjQ1xegZx2pdJYlyprSptsITKY%2FrCWMtgS7UD2BQ%3D%3D Mouser]
|400V AC rated from your local hardware store suffices as it's 2 in series
|-
|12V 2A DIN rail supply
|18€
|[https://www.mouser.de/ProductDetail/MEAN-WELL/HDR-30-12?qs=pHY8AWQbqIN66yYHZne39A%3D%3D Mouser]
|In case relays are needed later on, otherwise 5V model makes things easier
|-
|12V to 5V step-down converter
|5€
|ebay or ali
|Needed if you chose 12V supply
|-
|DIN rail cabinet
|20€
|Local hardware store
|
|-
|MC4 connector set
|5€
|
|
|-
|5V to 400V step up converter
|10€
|[https://www.ebay.de/itm/357155751299 ebay]
|Only needed for OEM cars
|}
The CCS connectors + and - is connected to the inverter input via the fuse blocks. I did not deploy additional contactors but rely on the ones that are already in the car and the inverter. The PLC modems output transformer is connected to PE and CP via a capacitor and a resistor, more details in [https://github.com/uhi22/pyPLC/blob/master/doc/hardware.md uhis github].

The BeagleBone is connected to the PLC modem and the inverter Ethernet port, so you will need a small network switch, also for the uplink to your home network. In addition the CAN outputs of the COMPCE cape connects to the inverters battery CAN (pins 3 and 4 on the Sungrow).

More info on the software setup in the development threads linked above, uhis github and [https://github.com/jsphuebner/esp-egycounter Johannes' github].

This setup can also be used with CHAdeMO cars in which case the powerline modem can be omitted.

== Compatible cars ==
This table lists cars where we successfully pulled power OUT of the cars battery via its quick charge port.

More details on [https://github.com/jsphuebner/esp-egycounter forum thread].

First column: Y - works flawlessly with no timeout, P - works partially with long timeout, N - works not at all or quick timeout
{| class="wikitable"
|+
!
!Make
!Model
!Requirements
!Remarks
|-
|P
|Hyundai
|Ioniq Classic 28 kWh
|Simulated precharge
|Timeout after 10 minutes
|-
|Y
|MG
|MG4
|Simulated precharge
|No timeout
|-
|Y
|Tesla
|Model Y
|Physical Precharge voltage
|5 kW tested
|-
|Y
|Tesla
|Model 3
|Physical Precharge voltage
|BMS aborts charging session if more than 15Ah discharge have been detected
|-
|Y
|BYD
|Atto 3
|
|5 kW tested
|-
|Y
|Polestar
|2
|Physical Precharge voltage
|
|-
|N
|VW
|ID.4
|
|Timeout after 1 minute
|-
|N
|BMW
|IX4
|
|Timeout after 5 minutes
|-
|N
|Chevrolet
|Bolt
|
|Timeout after 50 s
|-
|N
|Kia
|EV6
|
|Timeout after 10 s
|}

== Collection of documents related to bidirectional charging ==
todo

== References ==
todo

[[Category:CCS]]

Parameters

2025-12-13T19:08:04Z

Johu: Description of maxregentravelhz

The inverter can be adapted to many kinds of motors, battery packs and driver preferences by changing parameters. A video on parameters is here: https://youtu.be/GQNQbBUsqf0

A Parameter Database with common usage scenarios is here: https://openinverter.org/parameters/

A synchronous motor tuning guide is here: [[Using FOC Software]]

== Motor Parameters ==
The parameters to adjust the inverter to the motor are boost, fweak, fslipmin, fslipmax, polepairs, fmin, fmax and numimp.

They can be deduced from the motors nameplate or by trying which feels best. For illustration we will assume a bus voltage of 500V and a 4-pole (p=2) motor with a nominal speed of n=1450rpm@f=50Hz and 230V. With 500V DC an AC voltage of 500/1.41=355V can be generated.

'''boost''' is the digital amplitude of the sine wave at motor startup. It is needed to overcome the motors ohmic resistance. Digital amplitude is an internal quantity. 0 means no voltage is generated at all, 37813 means the full possible voltage is generated.

Example: boost=1700

At full throttle an effective voltage of 1700/37813*355=16V is generated. The best way to find a feasible value is to optimize it in the finished car. Start with the default value and increase until you get a good startup.

'''fweak''' is the frequency at which the full possible voltage is generated. It is also the point of the highest motor power. Beyond fweak torque will decrease to the square of frequency and thus power will decrease linear with frequency.

A starting point for fweak is the motors nameplate:

[[File:Fweak.png|210x210px]]

With our illustration motor fweak=(355 V/230 V) * 50 Hz = 77 Hz. fweak can be configured lower than that resulting in more torque at the low end.

'''fslipmin'''/'''fslipmax''' is the slip frequency at which the motor is run at minimum/maximum throttle. fslipmin is set to the motors optimal slip frequency which can be deduced from the nameplate. fslipmin=f-p*n/60. With our illustration motor fslipmin=50-2*1450/60=1.66Hz. fslipmax can be set as high as breakdown torque which is not found on the nameplate. So its best found experimental starting with 2*fslipmin. If set too high the motor will start to rock violently on startup, possibly tripping the over current limit.

'''polepairs''' is set to p, 2 in our example.

'''fmin''' should be set just below fslipmin.

'''fmax''' is used to limit the speed of the motor. The default 200Hz would result in a maximum speed of about 6000rpm.

'''ampmin''' Is the minimum relative amplitude fed to the motor. At very low amplitudes the motor does not generate any noticable torque and throttle travel is wasted that does nothing. Find out a good value by experimenting.

== Inverter Parameters ==
'''pwmfrq''' Sets the frequency at which the IGBTs are switched on and off. The faster the switching the higher the losses in the inverter and the lower the losses in the motor. The maximum frequency is also limited by the driver boards as explained here.

'''pwmpol''' Sets the polarity of the PWM signals, active high or active low. Do not touch this parameter if you don't know what you're doing. When configured inversely it will blow up your power stage immediatly if connected to a potent power source like batteries.

'''deadtime''' The time between switching off one IGBT and switching on the other. 28=800ns, 63=1.5µs. More values can be found in the STM32 data sheet. Make sure to test the deadtime at low power levels. Setting the deadtime too low while operating of a potent power source can blow up your power stage!

== Parameter Reference ==
The following parameters currently exist to customize the controller software. Type
set param <value>
to change it. Type
get param
to get the current value.

Parameters are internally stored with 5 binary fraction digits. That means there are 32 possible values after the decimal point. So when you set a value of 0.35 you might end up with 0.33.

{| class="wikitable"
|'''Name'''
|'''Unit'''
|'''Min'''
|'''Max'''
|'''Default'''
|'''Description'''
|-
| colspan="6" |'''Motor (FOC)'''
|-
|iqkp
|
|0
|20000
|64
|Current controller proportional gain. Low inductance/resistance motors need less, high inductance/resistance motors more
|-
|idkp
|
|0
|20000
|64
|Same as above but often a little higher then iqkp
|-
|curki
|
|0
|100000
|20000
|Current controller integral gain (id and iq)
|-
|exckp
|
|0
|20000
|3000
|Exciter controller gain (Renault Zoe variant only)
|-
|cogkp
|
| -1000
|1000
|0
|[https://openinverter.org/forum/viewtopic.php?t=5660 Anti-cogging modulator] gain. This generates a trapezoidal wave form to counter the cogging current of IPM motors.
|-
|cogph
|
|0
|65535
|0
|Anti-cogging modulator phase angle between cogging current and electrical rotor angle
|-
|cogmax
|
|0
|30000
|0
|Maximum amplitude of the anti-cogging current
|-
|vlimflt
|
| 0
|16
| 10
|Amplitude limiting field weakening filter
|-
|vlimmargin
|
|0
|10000
|2500
|Field weakening is brought in at modmax-vlimmargin. Increase if you get short bursts of unwanted regen at speed
|-
|fwcurmax
|A
| -1000
|0
| -100
|Maximum field weakening current. Must be set to critical current of motor (TODO: link forum). Set to 0 for disabling field weakening
|-
|excurmax
|A
|0
|10
|0
|Exciter current maximum (Renault Zoe variant only)
|-
|lqminusld
|mH
| 0
|1000
| 0
|Difference between d and q axis inductance. The higher, the more d-current is brought in for additional reluctance torque
|-
|fluxlinkage
|mWeber
|0
|1000
|90
|Magnetic link between rotor and stator, shapes MTPA curve
|-
|syncadv
|dig/Hz
| 0
|65535
|10
|Shifts "syncofs" downwards/upwards with frequency. Must be set so that ud remains at 0 when coasting below field weakening speed. '''SUPER DANGEROUS!''' Setting it wrong can cause unwanted acceleration.
|-
|''curkifrqgain''
|dig/Hz
|0
|1000
|50
|Current controllers integral gain frequency coefficient (deprecated, removed)
|-
|''ffwstart''
|Hz
|0
|1000
|200
|Starting point of field weakening controller. Below that frequency it is disabled, above it its gain is increased proportional to frequency and hits ''fwkp'' at ''fmax''. (deprecated, removed in latest release)
|-
| colspan="6" |'''Motor (sine)'''
|-
|boost
|dig
|0
|37813
|1700
|0 Hz Boost in digit. 1000 digit ~ 2.5%
|-
|fweakstrt
|Hz
|0
|1000
|400
|Fweak value at potnom < 35%. Can improve low speed stability and reduce oscillation when set higher than fweak. Set equal to fweak to disable.
|-
|fweak
|Hz
|0
|400
|67
|Frequency where V/Hz reaches its peak
|-
|fconst
|Hz
|0
|400
|400
|Maximum slip is increased from fslipmax to fslipconstmax as frequency approaches this value. Only effective when greater than fweak.
|-
|udcnom
|V
|0
|1000
|0
|Nominal voltage for fweak and boost. fweak and boost are scaled to the actual dc voltage. 0=don't scale
|-
|fslipmin
|Hz
|0
|100
|1
|Slip frequency at minimum throttle
|-
|fslipmax
|Hz
|0
|100
|3
|Slip frequency at maximum throttle
|-
|fslipconstmax
|Hz
|0
|10
|5
|Slip frequency at maximum throttle and fconst. Set equal to fslipmax to disable.
|-
|fmin
|Hz
|0
|400
|1
|Below this frequency no voltage is generated
|-
| colspan="6" |'''Motor (common)'''
|-
|polepairs
|
|1
|16
|2
|Pole pairs of motor (e.g. 4-pole motor: 2 pole pairs)
|-
|respolepairs
|
|1
|16
|1
|Pole pairs of resolver (normally same as polepairs of motor, but sometimes 1)
|-
|sincosofs
|dig
|0
|4096
|2048
|Mid point of sin/cos chip
|-
|encflt
|
|0
|16
|4
|Filter constant between pulse encoder and speed calculation. Makes up for slightly uneven pulse distribution
|-
|encmode
|
|0
|5
|0
|0=single channel encoder, 1=quadrature encoder,
2=quadrature /w index pulse,
3=SPI (deprecated),
4=Resolver,
5=sin/cos chip
|-
|fmax
|Hz
|0
|400
|200
|At this frequency rev limiting kicks in
|-
|numimp
|Imp/rev
|8
|8192
|60
|Pulse encoder pulses per turn
|-
|dirchrpm
|rpm
|0
|2000
|100
|Motor speed at which direction change is allowed
|-
|dirmode
|
|0
|1
|1
|0=button (momentary pulse selects forward/reverse), 1=switch (forward or reverse signal must be constantly high)
|-
|syncofs
|dig
|0
|65535
|0
|Phase shift of sine wave after receiving index pulse
|-
|snsm
|
|2
|3
|2
|Motor temperature sensor. 12=KTY83, 13=KTY84, 14=Leaf, 15=KTY81
|-
| colspan="6" |'''Inverter'''
|-
|pwmfrq
|
|0
|3
|2
|PWM frequency. 0=17.6kHz, 1=8.8kHz, 2=4.4kHz, 3=2.2kHz. Needs PWM restart
|-
|pwmpol
|
|0
|1
|0
|PWM polarity. 0=active high, 1=active low. DO NOT PLAY WITH THIS!
Needs PWM restart
|-
|deadtime
|dig
|0
|255
|28
|Deadtime between highside and lowside pulse. 28=800ns, 56=1.5µs. Not always linear, consult STM32 manual. Needs PWM restart
|-
|ocurlim
|A
| -65535
|65535
|100
|Hardware over current limit. RMS-current times sqrt(2) + some slack. Set negative if il1gain and il2gain are negative.
|-
|''minpulse''
|dig
|0
|4095
|1000
|Narrowest or widest pulse, all other mapped to full off or full on, respectively (Obsolete)
|-
|il1gain
|dig/A
|0
|4095
|4.7
|Digits per A of current sensor L1
|-
|il2gain
|dig/A
|0
|4095
|4.7
|Digits per A of current sensor L2
|-
|udcgain
|dig/V
|0
|4095
|6.15
|Digits per V of DC link
|-
|udcofs
|dig
|0
|4095
|0
|DC link 0V offset
|-
|udclim
|V
|0
|1000
|540
|High voltage at which the PWM is shut down
|-
|snshs
|
|0
|1
|0
|Heatsink temperature sensor. 0=JCurve, 1=Semikron, 2=MBB600, 3=KTY81, 4=PT1000, 5=NTCK45+2k2, 6=Leaf
|-
|pinswap
|
|0
|7
|0
|Swap pins (only "FOC" software). Multiple bits can be set. 1=Swap Current Inputs, 2=Swap Resolver sin/cos, 4=Swap PWM output 1/3
0001 = 1 Swap Currents ony

0010 = 2 Swap Resolver only

0011 = 3 Swap Resolver and Currents

0100 = 4 Swap PWM 1 and 3 only

0101 = 5 Swap PWM 1 and 3 and Currents

0110 = 6 Swap PWM 1 and 3 and Resolver

0111 = 7 Swap PWM 1 and 3 and Resolver and Currents

1xxx likewise with PWM 2 and 3
|-
|modmax
|dig
|37000
|45000
|37836
|Values over 37836 over-modulate the PWM sine wave. This can achieve a slightly higher AC voltage at the expense of greater motor losses. (only "FOC" software)
|-
| colspan="6" |'''Derating'''
|-
|bmslimhigh
|%
|0
|100
|50
|Positive throttle limit on BMS under voltage
|-
|bmslimlow
|%
| -100
|0
| -1
|Regen limit on BMS over voltage
|-
|udcmin
|V
|0
|1000
|450
|Minimum battery voltage
|-
|udcmax
|V
|0
|1000
|520
|Maximum battery voltage
|-
|iacmax
|A
|0
|5000
|5000
|Maximum peak AC current
|-
|idcmax
|A
|0
|5000
|5000
|Maximum DC input current
|-
|idcmin
|A
| -5000
|0
| -5000
|Maximum DC output current (regen)
|-
|idckp
|dig
|0.1
|20
|2
|Proportional rate of DC current derating
|-
|idcflt
|dig
|0
|11
|9
|Filter co-efficient applied to idc prior to derating. Increasing this makes the DC current derating smoother.
|-
|tmphsmax
|°C
|50
|150
|85
|Maximum permitted temperature of the inverter heatsink. As the temperature gets within 10°C of this limit the throttle will be scaled back by 10% for every degree until it hits the limit.
|-
|tmpmmax
|°C
|70
|300
|300
|Maximum permitted temperature of the motor. As the temperature gets within 10°C of this limit the throttle will be scaled back by 10% for every degree until it hits the limit.
|-
|throtmax
|%
|0
|100
|100
|Throttle limit
|-
|throtmin
|%
| -100
|0
| -100
|Throttle regen limit
|-
|accelmax
|rpm/10ms
|1
|1000
|1000
|Maximum permitted acceleration increase (traction control)
|-
|accelflt
|dig
|1
|5
|3
|Filter between the motor speed and the acceleration rate limiter. Higher values will smooth the input but will make the acceleration rate limiter react more slowly.
|-
|ifltrise
|dig
|0
|32
|10
|Controls how quickly slip and amplitude recover. The greater the value, the slower
|-
|ifltfall
|dig
|0
|32
|3
|Controls how quickly slip and amplitude are reduced on over current. The greater the value, the slower
|-
| colspan="6" |'''Charger'''
|-
|chargemode
|
|0
|4
|0
|0=Off, 3=Boost, 4=Buck
|-
|chargecur
|
|0
|50
|0
|Charge current setpoint. Boost mode: charger INPUT current. Buck mode: charger output current
|-
|chargekp
|
|0
|100
|80
|Charge controller proportional gain. Lower if you have oscillation, raise to get best power factor.
|-
|chargeki
|
|0
|100
|10
|Charge controller integral gain.
|-
|chargeflt
|
|0
|10
|8
|Charge current filtering. Raise if you have oscillations
|-
|chargepwmin
|%
|0
|99
|0
|Lowest charge mode duty cycle. This is needed for synchronous converters like in the Prius Gen2 where the lower IGBT is also active in buck mode and actually boosts the battery voltage into the bus capacitor when duty cycle is low.
|-
|chargepwmax
|%
|0
|99
|90
|Charge mode duty cycle limit. Especially in boost mode this makes sure you don't overvolt you IGBTs if there is no battery connected.
|-
| colspan="6" |'''Throttle'''
|-
|potmin
|dig
|0
|4095
|0
|Value of "pot" when pot isn't pressed at all
|-
|potmax
|dig
|0
|4095
|4095
|Value of "pot" when pot is pushed all the way in
|-
|pot2min
|dig
|0
|4095
|4095
|Value of "pot2" when regen pot is in 0 position
|-
|pot2max
|dig
|0
|4095
|4095
|Value of "pot2" when regen pot is in full on position
|-
|potmode
|
|0
|6
|0
|0=Pot 1 is throttle and pot 2 is regen strength preset
1=Pot 2 is proportional to pot 1 (redundancy)

2=Throttle/regen controlled via CAN (like 0)

3=Throttle via CAN with redundancy (like 1)

4=Bidirectional throttle sets torque and direction (e.g. for boats)

6=Bidirectional throttle controlled via CAN (like 4)
|-
|potlinearity
|%
|0
|100
|100
|Blend between a fully linear pedal (100%) and fully quadratic (0%). The throttle output is defined as potnom²*(1-potlinearity) + potnom * potlinearity. Regen is always linear.
|-
|throtramp
|%/10ms
|0
|100
|100
|Max positive throttle slew rate
|-
|throtramprpm
|rpm
|0
|20000
|20000
|No throttle ramping above this speed
|-
|ampmin
|%
|0
|100
|10
|Minimum relative sine amplitude (only "sine" software)
|-
|slipstart
|%
|10
|100
|50
|% positive throttle travel at which slip is increased (only "sine" software)
|-
|sinecurve
|
|0
|1
|0
|0=VoltageSlip - The first half of the throttle increases voltage but keeps slip at fslipin. Then the second half of the throttle increases slip up to fslipmax.

1=Simultaneous - Increases slip and voltage at the same time across the whole range of the throttle. Can provide smoother throttle response.
(only "sine" software)
|-
|throtfilter
|dig
|0
|10
|4
|How heavily the throttle is filtered. Lowering will increase throttle response at the expense of stability.(only "sine" software)
|-
|throtcur
|A/%
| -10
|10
|1
|Motor current per % of throttle travel (only "FOC" software)
|-
| colspan="6" |'''Regen'''
|-
|brknompedal / brakeregen
|%
| -100
|0
| -50
|Foot on brake pedal regen torque
|-
|regenramp
|%/10ms
|0.1
|100
|100
|Ramp speed when entering regen. E.g. when you set brkmax to -30% and regenramp to 1, it will take 300ms to arrive at brake force of -60%
|-
|brknom / regentravel
|%
|0
|100
|30
|Range of throttle pedal travel allocated to regen
|-
|brkmax / offthrotregen
|%
| -100
| 0
| -30
|Foot-off throttle regen torque
|-
|brkcruise / cruiseregen
|%
| -100
|0
| -30
|Maximum regen of cruise control
|-
|brkrampstr / regenrampstr
|Hz
|0
|400
|10
|Below this frequency the regen torque is reduced linearly with the frequency
|-
|maxregentravelhz
|Hz
|0
|1000
|0
|Frequency at which full regentravel is used. Below this frequency regentravel is linearly scaled down with frequency. Allows deadzone-free throttle reaction at standstill and low speed
|-
|brkout / brklightout
|%
| -100
| -1
| -50
|Activate brake light output at this amount of braking force
|-
| colspan="6" |'''Automation'''
|-
|idlespeed
|rpm
| -100
|1000
| -100
|Motor idle speed. Set to -100 to disable idle function. When idle speed controller is enabled, brake pedal must be pressed on start.
|-
|idlethrotlim
|%
|0
|100
|50
|Throttle limit of idle speed controller
|-
|idlemode
|
|0
|1
|0
|Motor idle speed mode. 0=always run idle speed controller, 1=only run it when brake pedal is released, 2=like 1 but only when cruise switch is on, 3=off, 4=Hill Hold
|-
|holdkp
|
| -100
|0
| -0.25
|How hard the throttle should be applied to counteract rollback in hill hold. Higher values reduce rollback at the risk of introducing oscillation due to sensor noise.
|-
|speedkp
|Hz
|0
|100
|1
|Speed controller gain (Cruise and idle speed). Decrease if speed oscillates. Increase for faster load regulation
|-
|speedflt
|dig
|0
|16
|1
|Filter before cruise controller
|-
|cruisemode
|
|0
|1
|0
|0=button (set when button pressed, reset with brake pedal), 1=switch (set when switched on, reset when switched off or brake pedal)
|-
|cruisethrotlim
|%
|0
|100
|50
|Amount of throttle cruise control is allowed to command
|-
| colspan="6" |'''Contactor Control'''
|-
|udcsw
|V
|0
|1000
|330
|Voltage at which the DC contactor is allowed to close
|-
|udcswbuck
|V
|0
|1000
|540
|Voltage at which the DC contactor is allowed to close in buck charge mode
|-
|tripmode
|
|0
|2
|0
|What to do with relays at a shutdown event. 0=All off, 1=Keep DC switch closed, 2=close precharge relay
|-
|bootprec
|
|0
|1
|0
|Engage precharge relay in boot loader. Introduced for enabling Prius Gen3 DC/DC converter when precharge relay is released. Use together with tripmode=2
|-
|outmode
|
|0
|2
|0
|0=DC switch output, 1=Motor temp controls the fan output, 2=Heatsink temp controls fan output
|-
|fanthresh
|°C
|20
|300
|50
|Temperature at which the fan output is turned on when outmode is 1 or 2
|-
| colspan="6" |'''Auxillary PWM'''
|-
|pwmfunc
|
|0
|2
|0
|Quantity that controls the PWM output. 0=tmpm, 1=tmphs, 2=speed
|-
|pwmgain
|dig/C
|0
|65535
|100
|Gain of PWM output
|-
|pwmofs
|dig
| -65535
|65535
|0
|Offset of PWM output, 4096=full on
|-
| colspan="6" |'''Communication'''
|-
|canspeed
|
|0
|3
|0
|Baud rate of CAN interface 0=250k, 1=500k, 2=800k, 3=1M
|-
|canperiod
|
|0
|1
|0
|0=send configured CAN messages every 100ms, 1=every 10ms
|-
|nodeid
|
|1
|63
|1
|Node ID for CAN SDO messages and for selective enabling of UART when sharing one ESP8266 module between multiple processors.
|-
|controlid
|
|1
|2047
|63
|The CAN ID used for controlling the [[CAN communication#Inverter_control_via_CAN_-_new!|controlling the inverter via CAN]]
|-
|controlcheck
|
|0
|1
|1
|0=Check the counter field in canio CAN frames '''for legacy VCUs only''', 1=Validate the 8-bit truncated STM32 CRC in the canio frame
|-
| colspan="6" |'''Testing'''
|-
|fslipspnt
|Hz
| -100
|100
|0
|Slip setpoint in mode 2. Written by software in mode 1
|-
|ampnom
|%
|0
|100
|0
|Nominal amplitude in mode 2. Written by software in mode 1
|}

== Spot values ==
The following values are available for diagnostic purposes. Type
get
to get the current value. To read more then one you can provide a list like
get il1,il2,udc
{| class="wikitable"
|'''Name'''
|'''Unit'''
|'''Description'''
|-
|version
|
|Firmware version
|-
|hwver
|
|Hardware version
|-
|opmode
|
|Operating mode. 0=Off, 1=Run, 2=Manual_run, 3=Boost, 4=Buck, 5=Sine, 6=2 Phase sine
|-
|lasterr
|
|Last error message
|-
|udc
|V
|DC link voltage
|-
|uac
|V
|Calculated AC voltage (only "sine" software)
|-
|idc
|A
|Calculated DC current
|-
|il1
|A
|AC current L1
|-
|il2
|A
|AC current L2
|-
|il1rms
|A
|RMS current L1 (only "sine" software)
|-
|il2rms
|A
|RMS current L2 (only "sine" software)
|-
|ilmax
|A
|Calculated max of il1, il2, il3 (only "sine" software)
|-
|boostcalc
|A
|DC link adjusted boost setting (only "sine" software)
|-
|fweakcalc
|A
|DC link adjusted fweak setting (only "sine" software)
|-
|id
|A
|Current in the direct(d) axis (only "FOC" software)
|-
|iq
|A
|Current in the quadrature(q) axis (only "FOC" software)
|-
|ifw
|A
|Field weakening current (only "FOC" software)
|-
|ud
|dig
|Computed voltage in the direct(d) axis (only "FOC" software)
|-
|uq
|dig
|Computed voltage in the quadrature(q) axis (only "FOC" software)
|-
|uexc
|dig
|Computed exciter voltage (only "FOC" software for the Renault Zoe variant)
|-
|anticog
|dig
|Amplitude of the anti-cogging modulation waveform (only "FOC" software)
|-
|fstat
|Hz
|Stator frequency
|-
|speed
|rpm
|Motor speed
|-
|cruisespeed
|rpm
|Motor RPM set point for cruise control if cruisemode=CAN
|-
|turns
|
|Number of turns the motor completed since power up
|-
|amp
|dig
|Sine amplitude, 37813=max
|-
|angle
|°
|Motor rotor angle, 0-360°. When using the SINE software, the slip is added to the rotor position.
This is not the physical angle, but a "virtual" angle. E.g. if your motor has four pole pairs (motor and resolver), then per one physical revolution the "angle" will change four times between 0 and 360°. Discussed here: https://openinverter.org/forum/viewtopic.php?p=71253#p71253
|-
|pot
|dig
|Pot value, 4095=max
|-
|pot2
|dig
|Regen Pot value, 4095=max
|-
|regenpreset
|%
|Regen preset value which can come from pot2 in potmode=0 or received via CAN
|-
|potnom
|%
|Scaled pot value, 0 accel.
potnom also includes the deratings. So say you have programmed udcmin=300V and you are tuning without HV, so udc=0, potnom will never be positive because it thinks the battery voltage is low. Discussed here: https://openinverter.org/forum/viewtopic.php?p=62930#p62930

range:

<nowiki>*</nowiki> negative means regeneration (e.g. -30%, according to [[Schematics and Instructions|Schematics and Instructions - openinverter.org wiki]])

<nowiki>*</nowiki> zero means "zero torque request"

<nowiki>*</nowiki> 100% means full acceleraton.
|-
|dir / seldir
|
|Selected rotation direction. -1=REV, 0=Neutral, 1=FWD
|-
|rotordir
|
|Actual rotor direction
|-
|tmphs
|°C
|Heatsink temperature
|-
|tmpm
|°C
|Motor temperature
|-
|uaux
|V
|Auxiliary voltage (i.e. 12V system). Measured on pin 11 (mprot)
|-
|pwmio
|
|raw state of PWM outputs at power up
|-
|canio
|
|Digital IO bits received via [[CAN communication#Controlling Digital IO via CAN|CAN]]
|-
|din_cruise
|
|Cruise Control. This pin activates the cruise control with the current speed. Pressing again updates the speed set point.
|-
|din_start
|
|State of digital input "start". This pin starts inverter operation
|-
|din_brake
|
|State of digital input "brake". This pin sets maximum regen torque (brknompedal). Cruise control is disabled.
|-
|din_mprot
|
|State of digital input "motor protection switch". Shuts down the inverter when =0
|-
|din_forward
|
|Direction forward
|-
|din_reverse
|
|Direction backward
|-
|din_emcystop
|
|State of digital input "emergency stop". Shuts down the inverter when =0
|-
|din_ocur
|
|Over current detected
|-
|din_desat
|
|Gate driver desaturation event
|-
|din_bms
|
|BMS over voltage/under voltage
|-
|uptime
|
|The number of 10ms ticks since power was applied to the inverter
|-
|cpuload
|%
|CPU load for everything except communication
|}

== Tuning Guide ==
First you want to find a flat surface - a parking lot etc. so you can drive and stop without checking traffic. Change only one parameter at a time and save settings that work!

1. set fslipmin so that you feel car taking off smoothly and try to change it by +/-0,1Hz and check differences in starting. Save when satisfied.

2. lower boost value in 100 point until motor jitters at start. Then return it to last good value.

3. try lowering ampmin in 0,1 increments and observe throttle travel. When throttle is not just smooth but becomes sluggish return some previous increments until throttle reaction is acceptable.

4. change fweak value in +/-10Hz increments from starting point and observe torque in starting. This value is very dependent on battery voltage and is very subjective.

Now you find a hill or ramp and set car on it. You want to hold car in position on slope just using throttle pedal. If there parameters are not good motor will jump or will feel sluggish

1. add boost if motor is oscillating if it is smooth reduce it in 100 point increments until you get oscillation. Then return to last good value

2. reduce/increase ampmin in 0,25 increments untill you get oscilation in motor and return last good value

Now set the car into a hill to set fslipmax. Warning full throttle will be used. Be sure there is no other traffic!

Set fslipmax to chosen value (guess it at 2xfslipmin if you have no other way) and try to take off with full throttle.

If car feels sluggish with full throttle you have to add more slip.

If motor starts to jitter there is too much slip. Try to reduce it in 0.1Hz increments.

When you feel satisfied with settings save them and go on setting regen and braking effect.

[[Category:OpenInverter]] [[Category:Inverter]]

Parameters

2025-12-13T19:06:06Z

Johu: description of cruisethrotlim

The inverter can be adapted to many kinds of motors, battery packs and driver preferences by changing parameters. A video on parameters is here: https://youtu.be/GQNQbBUsqf0

A Parameter Database with common usage scenarios is here: https://openinverter.org/parameters/

A synchronous motor tuning guide is here: [[Using FOC Software]]

== Motor Parameters ==
The parameters to adjust the inverter to the motor are boost, fweak, fslipmin, fslipmax, polepairs, fmin, fmax and numimp.

They can be deduced from the motors nameplate or by trying which feels best. For illustration we will assume a bus voltage of 500V and a 4-pole (p=2) motor with a nominal speed of n=1450rpm@f=50Hz and 230V. With 500V DC an AC voltage of 500/1.41=355V can be generated.

'''boost''' is the digital amplitude of the sine wave at motor startup. It is needed to overcome the motors ohmic resistance. Digital amplitude is an internal quantity. 0 means no voltage is generated at all, 37813 means the full possible voltage is generated.

Example: boost=1700

At full throttle an effective voltage of 1700/37813*355=16V is generated. The best way to find a feasible value is to optimize it in the finished car. Start with the default value and increase until you get a good startup.

'''fweak''' is the frequency at which the full possible voltage is generated. It is also the point of the highest motor power. Beyond fweak torque will decrease to the square of frequency and thus power will decrease linear with frequency.

A starting point for fweak is the motors nameplate:

[[File:Fweak.png|210x210px]]

With our illustration motor fweak=(355 V/230 V) * 50 Hz = 77 Hz. fweak can be configured lower than that resulting in more torque at the low end.

'''fslipmin'''/'''fslipmax''' is the slip frequency at which the motor is run at minimum/maximum throttle. fslipmin is set to the motors optimal slip frequency which can be deduced from the nameplate. fslipmin=f-p*n/60. With our illustration motor fslipmin=50-2*1450/60=1.66Hz. fslipmax can be set as high as breakdown torque which is not found on the nameplate. So its best found experimental starting with 2*fslipmin. If set too high the motor will start to rock violently on startup, possibly tripping the over current limit.

'''polepairs''' is set to p, 2 in our example.

'''fmin''' should be set just below fslipmin.

'''fmax''' is used to limit the speed of the motor. The default 200Hz would result in a maximum speed of about 6000rpm.

'''ampmin''' Is the minimum relative amplitude fed to the motor. At very low amplitudes the motor does not generate any noticable torque and throttle travel is wasted that does nothing. Find out a good value by experimenting.

== Inverter Parameters ==
'''pwmfrq''' Sets the frequency at which the IGBTs are switched on and off. The faster the switching the higher the losses in the inverter and the lower the losses in the motor. The maximum frequency is also limited by the driver boards as explained here.

'''pwmpol''' Sets the polarity of the PWM signals, active high or active low. Do not touch this parameter if you don't know what you're doing. When configured inversely it will blow up your power stage immediatly if connected to a potent power source like batteries.

'''deadtime''' The time between switching off one IGBT and switching on the other. 28=800ns, 63=1.5µs. More values can be found in the STM32 data sheet. Make sure to test the deadtime at low power levels. Setting the deadtime too low while operating of a potent power source can blow up your power stage!

== Parameter Reference ==
The following parameters currently exist to customize the controller software. Type
set param <value>
to change it. Type
get param
to get the current value.

Parameters are internally stored with 5 binary fraction digits. That means there are 32 possible values after the decimal point. So when you set a value of 0.35 you might end up with 0.33.

{| class="wikitable"
|'''Name'''
|'''Unit'''
|'''Min'''
|'''Max'''
|'''Default'''
|'''Description'''
|-
| colspan="6" |'''Motor (FOC)'''
|-
|iqkp
|
|0
|20000
|64
|Current controller proportional gain. Low inductance/resistance motors need less, high inductance/resistance motors more
|-
|idkp
|
|0
|20000
|64
|Same as above but often a little higher then iqkp
|-
|curki
|
|0
|100000
|20000
|Current controller integral gain (id and iq)
|-
|exckp
|
|0
|20000
|3000
|Exciter controller gain (Renault Zoe variant only)
|-
|cogkp
|
| -1000
|1000
|0
|[https://openinverter.org/forum/viewtopic.php?t=5660 Anti-cogging modulator] gain. This generates a trapezoidal wave form to counter the cogging current of IPM motors.
|-
|cogph
|
|0
|65535
|0
|Anti-cogging modulator phase angle between cogging current and electrical rotor angle
|-
|cogmax
|
|0
|30000
|0
|Maximum amplitude of the anti-cogging current
|-
|vlimflt
|
| 0
|16
| 10
|Amplitude limiting field weakening filter
|-
|vlimmargin
|
|0
|10000
|2500
|Field weakening is brought in at modmax-vlimmargin. Increase if you get short bursts of unwanted regen at speed
|-
|fwcurmax
|A
| -1000
|0
| -100
|Maximum field weakening current. Must be set to critical current of motor (TODO: link forum). Set to 0 for disabling field weakening
|-
|excurmax
|A
|0
|10
|0
|Exciter current maximum (Renault Zoe variant only)
|-
|lqminusld
|mH
| 0
|1000
| 0
|Difference between d and q axis inductance. The higher, the more d-current is brought in for additional reluctance torque
|-
|fluxlinkage
|mWeber
|0
|1000
|90
|Magnetic link between rotor and stator, shapes MTPA curve
|-
|syncadv
|dig/Hz
| 0
|65535
|10
|Shifts "syncofs" downwards/upwards with frequency. Must be set so that ud remains at 0 when coasting below field weakening speed. '''SUPER DANGEROUS!''' Setting it wrong can cause unwanted acceleration.
|-
|''curkifrqgain''
|dig/Hz
|0
|1000
|50
|Current controllers integral gain frequency coefficient (deprecated, removed)
|-
|''ffwstart''
|Hz
|0
|1000
|200
|Starting point of field weakening controller. Below that frequency it is disabled, above it its gain is increased proportional to frequency and hits ''fwkp'' at ''fmax''. (deprecated, removed in latest release)
|-
| colspan="6" |'''Motor (sine)'''
|-
|boost
|dig
|0
|37813
|1700
|0 Hz Boost in digit. 1000 digit ~ 2.5%
|-
|fweakstrt
|Hz
|0
|1000
|400
|Fweak value at potnom < 35%. Can improve low speed stability and reduce oscillation when set higher than fweak. Set equal to fweak to disable.
|-
|fweak
|Hz
|0
|400
|67
|Frequency where V/Hz reaches its peak
|-
|fconst
|Hz
|0
|400
|400
|Maximum slip is increased from fslipmax to fslipconstmax as frequency approaches this value. Only effective when greater than fweak.
|-
|udcnom
|V
|0
|1000
|0
|Nominal voltage for fweak and boost. fweak and boost are scaled to the actual dc voltage. 0=don't scale
|-
|fslipmin
|Hz
|0
|100
|1
|Slip frequency at minimum throttle
|-
|fslipmax
|Hz
|0
|100
|3
|Slip frequency at maximum throttle
|-
|fslipconstmax
|Hz
|0
|10
|5
|Slip frequency at maximum throttle and fconst. Set equal to fslipmax to disable.
|-
|fmin
|Hz
|0
|400
|1
|Below this frequency no voltage is generated
|-
| colspan="6" |'''Motor (common)'''
|-
|polepairs
|
|1
|16
|2
|Pole pairs of motor (e.g. 4-pole motor: 2 pole pairs)
|-
|respolepairs
|
|1
|16
|1
|Pole pairs of resolver (normally same as polepairs of motor, but sometimes 1)
|-
|sincosofs
|dig
|0
|4096
|2048
|Mid point of sin/cos chip
|-
|encflt
|
|0
|16
|4
|Filter constant between pulse encoder and speed calculation. Makes up for slightly uneven pulse distribution
|-
|encmode
|
|0
|5
|0
|0=single channel encoder, 1=quadrature encoder,
2=quadrature /w index pulse,
3=SPI (deprecated),
4=Resolver,
5=sin/cos chip
|-
|fmax
|Hz
|0
|400
|200
|At this frequency rev limiting kicks in
|-
|numimp
|Imp/rev
|8
|8192
|60
|Pulse encoder pulses per turn
|-
|dirchrpm
|rpm
|0
|2000
|100
|Motor speed at which direction change is allowed
|-
|dirmode
|
|0
|1
|1
|0=button (momentary pulse selects forward/reverse), 1=switch (forward or reverse signal must be constantly high)
|-
|syncofs
|dig
|0
|65535
|0
|Phase shift of sine wave after receiving index pulse
|-
|snsm
|
|2
|3
|2
|Motor temperature sensor. 12=KTY83, 13=KTY84, 14=Leaf, 15=KTY81
|-
| colspan="6" |'''Inverter'''
|-
|pwmfrq
|
|0
|3
|2
|PWM frequency. 0=17.6kHz, 1=8.8kHz, 2=4.4kHz, 3=2.2kHz. Needs PWM restart
|-
|pwmpol
|
|0
|1
|0
|PWM polarity. 0=active high, 1=active low. DO NOT PLAY WITH THIS!
Needs PWM restart
|-
|deadtime
|dig
|0
|255
|28
|Deadtime between highside and lowside pulse. 28=800ns, 56=1.5µs. Not always linear, consult STM32 manual. Needs PWM restart
|-
|ocurlim
|A
| -65535
|65535
|100
|Hardware over current limit. RMS-current times sqrt(2) + some slack. Set negative if il1gain and il2gain are negative.
|-
|''minpulse''
|dig
|0
|4095
|1000
|Narrowest or widest pulse, all other mapped to full off or full on, respectively (Obsolete)
|-
|il1gain
|dig/A
|0
|4095
|4.7
|Digits per A of current sensor L1
|-
|il2gain
|dig/A
|0
|4095
|4.7
|Digits per A of current sensor L2
|-
|udcgain
|dig/V
|0
|4095
|6.15
|Digits per V of DC link
|-
|udcofs
|dig
|0
|4095
|0
|DC link 0V offset
|-
|udclim
|V
|0
|1000
|540
|High voltage at which the PWM is shut down
|-
|snshs
|
|0
|1
|0
|Heatsink temperature sensor. 0=JCurve, 1=Semikron, 2=MBB600, 3=KTY81, 4=PT1000, 5=NTCK45+2k2, 6=Leaf
|-
|pinswap
|
|0
|7
|0
|Swap pins (only "FOC" software). Multiple bits can be set. 1=Swap Current Inputs, 2=Swap Resolver sin/cos, 4=Swap PWM output 1/3
0001 = 1 Swap Currents ony

0010 = 2 Swap Resolver only

0011 = 3 Swap Resolver and Currents

0100 = 4 Swap PWM 1 and 3 only

0101 = 5 Swap PWM 1 and 3 and Currents

0110 = 6 Swap PWM 1 and 3 and Resolver

0111 = 7 Swap PWM 1 and 3 and Resolver and Currents

1xxx likewise with PWM 2 and 3
|-
|modmax
|dig
|37000
|45000
|37836
|Values over 37836 over-modulate the PWM sine wave. This can achieve a slightly higher AC voltage at the expense of greater motor losses. (only "FOC" software)
|-
| colspan="6" |'''Derating'''
|-
|bmslimhigh
|%
|0
|100
|50
|Positive throttle limit on BMS under voltage
|-
|bmslimlow
|%
| -100
|0
| -1
|Regen limit on BMS over voltage
|-
|udcmin
|V
|0
|1000
|450
|Minimum battery voltage
|-
|udcmax
|V
|0
|1000
|520
|Maximum battery voltage
|-
|iacmax
|A
|0
|5000
|5000
|Maximum peak AC current
|-
|idcmax
|A
|0
|5000
|5000
|Maximum DC input current
|-
|idcmin
|A
| -5000
|0
| -5000
|Maximum DC output current (regen)
|-
|idckp
|dig
|0.1
|20
|2
|Proportional rate of DC current derating
|-
|idcflt
|dig
|0
|11
|9
|Filter co-efficient applied to idc prior to derating. Increasing this makes the DC current derating smoother.
|-
|tmphsmax
|°C
|50
|150
|85
|Maximum permitted temperature of the inverter heatsink. As the temperature gets within 10°C of this limit the throttle will be scaled back by 10% for every degree until it hits the limit.
|-
|tmpmmax
|°C
|70
|300
|300
|Maximum permitted temperature of the motor. As the temperature gets within 10°C of this limit the throttle will be scaled back by 10% for every degree until it hits the limit.
|-
|throtmax
|%
|0
|100
|100
|Throttle limit
|-
|throtmin
|%
| -100
|0
| -100
|Throttle regen limit
|-
|accelmax
|rpm/10ms
|1
|1000
|1000
|Maximum permitted acceleration increase (traction control)
|-
|accelflt
|dig
|1
|5
|3
|Filter between the motor speed and the acceleration rate limiter. Higher values will smooth the input but will make the acceleration rate limiter react more slowly.
|-
|ifltrise
|dig
|0
|32
|10
|Controls how quickly slip and amplitude recover. The greater the value, the slower
|-
|ifltfall
|dig
|0
|32
|3
|Controls how quickly slip and amplitude are reduced on over current. The greater the value, the slower
|-
| colspan="6" |'''Charger'''
|-
|chargemode
|
|0
|4
|0
|0=Off, 3=Boost, 4=Buck
|-
|chargecur
|
|0
|50
|0
|Charge current setpoint. Boost mode: charger INPUT current. Buck mode: charger output current
|-
|chargekp
|
|0
|100
|80
|Charge controller proportional gain. Lower if you have oscillation, raise to get best power factor.
|-
|chargeki
|
|0
|100
|10
|Charge controller integral gain.
|-
|chargeflt
|
|0
|10
|8
|Charge current filtering. Raise if you have oscillations
|-
|chargepwmin
|%
|0
|99
|0
|Lowest charge mode duty cycle. This is needed for synchronous converters like in the Prius Gen2 where the lower IGBT is also active in buck mode and actually boosts the battery voltage into the bus capacitor when duty cycle is low.
|-
|chargepwmax
|%
|0
|99
|90
|Charge mode duty cycle limit. Especially in boost mode this makes sure you don't overvolt you IGBTs if there is no battery connected.
|-
| colspan="6" |'''Throttle'''
|-
|potmin
|dig
|0
|4095
|0
|Value of "pot" when pot isn't pressed at all
|-
|potmax
|dig
|0
|4095
|4095
|Value of "pot" when pot is pushed all the way in
|-
|pot2min
|dig
|0
|4095
|4095
|Value of "pot2" when regen pot is in 0 position
|-
|pot2max
|dig
|0
|4095
|4095
|Value of "pot2" when regen pot is in full on position
|-
|potmode
|
|0
|6
|0
|0=Pot 1 is throttle and pot 2 is regen strength preset
1=Pot 2 is proportional to pot 1 (redundancy)

2=Throttle/regen controlled via CAN (like 0)

3=Throttle via CAN with redundancy (like 1)

4=Bidirectional throttle sets torque and direction (e.g. for boats)

6=Bidirectional throttle controlled via CAN (like 4)
|-
|potlinearity
|%
|0
|100
|100
|Blend between a fully linear pedal (100%) and fully quadratic (0%). The throttle output is defined as potnom²*(1-potlinearity) + potnom * potlinearity. Regen is always linear.
|-
|throtramp
|%/10ms
|0
|100
|100
|Max positive throttle slew rate
|-
|throtramprpm
|rpm
|0
|20000
|20000
|No throttle ramping above this speed
|-
|ampmin
|%
|0
|100
|10
|Minimum relative sine amplitude (only "sine" software)
|-
|slipstart
|%
|10
|100
|50
|% positive throttle travel at which slip is increased (only "sine" software)
|-
|sinecurve
|
|0
|1
|0
|0=VoltageSlip - The first half of the throttle increases voltage but keeps slip at fslipin. Then the second half of the throttle increases slip up to fslipmax.

1=Simultaneous - Increases slip and voltage at the same time across the whole range of the throttle. Can provide smoother throttle response.
(only "sine" software)
|-
|throtfilter
|dig
|0
|10
|4
|How heavily the throttle is filtered. Lowering will increase throttle response at the expense of stability.(only "sine" software)
|-
|throtcur
|A/%
| -10
|10
|1
|Motor current per % of throttle travel (only "FOC" software)
|-
| colspan="6" |'''Regen'''
|-
|brknompedal / brakeregen
|%
| -100
|0
| -50
|Foot on brake pedal regen torque
|-
|regenramp
|%/10ms
|0.1
|100
|100
|Ramp speed when entering regen. E.g. when you set brkmax to -30% and regenramp to 1, it will take 300ms to arrive at brake force of -60%
|-
|brknom / regentravel
|%
|0
|100
|30
|Range of throttle pedal travel allocated to regen
|-
|brkmax / offthrotregen
|%
| -100
| 0
| -30
|Foot-off throttle regen torque
|-
|brkcruise / cruiseregen
|%
| -100
|0
| -30
|Maximum regen of cruise control
|-
|brkrampstr / regenrampstr
|Hz
|0
|400
|10
|Below this frequency the regen torque is reduced linearly with the frequency
|-
|maxregentravelhz
|Hz
|0
|1000
|0
|
|-
|brkout / brklightout
|%
| -100
| -1
| -50
|Activate brake light output at this amount of braking force
|-
| colspan="6" |'''Automation'''
|-
|idlespeed
|rpm
| -100
|1000
| -100
|Motor idle speed. Set to -100 to disable idle function. When idle speed controller is enabled, brake pedal must be pressed on start.
|-
|idlethrotlim
|%
|0
|100
|50
|Throttle limit of idle speed controller
|-
|idlemode
|
|0
|1
|0
|Motor idle speed mode. 0=always run idle speed controller, 1=only run it when brake pedal is released, 2=like 1 but only when cruise switch is on, 3=off, 4=Hill Hold
|-
|holdkp
|
| -100
|0
| -0.25
|How hard the throttle should be applied to counteract rollback in hill hold. Higher values reduce rollback at the risk of introducing oscillation due to sensor noise.
|-
|speedkp
|Hz
|0
|100
|1
|Speed controller gain (Cruise and idle speed). Decrease if speed oscillates. Increase for faster load regulation
|-
|speedflt
|dig
|0
|16
|1
|Filter before cruise controller
|-
|cruisemode
|
|0
|1
|0
|0=button (set when button pressed, reset with brake pedal), 1=switch (set when switched on, reset when switched off or brake pedal)
|-
|cruisethrotlim
|%
|0
|100
|50
|Amount of throttle cruise control is allowed to command
|-
| colspan="6" |'''Contactor Control'''
|-
|udcsw
|V
|0
|1000
|330
|Voltage at which the DC contactor is allowed to close
|-
|udcswbuck
|V
|0
|1000
|540
|Voltage at which the DC contactor is allowed to close in buck charge mode
|-
|tripmode
|
|0
|2
|0
|What to do with relays at a shutdown event. 0=All off, 1=Keep DC switch closed, 2=close precharge relay
|-
|bootprec
|
|0
|1
|0
|Engage precharge relay in boot loader. Introduced for enabling Prius Gen3 DC/DC converter when precharge relay is released. Use together with tripmode=2
|-
|outmode
|
|0
|2
|0
|0=DC switch output, 1=Motor temp controls the fan output, 2=Heatsink temp controls fan output
|-
|fanthresh
|°C
|20
|300
|50
|Temperature at which the fan output is turned on when outmode is 1 or 2
|-
| colspan="6" |'''Auxillary PWM'''
|-
|pwmfunc
|
|0
|2
|0
|Quantity that controls the PWM output. 0=tmpm, 1=tmphs, 2=speed
|-
|pwmgain
|dig/C
|0
|65535
|100
|Gain of PWM output
|-
|pwmofs
|dig
| -65535
|65535
|0
|Offset of PWM output, 4096=full on
|-
| colspan="6" |'''Communication'''
|-
|canspeed
|
|0
|3
|0
|Baud rate of CAN interface 0=250k, 1=500k, 2=800k, 3=1M
|-
|canperiod
|
|0
|1
|0
|0=send configured CAN messages every 100ms, 1=every 10ms
|-
|nodeid
|
|1
|63
|1
|Node ID for CAN SDO messages and for selective enabling of UART when sharing one ESP8266 module between multiple processors.
|-
|controlid
|
|1
|2047
|63
|The CAN ID used for controlling the [[CAN communication#Inverter_control_via_CAN_-_new!|controlling the inverter via CAN]]
|-
|controlcheck
|
|0
|1
|1
|0=Check the counter field in canio CAN frames '''for legacy VCUs only''', 1=Validate the 8-bit truncated STM32 CRC in the canio frame
|-
| colspan="6" |'''Testing'''
|-
|fslipspnt
|Hz
| -100
|100
|0
|Slip setpoint in mode 2. Written by software in mode 1
|-
|ampnom
|%
|0
|100
|0
|Nominal amplitude in mode 2. Written by software in mode 1
|}

== Spot values ==
The following values are available for diagnostic purposes. Type
get
to get the current value. To read more then one you can provide a list like
get il1,il2,udc
{| class="wikitable"
|'''Name'''
|'''Unit'''
|'''Description'''
|-
|version
|
|Firmware version
|-
|hwver
|
|Hardware version
|-
|opmode
|
|Operating mode. 0=Off, 1=Run, 2=Manual_run, 3=Boost, 4=Buck, 5=Sine, 6=2 Phase sine
|-
|lasterr
|
|Last error message
|-
|udc
|V
|DC link voltage
|-
|uac
|V
|Calculated AC voltage (only "sine" software)
|-
|idc
|A
|Calculated DC current
|-
|il1
|A
|AC current L1
|-
|il2
|A
|AC current L2
|-
|il1rms
|A
|RMS current L1 (only "sine" software)
|-
|il2rms
|A
|RMS current L2 (only "sine" software)
|-
|ilmax
|A
|Calculated max of il1, il2, il3 (only "sine" software)
|-
|boostcalc
|A
|DC link adjusted boost setting (only "sine" software)
|-
|fweakcalc
|A
|DC link adjusted fweak setting (only "sine" software)
|-
|id
|A
|Current in the direct(d) axis (only "FOC" software)
|-
|iq
|A
|Current in the quadrature(q) axis (only "FOC" software)
|-
|ifw
|A
|Field weakening current (only "FOC" software)
|-
|ud
|dig
|Computed voltage in the direct(d) axis (only "FOC" software)
|-
|uq
|dig
|Computed voltage in the quadrature(q) axis (only "FOC" software)
|-
|uexc
|dig
|Computed exciter voltage (only "FOC" software for the Renault Zoe variant)
|-
|anticog
|dig
|Amplitude of the anti-cogging modulation waveform (only "FOC" software)
|-
|fstat
|Hz
|Stator frequency
|-
|speed
|rpm
|Motor speed
|-
|cruisespeed
|rpm
|Motor RPM set point for cruise control if cruisemode=CAN
|-
|turns
|
|Number of turns the motor completed since power up
|-
|amp
|dig
|Sine amplitude, 37813=max
|-
|angle
|°
|Motor rotor angle, 0-360°. When using the SINE software, the slip is added to the rotor position.
This is not the physical angle, but a "virtual" angle. E.g. if your motor has four pole pairs (motor and resolver), then per one physical revolution the "angle" will change four times between 0 and 360°. Discussed here: https://openinverter.org/forum/viewtopic.php?p=71253#p71253
|-
|pot
|dig
|Pot value, 4095=max
|-
|pot2
|dig
|Regen Pot value, 4095=max
|-
|regenpreset
|%
|Regen preset value which can come from pot2 in potmode=0 or received via CAN
|-
|potnom
|%
|Scaled pot value, 0 accel.
potnom also includes the deratings. So say you have programmed udcmin=300V and you are tuning without HV, so udc=0, potnom will never be positive because it thinks the battery voltage is low. Discussed here: https://openinverter.org/forum/viewtopic.php?p=62930#p62930

range:

<nowiki>*</nowiki> negative means regeneration (e.g. -30%, according to [[Schematics and Instructions|Schematics and Instructions - openinverter.org wiki]])

<nowiki>*</nowiki> zero means "zero torque request"

<nowiki>*</nowiki> 100% means full acceleraton.
|-
|dir / seldir
|
|Selected rotation direction. -1=REV, 0=Neutral, 1=FWD
|-
|rotordir
|
|Actual rotor direction
|-
|tmphs
|°C
|Heatsink temperature
|-
|tmpm
|°C
|Motor temperature
|-
|uaux
|V
|Auxiliary voltage (i.e. 12V system). Measured on pin 11 (mprot)
|-
|pwmio
|
|raw state of PWM outputs at power up
|-
|canio
|
|Digital IO bits received via [[CAN communication#Controlling Digital IO via CAN|CAN]]
|-
|din_cruise
|
|Cruise Control. This pin activates the cruise control with the current speed. Pressing again updates the speed set point.
|-
|din_start
|
|State of digital input "start". This pin starts inverter operation
|-
|din_brake
|
|State of digital input "brake". This pin sets maximum regen torque (brknompedal). Cruise control is disabled.
|-
|din_mprot
|
|State of digital input "motor protection switch". Shuts down the inverter when =0
|-
|din_forward
|
|Direction forward
|-
|din_reverse
|
|Direction backward
|-
|din_emcystop
|
|State of digital input "emergency stop". Shuts down the inverter when =0
|-
|din_ocur
|
|Over current detected
|-
|din_desat
|
|Gate driver desaturation event
|-
|din_bms
|
|BMS over voltage/under voltage
|-
|uptime
|
|The number of 10ms ticks since power was applied to the inverter
|-
|cpuload
|%
|CPU load for everything except communication
|}

== Tuning Guide ==
First you want to find a flat surface - a parking lot etc. so you can drive and stop without checking traffic. Change only one parameter at a time and save settings that work!

1. set fslipmin so that you feel car taking off smoothly and try to change it by +/-0,1Hz and check differences in starting. Save when satisfied.

2. lower boost value in 100 point until motor jitters at start. Then return it to last good value.

3. try lowering ampmin in 0,1 increments and observe throttle travel. When throttle is not just smooth but becomes sluggish return some previous increments until throttle reaction is acceptable.

4. change fweak value in +/-10Hz increments from starting point and observe torque in starting. This value is very dependent on battery voltage and is very subjective.

Now you find a hill or ramp and set car on it. You want to hold car in position on slope just using throttle pedal. If there parameters are not good motor will jump or will feel sluggish

1. add boost if motor is oscillating if it is smooth reduce it in 100 point increments until you get oscillation. Then return to last good value

2. reduce/increase ampmin in 0,25 increments untill you get oscilation in motor and return last good value

Now set the car into a hill to set fslipmax. Warning full throttle will be used. Be sure there is no other traffic!

Set fslipmax to chosen value (guess it at 2xfslipmin if you have no other way) and try to take off with full throttle.

If car feels sluggish with full throttle you have to add more slip.

If motor starts to jitter there is too much slip. Try to reduce it in 0.1Hz increments.

When you feel satisfied with settings save them and go on setting regen and braking effect.

[[Category:OpenInverter]] [[Category:Inverter]]

Main Page

2025-12-02T10:12:32Z

Johu:

[[Index|Wiki Index]] - quick reference for all info on the wiki.

If you have trouble logging into the forum, log into [https://openinverter.org:8444/forum this address], then go back to the [https://openinverter.org/forum normal forum].

Did you know you can convert your existing fossil powered vehicle to use electricity instead? And that you can even produce that electricity yourself?

Open Inverter is a [[Main Page#Who we are|community of people]] and projects focused on open source solutions for EV conversions. Founded in 2008 by Johannes Huebner as an open source inverter control firmware, the project has since expanded to include the reuse of components from production EVs and hybrids, including inverters, motors, batteries, on-board chargers, and DC-DC converters, as well as the open source implementation of other necessary systems for EV conversions such as DC Fast Charging controllers.

<imagemap>
File:Electric-car.jpg|none|frame|Click on the captions to learn more about the respective system! Image source: https://www.newkidscar.com/

poly 248 166 542 166 542 217 248 217 248 166 [[#Reusing motors and inverters - aka drive trains]]
poly 1041 455 1336 455 1336 506 1041 506 1041 455 [[#Reusing Batteries]]
poly 147 344 428 344 428 391 147 391 147 344 [[#Onboard chargers and DC/DC converters]]
poly 844 624 1118 624 1118 673 844 673 844 624 [[#Onboard chargers and DC/DC converters]]
poly 935 539 1200 539 1200 586 935 586 935 539 [[#Rapid Charging]]
poly 134 435 394 435 394 483 134 483 134 435 [[#Auxiliary Parts]]
</imagemap>

This wiki is maintained by the wider community. '''Please update this wiki'''. For example if your question has been clarified on the [https://openinverter.org/forum forum] and the new information can not be found here, please add it! The credentials are the same as for the forum.

'''[[Main Page#Who we are|Developers]] time is best spent developing;''' '''Support is best found in the forums''' - Developers of various projects are often bombarded with private messages and emails. Managing these emails and questions is a extremely large undertaking. Please read, and take the time to understand the information available here and across the web if you don't understand a topic. Developers are not your personal support team, unless you want to [[Application Support|pay them directly]] for their time. To keep developers independent please consider donating - donation links can be found [[Main Page#Who we are|down below]].

==Reusing motors and inverters - aka drive trains==
[[File:Tesla_LDU.jpg|thumb]]
The drive train is one of the defining building blocks of your conversion as it defines how well your vehicle picks up speed. Over the years we have reverse engineered many popular drive trains from [[:Category:OEM|production cars]] such as Teslas. As a bonus using such complete drive trains facilitates getting the vehicle [[Legalities|road legal]] in many countries. By now you have a choice of low to medium power drive trains that only cost a few 100€ up to high performance ones at many 1000€.

We have established two methods of running these [[:Category:OEM|OEM]] systems: reverse-engineering their communication protocol and making the drive train "think" it is still in its original vehicle OR swapping out the control electronics for our own open source motor controller. The latter method gives your more control and power but also a steeper learning curve.

Nearly all drive trains are targeted at 400V battery voltage. Run at a lower voltage they will produce proportionally less power.
Here is what we have done so far and how we've done it. Some is still work in progress (WIP)
{| class="wikitable"
|+
!Manufacturer
!Drive Train
!Control Method
! Approximate Power Output
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X Large Drive Unit ("LDU")|Large Drive Unit]]
|[https://openinverter.org/shop/index.php?route=product/product&path=61&product_id=64 Board Swap]
|335-475 kW
|-
|
|[[Tesla Model S/X Small Drive Unit ("SDU")|Small Drive Unit]]
|[https://openinverter.org/shop/index.php?route=product/product&path=61&product_id=62 Board Swap]
|180 kW
|-
|
|[[Tesla Model 3 Rear Drive Unit|Model 3/Y Rear Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|239 kW
|-
|
|[[Tesla Model 3 Front Drive Unit|Model 3/Y Front Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|121 kW
|-
|[[Nissan]]
|[[Nissan Leaf Motors|Gen1]]
|[[ZombieVerter VCU|CAN spoofing with ZombieVerter VCU]]
|80 kW
|-
|
| [[Nissan Leaf Gen2 Board|Gen2]]
|[[ZombieVerter VCU|CAN spoofing with ZombieVerter VCU]]/[https://openinverter.org/shop/index.php?route=product/product&product_id=57 Board Swap]
|80 kW / 130 kW (board swap)
|-
|
|[[Nissan Leaf Gen 3 (2018 up EM57)|Gen3]]
|[[ZombieVerter VCU|CAN spoofing with ZombieVerter VCU]]/Board Swap [WIP]
|110 - 160 kW
|-
|[[:Category:Toyota|Toyota]]
|[[Lexus GS450h Drivetrain|Lexus GS 450h]]
|[[ZombieVerter VCU|Communication spoofing with ZombieVerterVCU]]
|250 kW
|-
|
|[[Toyota/Lexus GS300h CVT|Lexus GS 300h]]
|[[ZombieVerter VCU|Communication spoofing with ZombieVerterVCU]]
|105 kW
|-
|
|[[Toyota Prius Gen2 Inverter|Prius Gen2]]
|[[Toyota Prius Gen2 Inverter Controller|External Control Board]] ([https://openinverter.org/shop/index.php?route=product/product&product_id=68 Buy here])
|40-70 kW
|-
|
|[[Toyota Prius Gen3 Board|Prius Gen3]]
|[https://evbmw.com/index.php/evbmw-webshop/toyota-built-and-tested-boards Board Swap]/[[ZombieVerter VCU|Communication spoofing with ZombieVerterVCU]]
|100 kW
|-
|
|[[Toyota/Lexus MGR Rear Transaxle Motor|MGR]]
|Prius Gen2 or Gen3 inverter
|18-50 kW (various models)
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander Rear Drive Unit|Rear Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing with ZombieVerterVCU]]
|60-70 kW
|-
|
|[[Mitsubishi Outlander Front Transaxle|Front Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing with ZombieVerterVCU]]
|60-70 kW
|-
|[[:Category:BMW|BMW]]
|[[BMW i3 Inverter|i3]]
|[https://openinverter.org/shop/index.php?route=product/product&path=61&product_id=72 Board Swap]
|125-135 kW
|-
|[[Chevrolet|Chevy/Opel]]
|[[Chevrolet Volt Inverter|Volt/Ampera]]
|Board Swap
|160 kW
|-
|[[:Category:Ford|Ford]]
|[[Ford Ranger TIM Controller|Ranger]]
|Board Swap
| Unknown
|-
| Renault
|[https://openinverter.org/forum/viewtopic.php?t=4749 Zoe]
|Board Swap [WIP]
|Unknown
|-
|MG
|[https://github.com/damienmaguire/MG-EV-Inverter ZS EV]
|Board Swap [WIP]
|Unknown
|}

==Reusing Batteries==
[[File:A09A7634.jpg|thumb]]
The most expensive and probably equally defining component is the [[Batteries|battery]] that stores all the energy for running your car. Batteries are usually assembled from a number of modules that in turn contain a number of cells. Usually batteries are reused on a [[Batteries#OEM modules|module level]]. In rare cases the battery can be [https://youtu.be/_7l0Y1GsNJ4 reused as is in its original battery] box.

While there are also various [[16-cell BMS|open source implementations]] of [https://www.youtube.com/watch?v=_QsMoCrSTYc battery management systems] (BMS) we generally recommend using as much of the OEM BMS as possible. Sometimes the [[:Category:OEM|OEM]] BMS comes as an all-in-one solution that measures cell data and spits out state of charge and power limit information. In other cases the BMS is split into module units that measure the physical data (voltages, temperatures) and a central unit that calculates the high level information.

Sometimes we managed to reuse the complete system which is generally the safest as you can rely on the manufacturers well tested charge and discharge limits as well as reliable state of charge information (i.e. how much energy is left in the battery at any given time). In other cases we only managed to reuse the module units. This adds the convenience of having a well tested piece of hardware with the matching connector but required us to calculate all high level battery data ourselves. This also includes [https://www.youtube.com/watch?v=RGYLPOlT45A cell balancing].
{| class="wikitable"
|+
!Manufacturer
!Model
!BMS usability
!Energy Content
!Configuration
!Rated Output
!Achieved Output
!Notes
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model 3 Battery|Model 3]]
|Module and high level [WIP]
|60-80 kWh ?
|
|
|
|
|-
|
|[[Batteries#OEM modules|Model S]]
|Unknown
|85-100 kWh
|
|
|
|
|-
|[[:Category:Nissan|Nissan]]
|[[Nissan Leaf BMS|Leaf/NV200]]
|High Level
|24-40 kWh
|
|
|
|
|-
|[[:Category:VAG|VW]]
|[[VW Hybrid Battery Packs|Passat/Golf]]
|Module Level
|8.7-36 kWh
|
|
|
|
|-
|
|[[MEB Batteries|MEB]]
|Module Level
|52-77 kwh
|
|
|
|
|-
|BMW
|[[BMW Hybrid Battery Pack|3 Series Hybrid]]
|Module Level
|Gen 1: 7kWh. Gen 2: 9KWh
|80s
|83kW
|
| rowspan="2" |These Batteries use the same modules. 3 series uses 5 whilst the 5 &7 series uses 6.
|-
|
|[[BMW Hybrid Battery Pack|5 & 7 Series Hybrid]]
|Module Level
|Gen 1: 9kWh. Gen 2: 12kWh
|96s
|83kW
|120kW
|-
|
|[[BMW Hybrid Battery Pack|X5]]
|Module Level
|24kWh
|96s
|83kw
|
|12 Modules.
|-
|Renault
|[[Renault Zoe Battery Pack|Zoe]]
|High Level
|22kWh - 52kWh
|2p96s
|100kW
|
|Available in 22kWh, 41kWh & 52kWh variants.
|}

== Onboard chargers and DC/DC converters ==
[[File:PXL_20241020_024043714.jpg|thumb|Onboard charger]]
The DC/DC converter takes energy from your HV traction battery and sends it to the cars 12V systems and 12V battery. It is basically a 1:1 replacement of the former alternator. An onboard charger (OBC) takes AC current from the grid and converts it into DC current to charge the battery. These two devices are often combined in one common enclosure hence why we treat them as one.
{| class="wikitable"
|+
!Manufacturer
!Model
!OBC
!DC/DC
!OBC power
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S GEN1 Charger|Model S]] (Gen1)
|yes
|no
|10 kW
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN2 Charger|Model S and X]] (Gen2)
|yes
|no
|11 kW
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN3 Charger|Model S and X]] (Gen3)
|yes
|no
|22 kW
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X DC/DC Converter|Model S and X]] (DC/DC)
|no
|yes
|
|-
| [[:Category:Tesla|Tesla]]
| [[Tesla Model 3 Charger/DCDC ("PCS")|Model 3]]
|yes
|yes
|11 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt Charger|Volt]]
|yes
|yes
|3.7 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt 2 Charger|Volt 2]]
|yes
|yes
|3.7 kW
|-
|[[Dilong/Cascadia Chargers|Dilong]]
|
|yes
|yes
|6.6 kW
|-
|[[Eltek chargers|Eltek]]
|
|yes
|no
|3 kW
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander DCDC OBC|Outlander / iMiev]]
|yes
|yes
|3.3 kW
|-
|[[:Category:MG|MG]]
|[[MG ZS Charger|ZS / MG4 / MG5]]
|yes
|yes
|6.6 - 11 kW
|}
There are more chargers under investigation, only the proven working ones are listed here. See our [[:Category:Charger|charger listing]] for more.

== Rapid Charging==
[[File:Ccs-socket.jpg|thumb|CCS2 rapid charging socket]]
The above mentioned onboard chargers always have limited power as the space requirements and cost rise with power. To overcome this limitation modern EVs offer external access to their HV battery via a so called [[:Category:Rapid Charging|rapid charging]] port. This allows to charge the battery with a much more powerful external charger. As a bonus it also allows [[Bidirectional Charging|taking energy from the HV battery]] and powering appliances with it.

There are 2 rapid charging protocols and 5 connector flavours world wide
{| class="wikitable"
|+
!Connector
!Communication
!Prevalent countries
!Open Source solutions
|-
|[[:Category:ChaDeMo|CHAdeMO]]
|CAN
|Japan, world wide
|[[Chademo with ESP32-Chademo|ESP32]], [[Chademo With Arduino Due|Arduino,]] [[Chademo with Zombieverter|ZombieVerter]]
|-
|CCS Combo1
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|CCS Combo2
|[[Foccci|PLC]]
|Europe
|[[Foccci]], [[pyPLC]], [[BMW I3 Fast Charging LIM Module|I3LIM]]
|-
|NACS
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|GB/T
|CAN
|China
|
|}

== Auxiliary Parts ==
We have now treated all the major building blocks of an EV, but there are many other components to complete the vehicle such as heaters, gear shifters and so on. We will summarize them here.

* [[:Category:HVJB|HV Junction Box]]
* [[:Category:HVAC|HVAC]] (Heating, Air conditioning)
* [[Vacuum Pumps]]
* [[:Category:Power Steering|Power Steering]]
* [[Water Pumps]]
* [[VCU Comparison|VCU]] (Vehicle Control Unit)
* [[Shift Controllers]]
* [[:Category:Charge Ports|Charge Ports]]

== Additional Reading ==

* [[:Category:Legalities|Legalities]] - Getting a vehicle road legal in your country
* [[Glossary of Terms]]
* [[Parameters|Inverter Parameter Definitions]]
* [[Common Inverter FAQ]] - questions common to all hardware variants
* [[Tesla Inverter FAQ]] - questions regarding Tesla Large Drive Units and Small Drive Units
* [[Electronics Basics]] - general advice for troubleshooting electronic circuits
* [[I want a cheap ev conversion|cheap EV conversions]] - this entry point for the penny pinchers
* [[I want a powerful ev conversion|performant EV conversions]] - where torque trumps money
* [[Mechanical design database]] - here you will find measurements, models, files, etc for a variety of components such as adapter plates and drive shaft flanges
* [[:Category:OpenInverter|Documentation of all OpenInverter Projects]]
* [[:Category:Tutorials|Tutorials]]
* [[Hardware Theory of Operation]]
* [[Software Theory of Operation]]

==Who we are==
There is no static team or openinverter company but here we list the most active community members with links to donation or information sites:

*Johannes Hübner, openinverter founder and developer - [https://www.patreon.com/openinverter support on patreon] follow on [https://www.youtube.com/user/EngineersFear youtube] and [https://github.com/jsphuebner/ github]
*Damien Maguire, developer and most active vehicle converter - [https://evbmw.com/index.php/evbmw-webshop visit shop] [https://www.patreon.com/evbmw support on patreon] follow on [https://www.youtube.com/@Evbmw youtube] and [https://github.com/damienmaguire/ github]
*Tom de Bree, active member and developer - [https://github.com/Tom-evnut github] and [https://citini.com/ shop]
*Uwe Hennig, master of CCS - [https://www.patreon.com/uhi22 support on patreon] follow on [https://github.com/uhi22/ github]
*celeron55, developer - support via [https://www.paypal.com/paypalme/celeron55 paypal] follow on [https://www.youtube.com/user/celeron55 youtube] and [https://github.com/celeron55 github]
*Dave Fiddes, active member and developer - Follow on [https://github.com/davefiddes/ github]
*Arber Kramar, long term member and developer - [https://leafdriveblog.wordpress.com/ Follow on blogspot]
*Janosch Oppermann, active member, developer and producer - follow on [https://www.youtube.com/@foxev-content youtube]

Bidirectional Charging

2025-11-19T11:21:16Z

Johu: /* Practical implementation with parts list */

Bidirectional charging means, that the car is able to provide power to the outside world, via the charge port.

Tags: bidi, inverse charging, vehicle-to-load, V2L, vehicle-to-home, V2H, vehicle-to-grid, V2G

=== Forum discussions related to bidirectional charging: ===
https://openinverter.org/forum/viewtopic.php?t=5090

https://openinverter.org/forum/viewtopic.php?t=3551

=== Bidirectional Charging via AC ===
Some OEM on-board-chargers are able to create AC voltage. Todo: any reverse-engineering ongoing for such chargers? E.g. for Hyundai/Kia E-GMP?

=== Bidirectional Charging via CHAdeMO ===
The CHAdeMO standard was planned for supporting bidirectional power transfer from the beginning. Todo: Any open-source projects in this direction?

=== Bidirectional Charging via CCS ===
The CCS standard did not plan bidirectional power transfer. This means, depending on the implementation details of the cars charge controller, the car may or may not allow to draw energy out of the CCS port. Later versions of the CCS standard, ISO15118 (2020?), are defining special communication procedures for bidirectional power transfer. But it will take some time until this standard is widely adapted.

In the open-source world, however, we do not need to wait until OEMs and charger manufacturers implement the latest ISO15118. We can support bidirectional charging even with the "old" DIN spec. The strategy is: Even if the car is requesting to be charged, it also accepts discharging, without terminating the charging session. It may terminate if the SOC falls below a certain, configurable level, to prevent an empty battery. The car announces the allowed charge current, and the same value, just in opposite direction, can be used as a discharge current limit, too.

== Practical implementation with parts list ==
[[File:CCS bidirectional charger.jpg|thumb|First prototype]]
One way to DIY a bidirectional charger is the use of a hybrid PV inverter with high voltage battery input. The advantage is that these are mass-produced (thus cheap) and conform to the various legal requirements. The inverter then handles power transfer and optionally smart functions such as zero grid import/export and we only need to supply the surrounding logic and electrics.
[[File:CCS bidirectional charger 2.jpg|thumb|Second version]]
This component list is just an example that has proven to work. It is preliminary and has not been tested with OEM cars yet, so it will likely be extended. As always, you are working with high voltage and especially grid voltage. Make sure you are qualified otherwise ask for help.
{| class="wikitable"
|+
!Item
!Approximate cost
!Link/Source
!Remarks
|-
|Sungrow SH5.0RT (or more powerful variant)
|850€
|[https://ger.sungrowpower.com/productDetail/905 Sungrow]
|Pick an inverter that is supported by [https://github.com/dalathegreat/Battery-Emulator/wiki#supported-inverters-list Battery Emulator]
|-
|CCS Connector
|90€
|AliExpress
|Plain connector without cable
|-
|BeagleBone Green
|45€
|[https://www.mouser.de/ProductDetail/Seeed-Studio/102010027?qs=Hlcjo%2FO3pQ5AxSET1oW%252B%252Bg%3D%3D Mouser]
|
|-
|[[FoccciCape]]
|t.b.d.
|t.b.d
|RS485, CAN comm, 2x relay driver, CCS
|-
|Flexible cable, 4 or 5 pole
|4€/m
|Local hardware store
|Size according to charging current. 5x2.5mm² used for the 5 kW inverter
For DC+, DC-, PE, CP and PP.
PP can optionally be terminated in the plug, then you just need 4 poles
|-
|2 Fuse blocks
|6€ each
|[https://www.mouser.de/ProductDetail/Altech/002540101?qs=rrS6PyfT74edEoVfbnqxvg%3D%3D Mouser]
|
|-
|2 25A fuses
|8€ each
|[https://www.mouser.de/ProductDetail/Eaton-Electronics/EKM10-25-1P?qs=sGAEpiMZZMsIz3CjQ1xegZx2pdJYlyprSptsITKY%2FrCWMtgS7UD2BQ%3D%3D Mouser]
|400V AC rated from your local hardware store suffices as it's 2 in series
|-
|12V 2A DIN rail supply
|18€
|[https://www.mouser.de/ProductDetail/MEAN-WELL/HDR-30-12?qs=pHY8AWQbqIN66yYHZne39A%3D%3D Mouser]
|In case relays are needed later on, otherwise 5V model makes things easier
|-
|12V to 5V step-down converter
|5€
|ebay or ali
|Needed if you chose 12V supply
|-
|DIN rail cabinet
|20€
|Local hardware store
|
|-
|MC4 connector set
|5€
|
|
|-
|5V to 400V step up converter
|10€
|[https://www.ebay.de/itm/357155751299 ebay]
|Only needed for OEM cars
|}
The CCS connectors + and - is connected to the inverter input via the fuse blocks. I did not deploy additional contactors but rely on the ones that are already in the car and the inverter. The PLC modems output transformer is connected to PE and CP via a capacitor and a resistor, more details in [https://github.com/uhi22/pyPLC/blob/master/doc/hardware.md uhis github].

The BeagleBone is connected to the PLC modem and the inverter Ethernet port, so you will need a small network switch, also for the uplink to your home network. In addition the CAN outputs of the COMPCE cape connects to the inverters battery CAN (pins 3 and 4 on the Sungrow).

More info on the software setup in the development threads linked above, uhis github and [https://github.com/jsphuebner/esp-egycounter Johannes' github].

This setup can also be used with CHAdeMO cars in which case the powerline modem can be omitted.

== Compatible cars ==
This table lists cars where we successfully pulled power OUT of the cars battery via its quick charge port.

More details on [https://github.com/jsphuebner/esp-egycounter forum thread].

First column: Y - works flawlessly with no timeout, P - works partially with long timeout, N - works not at all or quick timeout
{| class="wikitable"
|+
!
!Make
!Model
!Requirements
!Remarks
|-
|P
|Hyundai
|Ioniq Classic 28 kWh
|Simulated precharge
|Timeout after 10 minutes
|-
|Y
|MG
|MG4
|Simulated precharge
|No timeout
|-
|Y
|Tesla
|Model Y
|Physical Precharge voltage
|5 kW tested
|-
|Y
|Tesla
|Model 3
|Physical Precharge voltage
|BMS aborts charging session if more than 15Ah discharge have been detected
|-
|Y
|BYD
|Atto 3
|
|5 kW tested
|-
|Y
|Polestar
|2
|Physical Precharge voltage
|
|-
|N
|VW
|ID.4
|
|Timeout after 1 minute
|-
|N
|BMW
|IX4
|
|Timeout after 5 minutes
|-
|N
|Chevrolet
|Bolt
|
|Timeout after 50 s
|-
|N
|Kia
|EV6
|
|Timeout after 10 s
|}

== Collection of documents related to bidirectional charging ==
todo

== References ==
todo

Bidirectional Charging

2025-11-19T11:20:54Z

Johu: Part numbers, replaced PLC modem by FoccciCape

Bidirectional charging means, that the car is able to provide power to the outside world, via the charge port.

Tags: bidi, inverse charging, vehicle-to-load, V2L, vehicle-to-home, V2H, vehicle-to-grid, V2G

=== Forum discussions related to bidirectional charging: ===
https://openinverter.org/forum/viewtopic.php?t=5090

https://openinverter.org/forum/viewtopic.php?t=3551

=== Bidirectional Charging via AC ===
Some OEM on-board-chargers are able to create AC voltage. Todo: any reverse-engineering ongoing for such chargers? E.g. for Hyundai/Kia E-GMP?

=== Bidirectional Charging via CHAdeMO ===
The CHAdeMO standard was planned for supporting bidirectional power transfer from the beginning. Todo: Any open-source projects in this direction?

=== Bidirectional Charging via CCS ===
The CCS standard did not plan bidirectional power transfer. This means, depending on the implementation details of the cars charge controller, the car may or may not allow to draw energy out of the CCS port. Later versions of the CCS standard, ISO15118 (2020?), are defining special communication procedures for bidirectional power transfer. But it will take some time until this standard is widely adapted.

In the open-source world, however, we do not need to wait until OEMs and charger manufacturers implement the latest ISO15118. We can support bidirectional charging even with the "old" DIN spec. The strategy is: Even if the car is requesting to be charged, it also accepts discharging, without terminating the charging session. It may terminate if the SOC falls below a certain, configurable level, to prevent an empty battery. The car announces the allowed charge current, and the same value, just in opposite direction, can be used as a discharge current limit, too.

== Practical implementation with parts list ==
[[File:CCS bidirectional charger.jpg|thumb|First prototype]]
One way to DIY a bidirectional charger is the use of a hybrid PV inverter with high voltage battery input. The advantage is that these are mass-produced (thus cheap) and conform to the various legal requirements. The inverter then handles power transfer and optionally smart functions such as zero grid import/export and we only need to supply the surrounding logic and electrics.
[[File:CCS bidirectional charger 2.jpg|thumb|Second version]]
This component list is just an example that has proven to work. It is preliminary and has not been tested with OEM cars yet, so it will likely be extended. As always, you are working with high voltage and especially grid voltage. Make sure you are qualified otherwise ask for help.
{| class="wikitable"
|+
!Item
!Approximate cost
!Link/Source
!Remarks
|-
|Sungrow SH5.0RT (or more powerful variant)
|850€
|[https://ger.sungrowpower.com/productDetail/905 Sungrow]
|Pick an inverter that is supported by [https://github.com/dalathegreat/Battery-Emulator/wiki#supported-inverters-list Battery Emulator]
|-
|CCS Connector
|90€
|AliExpress
|Plain connector without cable
|-
|BeagleBone Green
|45€
|[https://www.mouser.de/ProductDetail/Seeed-Studio/102010027?qs=Hlcjo%2FO3pQ5AxSET1oW%252B%252Bg%3D%3D Mouser]
|
|-
|[[FoccciCape]]
|40€
|t.b.d
|RS485, CAN comm, 2x relay driver, CCS
|-
|Flexible cable, 4 or 5 pole
|4€/m
|Local hardware store
|Size according to charging current. 5x2.5mm² used for the 5 kW inverter
For DC+, DC-, PE, CP and PP.
PP can optionally be terminated in the plug, then you just need 4 poles
|-
|2 Fuse blocks
|6€ each
|[https://www.mouser.de/ProductDetail/Altech/002540101?qs=rrS6PyfT74edEoVfbnqxvg%3D%3D Mouser]
|
|-
|2 25A fuses
|8€ each
|[https://www.mouser.de/ProductDetail/Eaton-Electronics/EKM10-25-1P?qs=sGAEpiMZZMsIz3CjQ1xegZx2pdJYlyprSptsITKY%2FrCWMtgS7UD2BQ%3D%3D Mouser]
|400V AC rated from your local hardware store suffices as it's 2 in series
|-
|12V 2A DIN rail supply
|18€
|[https://www.mouser.de/ProductDetail/MEAN-WELL/HDR-30-12?qs=pHY8AWQbqIN66yYHZne39A%3D%3D Mouser]
|In case relays are needed later on, otherwise 5V model makes things easier
|-
|12V to 5V step-down converter
|5€
|ebay or ali
|Needed if you chose 12V supply
|-
|DIN rail cabinet
|20€
|Local hardware store
|
|-
|MC4 connector set
|5€
|
|
|-
|5V to 400V step up converter
|10€
|[https://www.ebay.de/itm/357155751299 ebay]
|Only needed for OEM cars
|}
The CCS connectors + and - is connected to the inverter input via the fuse blocks. I did not deploy additional contactors but rely on the ones that are already in the car and the inverter. The PLC modems output transformer is connected to PE and CP via a capacitor and a resistor, more details in [https://github.com/uhi22/pyPLC/blob/master/doc/hardware.md uhis github].

The BeagleBone is connected to the PLC modem and the inverter Ethernet port, so you will need a small network switch, also for the uplink to your home network. In addition the CAN outputs of the COMPCE cape connects to the inverters battery CAN (pins 3 and 4 on the Sungrow).

More info on the software setup in the development threads linked above, uhis github and [https://github.com/jsphuebner/esp-egycounter Johannes' github].

This setup can also be used with CHAdeMO cars in which case the powerline modem can be omitted.

== Compatible cars ==
This table lists cars where we successfully pulled power OUT of the cars battery via its quick charge port.

More details on [https://github.com/jsphuebner/esp-egycounter forum thread].

First column: Y - works flawlessly with no timeout, P - works partially with long timeout, N - works not at all or quick timeout
{| class="wikitable"
|+
!
!Make
!Model
!Requirements
!Remarks
|-
|P
|Hyundai
|Ioniq Classic 28 kWh
|Simulated precharge
|Timeout after 10 minutes
|-
|Y
|MG
|MG4
|Simulated precharge
|No timeout
|-
|Y
|Tesla
|Model Y
|Physical Precharge voltage
|5 kW tested
|-
|Y
|Tesla
|Model 3
|Physical Precharge voltage
|BMS aborts charging session if more than 15Ah discharge have been detected
|-
|Y
|BYD
|Atto 3
|
|5 kW tested
|-
|Y
|Polestar
|2
|Physical Precharge voltage
|
|-
|N
|VW
|ID.4
|
|Timeout after 1 minute
|-
|N
|BMW
|IX4
|
|Timeout after 5 minutes
|-
|N
|Chevrolet
|Bolt
|
|Timeout after 50 s
|-
|N
|Kia
|EV6
|
|Timeout after 10 s
|}

== Collection of documents related to bidirectional charging ==
todo

== References ==
todo

FoccciCape

2025-11-19T10:35:04Z

Johu: added part numbers for accessories

[[Category:CCS]] [[Category:Rapid Charging]]
[[Category:Charger]]
[[Category:OpenInverter]]
[[File:FoccciCape.jpg|thumb|FoccciCape]]
This is an add-on board for the popular BeagleBone single board computer. It is mainly a communication breakout board but features a very special form of communication: CCS! So with it you can get your EV to close its charge port contactors. At the very least you can then charge your EV with your hybrid PV inverter and if the manufacturer doesn't actively inhibit it you can also draw energy from your vehicles battery to supply your house or even selling it back to the grid.

In addition it has enough communication power to talk to all sorts of PV inverters, BMSes etc. to tie it all together an fully control the flow of energy from a single point.

== Connections ==
The board has a 12-way Phoenix connector or can be equipped with any other 3.81 mm pin pitch terminal. Together with the BeagleBone it offers the following interfaces:

* 1x RS485
* 2x CAN
* 1x CCS PowerLine communication and PWM signalling
* 2x open drain relay outputs
* 1x status LED output combined with button input
* 1x Ethernet (on BeagleBone)
* 1x USB (on BeagleBone)
* 1x HDMI (only BeagleBone Black)
* 1x Grove I2C (only BeagleBone Green)
* 1x Grove UART (only BeagleBone Green)

=== Part numbers and links ===

* Phoenix 12-way connector [https://www.mouser.de/ProductDetail/Phoenix-Contact/1803523?qs=CXo1rOUe%2FWsOGk2v2GZlUQ%3D%3D 1803523]
* Phoenix 12-way screw terminal [https://www.mouser.de/ProductDetail/Phoenix-Contact/1803675?qs=WWq3Ki8dym4RD77JGGq8bA%3D%3D 1803675]
* BeagleBone Green [https://www.mouser.de/ProductDetail/Seeed-Studio/102010027?qs=Hlcjo%2FO3pQ5AxSET1oW%252B%252Bg%3D%3D 102010027]
* DIN rail [https://www.reichelt.de/de/de/shop/produkt/gehaeuse_fuer_beaglbone_black_stahl_schwarz-315121 enclosure] and [https://www.reichelt.de/de/de/shop/produkt/gehaeuse_fuer_beaglbone_black_stahl_schwarz-315121 clip]

== Software ==
[[File:StorageSystemConfigurationScreen.png|thumb|Storage System Configuration Screen]]
The software is comprised of a bunch of [https://github.com/jsphuebner/esp-egycounter/tree/main/battery-control python scripts] that exchange information via MQTT. The following modules are available:

* Communication via Modbus using [https://github.com/tjhowse/modbus4mqtt Modbus4Mqtt]
* Communication with SoyoSource inverters
* Simulation of BYD battery via CAN
* Communication with Eltek Flatpack chargers
* Reading status from Keba P20 EVSE
* Communication with Manson switch mode power supply
* Communication with openinverter [[16-cell BMS]]
* Retrieval of spot market prices via awattar or Tibber API
* Data logger
* Submission of raw meter data to Tibber
* CCS communication via [[PyPLC]]
* Energy flow controller (Zero Grid Exchange, charge on low spot market price, discharge only on high spot market price)
* Web Interface for configuration and monitoring

== Installation ==
This section is only relevant if you're setting up the BeagleBone yourself. If you buy a preprogrammed one from the shop (not yet available) this has already been done for you. We are also working on an image file that is already set up.

The howto for compiling the QCA kernel module and setting it up can be found on the [https://openinverter.org/forum/viewtopic.php?p=87295#p87295 forum].

Next you need to flash the SPI flash on the cape with QCA firmware, this is also described on the [https://openinverter.org/forum/viewtopic.php?p=87710#p87710 forum].

Finally you enable all relevant peripherals in /boot/uEnv.txt:<syntaxhighlight lang="ini">
uboot_overlay_addr0=/lib/firmware/BB-CAN0-00A0.dtbo
uboot_overlay_addr1=/lib/firmware/BB-CAN1-00A0.dtbo
uboot_overlay_addr2=/lib/firmware/BB-SPI0-QCASPI-00A0.dtbo
uboot_overlay_addr3=/lib/firmware/BB-UART4-00A0.dtbo

</syntaxhighlight>To enable both CAN interfaces at boot you configure systemd-networkd by creating one file per interface, /etc/systemd/network/80-can0.network<syntaxhighlight lang="ini">
[Match]
Name=can0

[CAN]
BitRate=500K
RestartSec=100ms
</syntaxhighlight>And likewise 81-can1.network (Name=can1). Of course you need to pick the baud rate that matches the devices you connect to the port, but 500k is usually your best bet.

FoccciCape

2025-11-19T10:14:36Z

Johu: Created page with " Category:CCS Category:Rapid Charging Category:Charger Category:OpenInverter FoccciCape This is an add-on board for the popular BeagleBone single board computer. It is mainly a communication breakout board but features a very special form of communication: CCS! So with it you can get your EV to close its charge port contactors. At the very least you can then charge your EV with your hybrid PV inverter and if the manufacturer..."

[[Category:CCS]] [[Category:Rapid Charging]]
[[Category:Charger]]
[[Category:OpenInverter]]
[[File:FoccciCape.jpg|thumb|FoccciCape]]
This is an add-on board for the popular BeagleBone single board computer. It is mainly a communication breakout board but features a very special form of communication: CCS! So with it you can get your EV to close its charge port contactors. At the very least you can then charge your EV with your hybrid PV inverter and if the manufacturer doesn't actively inhibit it you can also draw energy from your vehicles battery to supply your house or even selling it back to the grid.

In addition it has enough communication power to talk to all sorts of PV inverters, BMSes etc. to tie it all together an fully control the flow of energy from a single point.

== Connections ==
The board has a 12-way Phoenix connector or can be equipped with any other 3.81 mm pin pitch terminal. Together with the BeagleBone it offers the following interfaces:

* 1x RS485
* 2x CAN
* 1x CCS PowerLine communication and PWM signalling
* 2x open drain relay outputs
* 1x status LED output combined with button input
* 1x Ethernet (on BeagleBone)
* 1x USB (on BeagleBone)
* 1x HDMI (only BeagleBone Black)
* 1x Grove I2C (only BeagleBone Green)
* 1x Grove UART (only BeagleBone Green)

== Software ==
[[File:StorageSystemConfigurationScreen.png|thumb|Storage System Configuration Screen]]
The software is comprised of a bunch of [https://github.com/jsphuebner/esp-egycounter/tree/main/battery-control python scripts] that exchange information via MQTT. The following modules are available:

* Communication via Modbus using [https://github.com/tjhowse/modbus4mqtt Modbus4Mqtt]
* Communication with SoyoSource inverters
* Simulation of BYD battery via CAN
* Communication with Eltek Flatpack chargers
* Reading status from Keba P20 EVSE
* Communication with Manson switch mode power supply
* Communication with openinverter [[16-cell BMS]]
* Retrieval of spot market prices via awattar or Tibber API
* Data logger
* Submission of raw meter data to Tibber
* CCS communication via [[PyPLC]]
* Energy flow controller (Zero Grid Exchange, charge on low spot market price, discharge only on high spot market price)
* Web Interface for configuration and monitoring

== Installation ==
This section is only relevant if you're setting up the BeagleBone yourself. If you buy a preprogrammed one from the shop (not yet available) this has already been done for you. We are also working on an image file that is already set up.

The howto for compiling the QCA kernel module and setting it up can be found on the [https://openinverter.org/forum/viewtopic.php?p=87295#p87295 forum].

Next you need to flash the SPI flash on the cape with QCA firmware, this is also described on the [https://openinverter.org/forum/viewtopic.php?p=87710#p87710 forum].

Finally you enable all relevant peripherals in /boot/uEnv.txt:<syntaxhighlight lang="ini">
uboot_overlay_addr0=/lib/firmware/BB-CAN0-00A0.dtbo
uboot_overlay_addr1=/lib/firmware/BB-CAN1-00A0.dtbo
uboot_overlay_addr2=/lib/firmware/BB-SPI0-QCASPI-00A0.dtbo
uboot_overlay_addr3=/lib/firmware/BB-UART4-00A0.dtbo

</syntaxhighlight>To enable both CAN interfaces at boot you configure systemd-networkd by creating one file per interface, /etc/systemd/network/80-can0.network<syntaxhighlight lang="ini">
[Match]
Name=can0

[CAN]
BitRate=500K
RestartSec=100ms
</syntaxhighlight>And likewise 81-can1.network (Name=can1). Of course you need to pick the baud rate that matches the devices you connect to the port, but 500k is usually your best bet.

File:StorageSystemConfigurationScreen.png

2025-11-19T10:01:04Z

Johu:

Storage System Configuration Screen

File:FoccciCape.jpg

2025-11-19T09:07:00Z

Johu:

FoccciCape with pin descriptions

Tesla Model S/X Small Drive Unit ("SDU")

2025-10-14T17:28:22Z

Johu: Added connector part numbers

== Overview ==
Tesla uses the Small Drive Unit (SDU) in dual-motor versions of the Model S/X. The Front SDU (FDU) is found in performance and non-performance dual-motor models, while the Rear SDU (RDSU) is only found in non-performance dual motor models.

== Wiring ==
[[File:Drive Inverter Front Connector.png|thumb|Small Drive Unit ("SDU") Data Connector|alt=]]
=== Low Voltage Data Connector ===
[[File:Drive Inverter Front Connector Schematic.png|thumb|Small Front Drive Unit ("SDU") Data Schematic|alt=]]

=== '''Housing''' ===
Molex MX150 33472-2002 (key “B”)

'''Pins:'''

22 AWG: Molex 33012-2003

18-20 AWG: Molex 33012-2002

14-16 AWG: Molex 33012-2001

=== High Voltage Power Connectors===
Although the connectors are known ([https://www.rosenberger.com/product/hpk/ Rosenberger HPK series]), they are not available through conventional vendors.

=== Internal connectors ===
20-pole Molex: 75757-5101

2-pole temp sensor: S02BA-AIT2-1AK

6-pole encoder: S06B-AIT2-1AK

24-pole inverter: CES-112-02-T-D

==Drop-in control board==
[[File:Tesla SDU controller connections.png|thumb|Tesla SDU drop-in board]]

This board replaces the original board that comes with the OEM Tesla drive train. As opposed to the latter this board lets you use the drive train in the first place and allows you to fine-tune driving behaviour with the usual set of openinverter parameters. It does not restrict you in power output or regen input.

You can fully control the board via CAN or via a set of digital and analog inputs.

Dual Pot mode, connect pot 2 to pin 10, BRAKE TRANSDUCER SIGNAL.
{| class="wikitable"
!Note: see this thread regarding throttle pedal safety https://openinverter.org/forum/viewtopic.php?p=75841 this applies to the SDU boards.
|}

===Resources===
'''Wiring'''

[https://github.com/damienmaguire/Tesla-Front-Drive-Unit/blob/master/SDU_Wiring_Connections.pdf Wiring connections]

[[:File:Zombieverter SDU Wiring.png|Wiring with Zombieverter]]

[https://github.com/damienmaguire/Tesla-Front-Drive-Unit/blob/master/FDU_Main_conn_pinout_V1.ods Pinout]

[https://www.thingiverse.com/thing:6230844 MX150 male header receptacle STL on Thingiverse]

'''Buying'''

[https://openinverter.org/shop/index.php?route=product/product&product_id=62 Purchase in openinverter shop]

'''Tuning'''

[https://openinverter.org/forum/viewtopic.php?t=2558 SDU Tuning Optimization Forum Thread]

[https://openinverter.org/parameters/view.html?id=15 Original Parameters from Johannes]

[https://openinverter.org/parameters/view.html?id=27 Parameters tuned by catphish]

[[Setup FAQ]]

===Application Info===
The board comes programmed with a recent software version. Please check [https://github.com/jsphuebner/stm32-sine/releases github] for recent software releases. In addition the board comes with a set of parameters appropriate to run the Tesla SDU. So it will work out of the box. Parameters that must not be changed are hidden to eliminate sources of error.

{| class="wikitable" style="background-color:#ffffcc;" cellpadding="10"
|'''It is essential that the tripmode parameter is set to 1 "DcSwOn"'''. Also do not use a low value fuse while testing. On over current trips some energy is still stored in the motor and it has nowhere to go if the contactor/fuse opens leading to immediate destruction of your inverter.
|}

You will need to solder the supplied connectors and the current sensors embedded into the inverter assembly to the board, see [https://youtu.be/VVSRzmP-fRw this video].

To test run your drive unit, supply the board with 12V and GND on Conn6.13 and Conn6.19, respectively. Also supply 12V to Conn6.5 to select forward direction.

Supply inverter with some high voltage. For first tests it is recommended to put a large resistor/heating element/kettle in series.

You can start in manual mode using the button on the web interface and enter like 1Hz for „Fslipspnt“ and some value between 10-50 for „ampnom“ to see if the motor spins up. Be careful because manual mode does not enforce a motor speed limit!

You may also set parameter „udcsw“ and „udcmin“ to 0 and start drive mode by pulsing 12V on Conn6.9. Then connect a pot between Conn6.4, Conn6.7 and Conn6.8 (wiper). This will also spin the motor AND enforce a speed limit.

==Cooling ==

===Small Front Drive Unit (FDU)===
[[File:Tesla FDU cooling.jpg|none|thumb|Tesla FDU cooling]]

===Small Rear Drive Unit (SRDU)===
[[File:Tesla SRDU cooling.png|none|thumb|Tesla SRDU cooling]]
[[Category:Tesla]]
[[Category:Motor]]
[[Category:Inverter]]
[[Category:Gearbox]]

Main Page

2025-09-22T12:35:36Z

Johu: added link to fallback forum

[[Index|Wiki Index]] - quick reference for all info on the wiki.

If you have trouble logging into the forum, log into [https://openinverter.org:8443/forum this address], then go back to the [https://openinverter.org/forum normal forum].

Did you know you can convert your existing fossil powered vehicle to use electricity instead? And that you can even produce that electricity yourself?

Open Inverter is a [[Main Page#Who we are|community of people]] and projects focused on open source solutions for EV conversions. Founded in 2008 by Johannes Huebner as an open source inverter control firmware, the project has since expanded to include the reuse of components from production EVs and hybrids, including inverters, motors, batteries, on-board chargers, and DC-DC converters, as well as the open source implementation of other necessary systems for EV conversions such as DC Fast Charging controllers.

<imagemap>
File:Electric-car.jpg|none|frame|Click on the captions to learn more about the respective system! Image source: https://www.newkidscar.com/

poly 248 166 542 166 542 217 248 217 248 166 [[#Reusing motors and inverters - aka drive trains]]
poly 1041 455 1336 455 1336 506 1041 506 1041 455 [[#Reusing Batteries]]
poly 147 344 428 344 428 391 147 391 147 344 [[#Onboard chargers and DC/DC converters]]
poly 844 624 1118 624 1118 673 844 673 844 624 [[#Onboard chargers and DC/DC converters]]
poly 935 539 1200 539 1200 586 935 586 935 539 [[#Rapid Charging]]
poly 134 435 394 435 394 483 134 483 134 435 [[#Auxiliary Parts]]
</imagemap>

This wiki is maintained by the wider community. '''Please update this wiki'''. For example if your question has been clarified on the [https://openinverter.org/forum forum] and the new information can not be found here, please add it! The credentials are the same as for the forum.

'''[[Main Page#Who we are|Developers]] time is best spent developing;''' '''Support is best found in the forums''' - Developers of various projects are often bombarded with private messages and emails. Managing these emails and questions is a extremely large undertaking. Please read, and take the time to understand the information available here and across the web if you don't understand a topic. Developers are not your personal support team, unless you want to [[Application Support|pay them directly]] for their time. To keep developers independent please consider donating - donation links can be found [[Main Page#Who we are|down below]].

==Reusing motors and inverters - aka drive trains==
[[File:Tesla_LDU.jpg|thumb]]
The drive train is one of the defining building blocks of your conversion as it defines how well your vehicle picks up speed. Over the years we have reverse engineered many popular drive trains from [[:Category:OEM|production cars]] such as Teslas. As a bonus using such complete drive trains facilitates getting the vehicle [[Legalities|road legal]] in many countries. By now you have a choice of low to medium power drive trains that only cost a few 100€ up to high performance ones at many 1000€.

We have established two methods of running these [[:Category:OEM|OEM]] systems: reverse-engineering their communication protocol and making the drive train "think" it is still in its original vehicle OR swapping out the control electronics for our own open source motor controller. The latter method gives your more control and power but also a steeper learning curve.

Nearly all drive trains are targeted at 400V battery voltage. Run at a lower voltage they will produce proportionally less power.
Here is what we have done so far and how we've done it. Some is still work in progress (WIP)
{| class="wikitable"
|+
!Manufacturer
!Drive Train
!Control Method
! Approximate Power Output
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X Large Drive Unit ("LDU")|Large Drive Unit]]
|[https://openinverter.org/shop/index.php?route=product/product&path=61&product_id=64 Board Swap]
|335-475 kW
|-
|
|[[Tesla Model S/X Small Drive Unit ("SDU")|Small Drive Unit]]
|[https://openinverter.org/shop/index.php?route=product/product&path=61&product_id=62 Board Swap]
|180 kW
|-
|
|[[Tesla Model 3 Rear Drive Unit|Model 3/Y Rear Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|239 kW
|-
|
|[[Tesla Model 3 Front Drive Unit|Model 3/Y Front Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|121 kW
|-
|[[Nissan]]
|[[Nissan Leaf Motors|Gen1]]
|[[ZombieVerter VCU|CAN spoofing with ZombieVerter VCU]]
|80 kW
|-
|
| [[Nissan Leaf Gen2 Board|Gen2]]
|[[ZombieVerter VCU|CAN spoofing with ZombieVerter VCU]]/[https://openinverter.org/shop/index.php?route=product/product&product_id=57 Board Swap]
|80 kW / 130 kW (board swap)
|-
|
|[[Nissan Leaf Gen 3 (2018 up EM57)|Gen3]]
|[[ZombieVerter VCU|CAN spoofing with ZombieVerter VCU]]/Board Swap [WIP]
|110 - 160 kW
|-
|[[:Category:Toyota|Toyota]]
|[[Lexus GS450h Drivetrain|Lexus GS 450h]]
|[[ZombieVerter VCU|Communication spoofing with ZombieVerterVCU]]
|250 kW
|-
|
|[[Toyota/Lexus GS300h CVT|Lexus GS 300h]]
|[[ZombieVerter VCU|Communication spoofing with ZombieVerterVCU]]
|105 kW
|-
|
|[[Toyota Prius Gen2 Inverter|Prius Gen2]]
|[[Toyota Prius Gen2 Inverter Controller|External Control Board]] ([https://openinverter.org/shop/index.php?route=product/product&product_id=68 Buy here])
|40-70 kW
|-
|
|[[Toyota Prius Gen3 Board|Prius Gen3]]
|[https://evbmw.com/index.php/evbmw-webshop/toyota-built-and-tested-boards Board Swap]/[[ZombieVerter VCU|Communication spoofing with ZombieVerterVCU]]
|100 kW
|-
|
|[[Toyota/Lexus MGR Rear Transaxle Motor|MGR]]
|Prius Gen2 or Gen3 inverter
|18-50 kW (various models)
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander Rear Drive Unit|Rear Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing with ZombieVerterVCU]]
|60-70 kW
|-
|
|[[Mitsubishi Outlander Front Transaxle|Front Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing with ZombieVerterVCU]]
|60-70 kW
|-
|[[:Category:BMW|BMW]]
|[[BMW i3 Inverter|i3]]
|[https://openinverter.org/shop/index.php?route=product/product&path=61&product_id=72 Board Swap]
|125-135 kW
|-
|[[Chevrolet|Chevy/Opel]]
|[[Chevrolet Volt Inverter|Volt/Ampera]]
|Board Swap
|160 kW
|-
|[[:Category:Ford|Ford]]
|[[Ford Ranger TIM Controller|Ranger]]
|Board Swap
| Unknown
|-
| Renault
|[https://openinverter.org/forum/viewtopic.php?t=4749 Zoe]
|Board Swap [WIP]
|Unknown
|-
|MG
|[https://github.com/damienmaguire/MG-EV-Inverter ZS EV]
|Board Swap [WIP]
|Unknown
|}

==Reusing Batteries==
[[File:A09A7634.jpg|thumb]]
The most expensive and probably equally defining component is the [[Batteries|battery]] that stores all the energy for running your car. Batteries are usually assembled from a number of modules that in turn contain a number of cells. Usually batteries are reused on a module level. In rare cases the battery can be [https://youtu.be/_7l0Y1GsNJ4 reused as is in its original battery] box.

While there are also various [[16-cell BMS|open source implementations]] of [https://www.youtube.com/watch?v=_QsMoCrSTYc battery management systems] (BMS) we generally recommend using as much of the OEM BMS as possible. Sometimes the [[:Category:OEM|OEM]] BMS comes as an all-in-one solution that measures cell data and spits out state of charge and power limit information. In other cases the BMS is split into module units that measure the physical data (voltages, temperatures) and a central unit that calculates the high level information.

Sometimes we managed to reuse the complete system which is generally the safest as you can rely on the manufacturers well tested charge and discharge limits as well as reliable state of charge information (i.e. how much energy is left in the battery at any given time). In other cases we only managed to reuse the module units. This adds the convenience of having a well tested piece of hardware with the matching connector but required us to calculate all high level battery data ourselves. This also includes [https://www.youtube.com/watch?v=RGYLPOlT45A cell balancing].
{| class="wikitable"
|+
!Manufacturer
!Model
!BMS usability
!Energy Content
!Configuration
!Rated Output
!Achieved Output
!Notes
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model 3 Battery|Model 3]]
|Module and high level [WIP]
|60-80 kWh ?
|
|
|
|
|-
|
|[[Batteries#OEM modules|Model S]]
|Unknown
|85-100 kWh
|
|
|
|
|-
|[[:Category:Nissan|Nissan]]
|[[Nissan Leaf BMS|Leaf/NV200]]
|High Level
|24-40 kWh
|
|
|
|
|-
|[[:Category:VAG|VW]]
|[[VW Hybrid Battery Packs|Passat/Golf]]
|Module Level
|8.7-36 kWh
|
|
|
|
|-
|
|[[MEB Batteries|MEB]]
|Module Level
|52-77 kwh
|
|
|
|
|-
|BMW
|[[BMW Hybrid Battery Pack|3 Series Hybrid]]
|Module Level
|Gen 1: 7kWh. Gen 2: 9KWh
|80s
|83kW
|
| rowspan="2" |These Batteries use the same modules. 3 series uses 5 whilst the 5 &7 series uses 6.
|-
|
|[[BMW Hybrid Battery Pack|5 & 7 Series Hybrid]]
|Module Level
|Gen 1: 9kWh. Gen 2: 12kWh
|96s
|83kW
|120kW
|-
|
|[[BMW Hybrid Battery Pack|X5]]
|Module Level
|24kWh
|96s
|83kw
|
|12 Modules.
|-
|Renault
|[[Renault Zoe Battery Pack|Zoe]]
|High Level
|22kWh - 52kWh
|2p96s
|100kW
|
|Available in 22kWh, 41kWh & 52kWh variants.
|}

== Onboard chargers and DC/DC converters ==
[[File:PXL_20241020_024043714.jpg|thumb|Onboard charger]]
The DC/DC converter takes energy from your HV traction battery and sends it to the cars 12V systems and 12V battery. It is basically a 1:1 replacement of the former alternator. An onboard charger (OBC) takes AC current from the grid and converts it into DC current to charge the battery. These two devices are often combined in one common enclosure hence why we treat them as one.
{| class="wikitable"
|+
!Manufacturer
!Model
!OBC
!DC/DC
!OBC power
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S GEN1 Charger|Model S]] (Gen1)
|yes
|no
|10 kW
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN2 Charger|Model S and X]] (Gen2)
|yes
|no
|11 kW
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN3 Charger|Model S and X]] (Gen3)
|yes
|no
|22 kW
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X DC/DC Converter|Model S and X]] (DC/DC)
|no
|yes
|
|-
| [[:Category:Tesla|Tesla]]
| [[Tesla Model 3 Charger/DCDC ("PCS")|Model 3]]
|yes
|yes
|11 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt Charger|Volt]]
|yes
|yes
|3.7 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt 2 Charger|Volt 2]]
|yes
|yes
|3.7 kW
|-
|[[Dilong/Cascadia Chargers|Dilong]]
|
|yes
|yes
|6.6 kW
|-
|[[Eltek chargers|Eltek]]
|
|yes
|no
|3 kW
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander DCDC OBC|Outlander / iMiev]]
|yes
|yes
|3.3 kW
|-
|[[:Category:MG|MG]]
|[[MG ZS Charger|ZS / MG4 / MG5]]
|yes
|yes
|6.6 - 11 kW
|}
There are more chargers under investigation, only the proven working ones are listed here. See our [[:Category:Charger|charger listing]] for more.

== Rapid Charging==
[[File:Ccs-socket.jpg|thumb|CCS2 rapid charging socket]]
The above mentioned onboard chargers always have limited power as the space requirements and cost rise with power. To overcome this limitation modern EVs offer external access to their HV battery via a so called [[:Category:Rapid Charging|rapid charging]] port. This allows to charge the battery with a much more powerful external charger. As a bonus it also allows [[Bidirectional Charging|taking energy from the HV battery]] and powering appliances with it.

There are 2 rapid charging protocols and 5 connector flavours world wide
{| class="wikitable"
|+
!Connector
!Communication
!Prevalent countries
!Open Source solutions
|-
|[[:Category:ChaDeMo|CHAdeMO]]
|CAN
|Japan, world wide
|[[Chademo with ESP32-Chademo|ESP32]], [[Chademo With Arduino Due|Arduino,]] [[Chademo with Zombieverter|ZombieVerter]]
|-
|CCS Combo1
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|CCS Combo2
|[[Foccci|PLC]]
|Europe
|[[Foccci]], [[pyPLC]], [[BMW I3 Fast Charging LIM Module|I3LIM]]
|-
|NACS
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|GB/T
|CAN
|China
|
|}

== Auxiliary Parts ==
We have now treated all the major building blocks of an EV, but there are many other components to complete the vehicle such as heaters, gear shifters and so on. We will summarize them here.

* [[:Category:HVJB|HV Junction Box]]
* [[:Category:HVAC|HVAC]] (Heating, Air conditioning)
* [[Vacuum Pumps]]
* [[:Category:Power Steering|Power Steering]]
* [[Water Pumps]]
* [[VCU Comparison|VCU]] (Vehicle Control Unit)
* [[Shift Controllers]]
* [[:Category:Charge Ports|Charge Ports]]

== Additional Reading ==

* [[:Category:Legalities|Legalities]] - Getting a vehicle road legal in your country
* [[Glossary of Terms]]
* [[Parameters|Inverter Parameter Definitions]]
* [[Common Inverter FAQ]] - questions common to all hardware variants
* [[Tesla Inverter FAQ]] - questions regarding Tesla Large Drive Units and Small Drive Units
* [[Electronics Basics]] - general advice for troubleshooting electronic circuits
* [[I want a cheap ev conversion|cheap EV conversions]] - this entry point for the penny pinchers
* [[I want a powerful ev conversion|performant EV conversions]] - where torque trumps money
* [[Mechanical design database]] - here you will find measurements, models, files, etc for a variety of components such as adapter plates and drive shaft flanges
* [[:Category:OpenInverter|Documentation of all OpenInverter Projects]]
* [[:Category:Tutorials|Tutorials]]
* [[Hardware Theory of Operation]]
* [[Software Theory of Operation]]

==Who we are==
There is no static team or openinverter company but here we list the most active community members with links to donation or information sites:

*Johannes Hübner, openinverter founder and developer - [https://www.patreon.com/openinverter support on patreon] follow on [https://www.youtube.com/user/EngineersFear youtube] and [https://github.com/jsphuebner/ github]
*Damien Maguire, developer and most active vehicle converter - [https://evbmw.com/index.php/evbmw-webshop visit shop] [https://www.patreon.com/evbmw support on patreon] follow on [https://www.youtube.com/@Evbmw youtube] and [https://github.com/damienmaguire/ github]
*Tom de Bree, active member and developer - [https://github.com/Tom-evnut github] and [https://citini.com/ shop]
*Uwe Hennig, master of CCS - [https://www.patreon.com/uhi22 support on patreon] follow on [https://github.com/uhi22/ github]
*celeron55, developer - support via [https://www.paypal.com/paypalme/celeron55 paypal] follow on [https://www.youtube.com/user/celeron55 youtube] and [https://github.com/celeron55 github]
*Dave Fiddes, active member and developer - Follow on [https://github.com/davefiddes/ github]
*Arber Kramar, long term member and developer - [https://leafdriveblog.wordpress.com/ Follow on blogspot]
*Janosch Oppermann, active member, developer and producer - follow on [https://www.youtube.com/@foxev-content youtube]

Application Support

2025-06-16T11:10:04Z

Johu:

Openinverter is an opensource project, i.e. there is no large company behind it that has paid employees. Therefore all products that you buy in the openinverter shop, the EVBMW shop or that you order yourself from a PCB manufacturer are self-supported. It means you need to research the needed information on the forum or on this wiki.

The developers are well aware that this research can be a show-stopper. Since we don't want people to get stuck in their project there are paid support options:

* Johannes Hübner offers [https://openinverter.org/shop/index.php?route=product/product&path=60&product_id=65 support time by the hour] for BMS and CCS boards (no longer inverters!). Most commonly you will [https://openinverter.org/forum/viewtopic.php?t=937 grant remote access] to your board and speak via video chat to diagnose and solve problems
* Janosch Oppermann offers [http://foxev.io/openinverter/?ref=oiw support time by the hour]. Any questions/projects/troubleshooting welcome.

Errors

2025-05-16T04:58:23Z

Johu: Added new codes

The inverter software continously checks it's inputs for implausibilities and error conditions. The last 4 errors are stored in RAM. They can be displayed by typing "errors" or pressing the according button on the web interface.

== Error Codes ==
{| class="wikitable"
|'''#'''
|'''Message'''
|'''Reaction'''
|'''Description'''
|-
|1
|OVERCURRENT
|STOP
|HW overcurrent limit was hit
|-
|2
|THROTTLE1
|DISPLAY
|Throttle input 1 went out of range → 0 throttle assumed
|-
|3
|THROTTLE2
|DISPLAY
|Throttle input 2 went out of range
|-
|4
|CANTIMEOUT
|DISPLAY
|No IO CAN messages for 500ms
|-
|5
|EMCYSTOP
|STOP
|Emcystop pin went low
|-
|6
|MPROT
|STOP
|Mprot pin went low
|-
|7
|DESAT
|STOP
|Desat pin went low
|-
|8
|OVERVOLTAGE
|STOP
|udcmax was hit
|-
|9
|ENCODER
|DISPLAY
|Implausible pulses on encoder (only single mode)
|-
|10
|PRECHARGE
|STOP
|udcsw was not reached after 5s of precharging
|-
|11
|TMPHSMAX
|DERATE
|Derating because maximum heatsink temperature of 85°C reached
|-
|12
|CURRENTLIMIT
|DERATE
|Derating because iacmax limit was approached
|-
|13
|PWMSTUCK
|DISPLAY
|For pwmpol=0 all 6 PWM pins are expected low on start, and all high for pwmpol=1. Otherwise this error is generated
|-
|14
|HICUROFS1/2
|DISPLAY
|Current channel 1 or 2, respectively, is below 1.23 or above 2.06V when no current is flowing. Check wiring and voltage dividers
|-
|15
|HICUROFS2
|DISPLAY
|
|-
|16
|HIRESOFS
|DISPLAY
|Resolver feedback voltage is below 1.23 or above 2.06V when idle. Check wiring.
|-
|17
|LORESAMP
|DISPLAY
|Resolver feedback voltage swing is below 0.8V peak-to-peak. Check wiring or raise amplitude of excitation.
|-
|18
|TMPMMAX
|DERATE
|Derating because maximum motor temperature reached
|-
|19
|CANCRC
|STOP
|Repeated CRC error in CAN control message detected
|-
|20
|CANCOUNTER
|STOP
|Repeated sequencing error in CAN control message detected
|}
[[Category:FAQ]] [[Category:Troubleshoot]] [[Category:Errors]]
[[Category:OpenInverter]]

Foccci

2025-02-06T21:19:16Z

Johu: /* External connector ("Deutsch Header") */

Disclaimer: This Page is still work in progress! Any information written here is a draft only and should be handled as such. Contributions more then welcome. If you have questions please ask them in the discussion section of the page or in the OpenInvert Forum.
[[File:Foccci pinout.svg|thumb|Foccci (v4.5) pinout]]

[[File:Foccci 4.5b pinout.png|thumb|Foccci 4.5b / 5 / 5.1 pinout]]
This page is about FOCCCI. FOCCCI is an open source CCS Charge Interface started by Uhi and developed by the OpenInverter Community.

Foccci is the hardware part, and on it runs the software Clara.

Here you will find documentation on the Hardware (and Clara software), where to get it (or how to build it yourself), News regarding the development and many more great things.

Video presentation: https://www.youtube.com/watch?v=Bc7lXPGtLXY

[https://openinverter.org/shop/index.php?route=product/product&product_id=79 Foccci for sale on OpenInverter Shop]

[https://github.com/uhi22/foccci Foccci on Github.]

[https://github.com/uhi22/ccs32clara Clara on Github.]

[https://openinverter.org/forum/viewtopic.php?t=3727 Foccci in the OpenInverter Forum.]

== Pin description ==

=== External connector ("Deutsch Header") ===
Starting version 4.5b the pins were reshuffled to allow one wiring loom going to the charge port and one to the car side. Changed pins are '''bold'''. [[Connector Part Numbers#FOCCCI|Connector part numbers]] are on a separate page.
{| class="wikitable"
|+
!Short name
!Pin up to version 4.5a
!Pin for version 4.5b, 5, 5.1
!Description
|-
|TEMP1
|A1
|A1
|Power pin temperature sensor. It is pulled up to 3.3V with 10k and the sensor must pull down to GND. Sensor characteristics are configurable in software
|-
|TEMP2
|A2
|A2
|As above
|-
|TEMP3
|A3
|A3
|As Above
|-
|LOCKFB
|A4
|A4
|Feedback signal from connector lock. Pulled up to 3.3V with 10k, so feedback must pull down to GND. Thresholds configurable in software
|-
|IN_U_HV
|A5
|'''B10'''
|Analog input 0 to 5V, with pull-down-resistor. Can be used to measure the charge port voltage, using a converter board, e.g. the "muehlpower board"
|-
|CP
|A6
|A6
|CP (Control Pilot) pin from charge port
|-
|SW2(_LS)
|A7
|'''B4'''
|Output for charge port contactor 2. Low side switch until Foccci 4.4, high side switch starting 4.5
Controls one of the contactors to make the connection between the HV battery and the vehicle inlet.

The output can drive inductive load without additional circuits. It will clamp the turn-off voltage to ~40V. The driver has protection against shortcut and thermal overload.

The output can be configured to be just digital on/off, and can also be configured to use PWM. BUT: In Foccci versions 4.2 and 4.3 (maybe more) the output driver is only capable of slow PWM, which is hearable and may cause trouble with the contactors. So it is recommended to NOT use the PWM feature, and instead use contactors which do not require economizing or use external economizers. In case you want the PWM nevertheless, you need a external freewheeling diode.

Starting Foccci 4.5 PWM is working as intended at 18 kHz. It is a high side output starting v4.5, so the other side of the contactor must be connected to GND. Before v4.5 it is a low side output so the other side must be connected to 12V
|-
|LOCK_MOT2
|A8
|A8
|Motor driver output for charge port lock servo
|-
|LOCK_MOT1
|A9
|A9
|
|-
|PP
|A10
|'''A5'''
|PP (Proximity Pilot) pin from charge port. If you want Foccci to wake up when an unpowered charge cord is plugged in you must close JP3 to pin 1 (towards R7). There mustn't be a pull-down resistor in the charge port in this case as that would permanently keep Foccci awake
|-
|5V
|A11
|'''B11'''
|5V, 500mA e.g. for supplying voltage sense board. This is an OUTPUT of Foccci. Do not apply an external voltage source here. Foccci contains a step-down-converter from the 12V supply to this 5V output.
|-
|GND
|A12
|'''B12'''
|
|-
|CANH
|B1
|B1
|CAN communication
|-
|CANL
|B2
|B2
|
|-
|n.c.
|B3
|
|Unused pins were assigned GND in 4.5b
|-
|n.c.
|B4
|
|
|-
|GND
|B5
|B5, '''B3'''
|
|-
|SW1(_LS)
|B6
|B6
|Output for the charge port contactor 1. See description of SW2(_LS).
|-
|WAKEUP
|B7
|B7
|Wakeup bus. Momentarily (or constantly) applying 12V wakes up the board. In the other direction Foccci can wake up (or supply with up to 1A) other devices via a 12V high side switch
|-
|12V
|B8
|B8
|Supply voltage, always on. 9 to 24V are fine.
|-
|LED_RED
|B9
|'''A12'''
|Status LEDs
|-
|LED_GREEN
|B10
|'''A11'''
|
|-
|LED_BLUE
|B11
|'''A10'''
|
|-
|BUTTON
|B12
|'''A7'''
|Wakes up Foccci or stops an ongoing charging session
|}

=== Internal connectors ===
{| class="wikitable"
|+
!short name
!description
|-
|UART TX
|Provides logging information, 921600 Baud. See also https://github.com/uhi22/ccs32clara/blob/main/doc/clara_user_manual.md#serial-logging
|-
|UART RX
|Not used
|-
|SWCLK
|for flashing with STLINK
|-
|SWDIO
|for flashing with STLINK
|}
== Integrating Foccci with your car/BMS==
[[File:Foccci CCS2.png|thumb|Foccci with (Orion) BMS]]
Depending on your use case Foccci has to communicate with one or more components in your car. All in-car communication happens via a single CAN bus.
===Basic communication considerations ===
Foccci can be configured to run at various baud rates and defaults to 500k. The Wifi interface mentioned below is hard coded to 500k. So when configuring a different baud rate you will loose communication with the Wifi interface. This might be fixed in the future by allowing variable baud rates for the wifi interface. Bottom line: '''keep it at 500k.'''

Apart from that it is mostly sufficient if Foccci can communicate, or more precisely, listen to the BMS. Foccci uses the flexible [[CAN communication|CAN mapping]] known from other OI firmware. There are 5 key parameters that need to be received via CAN:
*'''ChargeCurrent''': this is the single most important item. It is directly relayed to the charger and specifies the current the battery can accept at the given moment. This depends on battery voltage, temperature and other things to be determined by the BMS. ''Foccci itself does no battery monitoring of any kind, it is completely down to the BMS to specify a safe charge current'''''.''' When this value is not updated for more than 2 seconds the charging session is terminated.
* '''BatteryVoltage''': this item is important for precharging the CCS chargers output to the momentary battery voltage. Most BMSes output the total pack voltage in a CAN message
* '''TargetVoltage''': In theory this is the maximum voltage you want the battery to be charged to. In practise the maximum battery voltage MUST be governed by specifying an appropriate ChargeCurrent. More importantly many chargers cut back charge power when ''approaching'' this voltage resulting in poor charging performance towards the top end. So in practise you want to set this to a voltage about 10V above charge end voltage of your battery.
*'''soc''': This is purely informative as far as we know. It displays the batteries state of charge on the chargers display
*'''enable''': this is optional as it defaults to always enabled. It can be used to completely terminate the charging session by setting it to 0.
===Using Foccci as a charge coordinator===
This topic is still work in progress. The CCS connector, as its name suggests, combines both AC and DC charging in one socket. As long as we use the socket only for DC charging it is very easy to wire up. But once we also use the AC functionality we have to spend further thought on this.

The two pins PP and CP communicate information about the cable limit and the momentary current limit of the AC outlet. PP is a simple resistor between PE and PP that is evaluated by putting a test current onto it. This concludes that this signal can only be used by one device. CP is a bit more complex. When plugging in it communicates with a 2k7 resistor to PE that the cable is now connected to a car. From this simple fact we can again conclude that CP is a peer-to-peer signal only. Once the car is ready to charge it switches another 1k3 resistor in parallel to the 2k7 resistor. Only then the AC voltage is switched to the power pins. Lastly, the AC outlet encodes the momentary current limit in a PWM duty cycle.

Foccci does all the evaluation and makes the result available as spot values that can in turn be mapped to CAN:
*EvseAcCurrentLimit
*CableCurrentLimit
To activate the 1k3 resistor aka activating the AC outlet we map AcObcState. It must be set to 2 for activation.

Some chargers want to evaluate the CP (and perhaps PP) signal themselves. This issue can be solved with a change over switch that disconnects Foccci from CP while AC charging. Alternatively the CP signal can be spoofed and the charge current controlled by CAN to satisfy the limits of the AC outlet (EVSE).
== Wakeup ==
For charging it is particularly interesting to wake up Foccci itself and necessary subsystems <ref>https://openinverter.org/forum/viewtopic.php?p=66547#p66547</ref> when plugging in a charge cord. To allow for this, Foccci has various wakeup sources and also can wake up other devices. For wakeup to work, Foccci must be permanently supplied with 12V (it will draw no current when asleep). '''Hardware version V4.5 and above required for wakeup.'''

Here are the sources:

# Wakeup pin - bidirectional - level triggered (12V)
# Button - level triggered (GND)
# PP - optional via solder bridge - level triggered
# CP - Edge triggered

So the first 3 inputs will force the Foccci on. It can't turn itself off as long as that wakeup source is active. The last input will only trigger when transitioning from invalid to valid PWM and then Foccci can decide how long to stay awake. All modes always work regardless of software settings - except PP wakeup which can be turned off in hardware (JP3).

The wakeup output on the other hand is software-defined. Foccci offers the following options

# '''Level''' - as long as the Foccci doesn't decide to turn off, we keep Wakeup on as well
# '''Pulse''' - When Foccci boots generate a 1s wakeup pulse
# '''LevelOnValidCp''' - As long as CP is pulsing we keep wakeup on
# '''PulseOnValidCp''' - Whenever we transition from non-pulsing to pulsing CP we generate a 1s pulse
# '''LevelOnValidPp''' - As long as PP is valid keep wakeup on

The output can supply about 1A and 12V. When running loads larger than that (e.g. a pump) use a relay to amplify the current capability.

It depends on your vehicle architecture how you organize the wakeup. Here are some examples:

=== Basic wakeup ===
wakeup via PP enabled, WakeupPinFunc=LevelOnValidPp

# Foccci turns on as soon as even a non-powered charging cable is plugged in
# Wakeup signal is turned on
# BMS, VCU etc. is turned on (directly powered from wakeup as it can supply about 1A)
# VCU can detect via the level of the wakeup signal that a cable is plugged in and inhibit drive
# When charging cable is unplugged (as in PP lost), Wakeup is turned off and the VCU can allow driving
# If we wanted to report e.g. welded charge port relays Foccci would have to keep itself running until the car is started in drive mode again. Then something can be displayed on the instrument cluster. Of course this will time out eventually. Should be fine as you at least have to pull away from the rapid charger after charging.
# When charging is paused all ECUs stay on and consume 12V power (or HV power via DC/DC)

=== Advanced Wakeup ===
wakeup via PP disabled, WakeupPinFunc=PulseOnValidCp. Here we have a bidirectional wakeup bus. Any ECU connected to it can send or receive wakeup events and the individual ECUs can decide whether they are needed for a particular task or not.

# Foccci turns on as soon as CP PWM starts. So either a cable is being plugged in or is already plugged in and now wants to charge
# It then turns on the wakeup output for 1s and wakes up all other ECUs
# The relevant ECUs will detect that we want to charge and stay on, the other ones turn off
# If we turn on ignition the VCU is already on and in charge mode and can inhibit drive
# If charging is paused (i.e. cable plugged in but no CP PWM) and we turn on ignition the VCU wakes up the Foccci and queries PP status. If something is plugged in drive is inhbited
# If Foccci detects an error e.g. welded relays, it stores that error to flash. When woken up by the VCU it report its non-zero error code
# When charging is paused, ALL ECUs can turn off and no 12V power is consumed. When CP comes back, the cycle restarts

The second approach is more versatile but it also means all devices need to support this method.

So I think there can be an intermediate approach:

=== Semi-advanced wakeup ===
Here we only have a wakeup bus between VCU and Foccci. All other devices are powered up by other means, like VCU controlled relays. Wakeup via PP is disabled, WakeupPinFunc=LevelOnValidCp

# Foccci turns on as soon as CP PWM starts. So either a cable is being plugged in or is already plugged in and now wants to charge
# It then turns on the wakeup output this waking up the VCU
# The VCU determines via CAN message from Foccci whether we want to AC or DC charge and turns on needed components. Components needed in both cases that have low power consumption (e.g. BMS) can also be driven from the wakeup signal directly
# If we turn on ignition the VCU is already on and in charge mode and can inhibit drive
# If charging is paused (i.e. cable plugged in but no CP PWM) and we turn on ignition the VCU wakes up the Foccci and queries PP status. If something is plugged in drive is inhbited
# If Foccci detects an error e.g. welded relays, it stores that error to flash. When woken up by the VCU it report its non-zero error code
# When charging is paused, ALL ECUs will turn off and no 12V power is consumed. When CP comes back, the cycle restarts

== Configuring Foccci via CAN ==
Foccci exposes only one single CAN interface for vehicle communication and initial configuration. So we need a CAN counterpart to talk to it.

There are two main approaches to this: a) use a command line tool <ref>OIC https://openinverter.org/forum/viewtopic.php?t=2907</ref> or b) use an ESP based CAN module <ref>ESP32 CAN Web Interface https://openinverter.org/shop/index.php?route=product/product&path=59&product_id=78</ref>

Both ways require knowing Focccis so called Node Id (similar to an IP address on a local network). By default this is 22. You can enter this node id on the bottom left navigation bar.
== Parameters==
{| class="wikitable"
|'''Name'''
|'''Unit'''
| '''Min'''
|'''Max'''
|'''Default'''
| '''Description'''
|-
| colspan="6" |'''Hardware Config'''
|-
|UdcDivider
|dig/V
|0
|100
|10
|Division factor from ADC digits to V of external voltage measurement board.
In other words: The UdcDivider is the configuration parameter which defines the scaling of the physical inlet voltage measurement circuit. That's why it is only relevant if a physical inlet voltage measurement circuit is present, and if the parameter InletVtgSrc is 1, means the Foccci will measure the inlet voltage with the analog input. CAN mapping makes no sense for the UdcDivider, because it is a fix value. It is the ratio between the voltage on the inlet and the digital value on the AD converter.
|-
|EconomizerDuty
|%
| 0
|100
| 100
|Contactor economizer duty cycle. Contactors are always turned on with 12V for 1s then drop to this value. Set to 100% if your contactor has a built-in economizer
|-
|InletVtgSrc
|
|0
|2
| 0
|Inlet Voltage Source. There are three option where Foccci gets the CCS inlet voltage from:
0 - Charger output voltage (EVSEPresentVoltage) is considered equal to charge port inlet voltage 1 - Analog input U_IN_HV is used for measuring charge port inlet voltage

2 - Charge port inlet voltage is provided via CAN - don't forget to map something to InletVoltage

The InletVoltage is important for precharging, while the contactors are still open. The car (Foccci) will close the contactors, if the inlet voltage is near to the battery voltage. After closing the contactors, it is the battery voltage (besides some cable losses), and out of interest. The most straight forward solution to measure the inlet voltage is to rely on what the charging station tells us. It reports the voltage on the CCS plug in EVSEPresentVoltage. With configuring InletVtgSrc=0 we tell Foccci to use the EVSEPresentVoltage. In this case, neither an analog inlet voltage measuring circuit nor a separate gadget which provides the inlet voltage via CAN is necessary. For most users this will be fine (even OEM cars use this approach).
|-
|LockDuty
|%
| -100
| 100
|30
|H-bridge duty cycle for operating the lock. Use negative value if lock polarity is swapped
|-
| LockRunTime
|ms
|0
|10000
|1000
|Timeout for lock operation
|-
|LockClosedThresh
| dig
| 0
|4095
|0
| Lock feedback value for closed
|-
|LockOpenThresh
| dig
| 0
|4095
| 0
| Lock feedback value for open - if equal to lockclosethr no feedback is assumed and lock is operated timed
|-
| ppvariant
|
|0
|9
|0
|Various circuit variations exist for PP resistor measurement.
"0" is for the variant with 1k pull-up to 3.3V, like old the old Foccci 4.1
"1" is for the variant with 330 ohm pull-up to 5V and 3k pull-down.
"2" is for the variant with 330 ohm pull-up to 5V and NO pull-down.
Foccci 4.5 ususally has NO pulldown, except the related solder jumper was closed.
|-
|WakeupPinFunc
|
| 0
|4
|0
| Configure what the wakeup pin does. See [[Foccci#Wakeup|Wakeup]]
|-
| colspan="6" |'''Communication'''
|-
|NodeId
|
|1
|63
|22
|CANOpen node id for SDO requests
|-
|CanSpeed
|
|0
| 4
|2
|Baud rate of CAN interface 0=125k, 1=250k, 2=500k, 3=800k, 4=1M - '''when configuring this != 500k you have to change it also for your ESP web interface!'''
|-
| colspan="6" |'''Charge Parameters'''
|-
|MaxPower
|kW
|0
|1000
| 100
|Absolute maximum charge power. Foccci will announce this value in the ChargeParameterDiscoveryRequest message in the element EVMaximumPowerLimit. The charger may or may not respect this limitation.
|-
|MaxVoltage
|V
|0
|1000
|410
|Over voltage threshold. Always set about 10-20V higher then desired battery full voltage. Foccci will announce this value in the ChargeParameterDiscoveryRequest message to the charger, in the element EVMaximumVoltageLimit. The charger may or may not respect this limitation. Some chargers shut down, if this limit is reached. That's why it is recommended to set it some volts higher than the voltage which is used during normal charging.
|-
|MaxCurrent
|A
|0
|500
|125
| Absolute maximum charge current. Foccci will announce this value in the ChargeParameterDiscoveryRequest, in the element EVMaximumCurrentLimit. The charger may or may not respect this limitation.
|-
|MaxAllowedPinTemperature
|°C
|0
|120
|70
|Temperature of the CCS inlet which leads to fully reduced charge current. If the maximum of temp1, temp2, temp3 reaches this value, the charge current is cut down. Before reaching this limit, the charge current decreases linearily. If the temperature still rises and reaches 10 Kelvin more than parametrized, the charge session will be terminated.
For information purpose, the current limit caused by the temperature is visible in the spot value TempLimitedCurrent. If the limitation is effective, which means, that the BMS would have requested a higher current than the limitation, the spot value LimitationReason shows "InletHot".
In case of massive overheat (10K more than parametrized), the spotvalue StopReason will show "InletOverheat".
|-
|TargetVoltage
|V
|0
|1000
| 0
|Charge target voltage (volatile)
|-
|ChargeCurrent
|A
|0
|500
|0
| Instantaneous current setpoint (volatile) - must be written at least once per second to prevent [[Foccci#Errors|CANTIMEOUT]]
|-
|soc
|%
|0
|100
|0
|Battery SoC for display on charger (volatile)
|-
|BatteryVoltage
|V
|0
| 1000
|0
| Present battery voltage for precharge state (volatile)
|-
|enable
|
|0
|1
|1
|When 0 charging is stopped/not started (volatile) - must be written at least once per second to prevent [[Foccci#Errors|CANTIMEOUT]]
|-
|AcObcState
|
|0
|15
|0
|Feedback from OBC
|-
| colspan="6" |'''Testing'''
|-
|DemoVoltage
|V
|0
|500
|0
|Voltage for light bulb demo. To use the board without CAN, to get an constant voltage. Is ignored as long democtrl is not STANDALONE. Only values between 150V and 250V are accepted, others are treated as zero.
|-
|DemoControl
|
|0
|511
|0
|Enables the standalone demo mode if value is set to STANDALONE. In this mode, no CAN is required and the target voltages for precharge and charging loop are taken from demovtg.
|-
|ActuatorTest
|
|0
|7
|0
|Tests various outputs
|-
|logging
|
|0
|2047
|
|Selects which modules log to the serial console
|}
==Spot values ==
{| class="wikitable"
|+
!Name
!Unit
!Description
|-
|opmode
|
|State of the CCS state machine
|-
|version
|
|
|-
|lasterr
|
|Last detected error
|-
|EvseVoltage
|V
|Outlet voltage reported by EVSE
|-
|EvseCurrent
|A
|Outlet current reported by EVSE
|-
|TempLimitedCurrent
|A
|Current limit calculated based on the inlet temperature
|-
|EVTargetCurrent
|A
|Current demand which is communicated to the DC charging station. Is the minimum of TempLimitedCurrent and ChargeCurrent.
|-
|LimitationReason
|
|Shows the reason why charge power is limited
|-
|InletVoltage
|V
|Charge port voltage
|-
|EvseMaxCurrent
|A
|Maximum current the EVSE can deliver
|-
|EvseMaxVoltage
|V
|Maximum voltage the EVSE can deliver
|-
|ControlPilotDuty
|%
|The PWM ratio of the CP line. This is normally 5% for DC chargers, and between 10% and 90% for analog AC chargers.
Typical values are explained here: [https://de.wikipedia.org/wiki/IEC_62196_Typ_2 IEC 62196 Typ 2 – Wikipedia]
|-
|temp1, 2, 3
|°C
|Temperatures of the temperature sensors. Requires correct calibration values depending on the used NTC types.
|-
|MaxTemp
|°C
|Maximum of the above
|-
|ContactorDuty
|%
|Duty cycle of charge port contactor driver
|-
|AdcLockFeedback
|digit
|Feedback value from charge port lock
|-
|AdcProximityPilot
|digit
|Analog value of the PP line. This is the raw value of the analog-to-digital-converter in range 0 to 4095.
|-
|ResistanceProximityPilot
|ohm
|Measured resistance between PP line and ground. Requires correct setting of the parameter ppvariant.
|-
|CableCurrentLimit
|A
|Based on the PP resistance. The current limit of the charging cable for AC charging.
|-
|EvseCurrentLimit
|A
|Based on the CP PWM. The current limit of the charging station for AC charging.
|-
|AdcHwVariant
|digit
|raw AD value of the hardware variant coding input. Used to detect which variant of Foccci the software runs on.
|-
|AdcIpropi
|digit
|raw AD value of the current sensor for the charge port lock motor driver.
|-
|LockState
|
|State of charge port lock
|-
|StopReason
|
|shows the reason why the charging session stopped
|-
|checkpoint
|
|shows the progress of the charging session in detail. Explanation here: https://github.com/uhi22/pyPLC?tab=readme-ov-file#example-flow
|-
|CanWatchdog
|100 ms
|Time since last ChargeCurrent update. When it reaches 30 (3s) the charge session is stopped
|-
|cpuload
|
|
|}
==Errors==
The spot value "lasterr" displays the last detected error that lead to a cancellation of charging or to not starting in the first place
{| class="wikitable"
|+
!Error
!Description
|-
|CANTIMEOUT
|The ChargeCurrent or enable hasn't been updated via CAN for more than 2s
|-
|PLCTIMEOUT
|PLC communication with charger timed out
|-
|PRECTIMEOUT
|Precharging the EVSE output to specified voltage timed out or battery voltage is below minimum EVSE output voltage
|-
|LOCKTIMEOUT
|The connector lock didn't reach the desired position in time
|-
|EVSEFAULT
|The EVSE reported an error and stopped
|-
|RELAYWELDED
|A welded charge port relay was detected
|}
== Making Foccci talk CHAdeMO on the CAN side ==
A pretty straightforward way to integrate CCS charging into your vehicle is to use the existing CHAdeMO (let's call it CDM from here on) CAN messaging. CDM has pretty much all data items we need to initiate a CCS charging session, so rather than defining a new set of messages we might as well adopt it. For example, Orion BMS or Zombieverter VCU natively support CHAdeMO anyway.[[File:Can mapping chademo.png|thumb|Screenshot of CAN mapping to interface Foccci CCS with CHAdeMO]]Let's go over the items in the screenshot one by one. Note that the IDs are decimal! (256=0x100, 258=0x102, 264=0x108, 265=0x109)
*'''UdcDivider''' - Actually, here we just select some dummy item as the important bit is in the Offset field: the version. In this case I signal non-existent CDM version 10. This tells the CDM module in my car that it talks to Foccci. It then includes the battery voltage in some unused message bytes - see below.
*'''EvseVoltage''' - Transmits the charger's present output voltage back to the vehicle.
*'''EvseCurrent''' - Transmits the charger's present output current back to the vehicle.
*'''opmode''' - Observe the weird gain - this is forged to map Foccci state "CurrentDemand (13)" to CDM state "ConnectorLocked (4)". In my car's CDM module this is sufficient to initiate the charging progress. You may need to change it so that the ChargeEnable flag together with ConnectorLocked is forged (numerical value 5).
*'''EvseMaxVoltage''' - Transmits the EVSE's maximum output voltage back to the vehicle.
*'''EvseMaxCurrent''' - Transmits the EVSE's maximum output current back to the vehicle.
*'''BatteryVoltage''' - Transmits the present battery voltage to the EVSE. This is the special item that normally doesn't exist in CDM and that unfortunately will prevent you from using this solution with an OEM car in a safe manner. Of course, you could manually set this to some medium battery voltage like 360V, but if you arrive with a really low battery at, say, 300V this might weld your charge port contactors. You could also manually enter the battery voltage before each charging session.
*'''TargetVoltage''' - Transmits the charge end voltage to the EVSE.
*'''ChargeCurrent''' - By far the most important data item: the charge current request.
*'''soc''' - In CDM this isn't normally a percentage value but some encoded kWh value. In my car's CDM module I specify a full battery as "200" (no idea what this actually means in kWh) and thereby can just output the SoC in 0.5% steps.
*'''enable''' - The car's charge enable flag. When 0 will stop the CCS session.
As an additional safety measure you could connect CDM pin 4 (charge enable) to Foccci's button input (at least once we added an active low mode for it). It might also be worthwhile to connect pin 7 (connection check) to the PP input for drive away protection when CDM is plugged in but not charging (again, once we have actually implemented this).

Let's list the CHAdeMO pin mapping one by one as well:
*Pin 1 - GND
*Pin 2 (12V, charger start/stop) - 12V (I take it from cigarette lighter)
*Pin 4 (charging enable) - Foccci BUTTON
*Pin 5, 6 - Power pins, triple check correct polarity!
*Pin 7 (Connection check) - Foccci PP
*Pin 8, 9 (CAN) - Foccci CANL, CANH
*Pin 10 (charger start/stop 2) - Foccci SW1_LS
'''Attention:''' with this mapping the error flags are ignored, e.g. voltage or current mismatch.

==Making Foccci talk to boostech BMS==
The boostech BMS has a fixed CAN mapping. It doesn't expect any feedback from the CCS controller so we just keep the CHAdeMO mapping from above in case the info is needed elsewhere in the car.

The BMS sends out big endian messages hence why the length fields are negative. It does not send out a charge end voltage so we simply multiply the charge enable flag with the voltage we want. In the example 368V.
{| class="wikitable"
|+
!Item
!Direction
!ID
!Position
!Length
!Gain
!Offset
!Extended
!Remark
|-
|EvseMaxVoltage
|Transmit
|0x108 / 264
|8
|16
|1
|0
|no
|
|-
|EvseMaxCurrent
|Transmit
|0x108 / 264
|24
|8
|1
|0
|no
|
|-
|EvseVoltage
|Transmit
|0x109 / 265
|8
|16
|1
|0
|no
|
|-
|EvseCurrent
|Transmit
|0x109 / 265
|24
|8
|1
|0
|no
|
|-
|enable
|Receive
|0x310 / 784
|48
|1
|1
|0
|yes
|
|-
|BatteryVoltage
|Receive
|0x310 / 784
|15
| -16
|0.1
|0
|yes
|
|-
|soc
|Receive
|0x310 / 784
|47
| -16
|0.1
|0
|yes
|
|-
|TargetVoltage
|Receive
|0x310 / 784
|48
|1
|368
|0
|yes
|Put your desired TargetVoltage into gain
|-
|ChargeCurrent
|Receive
|0x313 / 787
|31
| -16
|0.097
|0
|yes
|This value is static, more below
|}
The boostech BMS '''lacks one critical feature''' for rapid charging: a dynamic charge limit. That means ChargeCurrent it always a fixed value that you program into the BMS. It will not cut back when cells are getting full, hot or cold. It can be somewhat mitigated by setting a sane target voltage (e.g. 4.1V x NumberOfCells). The rapid charger will then start to cut back charge current as this voltage is approached. Also by mapping the enable flag the BMS has the possibility to abort the charging session if one single cell voltage or module temperature rises above the safe threshold. In winter you will need to dial back your maximum charge current manually or heat you cells to avoid dendrites.

== Hardware detection ==
[[File:3.3v Addressing Voltage Divider.png|thumb]]
To allow software to reliably detect which version hardware it runs on, in HW version 4.1 a version indication resistor was added. As opposed to some other boards that run at 5.3V, the voltage here is 3.3V.
{| class="wikitable"
|+
!Variant
!R1
!R2
!voltage
!ADC
!-3%
!+3%
|-
| -
|47
|2,7
|0,179
|222
|216
|229
|-
| -
|47
|3,3
|0,217
|269
|261
|277
|-
| -
|47
|3,9
|0,253
|314
|304
|323
|-
| -
|47
|4,7
|0,300
|372
|361
|383
|-
| -
|47
|5,1
|0,323
|401
|389
|413
|-
| -
|47
|5,6
|0,351
|436
|423
|449
|-
| -
|47
|6,8
|0,417
|518
|502
|533
|-
| -
|47
|7,5
|0,454
|564
|547
|580
|-
|4.0 with economizer
|47
|8,2
|0,490
|608
|590
|627
|-
| -
|47
|9,1
|0,535
|664
|644
|684
|-
|4.2
|47
|10
|0,579
|718
|697
|740
|-
|4.3
|47
|12
|0,671
|833
|808
|858
|-
|4.4
|47
|15
|0,798
|991
|961
|1020
|-
|4.5 - 5.2
|47
|18
|0,914
|1134
|1100
|1168
|-
|
|47
|22
|1,052
|1306
|1266
|1345
|-
|
|47
|27
|1,204
|1494
|1449
|1539
|-
|
|47
|33
|1,361
|1689
|1639
|1740
|-
|
|47
|39
|1,497
|1857
|1801
|1913
|-
|
|47
|47
|1,650
|2048
|1986
|2109
|-
|
|47
|56
|1,794
|2226
|2160
|2293
|}
<references />

== Frequently Asked Questions ==

=== Q1: Does Foccci help me for AC charging with a Tesla OBC? ===
No. The Tesla OBC wants exclusive access to the control lines of the charge port. It handles the communications with the AC charging station by its own. This communication means providing the CP Résistance and measuring the CP PWM duty cycle. Foccci can also do this, but there cannot be two instances which do the same things. There is the other case: DC charging. For this, the Tesla OBC is not involved. The BMS needs to send the limits to Foccci, and Foccci performs the communication with the charging station.

=== Q2: Does Foccci create an 1kHz PWM, for controlling an onboard charger via the CP pin? ===
No. The CP pin of Foccci is the vehicle side of the CP line. This means, Foccci can *measure* the PWM duty cycle. It can *not* generate the PWM. If you need to generate a 1kHz PWM for your onboard charger, you could have a look to the Zombieverter.

=== Q3: What is the absolute minimum to start a DC charging session? ===
Foccci has the task, to tell the charging station three important values:

# The actual battery voltage, before the charging starts. The battery voltage is needed during the "precharge" phase, to give the charger the possibility to adjust the output voltage exactly to the battery voltage. This avoids large inrush currents when the contactors between the charger and the battery are closed. Large inrush current would damage the involved components, like contactors and capacitors.
# The target charge voltage. The voltage is chosen usually higher than the actual battery voltage, but lower than the maximum voltage rating of the battery. The charger will not deliver more than this voltage. The voltage limit is effective if the battery is nearly full, the current automatically drops slowly while charging in "constant voltage mode".
# The target charge current. This should be a value which is safe for the battery and cables, depending on temperature, SOC, whatever. The charger will use this demand as long as the target voltage is not reached. This is called "constant current mode".

Normally, these three values shall be provided via CAN bus from the battery management system (BMS). For experimentation, it is possible to set these values directly in the web interface, without the need of a BMS. This is called "DemoMode". Not recommended for real charging session, but ok to test the communication with the charger without having a battery installed.

Foccci needs to have the control, whether the DC contacts of the CCS socket shall be connected to the battery pack or not. For this purpose, two contactors are needed (one between CCS plus and battery plus, and one between CCS minus and battery minus). Foccci has two outputs, to control these two contactors.

Foccci needs a power supply, usually 12V, but everything between 9V and 16V is perfect. To have a permanent wakeup, you connect the 12V also to Focccis wakeup-pin.

That's it.

=== Q4: Besides the absolute minimum, what other features of Foccci are recommended to be used in a real-life scenario? ===

# Map the battery voltage, the target voltage and the target current to CAN signals, which are provided by your BMS. This gives the BMS the complete control about the charge parameters, to achieve a safe and fast charging.
# Connect three LEDs (red, green, blue), 12V, common ground, to see the progress of the communication.
# Connect a button (could be combined with the LEDs) which allows to stop the charging session.
# Connect the charge port lock motor. This allows Foccci to lock the charge plug, to avoid unintended disconnection.
# Connect up to 3 temperatur sensors, which are installed in the charge port or cable harness. This gives Foccci the chance to reduce the charge current in case of rising temperature, to avoid thermal damage of the components.

=== Q5: Can I use Foccci together with an onboard charger? ===
The main purpose of Foccci is DC charging. But since the CCS port is also intended to contain AC pins, Foccci supports the following features for AC charging:

- Foccci measures the PWM duty cycle on the control pilot (CP) pin, which the charging station provides. This is 5% in case of DC stations, and higher values on AC stations, depending on the allowed charge current. (There is also a special case, AC station with digital high-level communication. Foccci/Clara do not support this feature at the time of writing.) Foccci provides the measured PWM duty and the calculated AC current limit via CAN bus, so it can be used by an matching onboard charger, or an intermediate controller like Zombieverter, to control the AC charge current.

- In the other direction, Focccis status LEDs and CP status resistor can be controlled via CAN.

An example of usage of Foccci for AC charging is the integration with Zombieverter. An other possibility would be OBCs which can be configured or programmed to have full control via CAN bus.
=== Q5: I'm missing a certain feature of Foccci, could I add this by myself? ===
Sure. It's all open source. Feel free to experiment, discuss (in the forum or in github issues), and finally make a pull request.

=== Q6: Can I use Foccci also to build a charging station? ===
Not directly. Foccci is designed to play the car side of the CCS communication. For using it on the other side, some things need to be changed:

- generate the 1kHz PWM

- measure the CP resistance

- configure the PLC modem to be an EVSE modem instead a PEV modem

- and the biggest part: write the message handling of the high-level protocol for the charging station.

=== Q7: Does Foccci support Plug&Charge or AutoCharge? ===

# The "big" Plug&Charge according to ISO15118 is not supported. It would require a key infrastructure and a newer version of the EXI decoder software, which is not public available at the moment.
# AutoCharge (which is used by FastNed and EnBW) is supported. This uses the MAC address for identification. Focccis MAC address is calculated based on the serial number of the STM32 controller, and therefore each Foccci has (or at least is expected to have) a different MAC address. Alternatively you can patch the code to enter any MAC address you like.

=== Q8: How can I find out the version of Foccci/Clara, which I am running? ===
Using the web interface, show the spot values. At the top there is the software version of the Clara software. For example "0.42.76.B". The "B" means, it is a build from the github actions. And the 76 means, it is github action build number 76. If the version ends with the letter "R", you have a local build, and should contact the person who provided the binary file regarding the content.

Besides the software versions, there are also different hardware versions flying around. The early hardware versions could be (at least partially) identified by the spot value AdcHardwareVariant and HardwareVariant. Starting from Foccci version 4.5, this number is unchanged until (at least) versions 5, 5.1 and 5.2.

=== Q9: I want to try out a different software version. Where can I find it? ===
Each commit on github, or, in simple words, each change of the software, is automatically build into a binary file by a service called "Github actions". This is also called "Continuous Integration", or short "CI". All the generated binaries are available on the Github action page: https://github.com/uhi22/ccs32clara/actions Click on the headline of a certain run, to see the details, and scroll down to the "Artifacts" chapter. There you find the binary file (for flashing via the web interface) and the hex file (for flashing with the STLink tool).

Each run has a certain number (e.g. CI #90). After flashing a new version, the same number will be shown in the spot value "version" after the "0.42." and before the ".B".

=== Q10: ... Feel ... free ... to .... add ... more ... questions ... here. ===
Q11: ... Feel ... free ... to .... add ... more ... questions ... here.
[[Category:CCS]] [[Category:Rapid Charging]]
[[Category:Charger]]
[[Category:OpenInverter]]

16-cell BMS

2025-02-02T15:46:58Z

Johu: Enable signal

[[Category:BMS]]
[[Category:Battery]]
[[File:16-cell BMS.jpg|thumb|16-cell BMS]]
The goal of this BMS is to use mostly decade old components to create a 16 channel cell voltage meter. It uses a very accurate sigma/delta ADC for superb resolution. It can drain about 100mA from a cell or charge it with 50 mA via the DC/DC converter. The ability to both charge and discharge cells speeds up balancing despite the low balancing current.

When turned off it drains no current from the connected cells at all.

On the low voltage side it features two inputs for temperature sensors and one input for a 5V current sensor, differential or single ended.

It can be cascaded to be used with more than 16 cells and has an automatic addressing scheme to forgo the use of jumpers or DIP switches. All communication is done via CAN. Supply voltage is 12V with about 20 mA draw when not balancing.

The software is not yet finished, see forum for progress <ref>https://openinverter.org/forum/viewtopic.php?t=2338</ref>

The boards can be bought in the [https://openinverter.org/shop/index.php?route=product/product&product_id=74 shop].

== Pinout ==
The pinout is also written to the bottom silkscreen.

On the left side you see 17 inputs. The first one is connected to the negative pole (GND) of your (sub)pack, the subsequent ones to the positive poles of up to 16 cells. At least the lower two cell inputs must be connected. When cascading modules the positive-most input of module n is also the GND of module n+1, so must be spliced to connect to both.

On the top right is the vehicle interfacing or low voltage connector. From top to bottom it is low voltage GND, 12V, enable_in, enable_out, CANH, CANL. GND, 12V, CANH, CANL are connected to all modules in parallel whereas enable_out is chained to enable_in of the next module. The first enable_in must be connected to 12V whenever the BMS should become active, e.g. when charging or driving. The module with 12V on the enable_in auto-detects as "main" module, collects data from the subsequent modules and sends more high level CAN messages

On the bottom right is the temperature sensor and current sensor input. Top to bottom it is tsensor1+, tsensor1- (not silkscreened), tsensor2+ , tsensor2-(not silkscreened), 5V, CUR+, CUR-, GND. A single ended current sensor is just connected to CUR+.

Right now the current sensor is only supported on the main module.

=== Connector part numbers ===
{| class="wikitable"
|+
!Connector
!Manufacturer
!Header
!Counterpart
!Pins
|-
|LV connector (supply, CAN, enable)
|Phoenix Contact
|1803468
|1803617
|
|-
|Temperature and current sensors
|Molex
|640454-8
|1375820-8
|1445336-1
|-
|Cell taps
|Molex
|1-640456-7
|1-1375820-7
|1445336-1
|}

=== Power supply ===
The pins GND and 12V must be connected to a permanent 12V source in order to ensure correct operation. In other words, don't connect 12V for example to your cars ignition 12V that is interrupted whenever you stop the car.

The enable input of the first (main) module is connected to an interruptable 12V source. This input starts up the BMS. Enable can stay high but even a 1s pulse is enough to start the BMS, as it will then keep itself running as long as needed.

The BMS will then keep running as long as current flows through the battery. 2 hours after it has measured the last current flow it will shut down. It will use these 2 hours to let the cells settle to their open circuit voltage and will do balancing and [[16-cell BMS#State of Health calculation|SoH calculation]]. Afterwards it will shut itself down and consume only a few uA from your 12V source.

== Communication ==
All configuration, queries and firmware updates are done via the CAN bus. There is no independent web interface like known from e.g. the inverter. However there is a solution to connect an ESP32 via CAN and then have the known web interface <ref>https://openinverter.org/forum/viewtopic.php?p=56913#p56913</ref> or you can use Dave Fiddes "oic" tool for the command line<ref>https://openinverter.org/forum/viewtopic.php?t=2907</ref>. It is important to know that the main module has node-id 10 and the subsequent ones 10+i (i index of submodule, so 1st submodule has node-id 11). The base node id can be configured to start at something else than 10.

'''All info given here is preliminary and will likely change!'''

Apart from that the modules output periodic CAN messages depending on their role. The base address for cyclic messages defaults to 0x1F4 and can be changed by modifying pdobase on the main module. pdobase is ignored on the sub modules.

All modules output on ID 501 (0x1F5) + i
{| class="wikitable"
|+
!start
!length
!item
!description
|-
|0
|13
|umin
|minimum cell voltage of module i
|-
|16
|13
|umax
|maximum cell voltage of module i
|-
|30
|2
|counter
|counts from 0-3 (anti-freeze)
|-
|32
|13
|uavg
|average cell voltage of module i
|-
|48
|8
|tempmin
|Minimum temp +40 on module i
|-
|56
|8
|tempmax
|Maximum temp +40 on module i
|}
The main module does not output its local accumulated values but accumulated values over all modules.

In addition the main module outputs on id 500 (0x1F4)
{| class="wikitable"
!start
!length
!item
!description
|-
|0
|11
|chargelim
|maximum charge current in A
|-
|11
|11
|dischargelim
|maximum discharge current in A
|-
|22
|10
|soc
|Pack soc in 0.1%
|-
|32
|16
|idcavg
|Averaged current reading of last 1s in 0.1A - signed!
|-
|48
|10
|utotal
|Total pack voltage in V
|-
|62
|2
|counter
|counts from 0-3 (anti-freeze)
|}

=== Reading individual cell voltages ===
Cell voltages are only available via CAN SDO from the module that measures them. So voltages 1-16 must be queried from the first (main) module, 17-32 from the 2nd (1st submodule) and so on. With Dave Fiddes tool this translates to:<syntaxhighlight lang="bash">
oic -n 10 dumpall #dumps all values including cell voltages from 1st module
oic -n 11 dumpall #same for second module
oic -n 11 read u0 #Read first cell voltage of second module
</syntaxhighlight>For querying voltages say in your arduino sketch you'll need to acquire every voltage separately by sending and receiving SDO messages

<code>0x60A#0x40 idhigh 0x21 idlow 0 0 0 0</code>

idhigh and low are the bytes of the internal ID. The id of the first cell voltage is 2006 (0x7D6) so for querying the 1st cell voltage of the first module you send

<code>0x60A#0x40 0x07 0x21 0xD6 0 0 0 0</code>

And you will receive the reply

<code>0x58A#0x43 0x07 0x21 0xD6 0xD0 0xED 0x01 0</code>

0x0001EDD0 is the voltage value which decodes to mV x 32. So 0x1EDD0/32 = 3950.5 mV.

The next cell would be on 0x7D7 and the last on 0x7E5. The next 16 voltages are then queried from node id 0x60B.

=== Configuration Parameters ===
There is currently a limited set of parameters which will be extended as the software grows. This table always reflects the latest git commit. Check the page history for previous versions.

These are the parameters of v0.20.B
{| class="wikitable"
|+
!Name
!Unit
!Min
!Max
!Default
!Description
|-
| colspan="6" |'''BMS'''
|-
|gain
|uV/dig
|1
|1000
|586
|Scaling factor from ADC digits to mV
|-
|correction0
|ppm
| -10000
|10000
| -1250
|The first two and the last channel have slightly different topology and need their own correction factor
|-
|correction1
|ppm
| -10000
|10000
|1500
|
|-
|correction15
|ppm
| -10000
|10000
|1000
|
|-
|numchan
|
|1
|16
|16
|Number of cells connected to the module, power cycle required following saving parameters to update.
|-
|balmode
|
|0
|3
|0
|Balancing mode
0=No balancing
1=Only bump up low cells
2=Only dissipate high cells
3=Do both

By default balancing starts 60s after power up or in fact 60s after idcavg settled below 1A. You will see opmode changing to RunBalance
|-
|ubalance
|mV
|0
|4500
|4500
|Voltage above which top balancing is started
|-
|idlewait
|s
|0
|100000
|60
|Number of seconds to wait after stop of current flow to measure unloaded cell voltage und start balancing
|-
| colspan="6" |'''Battery Characteristics'''
|-
|dischargemax
|A
|1
|2047
|200
|Maximum discharge current
|-
|nomcap
|Ah
|0
|1000
|100
|Nominal capacity
|-
|icc1
|A
|1
|2000
|50
|Maximum charge current of empty battery
|-
|icc2
|A
|1
|2000
|30
|Maximum charge current of roughly half-charged battery
|-
|icc3
|A
|1
|2000
|20
|Maximum charge current of rather full battery
|-
|ucv1
|mV
|3000
|4500
|3900
|First constant voltage set point. Transition to next one when dropping below icc2
|-
|ucv2
|mV
|3000
|4500
|4000
|Second constant voltage set point. Transition to next one when dropping below icc3
|-
|ucellmax
|mV
|3000
|4500
|4200
|Third constant voltage set point and maximum cell voltage
|-
|ucellmin
|mV
|1000
|4500
|3300
|Minimum loaded cell voltage. Discharge limit is dropped to stay above this value
|-
|chargeXsoc
|%
|0
|100
|
|Percentage of charge current at soc X. In between two points charge current is interpolated
|-
|sohpreset
|%
|10
|100
|100
|This is the starting value for the state of health (SoH) calculation. The value is continuously updated by the BMS as SoH is estimated.
|-
| colspan="6" |'''Sensor Setup'''
|-
|idcgain
|dig/A
| -1000
|1000
|10
|Gain (or actually division factor) of current sensor
|-
|idcofs
|dig
| -4095
|4095
|0
|0A offset
|-
|idcmode
|
|0
|3
|0
|Current sensor mode 0=Off, 1=Single Ended ADC, 2=Differential ADC, 3=ISA current shunt
|-
|tempsns
|
| 0
|3
| 0
|Temperature sensor 0=None, 1=Channel1, 2=Channel3, 3=Both (set tempsns 0 in dashboard if dropdown not availble and value set as -1)
|-
|tempres
|Ohm
|10
|500000
|10000
|Nominal sensor resistance at 25°C
|-
|tempbeta
|
|1
|100000
|3900
|beta factor of Steinhart equation (see data sheet)
|-
| colspan="6" |'''Communication'''
|-
|pdobase
|
|0
|2047
|500
|base COB Id for cyclic messages. Main module uses pdobase and pdobase+1, 1st submodule uses pdobase+2 and so on
|-
|sdobase
|
|0
|63
|10
|base node ID for SDO queries. Main module uses sdobase, 1st submodule sdobase+1 and so on
|}

=== Spot values ===
All values that the BMS either measures or calculates are called spot values. While all modules show all spot values, some only make sense on the main module. The column "scope" denotes that. "M" means the value is only relevant on the main module, "S" means it's relevant on main and sub modules.
{| class="wikitable"
|+
!Name
!Unit
!Scope
!Description
|-
|version
|
|S
|Firmware version
|-
|opmode
|
|S
|State of operation

* BOOT - System starting
* GETADDR - Waiting for address assignment
* SETADDR - Setting address of next node
* REQINFO - Requesting info from sub modules
* RECVINFO - Receiving info
* INIT - Initialize BMS hardware
* SELFTEST - Running hardware self tests
* RUN - normal operation when current flows through battery
* IDLE - battery is idle, i.e. no current through it for a given time
* ERROR - selftests detected a critical error, operation halted
|-
|lasterr
|
|S
|Last detected error, see Errors
|-
|errchan
|
|S
|Cell tap channel causing the error, if applicable
|-
|modaddr
|
|S
|Address of module
|-
|modnum
|
|S
|Total number of modules
|-
|totalcells
|
|M
|Total number of cells
|-
|counter
|
|S
|Revolving counter 0-15 100 ms clock rate
|-
|uptime
|s
|S
|Time in s since power was applied to 12V pin
|-
|chargein
|As
|M
|Charge into the battery
|-
|chargeout
|As
|M
|Charge from the battery to load
|-
|soc
|%
|M
|State of charge, i.e. available charge in percent of fully charged battery
|-
|soh
|%
|M
|State of health, i.e. available total charge in percent of data sheet value when new
|-
|chargelim
|A
|M
|Current limit for charging the battery, see [[16-cell BMS#Charge Curve|Charge Curve]]
|-
|dischargelim
|A
|M
|Current limit for discharging, see [[16-cell BMS#Calculating current limits|Calculating current limits]]
|-
|idc
|A
|M
|Present current through battery, negative for current out of the battery, positive for current into the battery
|-
|idcavg
|A
|M
|Average current of the last second
|-
|power
|W
|M
|Average battery power of the last second
|-
|tempmin
|°C
|M
|Minimum temperature of all modules
|-
|tempmax
|°C
|M
|Maximum temperature of all modules
|-
|uavg
|mV
|M
|average cell voltage over entire pack
|-
|umin
|mV
|M
|Minimum cell voltage of entire pack
|-
|umax
|mV
|M
|Maximum cell voltage of entire pack
|-
|udelta
|mV
|M
|Difference between minimum and maximum cell voltage of entire pack
|-
|utotal
|mV
|M
|Sum of all cell voltages, i.e. pack voltage
|-
|uX
|mV
|S
|Present voltage of cell X of current module, see also [[16-cell BMS#Reading individual cell voltages|Reading individual cell voltages]]
|-
|uavgX, uminX, umaxX, tempminX, tempmaxX
|mV, °C
|M
|Average/Minimum/Maximum cell voltage and temperature of sub module X
|-
|uXcmd
|
|S
|State of balancer
|-
|cpuload
|%
|S
|Time the CPU spends actually doing something
|}

== Operation ==

=== State of Charge calculation ===
The State of Charge (SoC) lets you know how many percent of charge you battery still holds, in percent of a fully charged battery.

Determining SoC is split into two methods: determining the SoC from cell voltage and then tracking it as current flows in or out of the pack.

To estimate the SoC a 10-point lookup table is implemented that maps from cell voltage to SoC. The accuracy of this table is directly related to the accuracy of the estimation. You can edit the lookup table by changing the '''chargeXsoc''' parameters. The voltages you enter are open circuit voltages. These can only be obtained when there was no current flow through the battery for a certain amount of time, typically 10-30 minutes. This time is configured via the '''idlewait''' parameter.

So whenever the BMS has the chance to estimate the SoC it will do so. You can adjust '''idlewait''' to a low value to start estimating quickly. It means the first estimates will be off but it will become more accurate if the pack remains unloaded for longer time.

The subsequent tracking of SoC requires the BMS to know the current through the battery. Right now it supports analog current sensors (e.g. hall effect) with an operating voltage of 5V. Within this class it supports differential and single ended sensors, configurable via '''idcmode'''. The parameters '''idcofs''' and '''idcgain''' are used for calibration. When no current is flowing adjust '''idcofs''' until '''idcavg''' shows 0A. Then put a known current through the sensor and adjust '''idcgain''' until '''idcavg''' shows the correct current.

Lastly the BMS needs to know the energy or charge content of your battery in Ah. This is configured with the '''nomcap''' parameter and can be found in the data sheet.

=== State of Health calculation ===
The State of Health (SoH) lets you know how the remaining fully charged capacity, in percent of the data sheet value, i.e. when the battery was new. Batteries slowly degrade over time and usage cycles.

Whenever we do a SoC estimation as described above, we also update the SoH. If the estimated SoC has changed by more than 20% we compare the energy that we have taken out of the battery to the difference in SoC. If the two match, the SoH is 100%. If we have taken more energy from the battery then the difference in SoC suggests, SoH is above 100% (and you likely configured a wrong '''nomcap'''). Otherwise SoH is < 100%.

As this method comes with certain inaccuracies we only change the long term SoH slowly, i.e. every estimate is slowly averaged onto the long term SoH. This should balance out inaccuracies.

The spot value '''soh''' shows the current long term SoH. The value is also reflected onto '''sohpreset''', a saveable parameter. Whenever you need to interrupt the BMSes power supply you should go should save parameters so that next time it starts up with the correct long term SoH.

=== Calculating current limits ===
Limiting charge and discharge current are the only means of this BMS to protect the battery. It has no means to turn off the current flow by itself but instead relies on the connected components to obey the calculated current limits that are sent out via CAN. The current limits are calculated in a number of steps.

==== Charge Curve ====
The initial approach was to assign a certain charge current to points in the SoC curve. This method can be skewed if the SoC calculation is off for some reason. The new method deploys 3 CC/CV regulators. This was copied from oberving VWs charge curve of the MEB cars. The first regulator has the highest charge current and aims for a voltage typically around 3.9V for many NMC chemistries. When current drops below the CC value of the second regulator then that one is used, aiming for a higher voltage of typically 4V. And finally the 3rd regulator takes over aiming for the charge end voltage of typically 4.2V. When setting all 3 to the same values a simple CC/CV curve is generated.

==== Voltage limits ====
Voltage limits are enforced via a P-regulator. I.e. as we approach the upper or lower voltage limit current is cut back to stay away from the limits until it reaches 0A. The upper and lower limit is configurable

==== Temperature limits ====
High temperature will cut back both charge and discharge current whereas low temperature will only cut back charge current. These limits only work when you've set up your temperature sensors correctly. Please check the readings against a reference before relying on it.

Charge current has a proportional, multi-step temperature derating, i.e. the charge curve defined by iccX and ucvX is scaled with a derating factor the lower the temperature or when the maximum temperature is approached

* Below '''-20°C''' no charging is possible
* Between '''-20°C and 0°C''' charging with 0-30% of the charge curve is allowed
* Between '''0°C and 25°C''' charging with 30% to 100% of the charge curve is allowed
* Between '''43°C and 50°C''' charging with 100% to 0% of the charge curve is allowed, i.e. '''above 50°C''' charging is no longer allowed.

Discharging is not limited at low temperatures as high discharge currents at low temperatures are not known to cause damage. As the battery heats up discharge current is limited, starting at '''46°C''' until discharging is no longer allowed when reaching '''53°C'''.

==== Energy limits ====
Not enforced yet. Some OEM BMSes cut back charge current after a certain amount of energy has been put into the battery. E.g. When starting charge at 50% charge rate will end up higher at 70% than if we start charging at 10%.

== Calibration ==
As every instrument the voltage measurement needs to be calibrated to cancel out tolerances in the involved components. There are 4 parameters for calibration.

* '''gain:''' The translation ration between the ADC digits and mV. This applies to all channels
* '''correction0, 1 and 15''': This allows special tuning of said 3 channels because they use a slightly different current path and thus need a small gain correction

=== Calibration procedure ===
First we determine the general gain. Pick any of the voltages between u2 and u14 which share a common gain factor. Use a good multimeter to measure the physical voltage of your reference channel. Now tune the '''gain''' parameter until your multimeter and the BMS voltage read the same value +-0.5mV. Now all channels from 2-14 should read correctly.

Then for channels 0, 1 and 15 also measure the physical voltage input and tune the respective '''correctionX''' parameter until multimeter and BMS report the same voltage. The correction factors can be negative if a channels reads too high.

Save your parameters to flash to make the calibration permanent.

== Flashing firmware ==
If you have sourced the BMS boards from an alternative source then you will need to flash the bootloader and firmware onto the BMS. This is a relatively straightforward process once understood but took me a while to get it to work.

Firstly you will need an STLink dongle, I used this one <ref>https://www.amazon.co.uk/dp/B07QBLNDPM?psc=1</ref> but I believe any will do.

I used STM32CubeProgrammer <ref>https://www.st.com/en/development-tools/stm32cubeprog.html</ref> on Linux to flash my board and also (prior to flashing) upgrade the STLinkdongle to the latest firmware (might not be necessary but felt it was wise to do so).

Once you've got STM32Cubeprogrammer installed you're probably best erasing the STM32 Chip to ensure you're starting from a clean board. Navigate to the "Erasing & Programming" tab on the left and connect to your STlink dongle (if you havent already). Once connected, (you can also update the firmware on the dongle at this point on the "Memory & File Editing" tab), connect the dongle to the BMS board via the VDCG pins...

(V = Voltage 3.3V, D = SWDIO, C = SWCLK, G = Gnd)

and perform a "full chip erase".

Once thats complete head over to Github to download the Bootloader <ref>https://github.com/jsphuebner/stm32-CANBootloader/releases</ref> and download the hex file (you may need to be logged in to download the files).

Once downloaded, in STM32CubeProgrammer, navigate to the "Memory & File Editing" tab and open the hex file you just downloaded, once opened you can use the "Download" button to flash the bootloader to your BMS board.

You can now repeat the above process of opening the hex file and "downloading" to the BMS board for the main BMS firmware which is available from the BMS Github repository <ref>https://github.com/jsphuebner/FlyingAdcBms/actions</ref> .

Once all that is done, you can move onto the Web interface. You'll need the "Can Backend" version of the ESP32 Web Interface available here <ref>https://github.com/jsphuebner/esp32-web-interface/tree/can-backend</ref> (click the green code button and download zip)

Once downloaded download Arduino IDE 1.8.19 (you'll need this version, nothing beyond version 2 as this does not support SPIFFS flashing as far as I'm aware) and set it up for flashing to ESP32 boards <ref>https://docs.espressif.com/projects/arduino-esp32/en/latest/installing.html</ref> and also flashing ESP32 Spiffs <ref>https://randomnerdtutorials.com/install-esp32-filesystem-uploader-arduino-ide/</ref>.

To setup the Web interface Arduino sketch, you'll want to unzip and (IMPORTANT) RENAME the folder to "esp32-web-interface" to match the ino file within the folder, if you don't do this you'll have problems further down the line. Once unzipped and renamed, open the esp32-web-interface.ino sketch file and upload it to your ESP32 dev board. when this completed you'll also need to upload the SPIFFS image, you can do this by going to Tools and "ESP32 Sketch Data Upload" and choosing SPIFFS. once this is complete, you can connect your ESP32 to your BMS board via CAN and power them and they shuld work (note you'll need the 12V enable in line connected also).

Once on the Web interface, select Node ID 10 and a speed of 500kbps and you'll have all your wonderful BMS spot values and params ready to go.

== Operating Limits==

* Max voltage for the board is 70v
* Max number of cells is 16

==References==
<references />

16-cell BMS

2025-02-02T15:45:29Z

Johu: Added SoH

[[Category:BMS]]
[[Category:Battery]]
[[File:16-cell BMS.jpg|thumb|16-cell BMS]]
The goal of this BMS is to use mostly decade old components to create a 16 channel cell voltage meter. It uses a very accurate sigma/delta ADC for superb resolution. It can drain about 100mA from a cell or charge it with 50 mA via the DC/DC converter. The ability to both charge and discharge cells speeds up balancing despite the low balancing current.

When turned off it drains no current from the connected cells at all.

On the low voltage side it features two inputs for temperature sensors and one input for a 5V current sensor, differential or single ended.

It can be cascaded to be used with more than 16 cells and has an automatic addressing scheme to forgo the use of jumpers or DIP switches. All communication is done via CAN. Supply voltage is 12V with about 20 mA draw when not balancing.

The software is not yet finished, see forum for progress <ref>https://openinverter.org/forum/viewtopic.php?t=2338</ref>

The boards can be bought in the [https://openinverter.org/shop/index.php?route=product/product&product_id=74 shop].

== Pinout ==
The pinout is also written to the bottom silkscreen.

On the left side you see 17 inputs. The first one is connected to the negative pole (GND) of your (sub)pack, the subsequent ones to the positive poles of up to 16 cells. At least the lower two cell inputs must be connected. When cascading modules the positive-most input of module n is also the GND of module n+1, so must be spliced to connect to both.

On the top right is the vehicle interfacing or low voltage connector. From top to bottom it is low voltage GND, 12V, enable_in, enable_out, CANH, CANL. GND, 12V, CANH, CANL are connected to all modules in parallel whereas enable_out is chained to enable_in of the next module. The first enable_in must be connected to 12V whenever the BMS should become active, e.g. when charging or driving. The module with 12V on the enable_in auto-detects as "main" module, collects data from the subsequent modules and sends more high level CAN messages

On the bottom right is the temperature sensor and current sensor input. Top to bottom it is tsensor1+, tsensor1- (not silkscreened), tsensor2+ , tsensor2-(not silkscreened), 5V, CUR+, CUR-, GND. A single ended current sensor is just connected to CUR+.

Right now the current sensor is only supported on the main module.

=== Connector part numbers ===
{| class="wikitable"
|+
!Connector
!Manufacturer
!Header
!Counterpart
!Pins
|-
|LV connector (supply, CAN, enable)
|Phoenix Contact
|1803468
|1803617
|
|-
|Temperature and current sensors
|Molex
|640454-8
|1375820-8
|1445336-1
|-
|Cell taps
|Molex
|1-640456-7
|1-1375820-7
|1445336-1
|}

=== Power supply ===
The pins GND and 12V must be connected to a permanent 12V source in order to ensure correct operation. In other words, don't connect 12V for example to your cars ignition 12V that is interrupted whenever you stop the car.

The enable input of the first (main) module is connected to an interruptable 12V source. This input starts up the BMS.

The BMS will then keep running as long as current flows through the battery. 2 hours after it has measured the last current flow it will shut down. It will use these 2 hours to let the cells settle to their open circuit voltage and will do balancing and [[16-cell BMS#State of Health calculation|SoH calculation]]. Afterwards it will shut itself down and consume only a few uA from your 12V source.

== Communication ==
All configuration, queries and firmware updates are done via the CAN bus. There is no independent web interface like known from e.g. the inverter. However there is a solution to connect an ESP32 via CAN and then have the known web interface <ref>https://openinverter.org/forum/viewtopic.php?p=56913#p56913</ref> or you can use Dave Fiddes "oic" tool for the command line<ref>https://openinverter.org/forum/viewtopic.php?t=2907</ref>. It is important to know that the main module has node-id 10 and the subsequent ones 10+i (i index of submodule, so 1st submodule has node-id 11). The base node id can be configured to start at something else than 10.

'''All info given here is preliminary and will likely change!'''

Apart from that the modules output periodic CAN messages depending on their role. The base address for cyclic messages defaults to 0x1F4 and can be changed by modifying pdobase on the main module. pdobase is ignored on the sub modules.

All modules output on ID 501 (0x1F5) + i
{| class="wikitable"
|+
!start
!length
!item
!description
|-
|0
|13
|umin
|minimum cell voltage of module i
|-
|16
|13
|umax
|maximum cell voltage of module i
|-
|30
|2
|counter
|counts from 0-3 (anti-freeze)
|-
|32
|13
|uavg
|average cell voltage of module i
|-
|48
|8
|tempmin
|Minimum temp +40 on module i
|-
|56
|8
|tempmax
|Maximum temp +40 on module i
|}
The main module does not output its local accumulated values but accumulated values over all modules.

In addition the main module outputs on id 500 (0x1F4)
{| class="wikitable"
!start
!length
!item
!description
|-
|0
|11
|chargelim
|maximum charge current in A
|-
|11
|11
|dischargelim
|maximum discharge current in A
|-
|22
|10
|soc
|Pack soc in 0.1%
|-
|32
|16
|idcavg
|Averaged current reading of last 1s in 0.1A - signed!
|-
|48
|10
|utotal
|Total pack voltage in V
|-
|62
|2
|counter
|counts from 0-3 (anti-freeze)
|}

=== Reading individual cell voltages ===
Cell voltages are only available via CAN SDO from the module that measures them. So voltages 1-16 must be queried from the first (main) module, 17-32 from the 2nd (1st submodule) and so on. With Dave Fiddes tool this translates to:<syntaxhighlight lang="bash">
oic -n 10 dumpall #dumps all values including cell voltages from 1st module
oic -n 11 dumpall #same for second module
oic -n 11 read u0 #Read first cell voltage of second module
</syntaxhighlight>For querying voltages say in your arduino sketch you'll need to acquire every voltage separately by sending and receiving SDO messages

<code>0x60A#0x40 idhigh 0x21 idlow 0 0 0 0</code>

idhigh and low are the bytes of the internal ID. The id of the first cell voltage is 2006 (0x7D6) so for querying the 1st cell voltage of the first module you send

<code>0x60A#0x40 0x07 0x21 0xD6 0 0 0 0</code>

And you will receive the reply

<code>0x58A#0x43 0x07 0x21 0xD6 0xD0 0xED 0x01 0</code>

0x0001EDD0 is the voltage value which decodes to mV x 32. So 0x1EDD0/32 = 3950.5 mV.

The next cell would be on 0x7D7 and the last on 0x7E5. The next 16 voltages are then queried from node id 0x60B.

=== Configuration Parameters ===
There is currently a limited set of parameters which will be extended as the software grows. This table always reflects the latest git commit. Check the page history for previous versions.

These are the parameters of v0.20.B
{| class="wikitable"
|+
!Name
!Unit
!Min
!Max
!Default
!Description
|-
| colspan="6" |'''BMS'''
|-
|gain
|uV/dig
|1
|1000
|586
|Scaling factor from ADC digits to mV
|-
|correction0
|ppm
| -10000
|10000
| -1250
|The first two and the last channel have slightly different topology and need their own correction factor
|-
|correction1
|ppm
| -10000
|10000
|1500
|
|-
|correction15
|ppm
| -10000
|10000
|1000
|
|-
|numchan
|
|1
|16
|16
|Number of cells connected to the module, power cycle required following saving parameters to update.
|-
|balmode
|
|0
|3
|0
|Balancing mode
0=No balancing
1=Only bump up low cells
2=Only dissipate high cells
3=Do both

By default balancing starts 60s after power up or in fact 60s after idcavg settled below 1A. You will see opmode changing to RunBalance
|-
|ubalance
|mV
|0
|4500
|4500
|Voltage above which top balancing is started
|-
|idlewait
|s
|0
|100000
|60
|Number of seconds to wait after stop of current flow to measure unloaded cell voltage und start balancing
|-
| colspan="6" |'''Battery Characteristics'''
|-
|dischargemax
|A
|1
|2047
|200
|Maximum discharge current
|-
|nomcap
|Ah
|0
|1000
|100
|Nominal capacity
|-
|icc1
|A
|1
|2000
|50
|Maximum charge current of empty battery
|-
|icc2
|A
|1
|2000
|30
|Maximum charge current of roughly half-charged battery
|-
|icc3
|A
|1
|2000
|20
|Maximum charge current of rather full battery
|-
|ucv1
|mV
|3000
|4500
|3900
|First constant voltage set point. Transition to next one when dropping below icc2
|-
|ucv2
|mV
|3000
|4500
|4000
|Second constant voltage set point. Transition to next one when dropping below icc3
|-
|ucellmax
|mV
|3000
|4500
|4200
|Third constant voltage set point and maximum cell voltage
|-
|ucellmin
|mV
|1000
|4500
|3300
|Minimum loaded cell voltage. Discharge limit is dropped to stay above this value
|-
|chargeXsoc
|%
|0
|100
|
|Percentage of charge current at soc X. In between two points charge current is interpolated
|-
|sohpreset
|%
|10
|100
|100
|This is the starting value for the state of health (SoH) calculation. The value is continuously updated by the BMS as SoH is estimated.
|-
| colspan="6" |'''Sensor Setup'''
|-
|idcgain
|dig/A
| -1000
|1000
|10
|Gain (or actually division factor) of current sensor
|-
|idcofs
|dig
| -4095
|4095
|0
|0A offset
|-
|idcmode
|
|0
|3
|0
|Current sensor mode 0=Off, 1=Single Ended ADC, 2=Differential ADC, 3=ISA current shunt
|-
|tempsns
|
| 0
|3
| 0
|Temperature sensor 0=None, 1=Channel1, 2=Channel3, 3=Both (set tempsns 0 in dashboard if dropdown not availble and value set as -1)
|-
|tempres
|Ohm
|10
|500000
|10000
|Nominal sensor resistance at 25°C
|-
|tempbeta
|
|1
|100000
|3900
|beta factor of Steinhart equation (see data sheet)
|-
| colspan="6" |'''Communication'''
|-
|pdobase
|
|0
|2047
|500
|base COB Id for cyclic messages. Main module uses pdobase and pdobase+1, 1st submodule uses pdobase+2 and so on
|-
|sdobase
|
|0
|63
|10
|base node ID for SDO queries. Main module uses sdobase, 1st submodule sdobase+1 and so on
|}

=== Spot values ===
All values that the BMS either measures or calculates are called spot values. While all modules show all spot values, some only make sense on the main module. The column "scope" denotes that. "M" means the value is only relevant on the main module, "S" means it's relevant on main and sub modules.
{| class="wikitable"
|+
!Name
!Unit
!Scope
!Description
|-
|version
|
|S
|Firmware version
|-
|opmode
|
|S
|State of operation

* BOOT - System starting
* GETADDR - Waiting for address assignment
* SETADDR - Setting address of next node
* REQINFO - Requesting info from sub modules
* RECVINFO - Receiving info
* INIT - Initialize BMS hardware
* SELFTEST - Running hardware self tests
* RUN - normal operation when current flows through battery
* IDLE - battery is idle, i.e. no current through it for a given time
* ERROR - selftests detected a critical error, operation halted
|-
|lasterr
|
|S
|Last detected error, see Errors
|-
|errchan
|
|S
|Cell tap channel causing the error, if applicable
|-
|modaddr
|
|S
|Address of module
|-
|modnum
|
|S
|Total number of modules
|-
|totalcells
|
|M
|Total number of cells
|-
|counter
|
|S
|Revolving counter 0-15 100 ms clock rate
|-
|uptime
|s
|S
|Time in s since power was applied to 12V pin
|-
|chargein
|As
|M
|Charge into the battery
|-
|chargeout
|As
|M
|Charge from the battery to load
|-
|soc
|%
|M
|State of charge, i.e. available charge in percent of fully charged battery
|-
|soh
|%
|M
|State of health, i.e. available total charge in percent of data sheet value when new
|-
|chargelim
|A
|M
|Current limit for charging the battery, see [[16-cell BMS#Charge Curve|Charge Curve]]
|-
|dischargelim
|A
|M
|Current limit for discharging, see [[16-cell BMS#Calculating current limits|Calculating current limits]]
|-
|idc
|A
|M
|Present current through battery, negative for current out of the battery, positive for current into the battery
|-
|idcavg
|A
|M
|Average current of the last second
|-
|power
|W
|M
|Average battery power of the last second
|-
|tempmin
|°C
|M
|Minimum temperature of all modules
|-
|tempmax
|°C
|M
|Maximum temperature of all modules
|-
|uavg
|mV
|M
|average cell voltage over entire pack
|-
|umin
|mV
|M
|Minimum cell voltage of entire pack
|-
|umax
|mV
|M
|Maximum cell voltage of entire pack
|-
|udelta
|mV
|M
|Difference between minimum and maximum cell voltage of entire pack
|-
|utotal
|mV
|M
|Sum of all cell voltages, i.e. pack voltage
|-
|uX
|mV
|S
|Present voltage of cell X of current module, see also [[16-cell BMS#Reading individual cell voltages|Reading individual cell voltages]]
|-
|uavgX, uminX, umaxX, tempminX, tempmaxX
|mV, °C
|M
|Average/Minimum/Maximum cell voltage and temperature of sub module X
|-
|uXcmd
|
|S
|State of balancer
|-
|cpuload
|%
|S
|Time the CPU spends actually doing something
|}

== Operation ==

=== State of Charge calculation ===
The State of Charge (SoC) lets you know how many percent of charge you battery still holds, in percent of a fully charged battery.

Determining SoC is split into two methods: determining the SoC from cell voltage and then tracking it as current flows in or out of the pack.

To estimate the SoC a 10-point lookup table is implemented that maps from cell voltage to SoC. The accuracy of this table is directly related to the accuracy of the estimation. You can edit the lookup table by changing the '''chargeXsoc''' parameters. The voltages you enter are open circuit voltages. These can only be obtained when there was no current flow through the battery for a certain amount of time, typically 10-30 minutes. This time is configured via the '''idlewait''' parameter.

So whenever the BMS has the chance to estimate the SoC it will do so. You can adjust '''idlewait''' to a low value to start estimating quickly. It means the first estimates will be off but it will become more accurate if the pack remains unloaded for longer time.

The subsequent tracking of SoC requires the BMS to know the current through the battery. Right now it supports analog current sensors (e.g. hall effect) with an operating voltage of 5V. Within this class it supports differential and single ended sensors, configurable via '''idcmode'''. The parameters '''idcofs''' and '''idcgain''' are used for calibration. When no current is flowing adjust '''idcofs''' until '''idcavg''' shows 0A. Then put a known current through the sensor and adjust '''idcgain''' until '''idcavg''' shows the correct current.

Lastly the BMS needs to know the energy or charge content of your battery in Ah. This is configured with the '''nomcap''' parameter and can be found in the data sheet.

=== State of Health calculation ===
The State of Health (SoH) lets you know how the remaining fully charged capacity, in percent of the data sheet value, i.e. when the battery was new. Batteries slowly degrade over time and usage cycles.

Whenever we do a SoC estimation as described above, we also update the SoH. If the estimated SoC has changed by more than 20% we compare the energy that we have taken out of the battery to the difference in SoC. If the two match, the SoH is 100%. If we have taken more energy from the battery then the difference in SoC suggests, SoH is above 100% (and you likely configured a wrong '''nomcap'''). Otherwise SoH is < 100%.

As this method comes with certain inaccuracies we only change the long term SoH slowly, i.e. every estimate is slowly averaged onto the long term SoH. This should balance out inaccuracies.

The spot value '''soh''' shows the current long term SoH. The value is also reflected onto '''sohpreset''', a saveable parameter. Whenever you need to interrupt the BMSes power supply you should go should save parameters so that next time it starts up with the correct long term SoH.

=== Calculating current limits ===
Limiting charge and discharge current are the only means of this BMS to protect the battery. It has no means to turn off the current flow by itself but instead relies on the connected components to obey the calculated current limits that are sent out via CAN. The current limits are calculated in a number of steps.

==== Charge Curve ====
The initial approach was to assign a certain charge current to points in the SoC curve. This method can be skewed if the SoC calculation is off for some reason. The new method deploys 3 CC/CV regulators. This was copied from oberving VWs charge curve of the MEB cars. The first regulator has the highest charge current and aims for a voltage typically around 3.9V for many NMC chemistries. When current drops below the CC value of the second regulator then that one is used, aiming for a higher voltage of typically 4V. And finally the 3rd regulator takes over aiming for the charge end voltage of typically 4.2V. When setting all 3 to the same values a simple CC/CV curve is generated.

==== Voltage limits ====
Voltage limits are enforced via a P-regulator. I.e. as we approach the upper or lower voltage limit current is cut back to stay away from the limits until it reaches 0A. The upper and lower limit is configurable

==== Temperature limits ====
High temperature will cut back both charge and discharge current whereas low temperature will only cut back charge current. These limits only work when you've set up your temperature sensors correctly. Please check the readings against a reference before relying on it.

Charge current has a proportional, multi-step temperature derating, i.e. the charge curve defined by iccX and ucvX is scaled with a derating factor the lower the temperature or when the maximum temperature is approached

* Below '''-20°C''' no charging is possible
* Between '''-20°C and 0°C''' charging with 0-30% of the charge curve is allowed
* Between '''0°C and 25°C''' charging with 30% to 100% of the charge curve is allowed
* Between '''43°C and 50°C''' charging with 100% to 0% of the charge curve is allowed, i.e. '''above 50°C''' charging is no longer allowed.

Discharging is not limited at low temperatures as high discharge currents at low temperatures are not known to cause damage. As the battery heats up discharge current is limited, starting at '''46°C''' until discharging is no longer allowed when reaching '''53°C'''.

==== Energy limits ====
Not enforced yet. Some OEM BMSes cut back charge current after a certain amount of energy has been put into the battery. E.g. When starting charge at 50% charge rate will end up higher at 70% than if we start charging at 10%.

== Calibration ==
As every instrument the voltage measurement needs to be calibrated to cancel out tolerances in the involved components. There are 4 parameters for calibration.

* '''gain:''' The translation ration between the ADC digits and mV. This applies to all channels
* '''correction0, 1 and 15''': This allows special tuning of said 3 channels because they use a slightly different current path and thus need a small gain correction

=== Calibration procedure ===
First we determine the general gain. Pick any of the voltages between u2 and u14 which share a common gain factor. Use a good multimeter to measure the physical voltage of your reference channel. Now tune the '''gain''' parameter until your multimeter and the BMS voltage read the same value +-0.5mV. Now all channels from 2-14 should read correctly.

Then for channels 0, 1 and 15 also measure the physical voltage input and tune the respective '''correctionX''' parameter until multimeter and BMS report the same voltage. The correction factors can be negative if a channels reads too high.

Save your parameters to flash to make the calibration permanent.

== Flashing firmware ==
If you have sourced the BMS boards from an alternative source then you will need to flash the bootloader and firmware onto the BMS. This is a relatively straightforward process once understood but took me a while to get it to work.

Firstly you will need an STLink dongle, I used this one <ref>https://www.amazon.co.uk/dp/B07QBLNDPM?psc=1</ref> but I believe any will do.

I used STM32CubeProgrammer <ref>https://www.st.com/en/development-tools/stm32cubeprog.html</ref> on Linux to flash my board and also (prior to flashing) upgrade the STLinkdongle to the latest firmware (might not be necessary but felt it was wise to do so).

Once you've got STM32Cubeprogrammer installed you're probably best erasing the STM32 Chip to ensure you're starting from a clean board. Navigate to the "Erasing & Programming" tab on the left and connect to your STlink dongle (if you havent already). Once connected, (you can also update the firmware on the dongle at this point on the "Memory & File Editing" tab), connect the dongle to the BMS board via the VDCG pins...

(V = Voltage 3.3V, D = SWDIO, C = SWCLK, G = Gnd)

and perform a "full chip erase".

Once thats complete head over to Github to download the Bootloader <ref>https://github.com/jsphuebner/stm32-CANBootloader/releases</ref> and download the hex file (you may need to be logged in to download the files).

Once downloaded, in STM32CubeProgrammer, navigate to the "Memory & File Editing" tab and open the hex file you just downloaded, once opened you can use the "Download" button to flash the bootloader to your BMS board.

You can now repeat the above process of opening the hex file and "downloading" to the BMS board for the main BMS firmware which is available from the BMS Github repository <ref>https://github.com/jsphuebner/FlyingAdcBms/actions</ref> .

Once all that is done, you can move onto the Web interface. You'll need the "Can Backend" version of the ESP32 Web Interface available here <ref>https://github.com/jsphuebner/esp32-web-interface/tree/can-backend</ref> (click the green code button and download zip)

Once downloaded download Arduino IDE 1.8.19 (you'll need this version, nothing beyond version 2 as this does not support SPIFFS flashing as far as I'm aware) and set it up for flashing to ESP32 boards <ref>https://docs.espressif.com/projects/arduino-esp32/en/latest/installing.html</ref> and also flashing ESP32 Spiffs <ref>https://randomnerdtutorials.com/install-esp32-filesystem-uploader-arduino-ide/</ref>.

To setup the Web interface Arduino sketch, you'll want to unzip and (IMPORTANT) RENAME the folder to "esp32-web-interface" to match the ino file within the folder, if you don't do this you'll have problems further down the line. Once unzipped and renamed, open the esp32-web-interface.ino sketch file and upload it to your ESP32 dev board. when this completed you'll also need to upload the SPIFFS image, you can do this by going to Tools and "ESP32 Sketch Data Upload" and choosing SPIFFS. once this is complete, you can connect your ESP32 to your BMS board via CAN and power them and they shuld work (note you'll need the 12V enable in line connected also).

Once on the Web interface, select Node ID 10 and a speed of 500kbps and you'll have all your wonderful BMS spot values and params ready to go.

== Operating Limits==

* Max voltage for the board is 70v
* Max number of cells is 16

==References==
<references />

16-cell BMS

2025-02-02T15:22:20Z

Johu: Added spot values and SoC calculation

[[Category:BMS]]
[[Category:Battery]]
[[File:16-cell BMS.jpg|thumb|16-cell BMS]]
The goal of this BMS is to use mostly decade old components to create a 16 channel cell voltage meter. It uses a very accurate sigma/delta ADC for superb resolution. It can drain about 100mA from a cell or charge it with 50 mA via the DC/DC converter. The ability to both charge and discharge cells speeds up balancing despite the low balancing current.

When turned off it drains no current from the connected cells at all.

On the low voltage side it features two inputs for temperature sensors and one input for a 5V current sensor, differential or single ended.

It can be cascaded to be used with more than 16 cells and has an automatic addressing scheme to forgo the use of jumpers or DIP switches. All communication is done via CAN. Supply voltage is 12V with about 20 mA draw when not balancing.

The software is not yet finished, see forum for progress <ref>https://openinverter.org/forum/viewtopic.php?t=2338</ref>

The boards can be bought in the [https://openinverter.org/shop/index.php?route=product/product&product_id=74 shop].

== Pinout ==
The pinout is also written to the bottom silkscreen.

On the left side you see 17 inputs. The first one is connected to the negative pole (GND) of your (sub)pack, the subsequent ones to the positive poles of up to 16 cells. At least the lower two cell inputs must be connected. When cascading modules the positive-most input of module n is also the GND of module n+1, so must be spliced to connect to both.

On the top right is the vehicle interfacing or low voltage connector. From top to bottom it is low voltage GND, 12V, enable_in, enable_out, CANH, CANL. GND, 12V, CANH, CANL are connected to all modules in parallel whereas enable_out is chained to enable_in of the next module. The first enable_in must be connected to 12V whenever the BMS should become active, e.g. when charging or driving. The module with 12V on the enable_in auto-detects as "main" module, collects data from the subsequent modules and sends more high level CAN messages

On the bottom right is the temperature sensor and current sensor input. Top to bottom it is tsensor1+, tsensor1- (not silkscreened), tsensor2+ , tsensor2-(not silkscreened), 5V, CUR+, CUR-, GND. A single ended current sensor is just connected to CUR+.

Right now the current sensor is only supported on the main module.

=== Connector part numbers ===
{| class="wikitable"
|+
!Connector
!Manufacturer
!Header
!Counterpart
!Pins
|-
|LV connector (supply, CAN, enable)
|Phoenix Contact
|1803468
|1803617
|
|-
|Temperature and current sensors
|Molex
|640454-8
|1375820-8
|1445336-1
|-
|Cell taps
|Molex
|1-640456-7
|1-1375820-7
|1445336-1
|}

== Communication ==
All configuration, queries and firmware updates are done via the CAN bus. There is no independent web interface like known from e.g. the inverter. However there is a solution to connect an ESP32 via CAN and then have the known web interface <ref>https://openinverter.org/forum/viewtopic.php?p=56913#p56913</ref> or you can use Dave Fiddes "oic" tool for the command line<ref>https://openinverter.org/forum/viewtopic.php?t=2907</ref>. It is important to know that the main module has node-id 10 and the subsequent ones 10+i (i index of submodule, so 1st submodule has node-id 11). The base node id can be configured to start at something else than 10.

'''All info given here is preliminary and will likely change!'''

Apart from that the modules output periodic CAN messages depending on their role. The base address for cyclic messages defaults to 0x1F4 and can be changed by modifying pdobase on the main module. pdobase is ignored on the sub modules.

All modules output on ID 501 (0x1F5) + i
{| class="wikitable"
|+
!start
!length
!item
!description
|-
|0
|13
|umin
|minimum cell voltage of module i
|-
|16
|13
|umax
|maximum cell voltage of module i
|-
|30
|2
|counter
|counts from 0-3 (anti-freeze)
|-
|32
|13
|uavg
|average cell voltage of module i
|-
|48
|8
|tempmin
|Minimum temp +40 on module i
|-
|56
|8
|tempmax
|Maximum temp +40 on module i
|}
The main module does not output its local accumulated values but accumulated values over all modules.

In addition the main module outputs on id 500 (0x1F4)
{| class="wikitable"
!start
!length
!item
!description
|-
|0
|11
|chargelim
|maximum charge current in A
|-
|11
|11
|dischargelim
|maximum discharge current in A
|-
|22
|10
|soc
|Pack soc in 0.1%
|-
|32
|16
|idcavg
|Averaged current reading of last 1s in 0.1A - signed!
|-
|48
|10
|utotal
|Total pack voltage in V
|-
|62
|2
|counter
|counts from 0-3 (anti-freeze)
|}

=== Reading individual cell voltages ===
Cell voltages are only available via CAN SDO from the module that measures them. So voltages 1-16 must be queried from the first (main) module, 17-32 from the 2nd (1st submodule) and so on. With Dave Fiddes tool this translates to:<syntaxhighlight lang="bash">
oic -n 10 dumpall #dumps all values including cell voltages from 1st module
oic -n 11 dumpall #same for second module
oic -n 11 read u0 #Read first cell voltage of second module
</syntaxhighlight>For querying voltages say in your arduino sketch you'll need to acquire every voltage separately by sending and receiving SDO messages

<code>0x60A#0x40 idhigh 0x21 idlow 0 0 0 0</code>

idhigh and low are the bytes of the internal ID. The id of the first cell voltage is 2006 (0x7D6) so for querying the 1st cell voltage of the first module you send

<code>0x60A#0x40 0x07 0x21 0xD6 0 0 0 0</code>

And you will receive the reply

<code>0x58A#0x43 0x07 0x21 0xD6 0xD0 0xED 0x01 0</code>

0x0001EDD0 is the voltage value which decodes to mV x 32. So 0x1EDD0/32 = 3950.5 mV.

The next cell would be on 0x7D7 and the last on 0x7E5. The next 16 voltages are then queried from node id 0x60B.

=== Configuration Parameters ===
There is currently a limited set of parameters which will be extended as the software grows. This table always reflects the latest git commit. Check the page history for previous versions.

These are the parameters of v0.20.B
{| class="wikitable"
|+
!Name
!Unit
!Min
!Max
!Default
!Description
|-
| colspan="6" |'''BMS'''
|-
|gain
|uV/dig
|1
|1000
|586
|Scaling factor from ADC digits to mV
|-
|correction0
|ppm
| -10000
|10000
| -1250
|The first two and the last channel have slightly different topology and need their own correction factor
|-
|correction1
|ppm
| -10000
|10000
|1500
|
|-
|correction15
|ppm
| -10000
|10000
|1000
|
|-
|numchan
|
|1
|16
|16
|Number of cells connected to the module, power cycle required following saving parameters to update.
|-
|balmode
|
|0
|3
|0
|Balancing mode
0=No balancing
1=Only bump up low cells
2=Only dissipate high cells
3=Do both

By default balancing starts 60s after power up or in fact 60s after idcavg settled below 1A. You will see opmode changing to RunBalance
|-
|ubalance
|mV
|0
|4500
|4500
|Voltage above which top balancing is started
|-
|idlewait
|s
|0
|100000
|60
|Number of seconds to wait after stop of current flow to measure unloaded cell voltage und start balancing
|-
| colspan="6" |'''Battery Characteristics'''
|-
|dischargemax
|A
|1
|2047
|200
|Maximum discharge current
|-
|nomcap
|Ah
|0
|1000
|100
|Nominal capacity
|-
|icc1
|A
|1
|2000
|50
|Maximum charge current of empty battery
|-
|icc2
|A
|1
|2000
|30
|Maximum charge current of roughly half-charged battery
|-
|icc3
|A
|1
|2000
|20
|Maximum charge current of rather full battery
|-
|ucv1
|mV
|3000
|4500
|3900
|First constant voltage set point. Transition to next one when dropping below icc2
|-
|ucv2
|mV
|3000
|4500
|4000
|Second constant voltage set point. Transition to next one when dropping below icc3
|-
|ucellmax
|mV
|3000
|4500
|4200
|Third constant voltage set point and maximum cell voltage
|-
|ucellmin
|mV
|1000
|4500
|3300
|Minimum loaded cell voltage. Discharge limit is dropped to stay above this value
|-
|chargeXsoc
|%
|0
|100
|
|Percentage of charge current at soc X. In between two points charge current is interpolated
|-
|sohpreset
|%
|10
|100
|100
|This is the starting value for the state of health (SoH) calculation. The value is continuously updated by the BMS as SoH is estimated.
|-
| colspan="6" |'''Sensor Setup'''
|-
|idcgain
|dig/A
| -1000
|1000
|10
|Gain (or actually division factor) of current sensor
|-
|idcofs
|dig
| -4095
|4095
|0
|0A offset
|-
|idcmode
|
|0
|3
|0
|Current sensor mode 0=Off, 1=Single Ended ADC, 2=Differential ADC, 3=ISA current shunt
|-
|tempsns
|
| 0
|3
| 0
|Temperature sensor 0=None, 1=Channel1, 2=Channel3, 3=Both (set tempsns 0 in dashboard if dropdown not availble and value set as -1)
|-
|tempres
|Ohm
|10
|500000
|10000
|Nominal sensor resistance at 25°C
|-
|tempbeta
|
|1
|100000
|3900
|beta factor of Steinhart equation (see data sheet)
|-
| colspan="6" |'''Communication'''
|-
|pdobase
|
|0
|2047
|500
|base COB Id for cyclic messages. Main module uses pdobase and pdobase+1, 1st submodule uses pdobase+2 and so on
|-
|sdobase
|
|0
|63
|10
|base node ID for SDO queries. Main module uses sdobase, 1st submodule sdobase+1 and so on
|}

=== Spot values ===
All values that the BMS either measures or calculates are called spot values.
{| class="wikitable"
|+
!Name
!Unit
!Description
|-
|version
|
|Firmware version
|-
|opmode
|
|State of operation

* BOOT - System starting
* GETADDR - Waiting for address assignment
* SETADDR - Setting address of next node
* REQINFO - Requesting info from sub modules
* RECVINFO - Receiving info
* INIT - Initialize BMS hardware
* SELFTEST - Running hardware self tests
* RUN - normal operation when current flows through battery
* IDLE - battery is idle, i.e. no current through it for a given time
* ERROR - selftests detected a critical error, operation halted
|-
|lasterr
|
|Last detected error, see Errors
|-
|errchan
|
|Cell tap channel causing the error, if applicable
|-
|modaddr
|
|Address of module
|-
|modnum
|
|Total number of modules
|-
|totalcells
|
|Total number if cells
|-
|counter
|
|Revolving counter 0-15 100 ms clock rate
|-
|uptime
|s
|Time in s since power was applied to 12V pin
|-
|chargein
|As
|Charge into the battery
|-
|chargeout
|As
|Charge from the battery to load
|-
|soc
|%
|State of charge, i.e. available charge in percent of fully charged battery
|-
|soh
|%
|State of health, i.e. available total charge in percent of data sheet value when new
|-
|chargelim
|A
|Current limit for charging the battery, see [[16-cell BMS#Charge Curve|Charge Curve]]
|-
|dischargelim
|A
|Current limit for discharging, see [[16-cell BMS#Calculating current limits|Calculating current limits]]
|-
|idc
|A
|Present current through battery, negative for current out of the battery, positive for current into the battery
|-
|idcavg
|A
|Average current of the last second
|-
|power
|W
|Average battery power of the last second
|-
|tempmin
|°C
|Minimum temperature of all modules
|-
|tempmax
|°C
|Maximum temperature of all modules
|-
|uavg
|mV
|average cell voltage over entire pack
|-
|umin
|mV
|Minimum cell voltage of entire pack
|-
|umax
|mV
|Maximum cell voltage of entire pack
|-
|udelta
|mV
|Difference between minimum and maximum cell voltage of entire pack
|-
|utotal
|mV
|Sum of all cell voltages, i.e. pack voltage
|-
|uX
|mV
|Present voltage of cell X of current module, see also [[16-cell BMS#Reading individual cell voltages|Reading individual cell voltages]]
|-
|uavgX, uminX, umaxX, tempminX, tempmaxX
|mV/°C
|Average/Minimum/Maximum cell voltage and temperature of sub module X
|-
|uXcmd
|
|State of balancer
|-
|cpuload
|%
|Time the CPU spends with actually doing something
|}

== Operation ==

=== State of Charge calculation ===
Determining state of charge (SoC) is split into two methods: determining the SoC from cell voltage and then tracking it as current flows in or out of the pack.

To estimate the SoC a 10-point lookup table is implemented that maps from cell voltage to SoC. The accuracy of this table is directly related to the accuracy of the estimation. You can edit the lookup table by changing the '''chargeXsoc''' parameters. The voltages you enter are open circuit voltages. These can only be obtained when there was no current flow through the battery for a certain amount of time, typically 10-30 minutes. This time is configured via the '''idlewait''' parameter.

So whenever the BMS has the chance to estimate the SoC it will do so. You can adjust '''idlewait''' to a low value to start estimating quickly. It means the first estimates will be off but it will become more accurate if the pack remains unloaded for longer time.

The subsequent tracking of SoC requires the BMS to know the current through the battery. Right now it supports analog current sensors (e.g. hall effect) with an operating voltage of 5V. Within this class it supports differential and single ended sensors, configurable via '''idcmode'''. The parameters '''idcofs''' and '''idcgain''' are used for calibration. When no current is flowing adjust '''idcofs''' until '''idcavg''' shows 0A. Then put a known current through the sensor and adjust '''idcgain''' until '''idcavg''' shows the correct current.

Lastly the BMS needs to know the energy or charge content of your battery in Ah. This is configured with the '''nomcap''' parameter and can be found in the data sheet.

=== Calculating current limits ===
Limiting charge and discharge current are the only means of this BMS to protect the battery. It has no means to turn off the current flow by itself but instead relies on the connected components to obey the calculated current limits that are sent out via CAN. The current limits are calculated in a number of steps.

==== Charge Curve ====
The initial approach was to assign a certain charge current to points in the SoC curve. This method can be skewed if the SoC calculation is off for some reason. The new method deploys 3 CC/CV regulators. This was copied from oberving VWs charge curve of the MEB cars. The first regulator has the highest charge current and aims for a voltage typically around 3.9V for many NMC chemistries. When current drops below the CC value of the second regulator then that one is used, aiming for a higher voltage of typically 4V. And finally the 3rd regulator takes over aiming for the charge end voltage of typically 4.2V. When setting all 3 to the same values a simple CC/CV curve is generated.

==== Voltage limits ====
Voltage limits are enforced via a P-regulator. I.e. as we approach the upper or lower voltage limit current is cut back to stay away from the limits until it reaches 0A. The upper and lower limit is configurable

==== Temperature limits ====
High temperature will cut back both charge and discharge current whereas low temperature will only cut back charge current. These limits only work when you've set up your temperature sensors correctly. Please check the readings against a reference before relying on it.

Charge current has a proportional, multi-step temperature derating, i.e. the charge curve defined by iccX and ucvX is scaled with a derating factor the lower the temperature or when the maximum temperature is approached

* Below '''-20°C''' no charging is possible
* Between '''-20°C and 0°C''' charging with 0-30% of the charge curve is allowed
* Between '''0°C and 25°C''' charging with 30% to 100% of the charge curve is allowed
* Between '''43°C and 50°C''' charging with 100% to 0% of the charge curve is allowed, i.e. '''above 50°C''' charging is no longer allowed.

Discharging is not limited at low temperatures as high discharge currents at low temperatures are not known to cause damage. As the battery heats up discharge current is limited, starting at '''46°C''' until discharging is no longer allowed when reaching '''53°C'''.

==== Energy limits ====
Not enforced yet. Some OEM BMSes cut back charge current after a certain amount of energy has been put into the battery. E.g. When starting charge at 50% charge rate will end up higher at 70% than if we start charging at 10%.

== Calibration ==
As every instrument the voltage measurement needs to be calibrated to cancel out tolerances in the involved components. There are 4 parameters for calibration.

* '''gain:''' The translation ration between the ADC digits and mV. This applies to all channels
* '''correction0, 1 and 15''': This allows special tuning of said 3 channels because they use a slightly different current path and thus need a small gain correction

=== Calibration procedure ===
First we determine the general gain. Pick any of the voltages between u2 and u14 which share a common gain factor. Use a good multimeter to measure the physical voltage of your reference channel. Now tune the '''gain''' parameter until your multimeter and the BMS voltage read the same value +-0.5mV. Now all channels from 2-14 should read correctly.

Then for channels 0, 1 and 15 also measure the physical voltage input and tune the respective '''correctionX''' parameter until multimeter and BMS report the same voltage. The correction factors can be negative if a channels reads too high.

Save your parameters to flash to make the calibration permanent.

== Flashing firmware ==
If you have sourced the BMS boards from an alternative source then you will need to flash the bootloader and firmware onto the BMS. This is a relatively straightforward process once understood but took me a while to get it to work.

Firstly you will need an STLink dongle, I used this one <ref>https://www.amazon.co.uk/dp/B07QBLNDPM?psc=1</ref> but I believe any will do.

I used STM32CubeProgrammer <ref>https://www.st.com/en/development-tools/stm32cubeprog.html</ref> on Linux to flash my board and also (prior to flashing) upgrade the STLinkdongle to the latest firmware (might not be necessary but felt it was wise to do so).

Once you've got STM32Cubeprogrammer installed you're probably best erasing the STM32 Chip to ensure you're starting from a clean board. Navigate to the "Erasing & Programming" tab on the left and connect to your STlink dongle (if you havent already). Once connected, (you can also update the firmware on the dongle at this point on the "Memory & File Editing" tab), connect the dongle to the BMS board via the VDCG pins...

(V = Voltage 3.3V, D = SWDIO, C = SWCLK, G = Gnd)

and perform a "full chip erase".

Once thats complete head over to Github to download the Bootloader <ref>https://github.com/jsphuebner/stm32-CANBootloader/releases</ref> and download the hex file (you may need to be logged in to download the files).

Once downloaded, in STM32CubeProgrammer, navigate to the "Memory & File Editing" tab and open the hex file you just downloaded, once opened you can use the "Download" button to flash the bootloader to your BMS board.

You can now repeat the above process of opening the hex file and "downloading" to the BMS board for the main BMS firmware which is available from the BMS Github repository <ref>https://github.com/jsphuebner/FlyingAdcBms/actions</ref> .

Once all that is done, you can move onto the Web interface. You'll need the "Can Backend" version of the ESP32 Web Interface available here <ref>https://github.com/jsphuebner/esp32-web-interface/tree/can-backend</ref> (click the green code button and download zip)

Once downloaded download Arduino IDE 1.8.19 (you'll need this version, nothing beyond version 2 as this does not support SPIFFS flashing as far as I'm aware) and set it up for flashing to ESP32 boards <ref>https://docs.espressif.com/projects/arduino-esp32/en/latest/installing.html</ref> and also flashing ESP32 Spiffs <ref>https://randomnerdtutorials.com/install-esp32-filesystem-uploader-arduino-ide/</ref>.

To setup the Web interface Arduino sketch, you'll want to unzip and (IMPORTANT) RENAME the folder to "esp32-web-interface" to match the ino file within the folder, if you don't do this you'll have problems further down the line. Once unzipped and renamed, open the esp32-web-interface.ino sketch file and upload it to your ESP32 dev board. when this completed you'll also need to upload the SPIFFS image, you can do this by going to Tools and "ESP32 Sketch Data Upload" and choosing SPIFFS. once this is complete, you can connect your ESP32 to your BMS board via CAN and power them and they shuld work (note you'll need the 12V enable in line connected also).

Once on the Web interface, select Node ID 10 and a speed of 500kbps and you'll have all your wonderful BMS spot values and params ready to go.

== Operating Limits==

* Max voltage for the board is 70v
* Max number of cells is 16

==References==
<references />

16-cell BMS

2025-01-26T18:06:58Z

Johu:

16-cell BMS

2025-01-06T16:45:02Z

Johu: Added temperature derating doc

16-cell BMS

2025-01-06T16:19:45Z

Johu: Temp sensor update

Mini Mainboard

2024-12-16T18:10:53Z

Johu: Added Tesla M3

[[File:Mini mainboard front.jpg|thumb|Mini mainboard front]]
The mini mainboard is the smallest form factor openinverter motor control board. It has the same functionality as the [[Main Board Version 3]] but offloads a few components. It is meant to be used as a daughter board on top of an adapter board. The adapter board must (or may) implement:

* The Wifi module socket
* Relay drivers
In addition the mini mainboard allows talking to SPI peripherals. Therefore some pins have double mapping:

* SIG_CRUISE: MOSI (SJ3 must be closed to the right side for that).
* OUT_BRAKE: MISO
* OUT_ERR: SCK
* OUT_OUVTG: /CS
Like previous boards it contains a 5V switching regulator that can be loaded with about 500 mA. Alternatively It can be powered with a single 5V rail, which has to sit at 5.3V though for sufficient resolver excitation amplitude.

As opposed to earlier mainboards the current sensor inputs are now designed for 5V input, i.e. 2.5V @ 0A. This interfaces directly with most current sensors that OEMs use and also with Melexis chips, LEM HTFS and Tamura L06P current sensors.
== Digital inputs ==
There are external 7 digital inputs on JP2. A voltage of >7V is interpreted as a logical 1 (high). They all have a cutoff frequency of 40Hz.
# Cruise Control (Pin 4). This input sets the current motor speed as the set point for cruise control. Cruise control is disabled with the Brake input. In SPI mode: MOSI
# Start (Pin 5). This input starts the inverter operation.
# Brake input (Pin 6). This input is connected to the brake pedal. It sets a configurable negative torque (regen) which overrides the throttle. I.e. if you press both, brake pedal and throttle, the throttle is ignored.
# Forward (Pin 7). If this input is high the motor spins forward.
# Reverse (Pin 8). If this input is high the motor spins backward. When neither input is high the motor will not spin at all.
# Emergency stop (Pin 9). The PWM is enabled as long as this input is high and shut down as soon as it goes low.
# BMS input (Pin 10). This input limits the motor torque (both negative and positive) if a BMS signals an over or undervoltage condition. It is active high, i.e. high means over/undervoltage.
There is one more digital inputs on JP1
# Gate driver error/Desat (Pin 5) This pin is pulled high (5V). When pulled low an error is signalled and the PWM is inhibited

== Digital outputs ==
There are 5 outputs on JP2. They just source 3.3V with 220 Ohm series resistance and are meant to drive FETs or NPN transistors.
# Precharge output (Pin 15) This output is activated when the inverter is powered up. It is disabled as soon as the DC contactor is enabled.
# DC contactor output (Pin 16) This output is activated when the bus voltage is above a given threshold and the start pin goes high. It is disabled on overcurrent, motor overheat and emergency stop.
# Error output (Pin 17) This output is activated on over current, motor overheat, emergency stop, throttle out of range. In SPI mode: SCK
# Brake output (Pin 18) This output is high when potnom reaches a certain negative threshold. The purpose is to switch on the brake light on a certain regen level At startup this pin is configured as an analog input to sense some preset adapter boards In SPI mode: MISO
# Voltage output (Pin 19) This output is activated when the bus voltage surpasses an upper or lower threshold. In SPI mode: /CS
== PWM outputs ==
There is one external PWM output on JP2, Pin 20. It outputs a duty cycle that is proportional to the motor or heatsink temperature or speed. Its offset and gain is software configurable. The frequency is fixed to 17kHz.

There are 6 internal PWM outputs on JP1. The outputs are 3.3V, 16mA. Frequency is configurable to 4.4, 8.8 or 17.6kHz.
# PWM Top phase 1 (Pin 6)
# PWM Bottom phase 1 (Pin 7)
# PWM Top phase 2 (Pin 8)
# PWM Bottom phase 2 (Pin 9)
# PWM Top phase 3 (Pin 10)
# PWM Bottom phase 3 (Pin 11)
There is a configurable dead time between top and bottom outputs.

== Analog Inputs and over-current protection ==
There are 3 external analog inputs on JP2.
# Throttle input, 0-6.6V (Pin 11). Cutoff frequency 16Hz, input resistance 10k.
# Redundant throttle or Regen pot input, 0-6.6V (Pin 12). Cutoff frequency 16Hz, input resistance 10k.
# KTY83 temperature sensor input (Pin 14 positive, Pin 13 negative). Cutoff frequency 16Hz
There are 4 internal analog inputs on JP1.
# Udc (Pin 17) Bus voltage input. 0-3.3V, cutoff frequency 16Hz
# Heatsink temperature (Pin 18), cutoff frequency 16Hz
# Il1 (Pin 19) Current phase 1. 0V=-Imax, 2.5V=0A, 5V=Imax (software configurable). Cutoff frequency 48kHz.
# Il2 (Pin 20) Current phase 2
The two current sensors are used for the programmable hardware over-current protection. A trip limit can be programmed that configures a hardware comparator. When the given current limit is hit, the PWM signals will be shut down without software interaction.

== Position feedback ==
Multiple position feedback types are supported via JP1. On the back of the board you will find solder jumper SJ1 that enables a 500 Ohm pull-up resistor that is needed for open collector encoders.

# Single channel pulse encoder - signal connected to Pin 14
# Dual channel quadrature encoder - connected to Pin 14 (A) and Pin 15 (B)
# Resolver - Exciter coil connected to Pin 13 (R1) and Pin 12 (R2). Feedback coils positive connected to Pin 14 (S2) and Pin 15 (S3). Negative poles of coils tied together and connected to Pin 16 (S1S4)
# SinCos feedback chip 0-3.3V - connected to Pin 14 and 15

== Communication ==
JP1 provides a TTL level (3.3V) UART interface, Pin 3 (RX), Pin 4 (TX)

The communication parameters are fixed to 115200 8N2 (2 stop bits!) and may be raised to 921600.

CAN interface Pin 1 is CANH, Pin 2 is CANL

== Power input ==
The main board contains a regulated buck converter to power all of its components. The allowed input voltage is 7-26V.

== Pin Header Summary ==
Pin Header JP1
{| class="wikitable"
|'''Pin'''
|'''Signal'''
|'''Name'''
|-
|1
|CANH
|CANH
|-
|2
|CANL
|CANL
|-
|3
|RX
|Serial console
|-
|4
|TX
|Serial console
|-
|5
|DESAT
|Gate driver fault
|-
|6
|PWM1P
|Power stage PWM
|-
|7
|PWM1N
|Power stage PWM
|-
|8
|PWM2P
|Power stage PWM
|-
|9
|PWM2N
|Power stage PWM
|-
|10
|PWM3P
|Power stage PWM
|-
|11
|PWM3N
|Power stage PWM
|-
|12
|R2
|Resover excitation R2
|-
|13
|R1
|Resover excitation R1
|-
|14
|ENC_A/S2
|Encoder channel A or single channel input/Resolver S2
|-
|15
|ENC_B/S3
|Encoder channel B/Resolver S3
|-
|16
|S1S4
|GND/Resolver center point S1S4
|-
|17
|TMPHS
|Heatsink temperature sensor
|-
|18
|UDC
|Bus voltage
|-
|19
|IL1
|Phase current 1
|-
|20
|IL2
|Phase current 2
|}
Pin header JP2
{| class="wikitable"
|'''Pin'''
|'''Signal'''
|'''Name'''
|-
|1
|GND
|GND
|-
|2
|VCC
|Vcc (7-26V)
|-
|3
|5V
|500mA output
|-
|4
|SIG_CRUISE/MOSI
|Cruise Control Input (12V) or SPI MOSI (3.3V)
|-
|5
|SIG_START
|Start input (12V)
|-
|6
|SIG_BRAKE
|Brake Input (12V)
|-
|7
|SIG_FORWARD
|Forward (12V)
|-
|8
|SIG_REVERSE
|Reverse (12V)
|-
|9
|SIG_EMCYSTOP
|Emergency stop (12V)
|-
|10
|SIG_BMS
|BMS Over/Under Voltage input (12V)
|-
|11
|THROTTLE2
|Regen Pot Input (0-6.6V)
|-
|12
|THROTTLE1
|Throttle Input (0-6.6V)
|-
|13
|MTEMP-
|Motor Temperature Input -
|-
|14
|MTEMP+
|Motor Temperature Input +
|-
|15
|OUT_PRE
|Precharge Output (3.3V)
|-
|16
|OUT_DCSW
|DC contactor output (3.3V)
|-
|17
|OUT_ERR/SCK
|Error Signal or SPI SCK (both 3.3V)
|-
|18
|OUT_BRAKE/MISO
|Brake output or SPI MISO (both 3.3V)
|-
|19
|OUT_OUVTG/CS
|Over/Under Voltage or SPI /CS (both 3.3V)
|-
|20
|PWM_USER
|Temperature PWM output (3.3V)
|}
== Hardware detection ==
Because the mini mainboard is primarily meant to be mounted on some sort of base board, we wanted to introduce a detection mechanism for the base board in case any special treatment is needed.

We chose to assign a secondary meaning to the OUT_BRAKE pin because its level can be measured by the ADC. So OUT_BRAKE can be brought to a certain voltage level with a high impedance voltage divider. The voltage level encodes the hardware variant. It will not disturb normal operation because its total resistance is chosen at least one order of magnitude larger than the output impedance of OUT_BRAKE, which is about 270 Ohms.
[[File:Board address voltage divider.png|thumb]]
A the upper voltage divider resistor R1 is connected to the "5V" rail which actually sits at 5.3V. R2 is connected to GND
{| class="wikitable"
|+
!Variant
!R1
!R2
!voltage
!ADC
!+/-3% range
!Remark
|-
| MG
|47k
|2k7
|0.27 V
|337
|327-347
|Not Mini-MB based, upper voltage 5.0V
|-
| Tesla M3
|47k
|3k3
|0.33 V
|407
|395-419
|Not Mini-MB based, upper voltage 5.0V
|-
| -
|47k
|3k9
|0.41 V
|504
|489-519
|
|-
|Nissan Leaf Gen3
|47k
|4k7
|0.48 V
|598
|580-616
|
|-
| Renault Zoe Gen1
|47k
|5k1
|0.52 V
|643
|624-662
|
|-
| -
|47k
|5k6
|0.56 V
|700
|679-721
|
|-
| -
|47k
|6k8
|0.67 V
|831
|806-856
|
|-
| -
|47k
|7k5
|0.73 V
|905
|878-932
|
|-
| -
|47k
|8k2
|0.79 V
|977
|948-1006
|
|-
| -
|47k
|9k1
|0.86 V
|1067
|1035-1099
|
|-
| -
|47k
|10k
|0.93 V
|1154
|1119-1189
|
|-
| -
|47k
|12k
|1.08 V
|1338
|1298-1378
|
|}
[[Category:OpenInverter]] [[Category:Inverter]]

Mini Mainboard

2024-12-16T18:07:14Z

Johu: Added MG board

[[File:Mini mainboard front.jpg|thumb|Mini mainboard front]]
The mini mainboard is the smallest form factor openinverter motor control board. It has the same functionality as the [[Main Board Version 3]] but offloads a few components. It is meant to be used as a daughter board on top of an adapter board. The adapter board must (or may) implement:

* The Wifi module socket
* Relay drivers
In addition the mini mainboard allows talking to SPI peripherals. Therefore some pins have double mapping:

* SIG_CRUISE: MOSI (SJ3 must be closed to the right side for that).
* OUT_BRAKE: MISO
* OUT_ERR: SCK
* OUT_OUVTG: /CS
Like previous boards it contains a 5V switching regulator that can be loaded with about 500 mA. Alternatively It can be powered with a single 5V rail, which has to sit at 5.3V though for sufficient resolver excitation amplitude.

As opposed to earlier mainboards the current sensor inputs are now designed for 5V input, i.e. 2.5V @ 0A. This interfaces directly with most current sensors that OEMs use and also with Melexis chips, LEM HTFS and Tamura L06P current sensors.
== Digital inputs ==
There are external 7 digital inputs on JP2. A voltage of >7V is interpreted as a logical 1 (high). They all have a cutoff frequency of 40Hz.
# Cruise Control (Pin 4). This input sets the current motor speed as the set point for cruise control. Cruise control is disabled with the Brake input. In SPI mode: MOSI
# Start (Pin 5). This input starts the inverter operation.
# Brake input (Pin 6). This input is connected to the brake pedal. It sets a configurable negative torque (regen) which overrides the throttle. I.e. if you press both, brake pedal and throttle, the throttle is ignored.
# Forward (Pin 7). If this input is high the motor spins forward.
# Reverse (Pin 8). If this input is high the motor spins backward. When neither input is high the motor will not spin at all.
# Emergency stop (Pin 9). The PWM is enabled as long as this input is high and shut down as soon as it goes low.
# BMS input (Pin 10). This input limits the motor torque (both negative and positive) if a BMS signals an over or undervoltage condition. It is active high, i.e. high means over/undervoltage.
There is one more digital inputs on JP1
# Gate driver error/Desat (Pin 5) This pin is pulled high (5V). When pulled low an error is signalled and the PWM is inhibited

== Digital outputs ==
There are 5 outputs on JP2. They just source 3.3V with 220 Ohm series resistance and are meant to drive FETs or NPN transistors.
# Precharge output (Pin 15) This output is activated when the inverter is powered up. It is disabled as soon as the DC contactor is enabled.
# DC contactor output (Pin 16) This output is activated when the bus voltage is above a given threshold and the start pin goes high. It is disabled on overcurrent, motor overheat and emergency stop.
# Error output (Pin 17) This output is activated on over current, motor overheat, emergency stop, throttle out of range. In SPI mode: SCK
# Brake output (Pin 18) This output is high when potnom reaches a certain negative threshold. The purpose is to switch on the brake light on a certain regen level At startup this pin is configured as an analog input to sense some preset adapter boards In SPI mode: MISO
# Voltage output (Pin 19) This output is activated when the bus voltage surpasses an upper or lower threshold. In SPI mode: /CS
== PWM outputs ==
There is one external PWM output on JP2, Pin 20. It outputs a duty cycle that is proportional to the motor or heatsink temperature or speed. Its offset and gain is software configurable. The frequency is fixed to 17kHz.

There are 6 internal PWM outputs on JP1. The outputs are 3.3V, 16mA. Frequency is configurable to 4.4, 8.8 or 17.6kHz.
# PWM Top phase 1 (Pin 6)
# PWM Bottom phase 1 (Pin 7)
# PWM Top phase 2 (Pin 8)
# PWM Bottom phase 2 (Pin 9)
# PWM Top phase 3 (Pin 10)
# PWM Bottom phase 3 (Pin 11)
There is a configurable dead time between top and bottom outputs.

== Analog Inputs and over-current protection ==
There are 3 external analog inputs on JP2.
# Throttle input, 0-6.6V (Pin 11). Cutoff frequency 16Hz, input resistance 10k.
# Redundant throttle or Regen pot input, 0-6.6V (Pin 12). Cutoff frequency 16Hz, input resistance 10k.
# KTY83 temperature sensor input (Pin 14 positive, Pin 13 negative). Cutoff frequency 16Hz
There are 4 internal analog inputs on JP1.
# Udc (Pin 17) Bus voltage input. 0-3.3V, cutoff frequency 16Hz
# Heatsink temperature (Pin 18), cutoff frequency 16Hz
# Il1 (Pin 19) Current phase 1. 0V=-Imax, 2.5V=0A, 5V=Imax (software configurable). Cutoff frequency 48kHz.
# Il2 (Pin 20) Current phase 2
The two current sensors are used for the programmable hardware over-current protection. A trip limit can be programmed that configures a hardware comparator. When the given current limit is hit, the PWM signals will be shut down without software interaction.

== Position feedback ==
Multiple position feedback types are supported via JP1. On the back of the board you will find solder jumper SJ1 that enables a 500 Ohm pull-up resistor that is needed for open collector encoders.

# Single channel pulse encoder - signal connected to Pin 14
# Dual channel quadrature encoder - connected to Pin 14 (A) and Pin 15 (B)
# Resolver - Exciter coil connected to Pin 13 (R1) and Pin 12 (R2). Feedback coils positive connected to Pin 14 (S2) and Pin 15 (S3). Negative poles of coils tied together and connected to Pin 16 (S1S4)
# SinCos feedback chip 0-3.3V - connected to Pin 14 and 15

== Communication ==
JP1 provides a TTL level (3.3V) UART interface, Pin 3 (RX), Pin 4 (TX)

The communication parameters are fixed to 115200 8N2 (2 stop bits!) and may be raised to 921600.

CAN interface Pin 1 is CANH, Pin 2 is CANL

== Power input ==
The main board contains a regulated buck converter to power all of its components. The allowed input voltage is 7-26V.

== Pin Header Summary ==
Pin Header JP1
{| class="wikitable"
|'''Pin'''
|'''Signal'''
|'''Name'''
|-
|1
|CANH
|CANH
|-
|2
|CANL
|CANL
|-
|3
|RX
|Serial console
|-
|4
|TX
|Serial console
|-
|5
|DESAT
|Gate driver fault
|-
|6
|PWM1P
|Power stage PWM
|-
|7
|PWM1N
|Power stage PWM
|-
|8
|PWM2P
|Power stage PWM
|-
|9
|PWM2N
|Power stage PWM
|-
|10
|PWM3P
|Power stage PWM
|-
|11
|PWM3N
|Power stage PWM
|-
|12
|R2
|Resover excitation R2
|-
|13
|R1
|Resover excitation R1
|-
|14
|ENC_A/S2
|Encoder channel A or single channel input/Resolver S2
|-
|15
|ENC_B/S3
|Encoder channel B/Resolver S3
|-
|16
|S1S4
|GND/Resolver center point S1S4
|-
|17
|TMPHS
|Heatsink temperature sensor
|-
|18
|UDC
|Bus voltage
|-
|19
|IL1
|Phase current 1
|-
|20
|IL2
|Phase current 2
|}
Pin header JP2
{| class="wikitable"
|'''Pin'''
|'''Signal'''
|'''Name'''
|-
|1
|GND
|GND
|-
|2
|VCC
|Vcc (7-26V)
|-
|3
|5V
|500mA output
|-
|4
|SIG_CRUISE/MOSI
|Cruise Control Input (12V) or SPI MOSI (3.3V)
|-
|5
|SIG_START
|Start input (12V)
|-
|6
|SIG_BRAKE
|Brake Input (12V)
|-
|7
|SIG_FORWARD
|Forward (12V)
|-
|8
|SIG_REVERSE
|Reverse (12V)
|-
|9
|SIG_EMCYSTOP
|Emergency stop (12V)
|-
|10
|SIG_BMS
|BMS Over/Under Voltage input (12V)
|-
|11
|THROTTLE2
|Regen Pot Input (0-6.6V)
|-
|12
|THROTTLE1
|Throttle Input (0-6.6V)
|-
|13
|MTEMP-
|Motor Temperature Input -
|-
|14
|MTEMP+
|Motor Temperature Input +
|-
|15
|OUT_PRE
|Precharge Output (3.3V)
|-
|16
|OUT_DCSW
|DC contactor output (3.3V)
|-
|17
|OUT_ERR/SCK
|Error Signal or SPI SCK (both 3.3V)
|-
|18
|OUT_BRAKE/MISO
|Brake output or SPI MISO (both 3.3V)
|-
|19
|OUT_OUVTG/CS
|Over/Under Voltage or SPI /CS (both 3.3V)
|-
|20
|PWM_USER
|Temperature PWM output (3.3V)
|}
== Hardware detection ==
Because the mini mainboard is primarily meant to be mounted on some sort of base board, we wanted to introduce a detection mechanism for the base board in case any special treatment is needed.

We chose to assign a secondary meaning to the OUT_BRAKE pin because its level can be measured by the ADC. So OUT_BRAKE can be brought to a certain voltage level with a high impedance voltage divider. The voltage level encodes the hardware variant. It will not disturb normal operation because its total resistance is chosen at least one order of magnitude larger than the output impedance of OUT_BRAKE, which is about 270 Ohms.
[[File:Board address voltage divider.png|thumb]]
A the upper voltage divider resistor R1 is connected to the "5V" rail which actually sits at 5.3V. R2 is connected to GND
{| class="wikitable"
|+
!Variant
!R1
!R2
!voltage
!ADC
!+/-3% range
!Remark
|-
| MG
|47k
|2k7
|0.27 V
|357
|327-347
|Upper voltage 5.0V
|-
| -
|47k
|3k3
|0.35 V
|431
|418-444
|
|-
| -
|47k
|3k9
|0.41 V
|504
|489-519
|
|-
|Nissan Leaf Gen3
|47k
|4k7
|0.48 V
|598
|580-616
|
|-
| Renault Zoe Gen1
|47k
|5k1
|0.52 V
|643
|624-662
|
|-
| -
|47k
|5k6
|0.56 V
|700
|679-721
|
|-
| -
|47k
|6k8
|0.67 V
|831
|806-856
|
|-
| -
|47k
|7k5
|0.73 V
|905
|878-932
|
|-
| -
|47k
|8k2
|0.79 V
|977
|948-1006
|
|-
| -
|47k
|9k1
|0.86 V
|1067
|1035-1099
|
|-
| -
|47k
|10k
|0.93 V
|1154
|1119-1189
|
|-
| -
|47k
|12k
|1.08 V
|1338
|1298-1378
|
|}
[[Category:OpenInverter]] [[Category:Inverter]]

Foccci

2024-12-12T18:19:06Z

Johu: /* Errors */

Disclaimer: This Page is still work in progress! Any information written here is a draft only and should be handled as such. Contributions more then welcome. If you have questions please ask them in the discussion section of the page or in the OpenInvert Forum.
[[File:Foccci pinout.svg|thumb|Foccci (v4.5) pinout]]

[[File:Foccci 4.5b pinout.png|thumb|Foccci 4.5b / 5 / 5.1 pinout]]
This page is about FOCCCI. FOCCCI is an open source CCS Charge Interface started by Uhi and developed by the OpenInverter Community.

Foccci is the hardware part, and on it runs the software Clara.

Here you will find documentation on the Hardware (and Clara software), where to get it (or how to build it yourself), News regarding the development and many more great things.

[https://openinverter.org/shop/index.php?route=product/product&product_id=79 Foccci for sale on OpenInverter Shop]

[https://github.com/uhi22/foccci Foccci on Github.]

[https://github.com/uhi22/ccs32clara Clara on Github.]

[https://openinverter.org/forum/viewtopic.php?t=3727 Foccci in the OpenInverter Forum.]

== Pin description ==

=== External connector ("Deutsch Header") ===
Starting version 4.5b the pins were reshuffled to allow one wiring loom going to the charge port and one to the car side. Changed pins are '''bold'''.
{| class="wikitable"
|+
!Short name
!Pin up to version 4.5a
!Pin for version 4.5b, 5, 5.1
!Description
|-
|TEMP1
|A1
|A1
|Power pin temperature sensor. It is pulled up to 3.3V with 10k and the sensor must pull down to GND. Sensor characteristics are configurable in software
|-
|TEMP2
|A2
|A2
|As above
|-
|TEMP3
|A3
|A3
|As Above
|-
|LOCKFB
|A4
|A4
|Feedback signal from connector lock. Pulled up to 3.3V with 10k, so feedback must pull down to GND. Thresholds configurable in software
|-
|IN_U_HV
|A5
|'''B10'''
|Analog input 0 to 5V, with pull-down-resistor. Can be used to measure the charge port voltage, using a converter board, e.g. the "muehlpower board"
|-
|CP
|A6
|A6
|CP (Control Pilot) pin from charge port
|-
|SW2(_LS)
|A7
|'''B4'''
|Output for charge port contactor 2. Low side switch until Foccci 4.4, high side switch starting 4.5
Controls one of the contactors to make the connection between the HV battery and the vehicle inlet.

The output can drive inductive load without additional circuits. It will clamp the turn-off voltage to ~40V. The driver has protection against shortcut and thermal overload.

The output can be configured to be just digital on/off, and can also be configured to use PWM. BUT: In Foccci versions 4.2 and 4.3 (maybe more) the output driver is only capable of slow PWM, which is hearable and may cause trouble with the contactors. So it is recommended to NOT use the PWM feature, and instead use contactors which do not require economizing or use external economizers. In case you want the PWM nevertheless, you need a external freewheeling diode.

Starting Foccci 4.5 PWM is working as intended at 18 kHz. It is a high side output starting v4.5, so the other side of the contactor must be connected to GND. Before v4.5 it is a low side output so the other side must be connected to 12V
|-
|LOCK_MOT2
|A8
|A8
|Motor driver output for charge port lock servo
|-
|LOCK_MOT1
|A9
|A9
|
|-
|PP
|A10
|'''A5'''
|PP (Proximity Pilot) pin from charge port. If you want Foccci to wake up when an unpowered charge cord is plugged in you must close JP3 to pin 1 (towards R7). There mustn't be a pull-down resistor in the charge port in this case as that would permanently keep Foccci awake
|-
|5V
|A11
|'''B11'''
|5V, 500mA e.g. for supplying voltage sense board. This is an OUTPUT of Foccci. Do not apply an external voltage source here. Foccci contains a step-down-converter from the 12V supply to this 5V output.
|-
|GND
|A12
|'''B12'''
|
|-
|CANH
|B1
|B1
|CAN communication
|-
|CANL
|B2
|B2
|
|-
|n.c.
|B3
|
|Unused pins were assigned GND in 4.5b
|-
|n.c.
|B4
|
|
|-
|GND
|B5
|B5, '''B3'''
|
|-
|SW1(_LS)
|B6
|B6
|Output for the charge port contactor 1. See description of SW2(_LS).
|-
|WAKEUP
|B7
|B7
|Wakeup bus. Momentarily (or constantly) applying 12V wakes up the board. In the other direction Foccci can wake up (or supply with up to 1A) other devices via a 12V high side switch
|-
|12V
|B8
|B8
|Supply voltage, always on. 9 to 24V are fine.
|-
|LED_RED
|B9
|'''A12'''
|Status LEDs
|-
|LED_GREEN
|B10
|'''A11'''
|
|-
|LED_BLUE
|B11
|'''A10'''
|
|-
|BUTTON
|B12
|'''A7'''
|Wakes up Foccci or stops an ongoing charging session
|}

=== Internal connectors ===
{| class="wikitable"
|+
!short name
!description
|-
|UART TX
|Provides logging information, 921600 Baud. See also https://github.com/uhi22/ccs32clara/blob/main/doc/clara_user_manual.md#serial-logging
|-
|UART RX
|Not used
|-
|SWCLK
|for flashing with STLINK
|-
|SWDIO
|for flashing with STLINK
|}
== Integrating Foccci with your car/BMS==
[[File:Foccci CCS2.png|thumb|Foccci with (Orion) BMS]]
Depending on your use case Foccci has to communicate with one or more components in your car. All in-car communication happens via a single CAN bus.
===Basic communication considerations ===
Foccci can be configured to run at various baud rates and defaults to 500k. The Wifi interface mentioned below is hard coded to 500k. So when configuring a different baud rate you will loose communication with the Wifi interface. This might be fixed in the future by allowing variable baud rates for the wifi interface. Bottom line: '''keep it at 500k.'''

Apart from that it is mostly sufficient if Foccci can communicate, or more precisely, listen to the BMS. Foccci uses the flexible [[CAN communication|CAN mapping]] known from other OI firmware. There are 5 key parameters that need to be received via CAN:
*'''ChargeCurrent''': this is the single most important item. It is directly relayed to the charger and specifies the current the battery can accept at the given moment. This depends on battery voltage, temperature and other things to be determined by the BMS. ''Foccci itself does no battery monitoring of any kind, it is completely down to the BMS to specify a safe charge current'''''.''' When this value is not updated for more than 2 seconds the charging session is terminated.
* '''BatteryVoltage''': this item is important for precharging the CCS chargers output to the momentary battery voltage. Most BMSes output the total pack voltage in a CAN message
* '''TargetVoltage''': In theory this is the maximum voltage you want the battery to be charged to. In practise the maximum battery voltage MUST be governed by specifying an appropriate ChargeCurrent. More importantly many chargers cut back charge power when ''approaching'' this voltage resulting in poor charging performance towards the top end. So in practise you want to set this to a voltage about 10V above charge end voltage of your battery.
*'''soc''': This is purely informative as far as we know. It displays the batteries state of charge on the chargers display
*'''enable''': this is optional as it defaults to always enabled. It can be used to completely terminate the charging session by setting it to 0.
===Using Foccci as a charge coordinator===
This topic is still work in progress. The CCS connector, as its name suggests, combines both AC and DC charging in one socket. As long as we use the socket only for DC charging it is very easy to wire up. But once we also use the AC functionality we have to spend further thought on this.

The two pins PP and CP communicate information about the cable limit and the momentary current limit of the AC outlet. PP is a simple resistor between PE and PP that is evaluated by putting a test current onto it. This concludes that this signal can only be used by one device. CP is a bit more complex. When plugging in it communicates with a 2k7 resistor to PE that the cable is now connected to a car. From this simple fact we can again conclude that CP is a peer-to-peer signal only. Once the car is ready to charge it switches another 1k3 resistor in parallel to the 2k7 resistor. Only then the AC voltage is switched to the power pins. Lastly, the AC outlet encodes the momentary current limit in a PWM duty cycle.

Foccci does all the evaluation and makes the result available as spot values that can in turn be mapped to CAN:
*EvseAcCurrentLimit
*CableCurrentLimit
To activate the 1k3 resistor aka activating the AC outlet we map AcObcState. It must be set to 2 for activation.

Some chargers want to evaluate the CP (and perhaps PP) signal themselves. This issue can be solved with a change over switch that disconnects Foccci from CP while AC charging. Alternatively the CP signal can be spoofed and the charge current controlled by CAN to satisfy the limits of the AC outlet (EVSE).
== Wakeup ==
For charging it is particularly interesting to wake up Foccci itself and necessary subsystems <ref>https://openinverter.org/forum/viewtopic.php?p=66547#p66547</ref> when plugging in a charge cord. To allow for this, Foccci has various wakeup sources and also can wake up other devices. For wakeup to work, Foccci must be permanently supplied with 12V (it will draw no current when asleep). '''Hardware version V4.5 and above required for wakeup.'''

Here are the sources:

# Wakeup pin - bidirectional - level triggered (12V)
# Button - level triggered (GND)
# PP - optional via solder bridge - level triggered
# CP - Edge triggered

So the first 3 inputs will force the Foccci on. It can't turn itself off as long as that wakeup source is active. The last input will only trigger when transitioning from invalid to valid PWM and then Foccci can decide how long to stay awake. All modes always work regardless of software settings - except PP wakeup which can be turned off in hardware (JP3).

The wakeup output on the other hand is software-defined. Foccci offers the following options

# '''Level''' - as long as the Foccci doesn't decide to turn off, we keep Wakeup on as well
# '''Pulse''' - When Foccci boots generate a 1s wakeup pulse
# '''LevelOnValidCp''' - As long as CP is pulsing we keep wakeup on
# '''PulseOnValidCp''' - Whenever we transition from non-pulsing to pulsing CP we generate a 1s pulse
# '''LevelOnValidPp''' - As long as PP is valid keep wakeup on

The output can supply about 1A and 12V. When running loads larger than that (e.g. a pump) use a relay to amplify the current capability.

It depends on your vehicle architecture how you organize the wakeup. Here are some examples:

=== Basic wakeup ===
wakeup via PP enabled, WakeupPinFunc=LevelOnValidPp

# Foccci turns on as soon as even a non-powered charging cable is plugged in
# Wakeup signal is turned on
# BMS, VCU etc. is turned on (directly powered from wakeup as it can supply about 1A)
# VCU can detect via the level of the wakeup signal that a cable is plugged in and inhibit drive
# When charging cable is unplugged (as in PP lost), Wakeup is turned off and the VCU can allow driving
# If we wanted to report e.g. welded charge port relays Foccci would have to keep itself running until the car is started in drive mode again. Then something can be displayed on the instrument cluster. Of course this will time out eventually. Should be fine as you at least have to pull away from the rapid charger after charging.
# When charging is paused all ECUs stay on and consume 12V power (or HV power via DC/DC)

=== Advanced Wakeup ===
wakeup via PP disabled, WakeupPinFunc=PulseOnValidCp. Here we have a bidirectional wakeup bus. Any ECU connected to it can send or receive wakeup events and the individual ECUs can decide whether they are needed for a particular task or not.

# Foccci turns on as soon as CP PWM starts. So either a cable is being plugged in or is already plugged in and now wants to charge
# It then turns on the wakeup output for 1s and wakes up all other ECUs
# The relevant ECUs will detect that we want to charge and stay on, the other ones turn off
# If we turn on ignition the VCU is already on and in charge mode and can inhibit drive
# If charging is paused (i.e. cable plugged in but no CP PWM) and we turn on ignition the VCU wakes up the Foccci and queries PP status. If something is plugged in drive is inhbited
# If Foccci detects an error e.g. welded relays, it stores that error to flash. When woken up by the VCU it report its non-zero error code
# When charging is paused, ALL ECUs can turn off and no 12V power is consumed. When CP comes back, the cycle restarts

The second approach is more versatile but it also means all devices need to support this method.

So I think there can be an intermediate approach:

=== Semi-advanced wakeup ===
Here we only have a wakeup bus between VCU and Foccci. All other devices are powered up by other means, like VCU controlled relays. Wakeup via PP is disabled, WakeupPinFunc=LevelOnValidCp

# Foccci turns on as soon as CP PWM starts. So either a cable is being plugged in or is already plugged in and now wants to charge
# It then turns on the wakeup output this waking up the VCU
# The VCU determines via CAN message from Foccci whether we want to AC or DC charge and turns on needed components. Components needed in both cases that have low power consumption (e.g. BMS) can also be driven from the wakeup signal directly
# If we turn on ignition the VCU is already on and in charge mode and can inhibit drive
# If charging is paused (i.e. cable plugged in but no CP PWM) and we turn on ignition the VCU wakes up the Foccci and queries PP status. If something is plugged in drive is inhbited
# If Foccci detects an error e.g. welded relays, it stores that error to flash. When woken up by the VCU it report its non-zero error code
# When charging is paused, ALL ECUs will turn off and no 12V power is consumed. When CP comes back, the cycle restarts

== Configuring Foccci via CAN ==
Foccci exposes only one single CAN interface for vehicle communication and initial configuration. So we need a CAN counterpart to talk to it.

There are two main approaches to this: a) use a command line tool <ref>OIC https://openinverter.org/forum/viewtopic.php?t=2907</ref> or b) use an ESP based CAN module <ref>ESP32 CAN Web Interface https://openinverter.org/shop/index.php?route=product/product&path=59&product_id=78</ref>

Both ways require knowing Focccis so called Node Id (similar to an IP address on a local network). By default this is 22. You can enter this node id on the bottom left navigation bar.
== Parameters==
{| class="wikitable"
|'''Name'''
|'''Unit'''
| '''Min'''
|'''Max'''
|'''Default'''
| '''Description'''
|-
| colspan="6" |'''Hardware Config'''
|-
|UdcDivider
|dig/V
|0
|100
|10
|Division factor from ADC digits to V of external voltage measurement board.
In other words: The UdcDivider is the configuration parameter which defines the scaling of the physical inlet voltage measurement circuit. That's why it is only relevant if a physical inlet voltage measurement circuit is present, and if the parameter InletVtgSrc is 1, means the Foccci will measure the inlet voltage with the analog input. CAN mapping makes no sense for the UdcDivider, because it is a fix value. It is the ratio between the voltage on the inlet and the digital value on the AD converter.
|-
|EconomizerDuty
|%
| 0
|100
| 100
|Contactor economizer duty cycle. Contactors are always turned on with 12V for 1s then drop to this value. Set to 100% if your contactor has a built-in economizer
|-
|InletVtgSrc
|
|0
|2
| 0
|Inlet Voltage Source. There are three option where Foccci gets the CCS inlet voltage from:
0 - Charger output voltage (EVSEPresentVoltage) is considered equal to charge port inlet voltage 1 - Analog input U_IN_HV is used for measuring charge port inlet voltage

2 - Charge port inlet voltage is provided via CAN - don't forget to map something to InletVoltage

The InletVoltage is important for precharging, while the contactors are still open. The car (Foccci) will close the contactors, if the inlet voltage is near to the battery voltage. After closing the contactors, it is the battery voltage (besides some cable losses), and out of interest. The most straight forward solution to measure the inlet voltage is to rely on what the charging station tells us. It reports the voltage on the CCS plug in EVSEPresentVoltage. With configuring InletVtgSrc=0 we tell Foccci to use the EVSEPresentVoltage. In this case, neither an analog inlet voltage measuring circuit nor a separate gadget which provides the inlet voltage via CAN is necessary. For most users this will be fine (even OEM cars use this approach).
|-
|LockDuty
|%
| -100
| 100
|30
|H-bridge duty cycle for operating the lock. Use negative value if lock polarity is swapped
|-
| LockRunTime
|ms
|0
|10000
|1000
|Timeout for lock operation
|-
|LockClosedThresh
| dig
| 0
|4095
|0
| Lock feedback value for closed
|-
|LockOpenThresh
| dig
| 0
|4095
| 0
| Lock feedback value for open - if equal to lockclosethr no feedback is assumed and lock is operated timed
|-
| ppvariant
|
|0
|9
|0
|Various circuit variations exist for PP resistor measurement.
"0" is for the variant with 1k pull-up to 3.3V, like old the old Foccci 4.1
"1" is for the variant with 330 ohm pull-up to 5V and 3k pull-down.
"2" is for the variant with 330 ohm pull-up to 5V and NO pull-down.
Foccci 4.5 ususally has NO pulldown, except the related solder jumper was closed.
|-
|WakeupPinFunc
|
| 0
|4
|0
| Configure what the wakeup pin does. See [[Foccci#Wakeup|Wakeup]]
|-
| colspan="6" |'''Communication'''
|-
|NodeId
|
|1
|63
|22
|CANOpen node id for SDO requests
|-
|CanSpeed
|
|0
| 4
|2
|Baud rate of CAN interface 0=125k, 1=250k, 2=500k, 3=800k, 4=1M - '''when configuring this != 500k you have to change it also for your ESP web interface!'''
|-
| colspan="6" |'''Charge Parameters'''
|-
|MaxPower
|kW
|0
|1000
| 100
|Absolute maximum charge power. Foccci will announce this value in the ChargeParameterDiscoveryRequest message in the element EVMaximumPowerLimit. The charger may or may not respect this limitation.
|-
|MaxVoltage
|V
|0
|1000
|410
|Over voltage threshold. Always set about 10-20V higher then desired battery full voltage. Foccci will announce this value in the ChargeParameterDiscoveryRequest message to the charger, in the element EVMaximumVoltageLimit. The charger may or may not respect this limitation. Some chargers shut down, if this limit is reached. That's why it is recommended to set it some volts higher than the voltage which is used during normal charging.
|-
|MaxCurrent
|A
|0
|500
|125
| Absolute maximum charge current. Foccci will announce this value in the ChargeParameterDiscoveryRequest, in the element EVMaximumCurrentLimit. The charger may or may not respect this limitation.
|-
|MaxAllowedPinTemperature
|°C
|0
|120
|70
|Temperature of the CCS inlet which leads to fully reduced charge current. If the maximum of temp1, temp2, temp3 reaches this value, the charge current is cut down. Before reaching this limit, the charge current decreases linearily. If the temperature still rises and reaches 10 Kelvin more than parametrized, the charge session will be terminated.
For information purpose, the current limit caused by the temperature is visible in the spot value TempLimitedCurrent. If the limitation is effective, which means, that the BMS would have requested a higher current than the limitation, the spot value LimitationReason shows "InletHot".
In case of massive overheat (10K more than parametrized), the spotvalue StopReason will show "InletOverheat".
|-
|TargetVoltage
|V
|0
|1000
| 0
|Charge target voltage (volatile)
|-
|ChargeCurrent
|A
|0
|500
|0
| Instantaneous current setpoint (volatile) - must be written at least once per second to prevent [[Foccci#Errors|CANTIMEOUT]]
|-
|soc
|%
|0
|100
|0
|Battery SoC for display on charger (volatile)
|-
|BatteryVoltage
|V
|0
| 1000
|0
| Present battery voltage for precharge state (volatile)
|-
|enable
|
|0
|1
|1
|When 0 charging is stopped/not started (volatile) - must be written at least once per second to prevent [[Foccci#Errors|CANTIMEOUT]]
|-
|AcObcState
|
|0
|15
|0
|Feedback from OBC
|-
| colspan="6" |'''Testing'''
|-
|DemoVoltage
|V
|0
|500
|0
|Voltage for light bulb demo. To use the board without CAN, to get an constant voltage. Is ignored as long democtrl is not STANDALONE. Only values between 150V and 250V are accepted, others are treated as zero.
|-
|DemoControl
|
|0
|511
|0
|Enables the standalone demo mode if value is set to STANDALONE. In this mode, no CAN is required and the target voltages for precharge and charging loop are taken from demovtg.
|-
|ActuatorTest
|
|0
|7
|0
|Tests various outputs
|-
|logging
|
|0
|2047
|
|Selects which modules log to the serial console
|}
==Spot values ==
{| class="wikitable"
|+
!Name
!Unit
!Description
|-
|opmode
|
|State of the CCS state machine
|-
|version
|
|
|-
|lasterr
|
|Last detected error
|-
|EvseVoltage
|V
|Outlet voltage reported by EVSE
|-
|EvseCurrent
|A
|Outlet current reported by EVSE
|-
|TempLimitedCurrent
|A
|Current limit calculated based on the inlet temperature
|-
|EVTargetCurrent
|A
|Current demand which is communicated to the DC charging station. Is the minimum of TempLimitedCurrent and ChargeCurrent.
|-
|LimitationReason
|
|Shows the reason why charge power is limited
|-
|InletVoltage
|V
|Charge port voltage
|-
|EvseMaxCurrent
|A
|Maximum current the EVSE can deliver
|-
|EvseMaxVoltage
|V
|Maximum voltage the EVSE can deliver
|-
|ControlPilotDuty
|%
|The PWM ratio of the CP line. This is normally 5% for DC chargers, and between 10% and 90% for analog AC chargers.
Typical values are explained here: [https://de.wikipedia.org/wiki/IEC_62196_Typ_2 IEC 62196 Typ 2 – Wikipedia]
|-
|temp1, 2, 3
|°C
|Temperatures of the temperature sensors. Requires correct calibration values depending on the used NTC types.
|-
|MaxTemp
|°C
|Maximum of the above
|-
|ContactorDuty
|%
|Duty cycle of charge port contactor driver
|-
|AdcLockFeedback
|digit
|Feedback value from charge port lock
|-
|AdcProximityPilot
|digit
|Analog value of the PP line. This is the raw value of the analog-to-digital-converter in range 0 to 4095.
|-
|ResistanceProximityPilot
|ohm
|Measured resistance between PP line and ground. Requires correct setting of the parameter ppvariant.
|-
|CableCurrentLimit
|A
|Based on the PP resistance. The current limit of the charging cable for AC charging.
|-
|EvseCurrentLimit
|A
|Based on the CP PWM. The current limit of the charging station for AC charging.
|-
|AdcHwVariant
|digit
|raw AD value of the hardware variant coding input. Used to detect which variant of Foccci the software runs on.
|-
|AdcIpropi
|digit
|raw AD value of the current sensor for the charge port lock motor driver.
|-
|LockState
|
|State of charge port lock
|-
|StopReason
|
|shows the reason why the charging session stopped
|-
|checkpoint
|
|shows the progress of the charging session in detail. Explanation here: https://github.com/uhi22/pyPLC?tab=readme-ov-file#example-flow
|-
|CanWatchdog
|100 ms
|Time since last ChargeCurrent update. When it reaches 30 (3s) the charge session is stopped
|-
|cpuload
|
|
|}
==Errors==
The spot value "lasterr" displays the last detected error that lead to a cancellation of charging or to not starting in the first place
{| class="wikitable"
|+
!Error
!Description
|-
|CANTIMEOUT
|The ChargeCurrent or enable hasn't been updated via CAN for more than 2s
|-
|PLCTIMEOUT
|PLC communication with charger timed out
|-
|PRECTIMEOUT
|Precharging the EVSE output to specified voltage timed out or battery voltage is below minimum EVSE output voltage
|-
|LOCKTIMEOUT
|The connector lock didn't reach the desired position in time
|-
|EVSEFAULT
|The EVSE reported an error and stopped
|-
|RELAYWELDED
|A welded charge port relay was detected
|}
== Making Foccci talk CHAdeMO on the CAN side ==
A pretty straightforward way to integrate CCS charging into your vehicle is to use the existing CHAdeMO (let's call it CDM from here on) CAN messaging. CDM has pretty much all data items we need to initiate a CCS charging session, so rather than defining a new set of messages we might as well adopt it. For example, Orion BMS or Zombieverter VCU natively support CHAdeMO anyway.[[File:Can mapping chademo.png|thumb|Screenshot of CAN mapping to interface Foccci CCS with CHAdeMO]]Let's go over the items in the screenshot one by one. Note that the IDs are decimal! (256=0x100, 258=0x102, 264=0x108, 265=0x109)
*'''UdcDivider''' - Actually, here we just select some dummy item as the important bit is in the Offset field: the version. In this case I signal non-existent CDM version 10. This tells the CDM module in my car that it talks to Foccci. It then includes the battery voltage in some unused message bytes - see below.
*'''EvseVoltage''' - Transmits the charger's present output voltage back to the vehicle.
*'''EvseCurrent''' - Transmits the charger's present output current back to the vehicle.
*'''opmode''' - Observe the weird gain - this is forged to map Foccci state "CurrentDemand (13)" to CDM state "ConnectorLocked (4)". In my car's CDM module this is sufficient to initiate the charging progress. You may need to change it so that the ChargeEnable flag together with ConnectorLocked is forged (numerical value 5).
*'''EvseMaxVoltage''' - Transmits the EVSE's maximum output voltage back to the vehicle.
*'''EvseMaxCurrent''' - Transmits the EVSE's maximum output current back to the vehicle.
*'''BatteryVoltage''' - Transmits the present battery voltage to the EVSE. This is the special item that normally doesn't exist in CDM and that unfortunately will prevent you from using this solution with an OEM car in a safe manner. Of course, you could manually set this to some medium battery voltage like 360V, but if you arrive with a really low battery at, say, 300V this might weld your charge port contactors. You could also manually enter the battery voltage before each charging session.
*'''TargetVoltage''' - Transmits the charge end voltage to the EVSE.
*'''ChargeCurrent''' - By far the most important data item: the charge current request.
*'''soc''' - In CDM this isn't normally a percentage value but some encoded kWh value. In my car's CDM module I specify a full battery as "200" (no idea what this actually means in kWh) and thereby can just output the SoC in 0.5% steps.
*'''enable''' - The car's charge enable flag. When 0 will stop the CCS session.
As an additional safety measure you could connect CDM pin 4 (charge enable) to Foccci's button input (at least once we added an active low mode for it). It might also be worthwhile to connect pin 7 (connection check) to the PP input for drive away protection when CDM is plugged in but not charging (again, once we have actually implemented this).

Let's list the CHAdeMO pin mapping one by one as well:
*Pin 1 - GND
*Pin 2 (12V, charger start/stop) - 12V (I take it from cigarette lighter)
*Pin 4 (charging enable) - Foccci BUTTON
*Pin 5, 6 - Power pins, triple check correct polarity!
*Pin 7 (Connection check) - Foccci PP
*Pin 8, 9 (CAN) - Foccci CANL, CANH
*Pin 10 (charger start/stop 2) - Foccci SW1_LS
'''Attention:''' with this mapping the error flags are ignored, e.g. voltage or current mismatch.

==Making Foccci talk to boostech BMS==
The boostech BMS has a fixed CAN mapping. It doesn't expect any feedback from the CCS controller so we just keep the CHAdeMO mapping from above in case the info is needed elsewhere in the car.

The BMS sends out big endian messages hence why the length fields are negative. It does not send out a charge end voltage so we simply multiply the charge enable flag with the voltage we want. In the example 368V.
{| class="wikitable"
|+
!Item
!Direction
!ID
!Position
!Length
!Gain
!Offset
!Extended
!Remark
|-
|EvseMaxVoltage
|Transmit
|0x108 / 264
|8
|16
|1
|0
|no
|
|-
|EvseMaxCurrent
|Transmit
|0x108 / 264
|24
|8
|1
|0
|no
|
|-
|EvseVoltage
|Transmit
|0x109 / 265
|8
|16
|1
|0
|no
|
|-
|EvseCurrent
|Transmit
|0x109 / 265
|24
|8
|1
|0
|no
|
|-
|enable
|Receive
|0x310 / 784
|48
|1
|1
|0
|yes
|
|-
|BatteryVoltage
|Receive
|0x310 / 784
|15
| -16
|0.1
|0
|yes
|
|-
|soc
|Receive
|0x310 / 784
|47
| -16
|0.1
|0
|yes
|
|-
|TargetVoltage
|Receive
|0x310 / 784
|48
|1
|368
|0
|yes
|Put your desired TargetVoltage into gain
|-
|ChargeCurrent
|Receive
|0x313 / 787
|31
| -16
|0.097
|0
|yes
|This value is static, more below
|}
The boostech BMS '''lacks one critical feature''' for rapid charging: a dynamic charge limit. That means ChargeCurrent it always a fixed value that you program into the BMS. It will not cut back when cells are getting full, hot or cold. It can be somewhat mitigated by setting a sane target voltage (e.g. 4.1V x NumberOfCells). The rapid charger will then start to cut back charge current as this voltage is approached. Also by mapping the enable flag the BMS has the possibility to abort the charging session if one single cell voltage or module temperature rises above the safe threshold. In winter you will need to dial back your maximum charge current manually or heat you cells to avoid dendrites.

== Hardware detection ==
[[File:3.3v Addressing Voltage Divider.png|thumb]]
To allow software to reliably detect which version hardware it runs on, in HW version 4.1 a version indication resistor was added. As opposed to some other boards that run at 5.3V, the voltage here is 3.3V.
{| class="wikitable"
|+
!Variant
!R1
!R2
!voltage
!ADC
!-3%
!+3%
|-
| -
|47
|2,7
|0,179
|222
|216
|229
|-
| -
|47
|3,3
|0,217
|269
|261
|277
|-
| -
|47
|3,9
|0,253
|314
|304
|323
|-
| -
|47
|4,7
|0,300
|372
|361
|383
|-
| -
|47
|5,1
|0,323
|401
|389
|413
|-
| -
|47
|5,6
|0,351
|436
|423
|449
|-
| -
|47
|6,8
|0,417
|518
|502
|533
|-
| -
|47
|7,5
|0,454
|564
|547
|580
|-
|4.0 with economizer
|47
|8,2
|0,490
|608
|590
|627
|-
| -
|47
|9,1
|0,535
|664
|644
|684
|-
|4.2
|47
|10
|0,579
|718
|697
|740
|-
|4.3
|47
|12
|0,671
|833
|808
|858
|-
|4.4
|47
|15
|0,798
|991
|961
|1020
|-
|4.5 - 5.2
|47
|18
|0,914
|1134
|1100
|1168
|-
|
|47
|22
|1,052
|1306
|1266
|1345
|-
|
|47
|27
|1,204
|1494
|1449
|1539
|-
|
|47
|33
|1,361
|1689
|1639
|1740
|-
|
|47
|39
|1,497
|1857
|1801
|1913
|-
|
|47
|47
|1,650
|2048
|1986
|2109
|-
|
|47
|56
|1,794
|2226
|2160
|2293
|}
<references />
[[Category:ChaDeMo‏‎]] [[Category:CCS]] [[Category:Rapid Charging]]
[[Category:Charger]]
[[Category:OpenInverter]]

Foccci

2024-12-12T18:18:46Z

Johu: /* Parameters */

Disclaimer: This Page is still work in progress! Any information written here is a draft only and should be handled as such. Contributions more then welcome. If you have questions please ask them in the discussion section of the page or in the OpenInvert Forum.
[[File:Foccci pinout.svg|thumb|Foccci (v4.5) pinout]]

[[File:Foccci 4.5b pinout.png|thumb|Foccci 4.5b / 5 / 5.1 pinout]]
This page is about FOCCCI. FOCCCI is an open source CCS Charge Interface started by Uhi and developed by the OpenInverter Community.

Foccci is the hardware part, and on it runs the software Clara.

Here you will find documentation on the Hardware (and Clara software), where to get it (or how to build it yourself), News regarding the development and many more great things.

[https://openinverter.org/shop/index.php?route=product/product&product_id=79 Foccci for sale on OpenInverter Shop]

[https://github.com/uhi22/foccci Foccci on Github.]

[https://github.com/uhi22/ccs32clara Clara on Github.]

[https://openinverter.org/forum/viewtopic.php?t=3727 Foccci in the OpenInverter Forum.]

== Pin description ==

=== External connector ("Deutsch Header") ===
Starting version 4.5b the pins were reshuffled to allow one wiring loom going to the charge port and one to the car side. Changed pins are '''bold'''.
{| class="wikitable"
|+
!Short name
!Pin up to version 4.5a
!Pin for version 4.5b, 5, 5.1
!Description
|-
|TEMP1
|A1
|A1
|Power pin temperature sensor. It is pulled up to 3.3V with 10k and the sensor must pull down to GND. Sensor characteristics are configurable in software
|-
|TEMP2
|A2
|A2
|As above
|-
|TEMP3
|A3
|A3
|As Above
|-
|LOCKFB
|A4
|A4
|Feedback signal from connector lock. Pulled up to 3.3V with 10k, so feedback must pull down to GND. Thresholds configurable in software
|-
|IN_U_HV
|A5
|'''B10'''
|Analog input 0 to 5V, with pull-down-resistor. Can be used to measure the charge port voltage, using a converter board, e.g. the "muehlpower board"
|-
|CP
|A6
|A6
|CP (Control Pilot) pin from charge port
|-
|SW2(_LS)
|A7
|'''B4'''
|Output for charge port contactor 2. Low side switch until Foccci 4.4, high side switch starting 4.5
Controls one of the contactors to make the connection between the HV battery and the vehicle inlet.

The output can drive inductive load without additional circuits. It will clamp the turn-off voltage to ~40V. The driver has protection against shortcut and thermal overload.

The output can be configured to be just digital on/off, and can also be configured to use PWM. BUT: In Foccci versions 4.2 and 4.3 (maybe more) the output driver is only capable of slow PWM, which is hearable and may cause trouble with the contactors. So it is recommended to NOT use the PWM feature, and instead use contactors which do not require economizing or use external economizers. In case you want the PWM nevertheless, you need a external freewheeling diode.

Starting Foccci 4.5 PWM is working as intended at 18 kHz. It is a high side output starting v4.5, so the other side of the contactor must be connected to GND. Before v4.5 it is a low side output so the other side must be connected to 12V
|-
|LOCK_MOT2
|A8
|A8
|Motor driver output for charge port lock servo
|-
|LOCK_MOT1
|A9
|A9
|
|-
|PP
|A10
|'''A5'''
|PP (Proximity Pilot) pin from charge port. If you want Foccci to wake up when an unpowered charge cord is plugged in you must close JP3 to pin 1 (towards R7). There mustn't be a pull-down resistor in the charge port in this case as that would permanently keep Foccci awake
|-
|5V
|A11
|'''B11'''
|5V, 500mA e.g. for supplying voltage sense board. This is an OUTPUT of Foccci. Do not apply an external voltage source here. Foccci contains a step-down-converter from the 12V supply to this 5V output.
|-
|GND
|A12
|'''B12'''
|
|-
|CANH
|B1
|B1
|CAN communication
|-
|CANL
|B2
|B2
|
|-
|n.c.
|B3
|
|Unused pins were assigned GND in 4.5b
|-
|n.c.
|B4
|
|
|-
|GND
|B5
|B5, '''B3'''
|
|-
|SW1(_LS)
|B6
|B6
|Output for the charge port contactor 1. See description of SW2(_LS).
|-
|WAKEUP
|B7
|B7
|Wakeup bus. Momentarily (or constantly) applying 12V wakes up the board. In the other direction Foccci can wake up (or supply with up to 1A) other devices via a 12V high side switch
|-
|12V
|B8
|B8
|Supply voltage, always on. 9 to 24V are fine.
|-
|LED_RED
|B9
|'''A12'''
|Status LEDs
|-
|LED_GREEN
|B10
|'''A11'''
|
|-
|LED_BLUE
|B11
|'''A10'''
|
|-
|BUTTON
|B12
|'''A7'''
|Wakes up Foccci or stops an ongoing charging session
|}

=== Internal connectors ===
{| class="wikitable"
|+
!short name
!description
|-
|UART TX
|Provides logging information, 921600 Baud. See also https://github.com/uhi22/ccs32clara/blob/main/doc/clara_user_manual.md#serial-logging
|-
|UART RX
|Not used
|-
|SWCLK
|for flashing with STLINK
|-
|SWDIO
|for flashing with STLINK
|}
== Integrating Foccci with your car/BMS==
[[File:Foccci CCS2.png|thumb|Foccci with (Orion) BMS]]
Depending on your use case Foccci has to communicate with one or more components in your car. All in-car communication happens via a single CAN bus.
===Basic communication considerations ===
Foccci can be configured to run at various baud rates and defaults to 500k. The Wifi interface mentioned below is hard coded to 500k. So when configuring a different baud rate you will loose communication with the Wifi interface. This might be fixed in the future by allowing variable baud rates for the wifi interface. Bottom line: '''keep it at 500k.'''

Apart from that it is mostly sufficient if Foccci can communicate, or more precisely, listen to the BMS. Foccci uses the flexible [[CAN communication|CAN mapping]] known from other OI firmware. There are 5 key parameters that need to be received via CAN:
*'''ChargeCurrent''': this is the single most important item. It is directly relayed to the charger and specifies the current the battery can accept at the given moment. This depends on battery voltage, temperature and other things to be determined by the BMS. ''Foccci itself does no battery monitoring of any kind, it is completely down to the BMS to specify a safe charge current'''''.''' When this value is not updated for more than 2 seconds the charging session is terminated.
* '''BatteryVoltage''': this item is important for precharging the CCS chargers output to the momentary battery voltage. Most BMSes output the total pack voltage in a CAN message
* '''TargetVoltage''': In theory this is the maximum voltage you want the battery to be charged to. In practise the maximum battery voltage MUST be governed by specifying an appropriate ChargeCurrent. More importantly many chargers cut back charge power when ''approaching'' this voltage resulting in poor charging performance towards the top end. So in practise you want to set this to a voltage about 10V above charge end voltage of your battery.
*'''soc''': This is purely informative as far as we know. It displays the batteries state of charge on the chargers display
*'''enable''': this is optional as it defaults to always enabled. It can be used to completely terminate the charging session by setting it to 0.
===Using Foccci as a charge coordinator===
This topic is still work in progress. The CCS connector, as its name suggests, combines both AC and DC charging in one socket. As long as we use the socket only for DC charging it is very easy to wire up. But once we also use the AC functionality we have to spend further thought on this.

The two pins PP and CP communicate information about the cable limit and the momentary current limit of the AC outlet. PP is a simple resistor between PE and PP that is evaluated by putting a test current onto it. This concludes that this signal can only be used by one device. CP is a bit more complex. When plugging in it communicates with a 2k7 resistor to PE that the cable is now connected to a car. From this simple fact we can again conclude that CP is a peer-to-peer signal only. Once the car is ready to charge it switches another 1k3 resistor in parallel to the 2k7 resistor. Only then the AC voltage is switched to the power pins. Lastly, the AC outlet encodes the momentary current limit in a PWM duty cycle.

Foccci does all the evaluation and makes the result available as spot values that can in turn be mapped to CAN:
*EvseAcCurrentLimit
*CableCurrentLimit
To activate the 1k3 resistor aka activating the AC outlet we map AcObcState. It must be set to 2 for activation.

Some chargers want to evaluate the CP (and perhaps PP) signal themselves. This issue can be solved with a change over switch that disconnects Foccci from CP while AC charging. Alternatively the CP signal can be spoofed and the charge current controlled by CAN to satisfy the limits of the AC outlet (EVSE).
== Wakeup ==
For charging it is particularly interesting to wake up Foccci itself and necessary subsystems <ref>https://openinverter.org/forum/viewtopic.php?p=66547#p66547</ref> when plugging in a charge cord. To allow for this, Foccci has various wakeup sources and also can wake up other devices. For wakeup to work, Foccci must be permanently supplied with 12V (it will draw no current when asleep). '''Hardware version V4.5 and above required for wakeup.'''

Here are the sources:

# Wakeup pin - bidirectional - level triggered (12V)
# Button - level triggered (GND)
# PP - optional via solder bridge - level triggered
# CP - Edge triggered

So the first 3 inputs will force the Foccci on. It can't turn itself off as long as that wakeup source is active. The last input will only trigger when transitioning from invalid to valid PWM and then Foccci can decide how long to stay awake. All modes always work regardless of software settings - except PP wakeup which can be turned off in hardware (JP3).

The wakeup output on the other hand is software-defined. Foccci offers the following options

# '''Level''' - as long as the Foccci doesn't decide to turn off, we keep Wakeup on as well
# '''Pulse''' - When Foccci boots generate a 1s wakeup pulse
# '''LevelOnValidCp''' - As long as CP is pulsing we keep wakeup on
# '''PulseOnValidCp''' - Whenever we transition from non-pulsing to pulsing CP we generate a 1s pulse
# '''LevelOnValidPp''' - As long as PP is valid keep wakeup on

The output can supply about 1A and 12V. When running loads larger than that (e.g. a pump) use a relay to amplify the current capability.

It depends on your vehicle architecture how you organize the wakeup. Here are some examples:

=== Basic wakeup ===
wakeup via PP enabled, WakeupPinFunc=LevelOnValidPp

# Foccci turns on as soon as even a non-powered charging cable is plugged in
# Wakeup signal is turned on
# BMS, VCU etc. is turned on (directly powered from wakeup as it can supply about 1A)
# VCU can detect via the level of the wakeup signal that a cable is plugged in and inhibit drive
# When charging cable is unplugged (as in PP lost), Wakeup is turned off and the VCU can allow driving
# If we wanted to report e.g. welded charge port relays Foccci would have to keep itself running until the car is started in drive mode again. Then something can be displayed on the instrument cluster. Of course this will time out eventually. Should be fine as you at least have to pull away from the rapid charger after charging.
# When charging is paused all ECUs stay on and consume 12V power (or HV power via DC/DC)

=== Advanced Wakeup ===
wakeup via PP disabled, WakeupPinFunc=PulseOnValidCp. Here we have a bidirectional wakeup bus. Any ECU connected to it can send or receive wakeup events and the individual ECUs can decide whether they are needed for a particular task or not.

# Foccci turns on as soon as CP PWM starts. So either a cable is being plugged in or is already plugged in and now wants to charge
# It then turns on the wakeup output for 1s and wakes up all other ECUs
# The relevant ECUs will detect that we want to charge and stay on, the other ones turn off
# If we turn on ignition the VCU is already on and in charge mode and can inhibit drive
# If charging is paused (i.e. cable plugged in but no CP PWM) and we turn on ignition the VCU wakes up the Foccci and queries PP status. If something is plugged in drive is inhbited
# If Foccci detects an error e.g. welded relays, it stores that error to flash. When woken up by the VCU it report its non-zero error code
# When charging is paused, ALL ECUs can turn off and no 12V power is consumed. When CP comes back, the cycle restarts

The second approach is more versatile but it also means all devices need to support this method.

So I think there can be an intermediate approach:

=== Semi-advanced wakeup ===
Here we only have a wakeup bus between VCU and Foccci. All other devices are powered up by other means, like VCU controlled relays. Wakeup via PP is disabled, WakeupPinFunc=LevelOnValidCp

# Foccci turns on as soon as CP PWM starts. So either a cable is being plugged in or is already plugged in and now wants to charge
# It then turns on the wakeup output this waking up the VCU
# The VCU determines via CAN message from Foccci whether we want to AC or DC charge and turns on needed components. Components needed in both cases that have low power consumption (e.g. BMS) can also be driven from the wakeup signal directly
# If we turn on ignition the VCU is already on and in charge mode and can inhibit drive
# If charging is paused (i.e. cable plugged in but no CP PWM) and we turn on ignition the VCU wakes up the Foccci and queries PP status. If something is plugged in drive is inhbited
# If Foccci detects an error e.g. welded relays, it stores that error to flash. When woken up by the VCU it report its non-zero error code
# When charging is paused, ALL ECUs will turn off and no 12V power is consumed. When CP comes back, the cycle restarts

== Configuring Foccci via CAN ==
Foccci exposes only one single CAN interface for vehicle communication and initial configuration. So we need a CAN counterpart to talk to it.

There are two main approaches to this: a) use a command line tool <ref>OIC https://openinverter.org/forum/viewtopic.php?t=2907</ref> or b) use an ESP based CAN module <ref>ESP32 CAN Web Interface https://openinverter.org/shop/index.php?route=product/product&path=59&product_id=78</ref>

Both ways require knowing Focccis so called Node Id (similar to an IP address on a local network). By default this is 22. You can enter this node id on the bottom left navigation bar.
== Parameters==
{| class="wikitable"
|'''Name'''
|'''Unit'''
| '''Min'''
|'''Max'''
|'''Default'''
| '''Description'''
|-
| colspan="6" |'''Hardware Config'''
|-
|UdcDivider
|dig/V
|0
|100
|10
|Division factor from ADC digits to V of external voltage measurement board.
In other words: The UdcDivider is the configuration parameter which defines the scaling of the physical inlet voltage measurement circuit. That's why it is only relevant if a physical inlet voltage measurement circuit is present, and if the parameter InletVtgSrc is 1, means the Foccci will measure the inlet voltage with the analog input. CAN mapping makes no sense for the UdcDivider, because it is a fix value. It is the ratio between the voltage on the inlet and the digital value on the AD converter.
|-
|EconomizerDuty
|%
| 0
|100
| 100
|Contactor economizer duty cycle. Contactors are always turned on with 12V for 1s then drop to this value. Set to 100% if your contactor has a built-in economizer
|-
|InletVtgSrc
|
|0
|2
| 0
|Inlet Voltage Source. There are three option where Foccci gets the CCS inlet voltage from:
0 - Charger output voltage (EVSEPresentVoltage) is considered equal to charge port inlet voltage 1 - Analog input U_IN_HV is used for measuring charge port inlet voltage

2 - Charge port inlet voltage is provided via CAN - don't forget to map something to InletVoltage

The InletVoltage is important for precharging, while the contactors are still open. The car (Foccci) will close the contactors, if the inlet voltage is near to the battery voltage. After closing the contactors, it is the battery voltage (besides some cable losses), and out of interest. The most straight forward solution to measure the inlet voltage is to rely on what the charging station tells us. It reports the voltage on the CCS plug in EVSEPresentVoltage. With configuring InletVtgSrc=0 we tell Foccci to use the EVSEPresentVoltage. In this case, neither an analog inlet voltage measuring circuit nor a separate gadget which provides the inlet voltage via CAN is necessary. For most users this will be fine (even OEM cars use this approach).
|-
|LockDuty
|%
| -100
| 100
|30
|H-bridge duty cycle for operating the lock. Use negative value if lock polarity is swapped
|-
| LockRunTime
|ms
|0
|10000
|1000
|Timeout for lock operation
|-
|LockClosedThresh
| dig
| 0
|4095
|0
| Lock feedback value for closed
|-
|LockOpenThresh
| dig
| 0
|4095
| 0
| Lock feedback value for open - if equal to lockclosethr no feedback is assumed and lock is operated timed
|-
| ppvariant
|
|0
|9
|0
|Various circuit variations exist for PP resistor measurement.
"0" is for the variant with 1k pull-up to 3.3V, like old the old Foccci 4.1
"1" is for the variant with 330 ohm pull-up to 5V and 3k pull-down.
"2" is for the variant with 330 ohm pull-up to 5V and NO pull-down.
Foccci 4.5 ususally has NO pulldown, except the related solder jumper was closed.
|-
|WakeupPinFunc
|
| 0
|4
|0
| Configure what the wakeup pin does. See [[Foccci#Wakeup|Wakeup]]
|-
| colspan="6" |'''Communication'''
|-
|NodeId
|
|1
|63
|22
|CANOpen node id for SDO requests
|-
|CanSpeed
|
|0
| 4
|2
|Baud rate of CAN interface 0=125k, 1=250k, 2=500k, 3=800k, 4=1M - '''when configuring this != 500k you have to change it also for your ESP web interface!'''
|-
| colspan="6" |'''Charge Parameters'''
|-
|MaxPower
|kW
|0
|1000
| 100
|Absolute maximum charge power. Foccci will announce this value in the ChargeParameterDiscoveryRequest message in the element EVMaximumPowerLimit. The charger may or may not respect this limitation.
|-
|MaxVoltage
|V
|0
|1000
|410
|Over voltage threshold. Always set about 10-20V higher then desired battery full voltage. Foccci will announce this value in the ChargeParameterDiscoveryRequest message to the charger, in the element EVMaximumVoltageLimit. The charger may or may not respect this limitation. Some chargers shut down, if this limit is reached. That's why it is recommended to set it some volts higher than the voltage which is used during normal charging.
|-
|MaxCurrent
|A
|0
|500
|125
| Absolute maximum charge current. Foccci will announce this value in the ChargeParameterDiscoveryRequest, in the element EVMaximumCurrentLimit. The charger may or may not respect this limitation.
|-
|MaxAllowedPinTemperature
|°C
|0
|120
|70
|Temperature of the CCS inlet which leads to fully reduced charge current. If the maximum of temp1, temp2, temp3 reaches this value, the charge current is cut down. Before reaching this limit, the charge current decreases linearily. If the temperature still rises and reaches 10 Kelvin more than parametrized, the charge session will be terminated.
For information purpose, the current limit caused by the temperature is visible in the spot value TempLimitedCurrent. If the limitation is effective, which means, that the BMS would have requested a higher current than the limitation, the spot value LimitationReason shows "InletHot".
In case of massive overheat (10K more than parametrized), the spotvalue StopReason will show "InletOverheat".
|-
|TargetVoltage
|V
|0
|1000
| 0
|Charge target voltage (volatile)
|-
|ChargeCurrent
|A
|0
|500
|0
| Instantaneous current setpoint (volatile) - must be written at least once per second to prevent [[Foccci#Errors|CANTIMEOUT]]
|-
|soc
|%
|0
|100
|0
|Battery SoC for display on charger (volatile)
|-
|BatteryVoltage
|V
|0
| 1000
|0
| Present battery voltage for precharge state (volatile)
|-
|enable
|
|0
|1
|1
|When 0 charging is stopped/not started (volatile) - must be written at least once per second to prevent [[Foccci#Errors|CANTIMEOUT]]
|-
|AcObcState
|
|0
|15
|0
|Feedback from OBC
|-
| colspan="6" |'''Testing'''
|-
|DemoVoltage
|V
|0
|500
|0
|Voltage for light bulb demo. To use the board without CAN, to get an constant voltage. Is ignored as long democtrl is not STANDALONE. Only values between 150V and 250V are accepted, others are treated as zero.
|-
|DemoControl
|
|0
|511
|0
|Enables the standalone demo mode if value is set to STANDALONE. In this mode, no CAN is required and the target voltages for precharge and charging loop are taken from demovtg.
|-
|ActuatorTest
|
|0
|7
|0
|Tests various outputs
|-
|logging
|
|0
|2047
|
|Selects which modules log to the serial console
|}
==Spot values ==
{| class="wikitable"
|+
!Name
!Unit
!Description
|-
|opmode
|
|State of the CCS state machine
|-
|version
|
|
|-
|lasterr
|
|Last detected error
|-
|EvseVoltage
|V
|Outlet voltage reported by EVSE
|-
|EvseCurrent
|A
|Outlet current reported by EVSE
|-
|TempLimitedCurrent
|A
|Current limit calculated based on the inlet temperature
|-
|EVTargetCurrent
|A
|Current demand which is communicated to the DC charging station. Is the minimum of TempLimitedCurrent and ChargeCurrent.
|-
|LimitationReason
|
|Shows the reason why charge power is limited
|-
|InletVoltage
|V
|Charge port voltage
|-
|EvseMaxCurrent
|A
|Maximum current the EVSE can deliver
|-
|EvseMaxVoltage
|V
|Maximum voltage the EVSE can deliver
|-
|ControlPilotDuty
|%
|The PWM ratio of the CP line. This is normally 5% for DC chargers, and between 10% and 90% for analog AC chargers.
Typical values are explained here: [https://de.wikipedia.org/wiki/IEC_62196_Typ_2 IEC 62196 Typ 2 – Wikipedia]
|-
|temp1, 2, 3
|°C
|Temperatures of the temperature sensors. Requires correct calibration values depending on the used NTC types.
|-
|MaxTemp
|°C
|Maximum of the above
|-
|ContactorDuty
|%
|Duty cycle of charge port contactor driver
|-
|AdcLockFeedback
|digit
|Feedback value from charge port lock
|-
|AdcProximityPilot
|digit
|Analog value of the PP line. This is the raw value of the analog-to-digital-converter in range 0 to 4095.
|-
|ResistanceProximityPilot
|ohm
|Measured resistance between PP line and ground. Requires correct setting of the parameter ppvariant.
|-
|CableCurrentLimit
|A
|Based on the PP resistance. The current limit of the charging cable for AC charging.
|-
|EvseCurrentLimit
|A
|Based on the CP PWM. The current limit of the charging station for AC charging.
|-
|AdcHwVariant
|digit
|raw AD value of the hardware variant coding input. Used to detect which variant of Foccci the software runs on.
|-
|AdcIpropi
|digit
|raw AD value of the current sensor for the charge port lock motor driver.
|-
|LockState
|
|State of charge port lock
|-
|StopReason
|
|shows the reason why the charging session stopped
|-
|checkpoint
|
|shows the progress of the charging session in detail. Explanation here: https://github.com/uhi22/pyPLC?tab=readme-ov-file#example-flow
|-
|CanWatchdog
|100 ms
|Time since last ChargeCurrent update. When it reaches 30 (3s) the charge session is stopped
|-
|cpuload
|
|
|}
==Errors==
The spot value "lasterr" displays the last detected error that lead to a cancellation of charging or to not starting in the first place
{| class="wikitable"
|+
!Error
!Description
|-
|CANTIMEOUT
|The ChargeCurrent hasn't been updated via CAN for more than 2s
|-
|PLCTIMEOUT
|PLC communication with charger timed out
|-
|PRECTIMEOUT
|Precharging the EVSE output to specified voltage timed out or battery voltage is below minimum EVSE output voltage
|-
|LOCKTIMEOUT
|The connector lock didn't reach the desired position in time
|-
|EVSEFAULT
|The EVSE reported an error and stopped
|-
|RELAYWELDED
|A welded charge port relay was detected
|}
== Making Foccci talk CHAdeMO on the CAN side ==
A pretty straightforward way to integrate CCS charging into your vehicle is to use the existing CHAdeMO (let's call it CDM from here on) CAN messaging. CDM has pretty much all data items we need to initiate a CCS charging session, so rather than defining a new set of messages we might as well adopt it. For example, Orion BMS or Zombieverter VCU natively support CHAdeMO anyway.[[File:Can mapping chademo.png|thumb|Screenshot of CAN mapping to interface Foccci CCS with CHAdeMO]]Let's go over the items in the screenshot one by one. Note that the IDs are decimal! (256=0x100, 258=0x102, 264=0x108, 265=0x109)
*'''UdcDivider''' - Actually, here we just select some dummy item as the important bit is in the Offset field: the version. In this case I signal non-existent CDM version 10. This tells the CDM module in my car that it talks to Foccci. It then includes the battery voltage in some unused message bytes - see below.
*'''EvseVoltage''' - Transmits the charger's present output voltage back to the vehicle.
*'''EvseCurrent''' - Transmits the charger's present output current back to the vehicle.
*'''opmode''' - Observe the weird gain - this is forged to map Foccci state "CurrentDemand (13)" to CDM state "ConnectorLocked (4)". In my car's CDM module this is sufficient to initiate the charging progress. You may need to change it so that the ChargeEnable flag together with ConnectorLocked is forged (numerical value 5).
*'''EvseMaxVoltage''' - Transmits the EVSE's maximum output voltage back to the vehicle.
*'''EvseMaxCurrent''' - Transmits the EVSE's maximum output current back to the vehicle.
*'''BatteryVoltage''' - Transmits the present battery voltage to the EVSE. This is the special item that normally doesn't exist in CDM and that unfortunately will prevent you from using this solution with an OEM car in a safe manner. Of course, you could manually set this to some medium battery voltage like 360V, but if you arrive with a really low battery at, say, 300V this might weld your charge port contactors. You could also manually enter the battery voltage before each charging session.
*'''TargetVoltage''' - Transmits the charge end voltage to the EVSE.
*'''ChargeCurrent''' - By far the most important data item: the charge current request.
*'''soc''' - In CDM this isn't normally a percentage value but some encoded kWh value. In my car's CDM module I specify a full battery as "200" (no idea what this actually means in kWh) and thereby can just output the SoC in 0.5% steps.
*'''enable''' - The car's charge enable flag. When 0 will stop the CCS session.
As an additional safety measure you could connect CDM pin 4 (charge enable) to Foccci's button input (at least once we added an active low mode for it). It might also be worthwhile to connect pin 7 (connection check) to the PP input for drive away protection when CDM is plugged in but not charging (again, once we have actually implemented this).

Let's list the CHAdeMO pin mapping one by one as well:
*Pin 1 - GND
*Pin 2 (12V, charger start/stop) - 12V (I take it from cigarette lighter)
*Pin 4 (charging enable) - Foccci BUTTON
*Pin 5, 6 - Power pins, triple check correct polarity!
*Pin 7 (Connection check) - Foccci PP
*Pin 8, 9 (CAN) - Foccci CANL, CANH
*Pin 10 (charger start/stop 2) - Foccci SW1_LS
'''Attention:''' with this mapping the error flags are ignored, e.g. voltage or current mismatch.

==Making Foccci talk to boostech BMS==
The boostech BMS has a fixed CAN mapping. It doesn't expect any feedback from the CCS controller so we just keep the CHAdeMO mapping from above in case the info is needed elsewhere in the car.

The BMS sends out big endian messages hence why the length fields are negative. It does not send out a charge end voltage so we simply multiply the charge enable flag with the voltage we want. In the example 368V.
{| class="wikitable"
|+
!Item
!Direction
!ID
!Position
!Length
!Gain
!Offset
!Extended
!Remark
|-
|EvseMaxVoltage
|Transmit
|0x108 / 264
|8
|16
|1
|0
|no
|
|-
|EvseMaxCurrent
|Transmit
|0x108 / 264
|24
|8
|1
|0
|no
|
|-
|EvseVoltage
|Transmit
|0x109 / 265
|8
|16
|1
|0
|no
|
|-
|EvseCurrent
|Transmit
|0x109 / 265
|24
|8
|1
|0
|no
|
|-
|enable
|Receive
|0x310 / 784
|48
|1
|1
|0
|yes
|
|-
|BatteryVoltage
|Receive
|0x310 / 784
|15
| -16
|0.1
|0
|yes
|
|-
|soc
|Receive
|0x310 / 784
|47
| -16
|0.1
|0
|yes
|
|-
|TargetVoltage
|Receive
|0x310 / 784
|48
|1
|368
|0
|yes
|Put your desired TargetVoltage into gain
|-
|ChargeCurrent
|Receive
|0x313 / 787
|31
| -16
|0.097
|0
|yes
|This value is static, more below
|}
The boostech BMS '''lacks one critical feature''' for rapid charging: a dynamic charge limit. That means ChargeCurrent it always a fixed value that you program into the BMS. It will not cut back when cells are getting full, hot or cold. It can be somewhat mitigated by setting a sane target voltage (e.g. 4.1V x NumberOfCells). The rapid charger will then start to cut back charge current as this voltage is approached. Also by mapping the enable flag the BMS has the possibility to abort the charging session if one single cell voltage or module temperature rises above the safe threshold. In winter you will need to dial back your maximum charge current manually or heat you cells to avoid dendrites.

== Hardware detection ==
[[File:3.3v Addressing Voltage Divider.png|thumb]]
To allow software to reliably detect which version hardware it runs on, in HW version 4.1 a version indication resistor was added. As opposed to some other boards that run at 5.3V, the voltage here is 3.3V.
{| class="wikitable"
|+
!Variant
!R1
!R2
!voltage
!ADC
!-3%
!+3%
|-
| -
|47
|2,7
|0,179
|222
|216
|229
|-
| -
|47
|3,3
|0,217
|269
|261
|277
|-
| -
|47
|3,9
|0,253
|314
|304
|323
|-
| -
|47
|4,7
|0,300
|372
|361
|383
|-
| -
|47
|5,1
|0,323
|401
|389
|413
|-
| -
|47
|5,6
|0,351
|436
|423
|449
|-
| -
|47
|6,8
|0,417
|518
|502
|533
|-
| -
|47
|7,5
|0,454
|564
|547
|580
|-
|4.0 with economizer
|47
|8,2
|0,490
|608
|590
|627
|-
| -
|47
|9,1
|0,535
|664
|644
|684
|-
|4.2
|47
|10
|0,579
|718
|697
|740
|-
|4.3
|47
|12
|0,671
|833
|808
|858
|-
|4.4
|47
|15
|0,798
|991
|961
|1020
|-
|4.5 - 5.2
|47
|18
|0,914
|1134
|1100
|1168
|-
|
|47
|22
|1,052
|1306
|1266
|1345
|-
|
|47
|27
|1,204
|1494
|1449
|1539
|-
|
|47
|33
|1,361
|1689
|1639
|1740
|-
|
|47
|39
|1,497
|1857
|1801
|1913
|-
|
|47
|47
|1,650
|2048
|1986
|2109
|-
|
|47
|56
|1,794
|2226
|2160
|2293
|}
<references />
[[Category:ChaDeMo‏‎]] [[Category:CCS]] [[Category:Rapid Charging]]
[[Category:Charger]]
[[Category:OpenInverter]]

Foccci

2024-12-12T18:18:08Z

Johu: Added hint about CANTIMEOUT

Disclaimer: This Page is still work in progress! Any information written here is a draft only and should be handled as such. Contributions more then welcome. If you have questions please ask them in the discussion section of the page or in the OpenInvert Forum.
[[File:Foccci pinout.svg|thumb|Foccci (v4.5) pinout]]

[[File:Foccci 4.5b pinout.png|thumb|Foccci 4.5b / 5 / 5.1 pinout]]
This page is about FOCCCI. FOCCCI is an open source CCS Charge Interface started by Uhi and developed by the OpenInverter Community.

Foccci is the hardware part, and on it runs the software Clara.

Here you will find documentation on the Hardware (and Clara software), where to get it (or how to build it yourself), News regarding the development and many more great things.

[https://openinverter.org/shop/index.php?route=product/product&product_id=79 Foccci for sale on OpenInverter Shop]

[https://github.com/uhi22/foccci Foccci on Github.]

[https://github.com/uhi22/ccs32clara Clara on Github.]

[https://openinverter.org/forum/viewtopic.php?t=3727 Foccci in the OpenInverter Forum.]

== Pin description ==

=== External connector ("Deutsch Header") ===
Starting version 4.5b the pins were reshuffled to allow one wiring loom going to the charge port and one to the car side. Changed pins are '''bold'''.
{| class="wikitable"
|+
!Short name
!Pin up to version 4.5a
!Pin for version 4.5b, 5, 5.1
!Description
|-
|TEMP1
|A1
|A1
|Power pin temperature sensor. It is pulled up to 3.3V with 10k and the sensor must pull down to GND. Sensor characteristics are configurable in software
|-
|TEMP2
|A2
|A2
|As above
|-
|TEMP3
|A3
|A3
|As Above
|-
|LOCKFB
|A4
|A4
|Feedback signal from connector lock. Pulled up to 3.3V with 10k, so feedback must pull down to GND. Thresholds configurable in software
|-
|IN_U_HV
|A5
|'''B10'''
|Analog input 0 to 5V, with pull-down-resistor. Can be used to measure the charge port voltage, using a converter board, e.g. the "muehlpower board"
|-
|CP
|A6
|A6
|CP (Control Pilot) pin from charge port
|-
|SW2(_LS)
|A7
|'''B4'''
|Output for charge port contactor 2. Low side switch until Foccci 4.4, high side switch starting 4.5
Controls one of the contactors to make the connection between the HV battery and the vehicle inlet.

The output can drive inductive load without additional circuits. It will clamp the turn-off voltage to ~40V. The driver has protection against shortcut and thermal overload.

The output can be configured to be just digital on/off, and can also be configured to use PWM. BUT: In Foccci versions 4.2 and 4.3 (maybe more) the output driver is only capable of slow PWM, which is hearable and may cause trouble with the contactors. So it is recommended to NOT use the PWM feature, and instead use contactors which do not require economizing or use external economizers. In case you want the PWM nevertheless, you need a external freewheeling diode.

Starting Foccci 4.5 PWM is working as intended at 18 kHz. It is a high side output starting v4.5, so the other side of the contactor must be connected to GND. Before v4.5 it is a low side output so the other side must be connected to 12V
|-
|LOCK_MOT2
|A8
|A8
|Motor driver output for charge port lock servo
|-
|LOCK_MOT1
|A9
|A9
|
|-
|PP
|A10
|'''A5'''
|PP (Proximity Pilot) pin from charge port. If you want Foccci to wake up when an unpowered charge cord is plugged in you must close JP3 to pin 1 (towards R7). There mustn't be a pull-down resistor in the charge port in this case as that would permanently keep Foccci awake
|-
|5V
|A11
|'''B11'''
|5V, 500mA e.g. for supplying voltage sense board. This is an OUTPUT of Foccci. Do not apply an external voltage source here. Foccci contains a step-down-converter from the 12V supply to this 5V output.
|-
|GND
|A12
|'''B12'''
|
|-
|CANH
|B1
|B1
|CAN communication
|-
|CANL
|B2
|B2
|
|-
|n.c.
|B3
|
|Unused pins were assigned GND in 4.5b
|-
|n.c.
|B4
|
|
|-
|GND
|B5
|B5, '''B3'''
|
|-
|SW1(_LS)
|B6
|B6
|Output for the charge port contactor 1. See description of SW2(_LS).
|-
|WAKEUP
|B7
|B7
|Wakeup bus. Momentarily (or constantly) applying 12V wakes up the board. In the other direction Foccci can wake up (or supply with up to 1A) other devices via a 12V high side switch
|-
|12V
|B8
|B8
|Supply voltage, always on. 9 to 24V are fine.
|-
|LED_RED
|B9
|'''A12'''
|Status LEDs
|-
|LED_GREEN
|B10
|'''A11'''
|
|-
|LED_BLUE
|B11
|'''A10'''
|
|-
|BUTTON
|B12
|'''A7'''
|Wakes up Foccci or stops an ongoing charging session
|}

=== Internal connectors ===
{| class="wikitable"
|+
!short name
!description
|-
|UART TX
|Provides logging information, 921600 Baud. See also https://github.com/uhi22/ccs32clara/blob/main/doc/clara_user_manual.md#serial-logging
|-
|UART RX
|Not used
|-
|SWCLK
|for flashing with STLINK
|-
|SWDIO
|for flashing with STLINK
|}
== Integrating Foccci with your car/BMS==
[[File:Foccci CCS2.png|thumb|Foccci with (Orion) BMS]]
Depending on your use case Foccci has to communicate with one or more components in your car. All in-car communication happens via a single CAN bus.
===Basic communication considerations ===
Foccci can be configured to run at various baud rates and defaults to 500k. The Wifi interface mentioned below is hard coded to 500k. So when configuring a different baud rate you will loose communication with the Wifi interface. This might be fixed in the future by allowing variable baud rates for the wifi interface. Bottom line: '''keep it at 500k.'''

Apart from that it is mostly sufficient if Foccci can communicate, or more precisely, listen to the BMS. Foccci uses the flexible [[CAN communication|CAN mapping]] known from other OI firmware. There are 5 key parameters that need to be received via CAN:
*'''ChargeCurrent''': this is the single most important item. It is directly relayed to the charger and specifies the current the battery can accept at the given moment. This depends on battery voltage, temperature and other things to be determined by the BMS. ''Foccci itself does no battery monitoring of any kind, it is completely down to the BMS to specify a safe charge current'''''.''' When this value is not updated for more than 2 seconds the charging session is terminated.
* '''BatteryVoltage''': this item is important for precharging the CCS chargers output to the momentary battery voltage. Most BMSes output the total pack voltage in a CAN message
* '''TargetVoltage''': In theory this is the maximum voltage you want the battery to be charged to. In practise the maximum battery voltage MUST be governed by specifying an appropriate ChargeCurrent. More importantly many chargers cut back charge power when ''approaching'' this voltage resulting in poor charging performance towards the top end. So in practise you want to set this to a voltage about 10V above charge end voltage of your battery.
*'''soc''': This is purely informative as far as we know. It displays the batteries state of charge on the chargers display
*'''enable''': this is optional as it defaults to always enabled. It can be used to completely terminate the charging session by setting it to 0.
===Using Foccci as a charge coordinator===
This topic is still work in progress. The CCS connector, as its name suggests, combines both AC and DC charging in one socket. As long as we use the socket only for DC charging it is very easy to wire up. But once we also use the AC functionality we have to spend further thought on this.

The two pins PP and CP communicate information about the cable limit and the momentary current limit of the AC outlet. PP is a simple resistor between PE and PP that is evaluated by putting a test current onto it. This concludes that this signal can only be used by one device. CP is a bit more complex. When plugging in it communicates with a 2k7 resistor to PE that the cable is now connected to a car. From this simple fact we can again conclude that CP is a peer-to-peer signal only. Once the car is ready to charge it switches another 1k3 resistor in parallel to the 2k7 resistor. Only then the AC voltage is switched to the power pins. Lastly, the AC outlet encodes the momentary current limit in a PWM duty cycle.

Foccci does all the evaluation and makes the result available as spot values that can in turn be mapped to CAN:
*EvseAcCurrentLimit
*CableCurrentLimit
To activate the 1k3 resistor aka activating the AC outlet we map AcObcState. It must be set to 2 for activation.

Some chargers want to evaluate the CP (and perhaps PP) signal themselves. This issue can be solved with a change over switch that disconnects Foccci from CP while AC charging. Alternatively the CP signal can be spoofed and the charge current controlled by CAN to satisfy the limits of the AC outlet (EVSE).
== Wakeup ==
For charging it is particularly interesting to wake up Foccci itself and necessary subsystems <ref>https://openinverter.org/forum/viewtopic.php?p=66547#p66547</ref> when plugging in a charge cord. To allow for this, Foccci has various wakeup sources and also can wake up other devices. For wakeup to work, Foccci must be permanently supplied with 12V (it will draw no current when asleep). '''Hardware version V4.5 and above required for wakeup.'''

Here are the sources:

# Wakeup pin - bidirectional - level triggered (12V)
# Button - level triggered (GND)
# PP - optional via solder bridge - level triggered
# CP - Edge triggered

So the first 3 inputs will force the Foccci on. It can't turn itself off as long as that wakeup source is active. The last input will only trigger when transitioning from invalid to valid PWM and then Foccci can decide how long to stay awake. All modes always work regardless of software settings - except PP wakeup which can be turned off in hardware (JP3).

The wakeup output on the other hand is software-defined. Foccci offers the following options

# '''Level''' - as long as the Foccci doesn't decide to turn off, we keep Wakeup on as well
# '''Pulse''' - When Foccci boots generate a 1s wakeup pulse
# '''LevelOnValidCp''' - As long as CP is pulsing we keep wakeup on
# '''PulseOnValidCp''' - Whenever we transition from non-pulsing to pulsing CP we generate a 1s pulse
# '''LevelOnValidPp''' - As long as PP is valid keep wakeup on

The output can supply about 1A and 12V. When running loads larger than that (e.g. a pump) use a relay to amplify the current capability.

It depends on your vehicle architecture how you organize the wakeup. Here are some examples:

=== Basic wakeup ===
wakeup via PP enabled, WakeupPinFunc=LevelOnValidPp

# Foccci turns on as soon as even a non-powered charging cable is plugged in
# Wakeup signal is turned on
# BMS, VCU etc. is turned on (directly powered from wakeup as it can supply about 1A)
# VCU can detect via the level of the wakeup signal that a cable is plugged in and inhibit drive
# When charging cable is unplugged (as in PP lost), Wakeup is turned off and the VCU can allow driving
# If we wanted to report e.g. welded charge port relays Foccci would have to keep itself running until the car is started in drive mode again. Then something can be displayed on the instrument cluster. Of course this will time out eventually. Should be fine as you at least have to pull away from the rapid charger after charging.
# When charging is paused all ECUs stay on and consume 12V power (or HV power via DC/DC)

=== Advanced Wakeup ===
wakeup via PP disabled, WakeupPinFunc=PulseOnValidCp. Here we have a bidirectional wakeup bus. Any ECU connected to it can send or receive wakeup events and the individual ECUs can decide whether they are needed for a particular task or not.

# Foccci turns on as soon as CP PWM starts. So either a cable is being plugged in or is already plugged in and now wants to charge
# It then turns on the wakeup output for 1s and wakes up all other ECUs
# The relevant ECUs will detect that we want to charge and stay on, the other ones turn off
# If we turn on ignition the VCU is already on and in charge mode and can inhibit drive
# If charging is paused (i.e. cable plugged in but no CP PWM) and we turn on ignition the VCU wakes up the Foccci and queries PP status. If something is plugged in drive is inhbited
# If Foccci detects an error e.g. welded relays, it stores that error to flash. When woken up by the VCU it report its non-zero error code
# When charging is paused, ALL ECUs can turn off and no 12V power is consumed. When CP comes back, the cycle restarts

The second approach is more versatile but it also means all devices need to support this method.

So I think there can be an intermediate approach:

=== Semi-advanced wakeup ===
Here we only have a wakeup bus between VCU and Foccci. All other devices are powered up by other means, like VCU controlled relays. Wakeup via PP is disabled, WakeupPinFunc=LevelOnValidCp

# Foccci turns on as soon as CP PWM starts. So either a cable is being plugged in or is already plugged in and now wants to charge
# It then turns on the wakeup output this waking up the VCU
# The VCU determines via CAN message from Foccci whether we want to AC or DC charge and turns on needed components. Components needed in both cases that have low power consumption (e.g. BMS) can also be driven from the wakeup signal directly
# If we turn on ignition the VCU is already on and in charge mode and can inhibit drive
# If charging is paused (i.e. cable plugged in but no CP PWM) and we turn on ignition the VCU wakes up the Foccci and queries PP status. If something is plugged in drive is inhbited
# If Foccci detects an error e.g. welded relays, it stores that error to flash. When woken up by the VCU it report its non-zero error code
# When charging is paused, ALL ECUs will turn off and no 12V power is consumed. When CP comes back, the cycle restarts

== Configuring Foccci via CAN ==
Foccci exposes only one single CAN interface for vehicle communication and initial configuration. So we need a CAN counterpart to talk to it.

There are two main approaches to this: a) use a command line tool <ref>OIC https://openinverter.org/forum/viewtopic.php?t=2907</ref> or b) use an ESP based CAN module <ref>ESP32 CAN Web Interface https://openinverter.org/shop/index.php?route=product/product&path=59&product_id=78</ref>

Both ways require knowing Focccis so called Node Id (similar to an IP address on a local network). By default this is 22. You can enter this node id on the bottom left navigation bar.
== Parameters==
{| class="wikitable"
|'''Name'''
|'''Unit'''
| '''Min'''
|'''Max'''
|'''Default'''
| '''Description'''
|-
| colspan="6" |'''Hardware Config'''
|-
|UdcDivider
|dig/V
|0
|100
|10
|Division factor from ADC digits to V of external voltage measurement board.
In other words: The UdcDivider is the configuration parameter which defines the scaling of the physical inlet voltage measurement circuit. That's why it is only relevant if a physical inlet voltage measurement circuit is present, and if the parameter InletVtgSrc is 1, means the Foccci will measure the inlet voltage with the analog input. CAN mapping makes no sense for the UdcDivider, because it is a fix value. It is the ratio between the voltage on the inlet and the digital value on the AD converter.
|-
|EconomizerDuty
|%
| 0
|100
| 100
|Contactor economizer duty cycle. Contactors are always turned on with 12V for 1s then drop to this value. Set to 100% if your contactor has a built-in economizer
|-
|InletVtgSrc
|
|0
|2
| 0
|Inlet Voltage Source. There are three option where Foccci gets the CCS inlet voltage from:
0 - Charger output voltage (EVSEPresentVoltage) is considered equal to charge port inlet voltage 1 - Analog input U_IN_HV is used for measuring charge port inlet voltage

2 - Charge port inlet voltage is provided via CAN - don't forget to map something to InletVoltage

The InletVoltage is important for precharging, while the contactors are still open. The car (Foccci) will close the contactors, if the inlet voltage is near to the battery voltage. After closing the contactors, it is the battery voltage (besides some cable losses), and out of interest. The most straight forward solution to measure the inlet voltage is to rely on what the charging station tells us. It reports the voltage on the CCS plug in EVSEPresentVoltage. With configuring InletVtgSrc=0 we tell Foccci to use the EVSEPresentVoltage. In this case, neither an analog inlet voltage measuring circuit nor a separate gadget which provides the inlet voltage via CAN is necessary. For most users this will be fine (even OEM cars use this approach).
|-
|LockDuty
|%
| -100
| 100
|30
|H-bridge duty cycle for operating the lock. Use negative value if lock polarity is swapped
|-
| LockRunTime
|ms
|0
|10000
|1000
|Timeout for lock operation
|-
|LockClosedThresh
| dig
| 0
|4095
|0
| Lock feedback value for closed
|-
|LockOpenThresh
| dig
| 0
|4095
| 0
| Lock feedback value for open - if equal to lockclosethr no feedback is assumed and lock is operated timed
|-
| ppvariant
|
|0
|9
|0
|Various circuit variations exist for PP resistor measurement.
"0" is for the variant with 1k pull-up to 3.3V, like old the old Foccci 4.1
"1" is for the variant with 330 ohm pull-up to 5V and 3k pull-down.
"2" is for the variant with 330 ohm pull-up to 5V and NO pull-down.
Foccci 4.5 ususally has NO pulldown, except the related solder jumper was closed.
|-
|WakeupPinFunc
|
| 0
|4
|0
| Configure what the wakeup pin does. See [[Foccci#Wakeup|Wakeup]]
|-
| colspan="6" |'''Communication'''
|-
|NodeId
|
|1
|63
|22
|CANOpen node id for SDO requests
|-
|CanSpeed
|
|0
| 4
|2
|Baud rate of CAN interface 0=125k, 1=250k, 2=500k, 3=800k, 4=1M - '''when configuring this != 500k you have to change it also for your ESP web interface!'''
|-
| colspan="6" |'''Charge Parameters'''
|-
|MaxPower
|kW
|0
|1000
| 100
|Absolute maximum charge power. Foccci will announce this value in the ChargeParameterDiscoveryRequest message in the element EVMaximumPowerLimit. The charger may or may not respect this limitation.
|-
|MaxVoltage
|V
|0
|1000
|410
|Over voltage threshold. Always set about 10-20V higher then desired battery full voltage. Foccci will announce this value in the ChargeParameterDiscoveryRequest message to the charger, in the element EVMaximumVoltageLimit. The charger may or may not respect this limitation. Some chargers shut down, if this limit is reached. That's why it is recommended to set it some volts higher than the voltage which is used during normal charging.
|-
|MaxCurrent
|A
|0
|500
|125
| Absolute maximum charge current. Foccci will announce this value in the ChargeParameterDiscoveryRequest, in the element EVMaximumCurrentLimit. The charger may or may not respect this limitation.
|-
|MaxAllowedPinTemperature
|°C
|0
|120
|70
|Temperature of the CCS inlet which leads to fully reduced charge current. If the maximum of temp1, temp2, temp3 reaches this value, the charge current is cut down. Before reaching this limit, the charge current decreases linearily. If the temperature still rises and reaches 10 Kelvin more than parametrized, the charge session will be terminated.
For information purpose, the current limit caused by the temperature is visible in the spot value TempLimitedCurrent. If the limitation is effective, which means, that the BMS would have requested a higher current than the limitation, the spot value LimitationReason shows "InletHot".
In case of massive overheat (10K more than parametrized), the spotvalue StopReason will show "InletOverheat".
|-
|TargetVoltage
|V
|0
|1000
| 0
|Charge target voltage (volatile)
|-
|ChargeCurrent
|A
|0
|500
|0
| Instantaneous current setpoint (volatile) - must be written at least once per second to prevent [[Foccci#CANTIMEOUT|CANTIMEOUT]]
|-
|soc
|%
|0
|100
|0
|Battery SoC for display on charger (volatile)
|-
|BatteryVoltage
|V
|0
| 1000
|0
| Present battery voltage for precharge state (volatile)
|-
|enable
|
|0
|1
|1
|When 0 charging is stopped/not started (volatile) - must be written at least once per second to prevent [[Foccci#CANTIMEOUT|CANTIMEOUT]]
|-
|AcObcState
|
|0
|15
|0
|Feedback from OBC
|-
| colspan="6" |'''Testing'''
|-
|DemoVoltage
|V
|0
|500
|0
|Voltage for light bulb demo. To use the board without CAN, to get an constant voltage. Is ignored as long democtrl is not STANDALONE. Only values between 150V and 250V are accepted, others are treated as zero.
|-
|DemoControl
|
|0
|511
|0
|Enables the standalone demo mode if value is set to STANDALONE. In this mode, no CAN is required and the target voltages for precharge and charging loop are taken from demovtg.
|-
|ActuatorTest
|
|0
|7
|0
|Tests various outputs
|-
|logging
|
|0
|2047
|
|Selects which modules log to the serial console
|}
==Spot values ==
{| class="wikitable"
|+
!Name
!Unit
!Description
|-
|opmode
|
|State of the CCS state machine
|-
|version
|
|
|-
|lasterr
|
|Last detected error
|-
|EvseVoltage
|V
|Outlet voltage reported by EVSE
|-
|EvseCurrent
|A
|Outlet current reported by EVSE
|-
|TempLimitedCurrent
|A
|Current limit calculated based on the inlet temperature
|-
|EVTargetCurrent
|A
|Current demand which is communicated to the DC charging station. Is the minimum of TempLimitedCurrent and ChargeCurrent.
|-
|LimitationReason
|
|Shows the reason why charge power is limited
|-
|InletVoltage
|V
|Charge port voltage
|-
|EvseMaxCurrent
|A
|Maximum current the EVSE can deliver
|-
|EvseMaxVoltage
|V
|Maximum voltage the EVSE can deliver
|-
|ControlPilotDuty
|%
|The PWM ratio of the CP line. This is normally 5% for DC chargers, and between 10% and 90% for analog AC chargers.
Typical values are explained here: [https://de.wikipedia.org/wiki/IEC_62196_Typ_2 IEC 62196 Typ 2 – Wikipedia]
|-
|temp1, 2, 3
|°C
|Temperatures of the temperature sensors. Requires correct calibration values depending on the used NTC types.
|-
|MaxTemp
|°C
|Maximum of the above
|-
|ContactorDuty
|%
|Duty cycle of charge port contactor driver
|-
|AdcLockFeedback
|digit
|Feedback value from charge port lock
|-
|AdcProximityPilot
|digit
|Analog value of the PP line. This is the raw value of the analog-to-digital-converter in range 0 to 4095.
|-
|ResistanceProximityPilot
|ohm
|Measured resistance between PP line and ground. Requires correct setting of the parameter ppvariant.
|-
|CableCurrentLimit
|A
|Based on the PP resistance. The current limit of the charging cable for AC charging.
|-
|EvseCurrentLimit
|A
|Based on the CP PWM. The current limit of the charging station for AC charging.
|-
|AdcHwVariant
|digit
|raw AD value of the hardware variant coding input. Used to detect which variant of Foccci the software runs on.
|-
|AdcIpropi
|digit
|raw AD value of the current sensor for the charge port lock motor driver.
|-
|LockState
|
|State of charge port lock
|-
|StopReason
|
|shows the reason why the charging session stopped
|-
|checkpoint
|
|shows the progress of the charging session in detail. Explanation here: https://github.com/uhi22/pyPLC?tab=readme-ov-file#example-flow
|-
|CanWatchdog
|100 ms
|Time since last ChargeCurrent update. When it reaches 30 (3s) the charge session is stopped
|-
|cpuload
|
|
|}
==Errors==
The spot value "lasterr" displays the last detected error that lead to a cancellation of charging or to not starting in the first place
{| class="wikitable"
|+
!Error
!Description
|-
|CANTIMEOUT
|The ChargeCurrent hasn't been updated via CAN for more than 2s
|-
|PLCTIMEOUT
|PLC communication with charger timed out
|-
|PRECTIMEOUT
|Precharging the EVSE output to specified voltage timed out or battery voltage is below minimum EVSE output voltage
|-
|LOCKTIMEOUT
|The connector lock didn't reach the desired position in time
|-
|EVSEFAULT
|The EVSE reported an error and stopped
|-
|RELAYWELDED
|A welded charge port relay was detected
|}
== Making Foccci talk CHAdeMO on the CAN side ==
A pretty straightforward way to integrate CCS charging into your vehicle is to use the existing CHAdeMO (let's call it CDM from here on) CAN messaging. CDM has pretty much all data items we need to initiate a CCS charging session, so rather than defining a new set of messages we might as well adopt it. For example, Orion BMS or Zombieverter VCU natively support CHAdeMO anyway.[[File:Can mapping chademo.png|thumb|Screenshot of CAN mapping to interface Foccci CCS with CHAdeMO]]Let's go over the items in the screenshot one by one. Note that the IDs are decimal! (256=0x100, 258=0x102, 264=0x108, 265=0x109)
*'''UdcDivider''' - Actually, here we just select some dummy item as the important bit is in the Offset field: the version. In this case I signal non-existent CDM version 10. This tells the CDM module in my car that it talks to Foccci. It then includes the battery voltage in some unused message bytes - see below.
*'''EvseVoltage''' - Transmits the charger's present output voltage back to the vehicle.
*'''EvseCurrent''' - Transmits the charger's present output current back to the vehicle.
*'''opmode''' - Observe the weird gain - this is forged to map Foccci state "CurrentDemand (13)" to CDM state "ConnectorLocked (4)". In my car's CDM module this is sufficient to initiate the charging progress. You may need to change it so that the ChargeEnable flag together with ConnectorLocked is forged (numerical value 5).
*'''EvseMaxVoltage''' - Transmits the EVSE's maximum output voltage back to the vehicle.
*'''EvseMaxCurrent''' - Transmits the EVSE's maximum output current back to the vehicle.
*'''BatteryVoltage''' - Transmits the present battery voltage to the EVSE. This is the special item that normally doesn't exist in CDM and that unfortunately will prevent you from using this solution with an OEM car in a safe manner. Of course, you could manually set this to some medium battery voltage like 360V, but if you arrive with a really low battery at, say, 300V this might weld your charge port contactors. You could also manually enter the battery voltage before each charging session.
*'''TargetVoltage''' - Transmits the charge end voltage to the EVSE.
*'''ChargeCurrent''' - By far the most important data item: the charge current request.
*'''soc''' - In CDM this isn't normally a percentage value but some encoded kWh value. In my car's CDM module I specify a full battery as "200" (no idea what this actually means in kWh) and thereby can just output the SoC in 0.5% steps.
*'''enable''' - The car's charge enable flag. When 0 will stop the CCS session.
As an additional safety measure you could connect CDM pin 4 (charge enable) to Foccci's button input (at least once we added an active low mode for it). It might also be worthwhile to connect pin 7 (connection check) to the PP input for drive away protection when CDM is plugged in but not charging (again, once we have actually implemented this).

Let's list the CHAdeMO pin mapping one by one as well:
*Pin 1 - GND
*Pin 2 (12V, charger start/stop) - 12V (I take it from cigarette lighter)
*Pin 4 (charging enable) - Foccci BUTTON
*Pin 5, 6 - Power pins, triple check correct polarity!
*Pin 7 (Connection check) - Foccci PP
*Pin 8, 9 (CAN) - Foccci CANL, CANH
*Pin 10 (charger start/stop 2) - Foccci SW1_LS
'''Attention:''' with this mapping the error flags are ignored, e.g. voltage or current mismatch.

==Making Foccci talk to boostech BMS==
The boostech BMS has a fixed CAN mapping. It doesn't expect any feedback from the CCS controller so we just keep the CHAdeMO mapping from above in case the info is needed elsewhere in the car.

The BMS sends out big endian messages hence why the length fields are negative. It does not send out a charge end voltage so we simply multiply the charge enable flag with the voltage we want. In the example 368V.
{| class="wikitable"
|+
!Item
!Direction
!ID
!Position
!Length
!Gain
!Offset
!Extended
!Remark
|-
|EvseMaxVoltage
|Transmit
|0x108 / 264
|8
|16
|1
|0
|no
|
|-
|EvseMaxCurrent
|Transmit
|0x108 / 264
|24
|8
|1
|0
|no
|
|-
|EvseVoltage
|Transmit
|0x109 / 265
|8
|16
|1
|0
|no
|
|-
|EvseCurrent
|Transmit
|0x109 / 265
|24
|8
|1
|0
|no
|
|-
|enable
|Receive
|0x310 / 784
|48
|1
|1
|0
|yes
|
|-
|BatteryVoltage
|Receive
|0x310 / 784
|15
| -16
|0.1
|0
|yes
|
|-
|soc
|Receive
|0x310 / 784
|47
| -16
|0.1
|0
|yes
|
|-
|TargetVoltage
|Receive
|0x310 / 784
|48
|1
|368
|0
|yes
|Put your desired TargetVoltage into gain
|-
|ChargeCurrent
|Receive
|0x313 / 787
|31
| -16
|0.097
|0
|yes
|This value is static, more below
|}
The boostech BMS '''lacks one critical feature''' for rapid charging: a dynamic charge limit. That means ChargeCurrent it always a fixed value that you program into the BMS. It will not cut back when cells are getting full, hot or cold. It can be somewhat mitigated by setting a sane target voltage (e.g. 4.1V x NumberOfCells). The rapid charger will then start to cut back charge current as this voltage is approached. Also by mapping the enable flag the BMS has the possibility to abort the charging session if one single cell voltage or module temperature rises above the safe threshold. In winter you will need to dial back your maximum charge current manually or heat you cells to avoid dendrites.

== Hardware detection ==
[[File:3.3v Addressing Voltage Divider.png|thumb]]
To allow software to reliably detect which version hardware it runs on, in HW version 4.1 a version indication resistor was added. As opposed to some other boards that run at 5.3V, the voltage here is 3.3V.
{| class="wikitable"
|+
!Variant
!R1
!R2
!voltage
!ADC
!-3%
!+3%
|-
| -
|47
|2,7
|0,179
|222
|216
|229
|-
| -
|47
|3,3
|0,217
|269
|261
|277
|-
| -
|47
|3,9
|0,253
|314
|304
|323
|-
| -
|47
|4,7
|0,300
|372
|361
|383
|-
| -
|47
|5,1
|0,323
|401
|389
|413
|-
| -
|47
|5,6
|0,351
|436
|423
|449
|-
| -
|47
|6,8
|0,417
|518
|502
|533
|-
| -
|47
|7,5
|0,454
|564
|547
|580
|-
|4.0 with economizer
|47
|8,2
|0,490
|608
|590
|627
|-
| -
|47
|9,1
|0,535
|664
|644
|684
|-
|4.2
|47
|10
|0,579
|718
|697
|740
|-
|4.3
|47
|12
|0,671
|833
|808
|858
|-
|4.4
|47
|15
|0,798
|991
|961
|1020
|-
|4.5 - 5.2
|47
|18
|0,914
|1134
|1100
|1168
|-
|
|47
|22
|1,052
|1306
|1266
|1345
|-
|
|47
|27
|1,204
|1494
|1449
|1539
|-
|
|47
|33
|1,361
|1689
|1639
|1740
|-
|
|47
|39
|1,497
|1857
|1801
|1913
|-
|
|47
|47
|1,650
|2048
|1986
|2109
|-
|
|47
|56
|1,794
|2226
|2160
|2293
|}
<references />
[[Category:ChaDeMo‏‎]] [[Category:CCS]] [[Category:Rapid Charging]]
[[Category:Charger]]
[[Category:OpenInverter]]

File:Electric-car.jpg

2024-12-04T08:56:02Z

Johu: Johu uploaded a new version of File:Electric-car.jpg

Overview of EV systems, source https://www.newkidscar.com/

Main Page

2024-12-03T11:14:34Z

Johu: /* Rapid Charging */

Did you know you can convert your existing fossil powered vehicle to use electricity instead? And that you can even produce that electricity yourself?

Open Inverter is a [[Main Page#Who we are|community of people]] and projects focused on open source solutions for EV conversions. Founded in 2008 by Johannes Huebner as an open source inverter control firmware, the project has since expended to include the reuse of components from production EVs and hybrids, including inverters, motors, batteries, on-board chargers, and DC-DC converters, as well as the open source implementation of other necessary systems for EV conversions such as DC Fast Charging controllers.

<imagemap>
File:Electric-car.jpg|none|frame|Click on the captions to learn more about the respective system! Image source: https://www.newkidscar.com/

poly 248 166 542 166 542 217 248 217 248 166 [[#Reusing motors and inverters - aka drive trains]]
poly 1041 455 1336 455 1336 506 1041 506 1041 455 [[#Reusing Batteries]]
poly 147 344 428 344 428 391 147 391 147 344 [[#Onboard chargers and DC/DC converters]]
poly 844 624 1118 624 1118 673 844 673 844 624 [[#Onboard chargers and DC/DC converters]]
poly 935 539 1200 539 1200 586 935 586 935 539 [[#Rapid Charging]]
poly 134 435 394 435 394 483 134 483 134 435 [[#Auxiliary Parts]]
</imagemap>

This wiki is maintained by the wider community. '''Please update this wiki'''. For example if your question has been clarified on the [https://openinverter.org/forum forum] and the new information can not be found here, please add it! The credentials are the same as for the forum.

'''[[Main Page#Who we are|Developers]] time is best spent developing;''' '''Support is best found in the forums''' - Developers of various projects are often bombarded with private messages and emails. Managing these emails and questions is a extremely large undertaking. Please read, and take the time to understand the information available here and across the web if you don't understand a topic. Developers are not your personal support team, unless you want to [[Application Support|pay them directly]] for their time. To keep developers independent please consider donating - donation links can be found [[Main Page#Who we are|down below]].

==Reusing motors and inverters - aka drive trains==
[[File:Tesla_LDU.jpg|thumb]]
The drive train is one of the defining building blocks of your conversion as it defines how well your vehicle picks up speed. Over the years we have reverse engineered many popular drive trains from [[:Category:OEM|production cars]] such as Teslas. As a bonus using such complete drive trains facilitates getting the vehicle [[Legalities|road legal]] in many countries. By now you have a choice of low to medium power drive trains that only cost a few 100€ up to high performance ones at many 1000€.

We have established two methods of running these [[:Category:OEM|OEM]] systems: reverse-engineering their communication protocol and making the drive train "think" it is still in its original vehicle OR swapping out the control electronics for our own open source motor controller. The latter method gives your more control and power but also a steeper learning curve.

Nearly all drive trains are targeted at 400V battery voltage. Run at a lower voltage they will produce proportionally less power.
Here is what we have done so far and how we've done it. Some is still work in progress (WIP)
{| class="wikitable"
|+
!Manufacturer
!Drive Train
!Control Method
! Approximate Power Output
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X Large Drive Unit ("LDU")|Large Drive Unit]]
|[https://openinverter.org/shop/index.php?route=product/product&path=61&product_id=64 Board Swap]
|335-475 kW
|-
|
|[[Tesla Model S/X Small Drive Unit ("SDU")|Small Drive Unit]]
|[https://openinverter.org/shop/index.php?route=product/product&path=61&product_id=62 Board Swap]
|180 kW
|-
|
|[[Tesla Model 3 Rear Drive Unit|Model 3/Y Rear Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|239 kW
|-
|
|[[Tesla Model 3 Front Drive Unit|Model 3/Y Front Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|121 kW
|-
|[[Nissan]]
|[[Nissan Leaf Motors|Gen1]]
|[[ZombieVerter VCU|CAN spoofing]]
|80 kW
|-
|
| [[Nissan Leaf Gen2 Board|Gen2]]
|[[ZombieVerter VCU|CAN spoofing]]/[https://openinverter.org/shop/index.php?route=product/product&product_id=57 Board Swap]
|80 kW / 130 kW (board swap)
|-
|
|[[Nissan Leaf Gen 3 (2018 up EM57)|Gen3]]
|[[ZombieVerter VCU|CAN spoofing]]/Board Swap [WIP]
|110 - 160 kW
|-
|[[:Category:Toyota|Toyota]]
|[[Lexus GS450h Drivetrain|Lexus GS 450h]]
|[[ZombieVerter VCU|Communication spoofing]]
|250 kW
|-
|
|[[Toyota/Lexus GS300h CVT|Lexus GS 300h]]
|[[ZombieVerter VCU|Communication spoofing]]
|105 kW
|-
|
|[[Toyota Prius Gen2 Inverter|Prius Gen2]]
|[[Toyota Prius Gen2 Inverter Controller|External Control Board]] ([https://openinverter.org/shop/index.php?route=product/product&product_id=68 Buy here])
|40-70 kW
|-
|
|[[Toyota Prius Gen3 Board|Prius Gen3]]
|[https://evbmw.com/index.php/evbmw-webshop/toyota-built-and-tested-boards Board Swap]/[[ZombieVerter VCU|Communication spoofing]]
|100 kW
|-
|
|[[Toyota/Lexus MGR Rear Transaxle Motor|MGR]]
|Prius Gen2 or Gen3 inverter
|18-50 kW (various models)
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander Rear Drive Unit|Rear Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing]]
|60-70 kW
|-
|
|[[Mitsubishi Outlander Front Transaxle|Front Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing]]
|60-70 kW
|-
|[[:Category:BMW|BMW]]
|[[BMW i3 Inverter|i3]]
|[https://openinverter.org/shop/index.php?route=product/product&path=61&product_id=72 Board Swap]
|125-135 kW
|-
|[[Chevrolet|Chevy/Opel]]
|[[Chevrolet Volt Inverter|Volt/Ampera]]
|Board Swap
|160 kW
|-
|[[:Category:Ford|Ford]]
|[[Ford Ranger TIM Controller|Ranger]]
|Board Swap
| Unknown
|-
| Renault
|[https://openinverter.org/forum/viewtopic.php?t=4749 Zoe]
|Board Swap [WIP]
|Unknown
|-
|MG
|[https://github.com/damienmaguire/MG-EV-Inverter ZS EV]
|Board Swap [WIP]
|Unknown
|}

==Reusing Batteries==
[[File:A09A7634.jpg|thumb]]
The most expensive and probably equally defining component is the [[Batteries|battery]] that stores all the energy for running your car. Batteries are usually assembled from a number of modules that in turn contain a number of cells. Usually batteries are reused on a module level. In rare cases the battery can be [https://youtu.be/_7l0Y1GsNJ4 reused as is in its original battery] box.

While there are also various [[16-cell BMS|open source implementations]] of [https://www.youtube.com/watch?v=_QsMoCrSTYc battery management systems] (BMS) we generally recommend using as much of the OEM BMS as possible. Sometimes the [[:Category:OEM|OEM]] BMS comes as an all-in-one solution that measures cell data and spits out state of charge and power limit information. In other cases the BMS is split into module units that measure the physical data (voltages, temperatures) and a central unit that calculates the high level information.

Sometimes we managed to reuse the complete system which is generally the safest as you can rely on the manufacturers well tested charge and discharge limits as well as reliable state of charge information (i.e. how much energy is left in the battery at any given time). In other cases we only managed to reuse the module units. This adds the convenience of having a well tested piece of hardware with the matching connector but required us to calculate all high level battery data ourselves. This also incudes [https://www.youtube.com/watch?v=RGYLPOlT45A cell balancing].
{| class="wikitable"
|+
!Manufacturer
!Model
!BMS usability
!Energy Content
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model 3 Battery|Model 3]]
|Module and high level [WIP]
|60-80 kWh ?
|-
|
|[[Batteries#OEM modules|Model S]]
|Unknown
|85-100 kWh
|-
|[[:Category:Nissan|Nissan]]
|[[Nissan Leaf BMS|Leaf/NV200]]
|High Level
|24-40 kWh
|-
|[[:Category:VAG|VW]]
|[[VW Hybrid Battery Packs|Passat/Golf]]
|Module Level
|8.7-36 kWh
|-
|
|[[MEB Batteries|MEB]]
|Module Level
|52-77 kwh
|}

== Onboard chargers and DC/DC converters ==
[[File:PXL_20241020_024043714.jpg|thumb|Onboard charger]]
The DC/DC converter takes energy from your HV traction battery and sends it to the cars 12V systems and 12V battery. It is basically a 1:1 replacement of the former alternator. An onboard charger (OBC) takes AC current from the grid and converts it into DC current to charge the battery. These two devices are often combined in one common enclosure hence why we treat them as one.
{| class="wikitable"
|+
!Manufacturer
!Model
!OBC
!DC/DC
!OBC power
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN2 Charger|Model S and X]] (Gen2)
|yes
|no
|11 kW
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN3 Charger|Model S and X]] (Gen3)
|yes
|no
|22 kW
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X DC/DC Converter|Model S and X]] (DC/DC)
|no
|yes
|
|-
| [[:Category:Tesla|Tesla]]
| [[Tesla Model 3 Charger/DCDC ("PCS")|Model 3]]
|yes
|yes
|11 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt Charger|Volt]]
|yes
|yes
|3.7 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt 2 Charger|Volt 2]]
|yes
|yes
|3.7 kW
|-
|[[Dilong/Cascadia Chargers|Dilong]]
|
|yes
|yes
|6.6 kW
|-
|[[Eltek chargers|Eltek]]
|
|yes
|no
|3 kW
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander DCDC OBC|Outlander / iMiev]]
|yes
|yes
|3.3 kW
|-
|[[:Category:MG|MG]]
|[[MG ZS Charger|ZS / MG4 / MG5]]
|yes
|yes
|6.6 - 11 kW
|}
There are more chargers under investigation, only the proven working ones are listed here. See our [[:Category:Charger|charger listing]] for more.

== Rapid Charging==
[[File:Ccs-socket.jpg|thumb|CCS2 rapid charging socket]]
The above mentioned onboard chargers always have limited power as the space requirements and cost rise with power. To overcome this limitation modern EVs offer external access to their HV battery via a so called [[:Category:Rapid Charging|rapid charging]] port. This allows to charge the battery with a much more powerful external charger. As a bonus it also allows [[Bidirectional Charging|taking energy from the HV battery]] and powering appliances with it.

There are 2 rapid charging protocols and 5 connector flavours world wide
{| class="wikitable"
|+
!Connector
!Communication
!Prevalent countries
!Open Source solutions
|-
|[[:Category:ChaDeMo|CHAdeMO]]
|CAN
|Japan, world wide
|[[Chademo with ESP32-Chademo|ESP32]], [[Chademo With Arduino Due|Arduino,]] [[Chademo with Zombieverter|ZombieVerter]]
|-
|CCS Combo1
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|CCS Combo2
|[[Foccci|PLC]]
|Europe
|[[Foccci]], [[pyPLC]], [[BMW I3 Fast Charging LIM Module|I3LIM]]
|-
|NACS
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|GB/T
|CAN
|China
|
|}

== Auxiliary Parts ==
We have now treated all the major building blocks of an EV, but there are many other components to complete the vehicle such as heaters, gear shifters and so on. We will summarize them here.

* [[:Category:HVJB|HV Junction Box]]
* [[:Category:HVAC|HVAC]] (Heating, Air conditioning)
* [[Vacuum Pumps]]
* [[:Category:Power Steering|Power Steering]]
* [[VCU Comparison|VCU]] (Vehicle Control Unit)
* [[Shift Controllers]]

== Additional Reading ==

* [[:Category:Legalities|Legalities]] - Getting a vehicle road legal in your country
* [[Glossary of Terms]]
* [[Common Inverter FAQ]] - questions common to all hardware variants
* [[Tesla Inverter FAQ]] - questions regarding Tesla Large Drive Units and Small Drive Units
* [[Electronics Basics]] - general advice for troubleshooting electronic circuits
* [[I want a cheap ev conversion|cheap EV conversions]] - this entry point for the penny pinchers
* [[I want a powerful ev conversion|performant EV conversions]] - where torque trumps money
* [[Mechanical design database]] - here you will find measurements, models, files, etc for a variety of components such as adapter plates and drive shaft flanges
* [[:Category:OpenInverter|Documentation of all OpenInverter Projects]]
* [[:Category:Tutorials|Tutorials]]

==Who we are==
There is no static team or openinverter company but here we list the most active community members with links to donation or information sites:

*Johannes Hübner, openinverter founder and developer - [https://www.patreon.com/openinverter support on patreon] follow on [https://www.youtube.com/user/EngineersFear youtube] and [https://github.com/jsphuebner/ github]
*Damien Maguire, developer and most active vehicle converter - [https://evbmw.com/index.php/evbmw-webshop visit shop] [https://www.patreon.com/evbmw support on patreon] follow on [https://www.youtube.com/@Evbmw youtube] and [https://github.com/damienmaguire/ github]
*Tom de Bree, active member and developer - [https://github.com/Tom-evnut github] and [https://citini.com/ shop]
*Uwe Hennig, master of CCS - [https://www.patreon.com/uhi22 support on patreon] follow on [https://github.com/uhi22/ github]
*celeron55, developer - support via [https://www.paypal.com/paypalme/celeron55 paypal] follow on [https://www.youtube.com/user/celeron55 youtube] and [https://github.com/celeron55 github]
*Dave Fiddes, active member and developer - Follow on [https://github.com/davefiddes/ github]
*Arber Kramar, long term member and developer - [https://leafdriveblog.wordpress.com/ Follow on blogspot]
*Janosch Oppermann, active member, developer and producer - follow on [https://www.youtube.com/@foxev-content youtube]

Main Page

2024-12-03T11:12:29Z

Johu: forum link

Did you know you can convert your existing fossil powered vehicle to use electricity instead? And that you can even produce that electricity yourself?

Open Inverter is a [[Main Page#Who we are|community of people]] and projects focused on open source solutions for EV conversions. Founded in 2008 by Johannes Huebner as an open source inverter control firmware, the project has since expended to include the reuse of components from production EVs and hybrids, including inverters, motors, batteries, on-board chargers, and DC-DC converters, as well as the open source implementation of other necessary systems for EV conversions such as DC Fast Charging controllers.

<imagemap>
File:Electric-car.jpg|none|frame|Click on the captions to learn more about the respective system! Image source: https://www.newkidscar.com/

poly 248 166 542 166 542 217 248 217 248 166 [[#Reusing motors and inverters - aka drive trains]]
poly 1041 455 1336 455 1336 506 1041 506 1041 455 [[#Reusing Batteries]]
poly 147 344 428 344 428 391 147 391 147 344 [[#Onboard chargers and DC/DC converters]]
poly 844 624 1118 624 1118 673 844 673 844 624 [[#Onboard chargers and DC/DC converters]]
poly 935 539 1200 539 1200 586 935 586 935 539 [[#Rapid Charging]]
poly 134 435 394 435 394 483 134 483 134 435 [[#Auxiliary Parts]]
</imagemap>

This wiki is maintained by the wider community. '''Please update this wiki'''. For example if your question has been clarified on the [https://openinverter.org/forum forum] and the new information can not be found here, please add it! The credentials are the same as for the forum.

'''[[Main Page#Who we are|Developers]] time is best spent developing;''' '''Support is best found in the forums''' - Developers of various projects are often bombarded with private messages and emails. Managing these emails and questions is a extremely large undertaking. Please read, and take the time to understand the information available here and across the web if you don't understand a topic. Developers are not your personal support team, unless you want to [[Application Support|pay them directly]] for their time. To keep developers independent please consider donating - donation links can be found [[Main Page#Who we are|down below]].

==Reusing motors and inverters - aka drive trains==
[[File:Tesla_LDU.jpg|thumb]]
The drive train is one of the defining building blocks of your conversion as it defines how well your vehicle picks up speed. Over the years we have reverse engineered many popular drive trains from [[:Category:OEM|production cars]] such as Teslas. As a bonus using such complete drive trains facilitates getting the vehicle [[Legalities|road legal]] in many countries. By now you have a choice of low to medium power drive trains that only cost a few 100€ up to high performance ones at many 1000€.

We have established two methods of running these [[:Category:OEM|OEM]] systems: reverse-engineering their communication protocol and making the drive train "think" it is still in its original vehicle OR swapping out the control electronics for our own open source motor controller. The latter method gives your more control and power but also a steeper learning curve.

Nearly all drive trains are targeted at 400V battery voltage. Run at a lower voltage they will produce proportionally less power.
Here is what we have done so far and how we've done it. Some is still work in progress (WIP)
{| class="wikitable"
|+
!Manufacturer
!Drive Train
!Control Method
! Approximate Power Output
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X Large Drive Unit ("LDU")|Large Drive Unit]]
|[https://openinverter.org/shop/index.php?route=product/product&path=61&product_id=64 Board Swap]
|335-475 kW
|-
|
|[[Tesla Model S/X Small Drive Unit ("SDU")|Small Drive Unit]]
|[https://openinverter.org/shop/index.php?route=product/product&path=61&product_id=62 Board Swap]
|180 kW
|-
|
|[[Tesla Model 3 Rear Drive Unit|Model 3/Y Rear Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|239 kW
|-
|
|[[Tesla Model 3 Front Drive Unit|Model 3/Y Front Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|121 kW
|-
|[[Nissan]]
|[[Nissan Leaf Motors|Gen1]]
|[[ZombieVerter VCU|CAN spoofing]]
|80 kW
|-
|
| [[Nissan Leaf Gen2 Board|Gen2]]
|[[ZombieVerter VCU|CAN spoofing]]/[https://openinverter.org/shop/index.php?route=product/product&product_id=57 Board Swap]
|80 kW / 130 kW (board swap)
|-
|
|[[Nissan Leaf Gen 3 (2018 up EM57)|Gen3]]
|[[ZombieVerter VCU|CAN spoofing]]/Board Swap [WIP]
|110 - 160 kW
|-
|[[:Category:Toyota|Toyota]]
|[[Lexus GS450h Drivetrain|Lexus GS 450h]]
|[[ZombieVerter VCU|Communication spoofing]]
|250 kW
|-
|
|[[Toyota/Lexus GS300h CVT|Lexus GS 300h]]
|[[ZombieVerter VCU|Communication spoofing]]
|105 kW
|-
|
|[[Toyota Prius Gen2 Inverter|Prius Gen2]]
|[[Toyota Prius Gen2 Inverter Controller|External Control Board]] ([https://openinverter.org/shop/index.php?route=product/product&product_id=68 Buy here])
|40-70 kW
|-
|
|[[Toyota Prius Gen3 Board|Prius Gen3]]
|[https://evbmw.com/index.php/evbmw-webshop/toyota-built-and-tested-boards Board Swap]/[[ZombieVerter VCU|Communication spoofing]]
|100 kW
|-
|
|[[Toyota/Lexus MGR Rear Transaxle Motor|MGR]]
|Prius Gen2 or Gen3 inverter
|18-50 kW (various models)
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander Rear Drive Unit|Rear Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing]]
|60-70 kW
|-
|
|[[Mitsubishi Outlander Front Transaxle|Front Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing]]
|60-70 kW
|-
|[[:Category:BMW|BMW]]
|[[BMW i3 Inverter|i3]]
|[https://openinverter.org/shop/index.php?route=product/product&path=61&product_id=72 Board Swap]
|125-135 kW
|-
|[[Chevrolet|Chevy/Opel]]
|[[Chevrolet Volt Inverter|Volt/Ampera]]
|Board Swap
|160 kW
|-
|[[:Category:Ford|Ford]]
|[[Ford Ranger TIM Controller|Ranger]]
|Board Swap
| Unknown
|-
| Renault
|[https://openinverter.org/forum/viewtopic.php?t=4749 Zoe]
|Board Swap [WIP]
|Unknown
|-
|MG
|[https://github.com/damienmaguire/MG-EV-Inverter ZS EV]
|Board Swap [WIP]
|Unknown
|}

==Reusing Batteries==
[[File:A09A7634.jpg|thumb]]
The most expensive and probably equally defining component is the [[Batteries|battery]] that stores all the energy for running your car. Batteries are usually assembled from a number of modules that in turn contain a number of cells. Usually batteries are reused on a module level. In rare cases the battery can be [https://youtu.be/_7l0Y1GsNJ4 reused as is in its original battery] box.

While there are also various [[16-cell BMS|open source implementations]] of [https://www.youtube.com/watch?v=_QsMoCrSTYc battery management systems] (BMS) we generally recommend using as much of the OEM BMS as possible. Sometimes the [[:Category:OEM|OEM]] BMS comes as an all-in-one solution that measures cell data and spits out state of charge and power limit information. In other cases the BMS is split into module units that measure the physical data (voltages, temperatures) and a central unit that calculates the high level information.

Sometimes we managed to reuse the complete system which is generally the safest as you can rely on the manufacturers well tested charge and discharge limits as well as reliable state of charge information (i.e. how much energy is left in the battery at any given time). In other cases we only managed to reuse the module units. This adds the convenience of having a well tested piece of hardware with the matching connector but required us to calculate all high level battery data ourselves. This also incudes [https://www.youtube.com/watch?v=RGYLPOlT45A cell balancing].
{| class="wikitable"
|+
!Manufacturer
!Model
!BMS usability
!Energy Content
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model 3 Battery|Model 3]]
|Module and high level [WIP]
|60-80 kWh ?
|-
|
|[[Batteries#OEM modules|Model S]]
|Unknown
|85-100 kWh
|-
|[[:Category:Nissan|Nissan]]
|[[Nissan Leaf BMS|Leaf/NV200]]
|High Level
|24-40 kWh
|-
|[[:Category:VAG|VW]]
|[[VW Hybrid Battery Packs|Passat/Golf]]
|Module Level
|8.7-36 kWh
|-
|
|[[MEB Batteries|MEB]]
|Module Level
|52-77 kwh
|}

== Onboard chargers and DC/DC converters ==
[[File:PXL_20241020_024043714.jpg|thumb|Onboard charger]]
The DC/DC converter takes energy from your HV traction battery and sends it to the cars 12V systems and 12V battery. It is basically a 1:1 replacement of the former alternator. An onboard charger (OBC) takes AC current from the grid and converts it into DC current to charge the battery. These two devices are often combined in one common enclosure hence why we treat them as one.
{| class="wikitable"
|+
!Manufacturer
!Model
!OBC
!DC/DC
!OBC power
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN2 Charger|Model S and X]] (Gen2)
|yes
|no
|11 kW
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN3 Charger|Model S and X]] (Gen3)
|yes
|no
|22 kW
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X DC/DC Converter|Model S and X]] (DC/DC)
|no
|yes
|
|-
| [[:Category:Tesla|Tesla]]
| [[Tesla Model 3 Charger/DCDC ("PCS")|Model 3]]
|yes
|yes
|11 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt Charger|Volt]]
|yes
|yes
|3.7 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt 2 Charger|Volt 2]]
|yes
|yes
|3.7 kW
|-
|[[Dilong/Cascadia Chargers|Dilong]]
|
|yes
|yes
|6.6 kW
|-
|[[Eltek chargers|Eltek]]
|
|yes
|no
|3 kW
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander DCDC OBC|Outlander / iMiev]]
|yes
|yes
|3.3 kW
|-
|[[:Category:MG|MG]]
|[[MG ZS Charger|ZS / MG4 / MG5]]
|yes
|yes
|6.6 - 11 kW
|}
There are more chargers under investigation, only the proven working ones are listed here. See our [[:Category:Charger|charger listing]] for more.

== Rapid Charging==
[[File:Ccs-socket.jpg|thumb|CCS2 rapid charging socket]]
The above mentioned onboard chargers always have limited power as they space requirements and cost rise with charger power. To overcome this limitation modern EVs offer external access to their HV battery via a so called [[:Category:Rapid Charging|rapid charging]] port. This allows to charge the battery with a much more powerful external charger. As a bonus it also allows [[Bidirectional Charging|taking energy from the HV battery]] and powering appliances with it.

There are 2 rapid charging protocols and 5 connector flavours world wide
{| class="wikitable"
|+
!Connector
!Communication
!Prevalent countries
!Open Source solutions
|-
|[[:Category:ChaDeMo|CHAdeMO]]
|CAN
|Japan, world wide
|[[Chademo with ESP32-Chademo|ESP32]], [[Chademo With Arduino Due|Arduino,]] [[Chademo with Zombieverter|ZombieVerter]]
|-
|CCS Combo1
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|CCS Combo2
|[[Foccci|PLC]]
|Europe
|[[Foccci]], [[pyPLC]], [[BMW I3 Fast Charging LIM Module|I3LIM]]
|-
|NACS
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|GB/T
|CAN
|China
|
|}

== Auxiliary Parts ==
We have now treated all the major building blocks of an EV, but there are many other components to complete the vehicle such as heaters, gear shifters and so on. We will summarize them here.

* [[:Category:HVJB|HV Junction Box]]
* [[:Category:HVAC|HVAC]] (Heating, Air conditioning)
* [[Vacuum Pumps]]
* [[:Category:Power Steering|Power Steering]]
* [[VCU Comparison|VCU]] (Vehicle Control Unit)
* [[Shift Controllers]]

== Additional Reading ==

* [[:Category:Legalities|Legalities]] - Getting a vehicle road legal in your country
* [[Glossary of Terms]]
* [[Common Inverter FAQ]] - questions common to all hardware variants
* [[Tesla Inverter FAQ]] - questions regarding Tesla Large Drive Units and Small Drive Units
* [[Electronics Basics]] - general advice for troubleshooting electronic circuits
* [[I want a cheap ev conversion|cheap EV conversions]] - this entry point for the penny pinchers
* [[I want a powerful ev conversion|performant EV conversions]] - where torque trumps money
* [[Mechanical design database]] - here you will find measurements, models, files, etc for a variety of components such as adapter plates and drive shaft flanges
* [[:Category:OpenInverter|Documentation of all OpenInverter Projects]]
* [[:Category:Tutorials|Tutorials]]

==Who we are==
There is no static team or openinverter company but here we list the most active community members with links to donation or information sites:

*Johannes Hübner, openinverter founder and developer - [https://www.patreon.com/openinverter support on patreon] follow on [https://www.youtube.com/user/EngineersFear youtube] and [https://github.com/jsphuebner/ github]
*Damien Maguire, developer and most active vehicle converter - [https://evbmw.com/index.php/evbmw-webshop visit shop] [https://www.patreon.com/evbmw support on patreon] follow on [https://www.youtube.com/@Evbmw youtube] and [https://github.com/damienmaguire/ github]
*Tom de Bree, active member and developer - [https://github.com/Tom-evnut github] and [https://citini.com/ shop]
*Uwe Hennig, master of CCS - [https://www.patreon.com/uhi22 support on patreon] follow on [https://github.com/uhi22/ github]
*celeron55, developer - support via [https://www.paypal.com/paypalme/celeron55 paypal] follow on [https://www.youtube.com/user/celeron55 youtube] and [https://github.com/celeron55 github]
*Dave Fiddes, active member and developer - Follow on [https://github.com/davefiddes/ github]
*Arber Kramar, long term member and developer - [https://leafdriveblog.wordpress.com/ Follow on blogspot]
*Janosch Oppermann, active member, developer and producer - follow on [https://www.youtube.com/@foxev-content youtube]

Main Page

2024-12-03T11:10:11Z

Johu:

Did you know you can convert your existing fossil powered vehicle to use electricity instead? And that you can even produce that electricity yourself?

Open Inverter is a [[Main Page#Who we are|community of people]] and projects focused on open source solutions for EV conversions. Founded in 2008 by Johannes Huebner as an open source inverter control firmware, the project has since expended to include the reuse of components from production EVs and hybrids, including inverters, motors, batteries, on-board chargers, and DC-DC converters, as well as the open source implementation of other necessary systems for EV conversions such as DC Fast Charging controllers.

<imagemap>
File:Electric-car.jpg|none|frame|Click on the captions to learn more about the respective system! Image source: https://www.newkidscar.com/

poly 248 166 542 166 542 217 248 217 248 166 [[#Reusing motors and inverters - aka drive trains]]
poly 1041 455 1336 455 1336 506 1041 506 1041 455 [[#Reusing Batteries]]
poly 147 344 428 344 428 391 147 391 147 344 [[#Onboard chargers and DC/DC converters]]
poly 844 624 1118 624 1118 673 844 673 844 624 [[#Onboard chargers and DC/DC converters]]
poly 935 539 1200 539 1200 586 935 586 935 539 [[#Rapid Charging]]
poly 134 435 394 435 394 483 134 483 134 435 [[#Auxiliary Parts]]
</imagemap>

This wiki is maintained by the wider community. '''Please update this wiki'''. For example if your question has been clarified on the forum and the new information can not be found here, please add it! The credentials are the same as for the forum.

'''[[Main Page#Who we are|Developers]] time is best spent developing;''' '''Support is best found in the forums''' - Developers of various projects are often bombarded with private messages and emails. Managing these emails and questions is a extremely large undertaking. Please read, and take the time to understand the information available here and across the web if you don't understand a topic. Developers are not your personal support team, unless you want to [[Application Support|pay them directly]] for their time. To keep developers independent please consider donating - donation links can be found [[Main Page#Who we are|down below]].

==Reusing motors and inverters - aka drive trains==
[[File:Tesla_LDU.jpg|thumb]]
The drive train is one of the defining building blocks of your conversion as it defines how well your vehicle picks up speed. Over the years we have reverse engineered many popular drive trains from [[:Category:OEM|production cars]] such as Teslas. As a bonus using such complete drive trains facilitates getting the vehicle [[Legalities|road legal]] in many countries. By now you have a choice of low to medium power drive trains that only cost a few 100€ up to high performance ones at many 1000€.

We have established two methods of running these [[:Category:OEM|OEM]] systems: reverse-engineering their communication protocol and making the drive train "think" it is still in its original vehicle OR swapping out the control electronics for our own open source motor controller. The latter method gives your more control and power but also a steeper learning curve.

Nearly all drive trains are targeted at 400V battery voltage. Run at a lower voltage they will produce proportionally less power.
Here is what we have done so far and how we've done it. Some is still work in progress (WIP)
{| class="wikitable"
|+
!Manufacturer
!Drive Train
!Control Method
! Approximate Power Output
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X Large Drive Unit ("LDU")|Large Drive Unit]]
|[https://openinverter.org/shop/index.php?route=product/product&path=61&product_id=64 Board Swap]
|335-475 kW
|-
|
|[[Tesla Model S/X Small Drive Unit ("SDU")|Small Drive Unit]]
|[https://openinverter.org/shop/index.php?route=product/product&path=61&product_id=62 Board Swap]
|180 kW
|-
|
|[[Tesla Model 3 Rear Drive Unit|Model 3/Y Rear Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|239 kW
|-
|
|[[Tesla Model 3 Front Drive Unit|Model 3/Y Front Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|121 kW
|-
|[[Nissan]]
|[[Nissan Leaf Motors|Gen1]]
|[[ZombieVerter VCU|CAN spoofing]]
|80 kW
|-
|
| [[Nissan Leaf Gen2 Board|Gen2]]
|[[ZombieVerter VCU|CAN spoofing]]/[https://openinverter.org/shop/index.php?route=product/product&product_id=57 Board Swap]
|80 kW / 130 kW (board swap)
|-
|
|[[Nissan Leaf Gen 3 (2018 up EM57)|Gen3]]
|[[ZombieVerter VCU|CAN spoofing]]/Board Swap [WIP]
|110 - 160 kW
|-
|[[:Category:Toyota|Toyota]]
|[[Lexus GS450h Drivetrain|Lexus GS 450h]]
|[[ZombieVerter VCU|Communication spoofing]]
|250 kW
|-
|
|[[Toyota/Lexus GS300h CVT|Lexus GS 300h]]
|[[ZombieVerter VCU|Communication spoofing]]
|105 kW
|-
|
|[[Toyota Prius Gen2 Inverter|Prius Gen2]]
|[[Toyota Prius Gen2 Inverter Controller|External Control Board]] ([https://openinverter.org/shop/index.php?route=product/product&product_id=68 Buy here])
|40-70 kW
|-
|
|[[Toyota Prius Gen3 Board|Prius Gen3]]
|[https://evbmw.com/index.php/evbmw-webshop/toyota-built-and-tested-boards Board Swap]/[[ZombieVerter VCU|Communication spoofing]]
|100 kW
|-
|
|[[Toyota/Lexus MGR Rear Transaxle Motor|MGR]]
|Prius Gen2 or Gen3 inverter
|18-50 kW (various models)
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander Rear Drive Unit|Rear Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing]]
|60-70 kW
|-
|
|[[Mitsubishi Outlander Front Transaxle|Front Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing]]
|60-70 kW
|-
|[[:Category:BMW|BMW]]
|[[BMW i3 Inverter|i3]]
|[https://openinverter.org/shop/index.php?route=product/product&path=61&product_id=72 Board Swap]
|125-135 kW
|-
|[[Chevrolet|Chevy/Opel]]
|[[Chevrolet Volt Inverter|Volt/Ampera]]
|Board Swap
|160 kW
|-
|[[:Category:Ford|Ford]]
|[[Ford Ranger TIM Controller|Ranger]]
|Board Swap
| Unknown
|-
| Renault
|[https://openinverter.org/forum/viewtopic.php?t=4749 Zoe]
|Board Swap [WIP]
|Unknown
|-
|MG
|[https://github.com/damienmaguire/MG-EV-Inverter ZS EV]
|Board Swap [WIP]
|Unknown
|}

==Reusing Batteries==
[[File:A09A7634.jpg|thumb]]
The most expensive and probably equally defining component is the [[Batteries|battery]] that stores all the energy for running your car. Batteries are usually assembled from a number of modules that in turn contain a number of cells. Usually batteries are reused on a module level. In rare cases the battery can be [https://youtu.be/_7l0Y1GsNJ4 reused as is in its original battery] box.

While there are also various [[16-cell BMS|open source implementations]] of [https://www.youtube.com/watch?v=_QsMoCrSTYc battery management systems] (BMS) we generally recommend using as much of the OEM BMS as possible. Sometimes the [[:Category:OEM|OEM]] BMS comes as an all-in-one solution that measures cell data and spits out state of charge and power limit information. In other cases the BMS is split into module units that measure the physical data (voltages, temperatures) and a central unit that calculates the high level information.

Sometimes we managed to reuse the complete system which is generally the safest as you can rely on the manufacturers well tested charge and discharge limits as well as reliable state of charge information (i.e. how much energy is left in the battery at any given time). In other cases we only managed to reuse the module units. This adds the convenience of having a well tested piece of hardware with the matching connector but required us to calculate all high level battery data ourselves. This also incudes [https://www.youtube.com/watch?v=RGYLPOlT45A cell balancing].
{| class="wikitable"
|+
!Manufacturer
!Model
!BMS usability
!Energy Content
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model 3 Battery|Model 3]]
|Module and high level [WIP]
|60-80 kWh ?
|-
|
|[[Batteries#OEM modules|Model S]]
|Unknown
|85-100 kWh
|-
|[[:Category:Nissan|Nissan]]
|[[Nissan Leaf BMS|Leaf/NV200]]
|High Level
|24-40 kWh
|-
|[[:Category:VAG|VW]]
|[[VW Hybrid Battery Packs|Passat/Golf]]
|Module Level
|8.7-36 kWh
|-
|
|[[MEB Batteries|MEB]]
|Module Level
|52-77 kwh
|}

== Onboard chargers and DC/DC converters ==
[[File:PXL_20241020_024043714.jpg|thumb|Onboard charger]]
The DC/DC converter takes energy from your HV traction battery and sends it to the cars 12V systems and 12V battery. It is basically a 1:1 replacement of the former alternator. An onboard charger (OBC) takes AC current from the grid and converts it into DC current to charge the battery. These two devices are often combined in one common enclosure hence why we treat them as one.
{| class="wikitable"
|+
!Manufacturer
!Model
!OBC
!DC/DC
!OBC power
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN2 Charger|Model S and X]] (Gen2)
|yes
|no
|11 kW
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN3 Charger|Model S and X]] (Gen3)
|yes
|no
|22 kW
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X DC/DC Converter|Model S and X]] (DC/DC)
|no
|yes
|
|-
| [[:Category:Tesla|Tesla]]
| [[Tesla Model 3 Charger/DCDC ("PCS")|Model 3]]
|yes
|yes
|11 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt Charger|Volt]]
|yes
|yes
|3.7 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt 2 Charger|Volt 2]]
|yes
|yes
|3.7 kW
|-
|[[Dilong/Cascadia Chargers|Dilong]]
|
|yes
|yes
|6.6 kW
|-
|[[Eltek chargers|Eltek]]
|
|yes
|no
|3 kW
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander DCDC OBC|Outlander / iMiev]]
|yes
|yes
|3.3 kW
|-
|[[:Category:MG|MG]]
|[[MG ZS Charger|ZS / MG4 / MG5]]
|yes
|yes
|6.6 - 11 kW
|}
There are more chargers under investigation, only the proven working ones are listed here. See our [[:Category:Charger|charger listing]] for more.

== Rapid Charging==
[[File:Ccs-socket.jpg|thumb|CCS2 rapid charging socket]]
The above mentioned onboard chargers always have limited power as they space requirements and cost rise with charger power. To overcome this limitation modern EVs offer external access to their HV battery via a so called [[:Category:Rapid Charging|rapid charging]] port. This allows to charge the battery with a much more powerful external charger. As a bonus it also allows [[Bidirectional Charging|taking energy from the HV battery]] and powering appliances with it.

There are 2 rapid charging protocols and 5 connector flavours world wide
{| class="wikitable"
|+
!Connector
!Communication
!Prevalent countries
!Open Source solutions
|-
|[[:Category:ChaDeMo|CHAdeMO]]
|CAN
|Japan, world wide
|[[Chademo with ESP32-Chademo|ESP32]], [[Chademo With Arduino Due|Arduino,]] [[Chademo with Zombieverter|ZombieVerter]]
|-
|CCS Combo1
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|CCS Combo2
|[[Foccci|PLC]]
|Europe
|[[Foccci]], [[pyPLC]], [[BMW I3 Fast Charging LIM Module|I3LIM]]
|-
|NACS
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|GB/T
|CAN
|China
|
|}

== Auxiliary Parts ==
We have now treated all the major building blocks of an EV, but there are many other components to complete the vehicle such as heaters, gear shifters and so on. We will summarize them here.

* [[:Category:HVJB|HV Junction Box]]
* [[:Category:HVAC|HVAC]] (Heating, Air conditioning)
* [[Vacuum Pumps]]
* [[:Category:Power Steering|Power Steering]]
* [[VCU Comparison|VCU]] (Vehicle Control Unit)
* [[Shift Controllers]]

== Additional Reading ==

* [[:Category:Legalities|Legalities]] - Getting a vehicle road legal in your country
* [[Glossary of Terms]]
* [[Common Inverter FAQ]] - questions common to all hardware variants
* [[Tesla Inverter FAQ]] - questions regarding Tesla Large Drive Units and Small Drive Units
* [[Electronics Basics]] - general advice for troubleshooting electronic circuits
* [[I want a cheap ev conversion|cheap EV conversions]] - this entry point for the penny pinchers
* [[I want a powerful ev conversion|performant EV conversions]] - where torque trumps money
* [[Mechanical design database]] - here you will find measurements, models, files, etc for a variety of components such as adapter plates and drive shaft flanges
* [[:Category:OpenInverter|Documentation of all OpenInverter Projects]]
* [[:Category:Tutorials|Tutorials]]

==Who we are==
There is no static team or openinverter company but here we list the most active community members with links to donation or information sites:

*Johannes Hübner, openinverter founder and developer - [https://www.patreon.com/openinverter support on patreon] follow on [https://www.youtube.com/user/EngineersFear youtube] and [https://github.com/jsphuebner/ github]
*Damien Maguire, developer and most active vehicle converter - [https://evbmw.com/index.php/evbmw-webshop visit shop] [https://www.patreon.com/evbmw support on patreon] follow on [https://www.youtube.com/@Evbmw youtube] and [https://github.com/damienmaguire/ github]
*Tom de Bree, active member and developer - [https://github.com/Tom-evnut github] and [https://citini.com/ shop]
*Uwe Hennig, master of CCS - [https://www.patreon.com/uhi22 support on patreon] follow on [https://github.com/uhi22/ github]
*celeron55, developer - support via [https://www.paypal.com/paypalme/celeron55 paypal] follow on [https://www.youtube.com/user/celeron55 youtube] and [https://github.com/celeron55 github]
*Dave Fiddes, active member and developer - Follow on [https://github.com/davefiddes/ github]
*Arber Kramar, long term member and developer - [https://leafdriveblog.wordpress.com/ Follow on blogspot]
*Janosch Oppermann, active member, developer and producer - follow on [https://www.youtube.com/@foxev-content youtube]

Main Page

2024-12-03T11:07:58Z

Johu: Added shop links

Did you know you can convert your existing fossil powered vehicle to use electricity instead? And that you can even produce that electricity yourself?

Open Inverter is a [[Main Page#Who we are|community of people]] and projects focused on open source solutions for EV conversions. Founded in 2008 by Johannes Huebner as an open source inverter control firmware, the project has since expended to include the reuse of components from production EVs and hybrids, including inverters, motors, batteries, on-board chargers, and DC-DC converters, as well as the open source implementation of other necessary systems for EV conversions such as DC Fast Charging controllers.

<imagemap>
File:Electric-car.jpg|none|frame|Click on the captions to learn more about the respective system! Image source: https://www.newkidscar.com/

poly 248 166 542 166 542 217 248 217 248 166 [[#Reusing motors and inverters - aka drive trains]]
poly 1041 455 1336 455 1336 506 1041 506 1041 455 [[#Reusing Batteries]]
poly 147 344 428 344 428 391 147 391 147 344 [[#Onboard chargers and DC/DC converters]]
poly 844 624 1118 624 1118 673 844 673 844 624 [[#Onboard chargers and DC/DC converters]]
poly 935 539 1200 539 1200 586 935 586 935 539 [[#Rapid Charging]]
poly 134 435 394 435 394 483 134 483 134 435 [[#Auxiliary Parts]]
</imagemap>

This wiki is maintained by the wider community. '''Please update this wiki'''. For example if your question has been clarified on the forum and the new information can not be found here, please add it! The credentials are the same as for the forum.

'''[[Main Page#Who we are|Developers]] time is best spent developing;''' '''Support is best found in the forums''' - Developers of various projects are often bombarded with private messages and emails. Managing these emails and questions is a extremely large undertaking. Please read, and take the time to understand the information available here and across the web if you don't understand a topic. Developers are not your personal support team, unless you want to pay them directly for their time. To keep developers independent please consider donating - donation links can be found [[Main Page#Who we are|down below]].

Read more about [[Application Support]]

==Reusing motors and inverters - aka drive trains==
[[File:Tesla_LDU.jpg|thumb]]
The drive train is one of the defining building blocks of your conversion as it defines how well your vehicle picks up speed. Over the years we have reverse engineered many popular drive trains from [[:Category:OEM|production cars]] such as Teslas. As a bonus using such complete drive trains facilitates getting the vehicle [[Legalities|road legal]] in many countries. By now you have a choice of low to medium power drive trains that only cost a few 100€ up to high performance ones at many 1000€.

We have established two methods of running these [[:Category:OEM|OEM]] systems: reverse-engineering their communication protocol and making the drive train "think" it is still in its original vehicle OR swapping out the control electronics for our own open source motor controller. The latter method gives your more control and power but also a steeper learning curve.

Nearly all drive trains are targeted at 400V battery voltage. Run at a lower voltage they will produce proportionally less power.
Here is what we have done so far and how we've done it. Some is still work in progress (WIP)
{| class="wikitable"
|+
!Manufacturer
!Drive Train
!Control Method
! Approximate Power Output
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X Large Drive Unit ("LDU")|Large Drive Unit]]
|[https://openinverter.org/shop/index.php?route=product/product&path=61&product_id=64 Board Swap]
|335-475 kW
|-
|
|[[Tesla Model S/X Small Drive Unit ("SDU")|Small Drive Unit]]
|[https://openinverter.org/shop/index.php?route=product/product&path=61&product_id=62 Board Swap]
|180 kW
|-
|
|[[Tesla Model 3 Rear Drive Unit|Model 3/Y Rear Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|239 kW
|-
|
|[[Tesla Model 3 Front Drive Unit|Model 3/Y Front Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|121 kW
|-
|[[Nissan]]
|[[Nissan Leaf Motors|Gen1]]
|[[ZombieVerter VCU|CAN spoofing]]
|80 kW
|-
|
| [[Nissan Leaf Gen2 Board|Gen2]]
|[[ZombieVerter VCU|CAN spoofing]]/[https://openinverter.org/shop/index.php?route=product/product&product_id=57 Board Swap]
|80 kW / 130 kW (board swap)
|-
|
|[[Nissan Leaf Gen 3 (2018 up EM57)|Gen3]]
|[[ZombieVerter VCU|CAN spoofing]]/Board Swap [WIP]
|110 - 160 kW
|-
|[[:Category:Toyota|Toyota]]
|[[Lexus GS450h Drivetrain|Lexus GS 450h]]
|[[ZombieVerter VCU|Communication spoofing]]
|250 kW
|-
|
|[[Toyota/Lexus GS300h CVT|Lexus GS 300h]]
|[[ZombieVerter VCU|Communication spoofing]]
|105 kW
|-
|
|[[Toyota Prius Gen2 Inverter|Prius Gen2]]
|[[Toyota Prius Gen2 Inverter Controller|External Control Board]] ([https://openinverter.org/shop/index.php?route=product/product&product_id=68 Buy here])
|40-70 kW
|-
|
|[[Toyota Prius Gen3 Board|Prius Gen3]]
|[https://evbmw.com/index.php/evbmw-webshop/toyota-built-and-tested-boards Board Swap]/[[ZombieVerter VCU|Communication spoofing]]
|100 kW
|-
|
|[[Toyota/Lexus MGR Rear Transaxle Motor|MGR]]
|Prius Gen2 or Gen3 inverter
|18-50 kW (various models)
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander Rear Drive Unit|Rear Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing]]
|60-70 kW
|-
|
|[[Mitsubishi Outlander Front Transaxle|Front Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing]]
|60-70 kW
|-
|[[:Category:BMW|BMW]]
|[[BMW i3 Inverter|i3]]
|[https://openinverter.org/shop/index.php?route=product/product&path=61&product_id=72 Board Swap]
|125-135 kW
|-
|[[Chevrolet|Chevy/Opel]]
|[[Chevrolet Volt Inverter|Volt/Ampera]]
|Board Swap
|160 kW
|-
|[[:Category:Ford|Ford]]
|[[Ford Ranger TIM Controller|Ranger]]
|Board Swap
| Unknown
|-
| Renault
|[https://openinverter.org/forum/viewtopic.php?t=4749 Zoe]
|Board Swap [WIP]
|Unknown
|-
|MG
|[https://github.com/damienmaguire/MG-EV-Inverter ZS EV]
|Board Swap [WIP]
|Unknown
|}

==Reusing Batteries==
[[File:A09A7634.jpg|thumb]]
The most expensive and probably equally defining component is the [[Batteries|battery]] that stores all the energy for running your car. Batteries are usually assembled from a number of modules that in turn contain a number of cells. Usually batteries are reused on a module level. In rare cases the battery can be [https://youtu.be/_7l0Y1GsNJ4 reused as is in its original battery] box.

While there are also various [[16-cell BMS|open source implementations]] of [https://www.youtube.com/watch?v=_QsMoCrSTYc battery management systems] (BMS) we generally recommend using as much of the OEM BMS as possible. Sometimes the [[:Category:OEM|OEM]] BMS comes as an all-in-one solution that measures cell data and spits out state of charge and power limit information. In other cases the BMS is split into module units that measure the physical data (voltages, temperatures) and a central unit that calculates the high level information.

Sometimes we managed to reuse the complete system which is generally the safest as you can rely on the manufacturers well tested charge and discharge limits as well as reliable state of charge information (i.e. how much energy is left in the battery at any given time). In other cases we only managed to reuse the module units. This adds the convenience of having a well tested piece of hardware with the matching connector but required us to calculate all high level battery data ourselves. This also incudes [https://www.youtube.com/watch?v=RGYLPOlT45A cell balancing].
{| class="wikitable"
|+
!Manufacturer
!Model
!BMS usability
!Energy Content
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model 3 Battery|Model 3]]
|Module and high level [WIP]
|60-80 kWh ?
|-
|
|[[Batteries#OEM modules|Model S]]
|Unknown
|85-100 kWh
|-
|[[:Category:Nissan|Nissan]]
|[[Nissan Leaf BMS|Leaf/NV200]]
|High Level
|24-40 kWh
|-
|[[:Category:VAG|VW]]
|[[VW Hybrid Battery Packs|Passat/Golf]]
|Module Level
|8.7-36 kWh
|-
|
|[[MEB Batteries|MEB]]
|Module Level
|52-77 kwh
|}

== Onboard chargers and DC/DC converters ==
[[File:PXL_20241020_024043714.jpg|thumb|Onboard charger]]
The DC/DC converter takes energy from your HV traction battery and sends it to the cars 12V systems and 12V battery. It is basically a 1:1 replacement of the former alternator. An onboard charger (OBC) takes AC current from the grid and converts it into DC current to charge the battery. These two devices are often combined in one common enclosure hence why we treat them as one.
{| class="wikitable"
|+
!Manufacturer
!Model
!OBC
!DC/DC
!OBC power
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN2 Charger|Model S and X]] (Gen2)
|yes
|no
|11 kW
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN3 Charger|Model S and X]] (Gen3)
|yes
|no
|22 kW
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X DC/DC Converter|Model S and X]] (DC/DC)
|no
|yes
|
|-
| [[:Category:Tesla|Tesla]]
| [[Tesla Model 3 Charger/DCDC ("PCS")|Model 3]]
|yes
|yes
|11 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt Charger|Volt]]
|yes
|yes
|3.7 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt 2 Charger|Volt 2]]
|yes
|yes
|3.7 kW
|-
|[[Dilong/Cascadia Chargers|Dilong]]
|
|yes
|yes
|6.6 kW
|-
|[[Eltek chargers|Eltek]]
|
|yes
|no
|3 kW
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander DCDC OBC|Outlander / iMiev]]
|yes
|yes
|3.3 kW
|-
|[[:Category:MG|MG]]
|[[MG ZS Charger|ZS / MG4 / MG5]]
|yes
|yes
|6.6 - 11 kW
|}
There are more chargers under investigation, only the proven working ones are listed here. See our [[:Category:Charger|charger listing]] for more.

== Rapid Charging==
[[File:Ccs-socket.jpg|thumb|CCS2 rapid charging socket]]
The above mentioned onboard chargers always have limited power as they space requirements and cost rise with charger power. To overcome this limitation modern EVs offer external access to their HV battery via a so called [[:Category:Rapid Charging|rapid charging]] port. This allows to charge the battery with a much more powerful external charger. As a bonus it also allows [[Bidirectional Charging|taking energy from the HV battery]] and powering appliances with it.

There are 2 rapid charging protocols and 5 connector flavours world wide
{| class="wikitable"
|+
!Connector
!Communication
!Prevalent countries
!Open Source solutions
|-
|[[:Category:ChaDeMo|CHAdeMO]]
|CAN
|Japan, world wide
|[[Chademo with ESP32-Chademo|ESP32]], [[Chademo With Arduino Due|Arduino,]] [[Chademo with Zombieverter|ZombieVerter]]
|-
|CCS Combo1
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|CCS Combo2
|[[Foccci|PLC]]
|Europe
|[[Foccci]], [[pyPLC]], [[BMW I3 Fast Charging LIM Module|I3LIM]]
|-
|NACS
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|GB/T
|CAN
|China
|
|}

== Auxiliary Parts ==
We have now treated all the major building blocks of an EV, but there are many other components to complete the vehicle such as heaters, gear shifters and so on. We will summarize them here.

* [[:Category:HVJB|HV Junction Box]]
* [[:Category:HVAC|HVAC]] (Heating, Air conditioning)
* [[Vacuum Pumps]]
* [[:Category:Power Steering|Power Steering]]
* [[VCU Comparison|VCU]] (Vehicle Control Unit)
* [[Shift Controllers]]

== Additional Reading ==

* [[:Category:Legalities|Legalities]] - Getting a vehicle road legal in your country
* [[Glossary of Terms]]
* [[Common Inverter FAQ]] - questions common to all hardware variants
* [[Tesla Inverter FAQ]] - questions regarding Tesla Large Drive Units and Small Drive Units
* [[Electronics Basics]] - general advice for troubleshooting electronic circuits
* [[I want a cheap ev conversion|cheap EV conversions]] - this entry point for the penny pinchers
* [[I want a powerful ev conversion|performant EV conversions]] - where torque trumps money
* [[Mechanical design database]] - here you will find measurements, models, files, etc for a variety of components such as adapter plates and drive shaft flanges
* [[:Category:OpenInverter|Documentation of all OpenInverter Projects]]
* [[:Category:Tutorials|Tutorials]]

==Who we are==
There is no static team or openinverter company but here we list the most active community members with links to donation or information sites:

*Johannes Hübner, openinverter founder and developer - [https://www.patreon.com/openinverter support on patreon] follow on [https://www.youtube.com/user/EngineersFear youtube] and [https://github.com/jsphuebner/ github]
*Damien Maguire, developer and most active vehicle converter - [https://evbmw.com/index.php/evbmw-webshop visit shop] [https://www.patreon.com/evbmw support on patreon] follow on [https://www.youtube.com/@Evbmw youtube] and [https://github.com/damienmaguire/ github]
*Tom de Bree, active member and developer - [https://github.com/Tom-evnut github] and [https://citini.com/ shop]
*Uwe Hennig, master of CCS - [https://www.patreon.com/uhi22 support on patreon] follow on [https://github.com/uhi22/ github]
*celeron55, developer - support via [https://www.paypal.com/paypalme/celeron55 paypal] follow on [https://www.youtube.com/user/celeron55 youtube] and [https://github.com/celeron55 github]
*Dave Fiddes, active member and developer - Follow on [https://github.com/davefiddes/ github]
*Arber Kramar, long term member and developer - [https://leafdriveblog.wordpress.com/ Follow on blogspot]
*Janosch Oppermann, active member, developer and producer - follow on [https://www.youtube.com/@foxev-content youtube]

Main Page

2024-12-03T11:02:58Z

Johu: Removed list of systems, seems redundant. Transferred parts of "before you begin" to the space

Did you know you can convert your existing fossil powered vehicle to use electricity instead? And that you can even produce that electricity yourself?

Open Inverter is a [[Main Page#Who we are|community of people]] and projects focused on open source solutions for EV conversions. Founded in 2008 by Johannes Huebner as an open source inverter control firmware, the project has since expended to include the reuse of components from production EVs and hybrids, including inverters, motors, batteries, on-board chargers, and DC-DC converters, as well as the open source implementation of other necessary systems for EV conversions such as DC Fast Charging controllers.

<imagemap>
File:Electric-car.jpg|none|frame|Click on the captions to learn more about the respective system! Image source: https://www.newkidscar.com/

poly 248 166 542 166 542 217 248 217 248 166 [[#Reusing motors and inverters - aka drive trains]]
poly 1041 455 1336 455 1336 506 1041 506 1041 455 [[#Reusing Batteries]]
poly 147 344 428 344 428 391 147 391 147 344 [[#Onboard chargers and DC/DC converters]]
poly 844 624 1118 624 1118 673 844 673 844 624 [[#Onboard chargers and DC/DC converters]]
poly 935 539 1200 539 1200 586 935 586 935 539 [[#Rapid Charging]]
poly 134 435 394 435 394 483 134 483 134 435 [[#Auxiliary Parts]]
</imagemap>

This wiki is maintained by the wider community. '''Please update this wiki'''. For example if your question has been clarified on the forum and the new information can not be found here, please add it! The credentials are the same as for the forum.

'''[[Main Page#Who we are|Developers]] time is best spent developing;''' '''Support is best found in the forums''' - Developers of various projects are often bombarded with private messages and emails. Managing these emails and questions is a extremely large undertaking. Please read, and take the time to understand the information available here and across the web if you don't understand a topic. Developers are not your personal support team, unless you want to pay them directly for their time. To keep developers independent please consider donating - donation links can be found [[Main Page#Who we are|down below]].

Read more about [[Application Support]]

==Reusing motors and inverters - aka drive trains==
[[File:Tesla_LDU.jpg|thumb]]
The drive train is one of the defining building blocks of your conversion as it defines how well your vehicle picks up speed. Over the years we have reverse engineered many popular drive trains from [[:Category:OEM|production cars]] such as Teslas. As a bonus using such complete drive trains facilitates getting the vehicle [[Legalities|road legal]] in many countries. By now you have a choice of low to medium power drive trains that only cost a few 100€ up to high performance ones at many 1000€.

We have established two methods of running these [[:Category:OEM|OEM]] systems: reverse-engineering their communication protocol and making the drive train "think" it is still in its original vehicle OR swapping out the control electronics for our own open source motor controller. The latter method gives your more control and power but also a steeper learning curve.

Nearly all drive trains are targeted at 400V battery voltage. Run at a lower voltage they will produce proportionally less power.
Here is what we have done so far and how we've done it. Some is still work in progress (WIP)
{| class="wikitable"
|+
!Manufacturer
!Drive Train
!Control Method
! Approximate Power Output
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X Large Drive Unit ("LDU")|Large Drive Unit]]
|Board Swap
|335-475 kW
|-
|
|[[Tesla Model S/X Small Drive Unit ("SDU")|Small Drive Unit]]
|Board Swap
|180 kW
|-
|
|[[Tesla Model 3 Rear Drive Unit|Model 3/Y Rear Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|239 kW
|-
|
|[[Tesla Model 3 Front Drive Unit|Model 3/Y Front Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|121 kW
|-
|[[Nissan]]
|[[Nissan Leaf Motors|Gen1]]
|[[ZombieVerter VCU|CAN spoofing]]
|80 kW
|-
|
| [[Nissan Leaf Gen2 Board|Gen2]]
|[[ZombieVerter VCU|CAN spoofing]]/Board Swap
|80 kW / 130 kW (board swap)
|-
|
|[[Nissan Leaf Gen 3 (2018 up EM57)|Gen3]]
|[[ZombieVerter VCU|CAN spoofing]]/Board Swap [WIP]
|110 - 160 kW
|-
|[[:Category:Toyota|Toyota]]
|[[Lexus GS450h Drivetrain|Lexus GS 450h]]
|[[ZombieVerter VCU|Communication spoofing]]
|250 kW
|-
|
|[[Toyota/Lexus GS300h CVT|Lexus GS 300h]]
|[[ZombieVerter VCU|Communication spoofing]]
|105 kW
|-
|
|[[Toyota Prius Gen2 Inverter|Prius Gen2]]
|[[Toyota Prius Gen2 Inverter Controller|External Control Board]]
|40-70 kW
|-
|
|[[Toyota Prius Gen3 Board|Prius Gen3]]
|Board Swap/[[ZombieVerter VCU|Communication spoofing]]
|100 kW
|-
|
|[[Toyota/Lexus MGR Rear Transaxle Motor|MGR]]
|Prius Gen2 or Gen3 inverter
|18-50 kW (various models)
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander Rear Drive Unit|Rear Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing]]
|60-70 kW
|-
|
|[[Mitsubishi Outlander Front Transaxle|Front Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing]]
|60-70 kW
|-
|[[:Category:BMW|BMW]]
|[[BMW i3 Inverter|i3]]
|Board Swap
|125-135 kW
|-
|[[Chevrolet|Chevy/Opel]]
|[[Chevrolet Volt Inverter|Volt/Ampera]]
|Board Swap
|160 kW
|-
|[[:Category:Ford|Ford]]
|[[Ford Ranger TIM Controller|Ranger]]
|Board Swap
| Unknown
|-
| Renault
|[https://openinverter.org/forum/viewtopic.php?t=4749 Zoe]
|Board Swap [WIP]
|Unknown
|-
|MG
|[https://github.com/damienmaguire/MG-EV-Inverter ZS EV]
|Board Swap [WIP]
|Unknown
|}

==Reusing Batteries==
[[File:A09A7634.jpg|thumb]]
The most expensive and probably equally defining component is the [[Batteries|battery]] that stores all the energy for running your car. Batteries are usually assembled from a number of modules that in turn contain a number of cells. Usually batteries are reused on a module level. In rare cases the battery can be [https://youtu.be/_7l0Y1GsNJ4 reused as is in its original battery] box.

While there are also various [[16-cell BMS|open source implementations]] of [https://www.youtube.com/watch?v=_QsMoCrSTYc battery management systems] (BMS) we generally recommend using as much of the OEM BMS as possible. Sometimes the [[:Category:OEM|OEM]] BMS comes as an all-in-one solution that measures cell data and spits out state of charge and power limit information. In other cases the BMS is split into module units that measure the physical data (voltages, temperatures) and a central unit that calculates the high level information.

Sometimes we managed to reuse the complete system which is generally the safest as you can rely on the manufacturers well tested charge and discharge limits as well as reliable state of charge information (i.e. how much energy is left in the battery at any given time). In other cases we only managed to reuse the module units. This adds the convenience of having a well tested piece of hardware with the matching connector but required us to calculate all high level battery data ourselves. This also incudes [https://www.youtube.com/watch?v=RGYLPOlT45A cell balancing].
{| class="wikitable"
|+
!Manufacturer
!Model
!BMS usability
!Energy Content
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model 3 Battery|Model 3]]
|Module and high level [WIP]
|60-80 kWh ?
|-
|
|[[Batteries#OEM modules|Model S]]
|Unknown
|85-100 kWh
|-
|[[:Category:Nissan|Nissan]]
|[[Nissan Leaf BMS|Leaf/NV200]]
|High Level
|24-40 kWh
|-
|[[:Category:VAG|VW]]
|[[VW Hybrid Battery Packs|Passat/Golf]]
|Module Level
|8.7-36 kWh
|-
|
|[[MEB Batteries|MEB]]
|Module Level
|52-77 kwh
|}

== Onboard chargers and DC/DC converters ==
[[File:PXL_20241020_024043714.jpg|thumb|Onboard charger]]
The DC/DC converter takes energy from your HV traction battery and sends it to the cars 12V systems and 12V battery. It is basically a 1:1 replacement of the former alternator. An onboard charger (OBC) takes AC current from the grid and converts it into DC current to charge the battery. These two devices are often combined in one common enclosure hence why we treat them as one.
{| class="wikitable"
|+
!Manufacturer
!Model
!OBC
!DC/DC
!OBC power
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN2 Charger|Model S and X]] (Gen2)
|yes
|no
|11 kW
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN3 Charger|Model S and X]] (Gen3)
|yes
|no
|22 kW
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X DC/DC Converter|Model S and X]] (DC/DC)
|no
|yes
|
|-
| [[:Category:Tesla|Tesla]]
| [[Tesla Model 3 Charger/DCDC ("PCS")|Model 3]]
|yes
|yes
|11 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt Charger|Volt]]
|yes
|yes
|3.7 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt 2 Charger|Volt 2]]
|yes
|yes
|3.7 kW
|-
|[[Dilong/Cascadia Chargers|Dilong]]
|
|yes
|yes
|6.6 kW
|-
|[[Eltek chargers|Eltek]]
|
|yes
|no
|3 kW
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander DCDC OBC|Outlander / iMiev]]
|yes
|yes
|3.3 kW
|-
|[[:Category:MG|MG]]
|[[MG ZS Charger|ZS / MG4 / MG5]]
|yes
|yes
|6.6 - 11 kW
|}
There are more chargers under investigation, only the proven working ones are listed here. See our [[:Category:Charger|charger listing]] for more.

== Rapid Charging==
[[File:Ccs-socket.jpg|thumb|CCS2 rapid charging socket]]
The above mentioned onboard chargers always have limited power as they space requirements and cost rise with charger power. To overcome this limitation modern EVs offer external access to their HV battery via a so called [[:Category:Rapid Charging|rapid charging]] port. This allows to charge the battery with a much more powerful external charger. As a bonus it also allows [[Bidirectional Charging|taking energy from the HV battery]] and powering appliances with it.

There are 2 rapid charging protocols and 5 connector flavours world wide
{| class="wikitable"
|+
!Connector
!Communication
!Prevalent countries
!Open Source solutions
|-
|[[:Category:ChaDeMo|CHAdeMO]]
|CAN
|Japan, world wide
|[[Chademo with ESP32-Chademo|ESP32]], [[Chademo With Arduino Due|Arduino,]] [[Chademo with Zombieverter|ZombieVerter]]
|-
|CCS Combo1
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|CCS Combo2
|[[Foccci|PLC]]
|Europe
|[[Foccci]], [[pyPLC]], [[BMW I3 Fast Charging LIM Module|I3LIM]]
|-
|NACS
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|GB/T
|CAN
|China
|
|}

== Auxiliary Parts ==
We have now treated all the major building blocks of an EV, but there are many other components to complete the vehicle such as heaters, gear shifters and so on. We will summarize them here.

* [[:Category:HVJB|HV Junction Box]]
* [[:Category:HVAC|HVAC]] (Heating, Air conditioning)
* [[Vacuum Pumps]]
* [[:Category:Power Steering|Power Steering]]
* [[VCU Comparison|VCU]] (Vehicle Control Unit)
* [[Shift Controllers]]

== Additional Reading ==

* [[:Category:Legalities|Legalities]] - Getting a vehicle road legal in your country
* [[Glossary of Terms]]
* [[Common Inverter FAQ]] - questions common to all hardware variants
* [[Tesla Inverter FAQ]] - questions regarding Tesla Large Drive Units and Small Drive Units
* [[Electronics Basics]] - general advice for troubleshooting electronic circuits
* [[I want a cheap ev conversion|cheap EV conversions]] - this entry point for the penny pinchers
* [[I want a powerful ev conversion|performant EV conversions]] - where torque trumps money
* [[Mechanical design database]] - here you will find measurements, models, files, etc for a variety of components such as adapter plates and drive shaft flanges
* [[:Category:OpenInverter|Documentation of all OpenInverter Projects]]
* [[:Category:Tutorials|Tutorials]]

==Who we are==
There is no static team or openinverter company but here we list the most active community members with links to donation or information sites:

*Johannes Hübner, openinverter founder and developer - [https://www.patreon.com/openinverter support on patreon] follow on [https://www.youtube.com/user/EngineersFear youtube] and [https://github.com/jsphuebner/ github]
*Damien Maguire, developer and most active vehicle converter - [https://evbmw.com/index.php/evbmw-webshop visit shop] [https://www.patreon.com/evbmw support on patreon] follow on [https://www.youtube.com/@Evbmw youtube] and [https://github.com/damienmaguire/ github]
*Tom de Bree, active member and developer - [https://github.com/Tom-evnut github] and [https://citini.com/ shop]
*Uwe Hennig, master of CCS - [https://www.patreon.com/uhi22 support on patreon] follow on [https://github.com/uhi22/ github]
*celeron55, developer - support via [https://www.paypal.com/paypalme/celeron55 paypal] follow on [https://www.youtube.com/user/celeron55 youtube] and [https://github.com/celeron55 github]
*Dave Fiddes, active member and developer - Follow on [https://github.com/davefiddes/ github]
*Arber Kramar, long term member and developer - [https://leafdriveblog.wordpress.com/ Follow on blogspot]
*Janosch Oppermann, active member, developer and producer - follow on [https://www.youtube.com/@foxev-content youtube]

MediaWiki:Sitenotice

2024-12-03T10:49:48Z

Johu:

'''You undertake your project at your own risk.'''

Converting a vehicle to electric drive is likely to be difficult. Users should satisfy themselves that they are physically able to perform any mechanical work on their vehicle, safely install and troubleshoot electrical systems, and satisfy any legal requirements they may be subject to before beginning their conversion. Read [[High Voltage Safety]]

The information provided on this wiki and the support forums is intended as information only. The Open Inverter project and contributors to the forums and this wiki take no responsibility for how you use the information on this site, nor any liability for injuries, or death, that may result from your actions.

MediaWiki:Sitenotice

2024-12-03T10:44:53Z

Johu: Added link to High_Voltage_Safety

'''You undertake your project at your own risk.'''

Converting a vehicle to electric drive is likely to be difficult. Users should satisfy themselves that they are physically able to perform any mechanical work on their vehicle, safely install and troubleshoot electrical systems, and satisfy any legal requirements they may be subject to before beginning their conversion. Read [[High_Voltage_Safety]]

The information provided on this wiki and the support forums is intended as information only. The Open Inverter project and contributors to the forums and this wiki take no responsibility for how you use the information on this site, nor any liability for injuries, or death, that may result from your actions.

Main Page

2024-12-03T10:40:52Z

Johu: /* Who we are */

Did you know you can convert your existing fossil powered vehicle to use electricity instead? And that you can even produce that electricity yourself?

Open Inverter is a [[Main Page#Who we are|community of people]] and projects focused on open source solutions for EV conversions. Founded in 2008 by Johannes Huebner as an open source inverter control firmware, the project has since expended to include the reuse of components from production EVs and hybrids, including inverters, motors, batteries, on-board chargers, and DC-DC converters, as well as the open source implementation of other necessary systems for EV conversions such as DC Fast Charging controllers.

<imagemap>
File:Electric-car.jpg|none|frame|Click on the captions to learn more about the respective system! Image source: https://www.newkidscar.com/

poly 248 166 542 166 542 217 248 217 248 166 [[#Reusing motors and inverters - aka drive trains]]
poly 1041 455 1336 455 1336 506 1041 506 1041 455 [[#Reusing Batteries]]
poly 147 344 428 344 428 391 147 391 147 344 [[#Onboard chargers and DC/DC converters]]
poly 844 624 1118 624 1118 673 844 673 844 624 [[#Onboard chargers and DC/DC converters]]
poly 935 539 1200 539 1200 586 935 586 935 539 [[#Rapid Charging]]
poly 134 435 394 435 394 483 134 483 134 435 [[#Auxiliary Parts]]
</imagemap>

While the project, as the name suggests, started out as an open source implementation of a traction motor inverter it now comprises many other topics as well:

*Reusing complete drive trains
* Reusing batteries including the management electronics (BMS)
*Reusing on board chargers to charge your vehicle from AC outlets
*Reusing DC/DC converters to run your 12V system from the high voltage traction battery
*Reusing A/C compressors and cabin heaters
*Fast charging your vehicle on public rapid charging infrastructure
*Tying all components together with a vehicle control unit (VCU)
* Building small scale PV systems including storage
More on these topics in the detailed sections below. Happy reading!

==Reusing motors and inverters - aka drive trains==
[[File:Tesla_LDU.jpg|thumb]]
The drive train is one of the defining building blocks of your conversion as it defines how well your vehicle picks up speed. Over the years we have reverse engineered many popular drive trains from [[:Category:OEM|production cars]] such as Teslas. As a bonus using such complete drive trains facilitates getting the vehicle [[Legalities|road legal]] in many countries. By now you have a choice of low to medium power drive trains that only cost a few 100€ up to high performance ones at many 1000€.

We have established two methods of running these [[:Category:OEM|OEM]] systems: reverse-engineering their communication protocol and making the drive train "think" it is still in its original vehicle OR swapping out the control electronics for our own open source motor controller. The latter method gives your more control and power but also a steeper learning curve.

Nearly all drive trains are targeted at 400V battery voltage. Run at a lower voltage they will produce proportionally less power.
Here is what we have done so far and how we've done it. Some is still work in progress (WIP)
{| class="wikitable"
|+
!Manufacturer
!Drive Train
!Control Method
! Approximate Power Output
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X Large Drive Unit ("LDU")|Large Drive Unit]]
|Board Swap
|335-475 kW
|-
|
|[[Tesla Model S/X Small Drive Unit ("SDU")|Small Drive Unit]]
|Board Swap
|180 kW
|-
|
|[[Tesla Model 3 Rear Drive Unit|Model 3/Y Rear Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|239 kW
|-
|
|[[Tesla Model 3 Front Drive Unit|Model 3/Y Front Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|121 kW
|-
|[[Nissan]]
|[[Nissan Leaf Motors|Gen1]]
|[[ZombieVerter VCU|CAN spoofing]]
|80 kW
|-
|
| [[Nissan Leaf Gen2 Board|Gen2]]
|[[ZombieVerter VCU|CAN spoofing]]/Board Swap
|80 kW / 130 kW (board swap)
|-
|
|[[Nissan Leaf Gen 3 (2018 up EM57)|Gen3]]
|[[ZombieVerter VCU|CAN spoofing]]/Board Swap [WIP]
|110 - 160 kW
|-
|[[:Category:Toyota|Toyota]]
|[[Lexus GS450h Drivetrain|Lexus GS 450h]]
|[[ZombieVerter VCU|Communication spoofing]]
|250 kW
|-
|
|[[Toyota/Lexus GS300h CVT|Lexus GS 300h]]
|[[ZombieVerter VCU|Communication spoofing]]
|105 kW
|-
|
|[[Toyota Prius Gen2 Inverter|Prius Gen2]]
|[[Toyota Prius Gen2 Inverter Controller|External Control Board]]
|40-70 kW
|-
|
|[[Toyota Prius Gen3 Board|Prius Gen3]]
|Board Swap/[[ZombieVerter VCU|Communication spoofing]]
|100 kW
|-
|
|[[Toyota/Lexus MGR Rear Transaxle Motor|MGR]]
|Prius Gen2 or Gen3 inverter
|18-50 kW (various models)
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander Rear Drive Unit|Rear Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing]]
|60-70 kW
|-
|
|[[Mitsubishi Outlander Front Transaxle|Front Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing]]
|60-70 kW
|-
|[[:Category:BMW|BMW]]
|[[BMW i3 Inverter|i3]]
|Board Swap
|125-135 kW
|-
|[[Chevrolet|Chevy/Opel]]
|[[Chevrolet Volt Inverter|Volt/Ampera]]
|Board Swap
|160 kW
|-
|[[:Category:Ford|Ford]]
|[[Ford Ranger TIM Controller|Ranger]]
|Board Swap
| Unknown
|-
| Renault
|[https://openinverter.org/forum/viewtopic.php?t=4749 Zoe]
|Board Swap [WIP]
|Unknown
|-
|MG
|[https://github.com/damienmaguire/MG-EV-Inverter ZS EV]
|Board Swap [WIP]
|Unknown
|}

==Reusing Batteries==
[[File:A09A7634.jpg|thumb]]
The most expensive and probably equally defining component is the [[Batteries|battery]] that stores all the energy for running your car. Batteries are usually assembled from a number of modules that in turn contain a number of cells. Usually batteries are reused on a module level. In rare cases the battery can be [https://youtu.be/_7l0Y1GsNJ4 reused as is in its original battery] box.

While there are also various [[16-cell BMS|open source implementations]] of [https://www.youtube.com/watch?v=_QsMoCrSTYc battery management systems] (BMS) we generally recommend using as much of the OEM BMS as possible. Sometimes the [[:Category:OEM|OEM]] BMS comes as an all-in-one solution that measures cell data and spits out state of charge and power limit information. In other cases the BMS is split into module units that measure the physical data (voltages, temperatures) and a central unit that calculates the high level information.

Sometimes we managed to reuse the complete system which is generally the safest as you can rely on the manufacturers well tested charge and discharge limits as well as reliable state of charge information (i.e. how much energy is left in the battery at any given time). In other cases we only managed to reuse the module units. This adds the convenience of having a well tested piece of hardware with the matching connector but required us to calculate all high level battery data ourselves. This also incudes [https://www.youtube.com/watch?v=RGYLPOlT45A cell balancing].
{| class="wikitable"
|+
!Manufacturer
!Model
!BMS usability
!Energy Content
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model 3 Battery|Model 3]]
|Module and high level [WIP]
|60-80 kWh ?
|-
|
|[[Batteries#OEM modules|Model S]]
|Unknown
|85-100 kWh
|-
|[[:Category:Nissan|Nissan]]
|[[Nissan Leaf BMS|Leaf/NV200]]
|High Level
|24-40 kWh
|-
|[[:Category:VAG|VW]]
|[[VW Hybrid Battery Packs|Passat/Golf]]
|Module Level
|8.7-36 kWh
|-
|
|[[MEB Batteries|MEB]]
|Module Level
|52-77 kwh
|}

== Onboard chargers and DC/DC converters ==
[[File:PXL_20241020_024043714.jpg|thumb|Onboard charger]]
The DC/DC converter takes energy from your HV traction battery and sends it to the cars 12V systems and 12V battery. It is basically a 1:1 replacement of the former alternator. An onboard charger (OBC) takes AC current from the grid and converts it into DC current to charge the battery. These two devices are often combined in one common enclosure hence why we treat them as one.
{| class="wikitable"
|+
!Manufacturer
!Model
!OBC
!DC/DC
!OBC power
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN2 Charger|Model S and X]] (Gen2)
|yes
|no
|11 kW
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN3 Charger|Model S and X]] (Gen3)
|yes
|no
|22 kW
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X DC/DC Converter|Model S and X]] (DC/DC)
|no
|yes
|
|-
| [[:Category:Tesla|Tesla]]
| [[Tesla Model 3 Charger/DCDC ("PCS")|Model 3]]
|yes
|yes
|11 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt Charger|Volt]]
|yes
|yes
|3.7 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt 2 Charger|Volt 2]]
|yes
|yes
|3.7 kW
|-
|[[Dilong/Cascadia Chargers|Dilong]]
|
|yes
|yes
|6.6 kW
|-
|[[Eltek chargers|Eltek]]
|
|yes
|no
|3 kW
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander DCDC OBC|Outlander / iMiev]]
|yes
|yes
|3.3 kW
|-
|[[:Category:MG|MG]]
|[[MG ZS Charger|ZS / MG4 / MG5]]
|yes
|yes
|6.6 - 11 kW
|}
There are more chargers under investigation, only the proven working ones are listed here. See our [[:Category:Charger|charger listing]] for more.

== Rapid Charging==
[[File:Ccs-socket.jpg|thumb|CCS2 rapid charging socket]]
The above mentioned onboard chargers always have limited power as they space requirements and cost rise with charger power. To overcome this limitation modern EVs offer external access to their HV battery via a so called [[:Category:Rapid Charging|rapid charging]] port. This allows to charge the battery with a much more powerful external charger. As a bonus it also allows [[Bidirectional Charging|taking energy from the HV battery]] and powering appliances with it.

There are 2 rapid charging protocols and 5 connector flavours world wide
{| class="wikitable"
|+
!Connector
!Communication
!Prevalent countries
!Open Source solutions
|-
|[[:Category:ChaDeMo|CHAdeMO]]
|CAN
|Japan, world wide
|[[Chademo with ESP32-Chademo|ESP32]], [[Chademo With Arduino Due|Arduino,]] [[Chademo with Zombieverter|ZombieVerter]]
|-
|CCS Combo1
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|CCS Combo2
|[[Foccci|PLC]]
|Europe
|[[Foccci]], [[pyPLC]], [[BMW I3 Fast Charging LIM Module|I3LIM]]
|-
|NACS
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|GB/T
|CAN
|China
|
|}

== Auxiliary Parts ==
We have now treated all the major building blocks of an EV, but there are many other components to complete the vehicle such as heaters, gear shifters and so on. We will summarize them here.

* [[:Category:HVJB|HV Junction Box]]
* [[:Category:HVAC|HVAC]] (Heating, Air conditioning)
* [[Vacuum Pumps]]
* [[:Category:Power Steering|Power Steering]]
* [[VCU Comparison|VCU]] (Vehicle Control Unit)
* [[Shift Controllers]]

== Additional Reading ==

* [[:Category:Legalities|Legalities]] - Getting a vehicle road legal in your country
* [[Glossary of Terms]]
* [[Common Inverter FAQ]] - questions common to all hardware variants
* [[Tesla Inverter FAQ]] - questions regarding Tesla Large Drive Units and Small Drive Units
* [[Electronics Basics]] - general advice for troubleshooting electronic circuits
* [[I want a cheap ev conversion|cheap EV conversions]] - this entry point for the penny pinchers
* [[I want a powerful ev conversion|performant EV conversions]] - where torque trumps money
* [[Mechanical design database]] - here you will find measurements, models, files, etc for a variety of components such as adapter plates and drive shaft flanges
* [[:Category:OpenInverter|Documentation of all OpenInverter Projects]]
* [[:Category:Tutorials|Tutorials]]

==Who we are==
There is no static team or openinverter company but here we list the most active community members with links to donation or information sites:

*Johannes Hübner, openinverter founder and developer - [https://www.patreon.com/openinverter support on patreon] follow on [https://www.youtube.com/user/EngineersFear youtube] and [https://github.com/jsphuebner/ github]
*Damien Maguire, developer and most active vehicle converter - [https://evbmw.com/index.php/evbmw-webshop visit shop] [https://www.patreon.com/evbmw support on patreon] follow on [https://www.youtube.com/@Evbmw youtube] and [https://github.com/damienmaguire/ github]
*Tom de Bree, active member and developer - [https://github.com/Tom-evnut github] and [https://citini.com/ shop]
*Uwe Hennig, master of CCS - [https://www.patreon.com/uhi22 support on patreon] follow on [https://github.com/uhi22/ github]
*celeron55, developer - support via [https://www.paypal.com/paypalme/celeron55 paypal] follow on [https://www.youtube.com/user/celeron55 youtube] and [https://github.com/celeron55 github]
*Dave Fiddes, active member and developer - Follow on [https://github.com/davefiddes/ github]
*Arber Kramar, long term member and developer - [https://leafdriveblog.wordpress.com/ Follow on blogspot]
*Janosch Oppermann, active member, developer and producer - follow on [https://www.youtube.com/@foxev-content youtube]

Main Page

2024-12-02T13:21:54Z

Johu: /* Who we are */

Did you know you can convert your existing fossil powered vehicle to use electricity instead? And that you can even produce that electricity yourself?

Open Inverter is a [[Main Page#Who we are|community of people]] and projects focused on open source solutions for EV conversions. Founded in 2008 by Johannes Huebner as an open source inverter control firmware, the project has since expended to include the reuse of components from production EVs and hybrids, including inverters, motors, batteries, on-board chargers, and DC-DC converters, as well as the open source implementation of other necessary systems for EV conversions such as DC Fast Charging controllers.

<imagemap>
File:Electric-car.jpg|none|frame|Click on the captions to learn more about the respective system! Image source: https://www.newkidscar.com/

poly 248 166 542 166 542 217 248 217 248 166 [[#Reusing motors and inverters - aka drive trains]]
poly 1041 455 1336 455 1336 506 1041 506 1041 455 [[#Reusing Batteries]]
poly 147 344 428 344 428 391 147 391 147 344 [[#Onboard chargers and DC/DC converters]]
poly 844 624 1118 624 1118 673 844 673 844 624 [[#Onboard chargers and DC/DC converters]]
poly 935 539 1200 539 1200 586 935 586 935 539 [[#Rapid Charging]]
poly 134 435 394 435 394 483 134 483 134 435 [[#Auxiliary Parts]]
</imagemap>

While the project, as the name suggests, started out as an open source implementation of a traction motor inverter it now comprises many other topics as well:

*Reusing complete drive trains
* Reusing batteries including the management electronics (BMS)
*Reusing on board chargers to charge your vehicle from AC outlets
*Reusing DC/DC converters to run your 12V system from the high voltage traction battery
*Reusing A/C compressors and cabin heaters
*Fast charging your vehicle on public rapid charging infrastructure
*Tying all components together with a vehicle control unit (VCU)
* Building small scale PV systems including storage
More on these topics in the detailed sections below. Happy reading!

==Reusing motors and inverters - aka drive trains==
[[File:Tesla_LDU.jpg|thumb]]
The drive train is one of the defining building blocks of your conversion as it defines how well your vehicle picks up speed. Over the years we have reverse engineered many popular drive trains from [[:Category:OEM|production cars]] such as Teslas. As a bonus using such complete drive trains facilitates getting the vehicle [[Legalities|road legal]] in many countries. By now you have a choice of low to medium power drive trains that only cost a few 100€ up to high performance ones at many 1000€.

We have established two methods of running these [[:Category:OEM|OEM]] systems: reverse-engineering their communication protocol and making the drive train "think" it is still in its original vehicle OR swapping out the control electronics for our own open source motor controller. The latter method gives your more control and power but also a steeper learning curve.

Nearly all drive trains are targeted at 400V battery voltage. Run at a lower voltage they will produce proportionally less power.
Here is what we have done so far and how we've done it. Some is still work in progress (WIP)
{| class="wikitable"
|+
!Manufacturer
!Drive Train
!Control Method
! Approximate Power Output
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X Large Drive Unit ("LDU")|Large Drive Unit]]
|Board Swap
|335-475 kW
|-
|
|[[Tesla Model S/X Small Drive Unit ("SDU")|Small Drive Unit]]
|Board Swap
|180 kW
|-
|
|[[Tesla Model 3 Rear Drive Unit|Model 3/Y Rear Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|239 kW
|-
|
|[[Tesla Model 3 Front Drive Unit|Model 3/Y Front Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|121 kW
|-
|[[Nissan]]
|[[Nissan Leaf Motors|Gen1]]
|[[ZombieVerter VCU|CAN spoofing]]
|80 kW
|-
|
| [[Nissan Leaf Gen2 Board|Gen2]]
|[[ZombieVerter VCU|CAN spoofing]]/Board Swap
|80 kW / 130 kW (board swap)
|-
|
|[[Nissan Leaf Gen 3 (2018 up EM57)|Gen3]]
|[[ZombieVerter VCU|CAN spoofing]]/Board Swap [WIP]
|110 - 160 kW
|-
|[[:Category:Toyota|Toyota]]
|[[Lexus GS450h Drivetrain|Lexus GS 450h]]
|[[ZombieVerter VCU|Communication spoofing]]
|250 kW
|-
|
|[[Toyota/Lexus GS300h CVT|Lexus GS 300h]]
|[[ZombieVerter VCU|Communication spoofing]]
|105 kW
|-
|
|[[Toyota Prius Gen2 Inverter|Prius Gen2]]
|[[Toyota Prius Gen2 Inverter Controller|External Control Board]]
|40-70 kW
|-
|
|[[Toyota Prius Gen3 Board|Prius Gen3]]
|Board Swap/[[ZombieVerter VCU|Communication spoofing]]
|100 kW
|-
|
|[[Toyota/Lexus MGR Rear Transaxle Motor|MGR]]
|Prius Gen2 or Gen3 inverter
|18-50 kW (various models)
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander Rear Drive Unit|Rear Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing]]
|60-70 kW
|-
|
|[[Mitsubishi Outlander Front Transaxle|Front Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing]]
|60-70 kW
|-
|[[:Category:BMW|BMW]]
|[[BMW i3 Inverter|i3]]
|Board Swap
|125-135 kW
|-
|[[Chevrolet|Chevy/Opel]]
|[[Chevrolet Volt Inverter|Volt/Ampera]]
|Board Swap
|160 kW
|-
|[[:Category:Ford|Ford]]
|[[Ford Ranger TIM Controller|Ranger]]
|Board Swap
| Unknown
|-
| Renault
|[https://openinverter.org/forum/viewtopic.php?t=4749 Zoe]
|Board Swap [WIP]
|Unknown
|-
|MG
|[https://github.com/damienmaguire/MG-EV-Inverter ZS EV]
|Board Swap [WIP]
|Unknown
|}

==Reusing Batteries==
[[File:A09A7634.jpg|thumb]]
The most expensive and probably equally defining component is the [[Batteries|battery]] that stores all the energy for running your car. Batteries are usually assembled from a number of modules that in turn contain a number of cells. Usually batteries are reused on a module level. In rare cases the battery can be [https://youtu.be/_7l0Y1GsNJ4 reused as is in its original battery] box.

While there are also various [[16-cell BMS|open source implementations]] of [https://www.youtube.com/watch?v=_QsMoCrSTYc battery management systems] (BMS) we generally recommend using as much of the OEM BMS as possible. Sometimes the [[:Category:OEM|OEM]] BMS comes as an all-in-one solution that measures cell data and spits out state of charge and power limit information. In other cases the BMS is split into module units that measure the physical data (voltages, temperatures) and a central unit that calculates the high level information.

Sometimes we managed to reuse the complete system which is generally the safest as you can rely on the manufacturers well tested charge and discharge limits as well as reliable state of charge information (i.e. how much energy is left in the battery at any given time). In other cases we only managed to reuse the module units. This adds the convenience of having a well tested piece of hardware with the matching connector but required us to calculate all high level battery data ourselves. This also incudes [https://www.youtube.com/watch?v=RGYLPOlT45A cell balancing].
{| class="wikitable"
|+
!Manufacturer
!Model
!BMS usability
!Energy Content
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model 3 Battery|Model 3]]
|Module and high level [WIP]
|60-80 kWh ?
|-
|
|[[Batteries#OEM modules|Model S]]
|Unknown
|85-100 kWh
|-
|[[:Category:Nissan|Nissan]]
|[[Nissan Leaf BMS|Leaf/NV200]]
|High Level
|24-40 kWh
|-
|[[:Category:VAG|VW]]
|[[VW Hybrid Battery Packs|Passat/Golf]]
|Module Level
|8.7-36 kWh
|-
|
|[[MEB Batteries|MEB]]
|Module Level
|52-77 kwh
|}

== Onboard chargers and DC/DC converters ==
[[File:PXL_20241020_024043714.jpg|thumb|Onboard charger]]
The DC/DC converter takes energy from your HV traction battery and sends it to the cars 12V systems and 12V battery. It is basically a 1:1 replacement of the former alternator. An onboard charger (OBC) takes AC current from the grid and converts it into DC current to charge the battery. These two devices are often combined in one common enclosure hence why we treat them as one.
{| class="wikitable"
|+
!Manufacturer
!Model
!OBC
!DC/DC
!OBC power
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN2 Charger|Model S and X]] (Gen2)
|yes
|no
|11 kW
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN3 Charger|Model S and X]] (Gen3)
|yes
|no
|22 kW
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X DC/DC Converter|Model S and X]] (DC/DC)
|no
|yes
|
|-
| [[:Category:Tesla|Tesla]]
| [[Tesla Model 3 Charger/DCDC ("PCS")|Model 3]]
|yes
|yes
|11 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt Charger|Volt]]
|yes
|yes
|3.7 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt 2 Charger|Volt 2]]
|yes
|yes
|3.7 kW
|-
|[[Dilong/Cascadia Chargers|Dilong]]
|
|yes
|yes
|6.6 kW
|-
|[[Eltek chargers|Eltek]]
|
|yes
|no
|3 kW
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander DCDC OBC|Outlander / iMiev]]
|yes
|yes
|3.3 kW
|-
|[[:Category:MG|MG]]
|[[MG ZS Charger|ZS / MG4 / MG5]]
|yes
|yes
|6.6 - 11 kW
|}
There are more chargers under investigation, only the proven working ones are listed here. See our [[:Category:Charger|charger listing]] for more.

== Rapid Charging==
[[File:Ccs-socket.jpg|thumb|CCS2 rapid charging socket]]
The above mentioned onboard chargers always have limited power as they space requirements and cost rise with charger power. To overcome this limitation modern EVs offer external access to their HV battery via a so called [[:Category:Rapid Charging|rapid charging]] port. This allows to charge the battery with a much more powerful external charger. As a bonus it also allows [[Bidirectional Charging|taking energy from the HV battery]] and powering appliances with it.

There are 2 rapid charging protocols and 5 connector flavours world wide
{| class="wikitable"
|+
!Connector
!Communication
!Prevalent countries
!Open Source solutions
|-
|[[:Category:ChaDeMo|CHAdeMO]]
|CAN
|Japan, world wide
|[[Chademo with ESP32-Chademo|ESP32]], [[Chademo With Arduino Due|Arduino,]] [[Chademo with Zombieverter|ZombieVerter]]
|-
|CCS Combo1
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|CCS Combo2
|[[Foccci|PLC]]
|Europe
|[[Foccci]], [[pyPLC]], [[BMW I3 Fast Charging LIM Module|I3LIM]]
|-
|NACS
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|GB/T
|CAN
|China
|
|}

== Auxiliary Parts ==
We have now treated all the major building blocks of an EV, but there are many other components to complete the vehicle such as heaters, gear shifters and so on. We will summarize them here.

* [[:Category:HVJB|HV Junction Box]]
* [[:Category:HVAC|HVAC]] (Heating, Air conditioning)
* [[Vacuum Pumps]]
* [[:Category:Power Steering|Power Steering]]
* [[VCU Comparison|VCU]] (Vehicle Control Unit)
* [[Shift Controllers]]

== Additional Reading ==

* [[:Category:Legalities|Legalities]] - Getting a vehicle road legal in your country
* [[Glossary of Terms]]
* [[Common Inverter FAQ]] - questions common to all hardware variants
* [[Tesla Inverter FAQ]] - questions regarding Tesla Large Drive Units and Small Drive Units
* [[Electronics Basics]] - general advice for troubleshooting electronic circuits
* [[I want a cheap ev conversion|cheap EV conversions]] - this entry point for the penny pinchers
* [[I want a powerful ev conversion|performant EV conversions]] - where torque trumps money
* [[Mechanical design database]] - here you will find measurements, models, files, etc for a variety of components such as adapter plates and drive shaft flanges
* [[:Category:OpenInverter|Documentation of all OpenInverter Projects]]
* [[:Category:Tutorials|Tutorials]]

==Who we are==
There is no static team or openinverter company but here we list the most active community members with links to donation or information sites:

*Johannes Hübner, openinverter founder and developer - [https://www.patreon.com/openinverter support on patreon] follow on [https://www.youtube.com/user/EngineersFear youtube] and [https://github.com/jsphuebner/ github]
*Damien Maguire, developer and most active vehicle converter - [https://www.patreon.com/evbmw support on patreon] follow on [https://www.youtube.com/@Evbmw youtube] and [https://github.com/damienmaguire/ github]
*Uwe Hennig, master of CCS - [https://www.patreon.com/uhi22 support on patreon] follow on [https://github.com/uhi22/ github]
*celeron55, developer - support via [https://www.paypal.com/paypalme/celeron55 paypal] follow on [https://www.youtube.com/user/celeron55 youtube] and [https://github.com/celeron55 github]
*Dave Fiddes, active member and developer - Follow on [https://github.com/davefiddes/ github]
*Arber Kramar, long term member and developer - [https://leafdriveblog.wordpress.com/ Follow on blogspot]
*Janosch Oppermann, active member, developer and producer - follow on [https://www.youtube.com/@foxev-content youtube]

Main Page

2024-12-02T13:21:39Z

Johu:

Did you know you can convert your existing fossil powered vehicle to use electricity instead? And that you can even produce that electricity yourself?

Open Inverter is a [[Main Page#Who we are|community of people]] and projects focused on open source solutions for EV conversions. Founded in 2008 by Johannes Huebner as an open source inverter control firmware, the project has since expended to include the reuse of components from production EVs and hybrids, including inverters, motors, batteries, on-board chargers, and DC-DC converters, as well as the open source implementation of other necessary systems for EV conversions such as DC Fast Charging controllers.

<imagemap>
File:Electric-car.jpg|none|frame|Click on the captions to learn more about the respective system! Image source: https://www.newkidscar.com/

poly 248 166 542 166 542 217 248 217 248 166 [[#Reusing motors and inverters - aka drive trains]]
poly 1041 455 1336 455 1336 506 1041 506 1041 455 [[#Reusing Batteries]]
poly 147 344 428 344 428 391 147 391 147 344 [[#Onboard chargers and DC/DC converters]]
poly 844 624 1118 624 1118 673 844 673 844 624 [[#Onboard chargers and DC/DC converters]]
poly 935 539 1200 539 1200 586 935 586 935 539 [[#Rapid Charging]]
poly 134 435 394 435 394 483 134 483 134 435 [[#Auxiliary Parts]]
</imagemap>

While the project, as the name suggests, started out as an open source implementation of a traction motor inverter it now comprises many other topics as well:

*Reusing complete drive trains
* Reusing batteries including the management electronics (BMS)
*Reusing on board chargers to charge your vehicle from AC outlets
*Reusing DC/DC converters to run your 12V system from the high voltage traction battery
*Reusing A/C compressors and cabin heaters
*Fast charging your vehicle on public rapid charging infrastructure
*Tying all components together with a vehicle control unit (VCU)
* Building small scale PV systems including storage
More on these topics in the detailed sections below. Happy reading!

==Reusing motors and inverters - aka drive trains==
[[File:Tesla_LDU.jpg|thumb]]
The drive train is one of the defining building blocks of your conversion as it defines how well your vehicle picks up speed. Over the years we have reverse engineered many popular drive trains from [[:Category:OEM|production cars]] such as Teslas. As a bonus using such complete drive trains facilitates getting the vehicle [[Legalities|road legal]] in many countries. By now you have a choice of low to medium power drive trains that only cost a few 100€ up to high performance ones at many 1000€.

We have established two methods of running these [[:Category:OEM|OEM]] systems: reverse-engineering their communication protocol and making the drive train "think" it is still in its original vehicle OR swapping out the control electronics for our own open source motor controller. The latter method gives your more control and power but also a steeper learning curve.

Nearly all drive trains are targeted at 400V battery voltage. Run at a lower voltage they will produce proportionally less power.
Here is what we have done so far and how we've done it. Some is still work in progress (WIP)
{| class="wikitable"
|+
!Manufacturer
!Drive Train
!Control Method
! Approximate Power Output
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X Large Drive Unit ("LDU")|Large Drive Unit]]
|Board Swap
|335-475 kW
|-
|
|[[Tesla Model S/X Small Drive Unit ("SDU")|Small Drive Unit]]
|Board Swap
|180 kW
|-
|
|[[Tesla Model 3 Rear Drive Unit|Model 3/Y Rear Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|239 kW
|-
|
|[[Tesla Model 3 Front Drive Unit|Model 3/Y Front Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|121 kW
|-
|[[Nissan]]
|[[Nissan Leaf Motors|Gen1]]
|[[ZombieVerter VCU|CAN spoofing]]
|80 kW
|-
|
| [[Nissan Leaf Gen2 Board|Gen2]]
|[[ZombieVerter VCU|CAN spoofing]]/Board Swap
|80 kW / 130 kW (board swap)
|-
|
|[[Nissan Leaf Gen 3 (2018 up EM57)|Gen3]]
|[[ZombieVerter VCU|CAN spoofing]]/Board Swap [WIP]
|110 - 160 kW
|-
|[[:Category:Toyota|Toyota]]
|[[Lexus GS450h Drivetrain|Lexus GS 450h]]
|[[ZombieVerter VCU|Communication spoofing]]
|250 kW
|-
|
|[[Toyota/Lexus GS300h CVT|Lexus GS 300h]]
|[[ZombieVerter VCU|Communication spoofing]]
|105 kW
|-
|
|[[Toyota Prius Gen2 Inverter|Prius Gen2]]
|[[Toyota Prius Gen2 Inverter Controller|External Control Board]]
|40-70 kW
|-
|
|[[Toyota Prius Gen3 Board|Prius Gen3]]
|Board Swap/[[ZombieVerter VCU|Communication spoofing]]
|100 kW
|-
|
|[[Toyota/Lexus MGR Rear Transaxle Motor|MGR]]
|Prius Gen2 or Gen3 inverter
|18-50 kW (various models)
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander Rear Drive Unit|Rear Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing]]
|60-70 kW
|-
|
|[[Mitsubishi Outlander Front Transaxle|Front Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing]]
|60-70 kW
|-
|[[:Category:BMW|BMW]]
|[[BMW i3 Inverter|i3]]
|Board Swap
|125-135 kW
|-
|[[Chevrolet|Chevy/Opel]]
|[[Chevrolet Volt Inverter|Volt/Ampera]]
|Board Swap
|160 kW
|-
|[[:Category:Ford|Ford]]
|[[Ford Ranger TIM Controller|Ranger]]
|Board Swap
| Unknown
|-
| Renault
|[https://openinverter.org/forum/viewtopic.php?t=4749 Zoe]
|Board Swap [WIP]
|Unknown
|-
|MG
|[https://github.com/damienmaguire/MG-EV-Inverter ZS EV]
|Board Swap [WIP]
|Unknown
|}

==Reusing Batteries==
[[File:A09A7634.jpg|thumb]]
The most expensive and probably equally defining component is the [[Batteries|battery]] that stores all the energy for running your car. Batteries are usually assembled from a number of modules that in turn contain a number of cells. Usually batteries are reused on a module level. In rare cases the battery can be [https://youtu.be/_7l0Y1GsNJ4 reused as is in its original battery] box.

While there are also various [[16-cell BMS|open source implementations]] of [https://www.youtube.com/watch?v=_QsMoCrSTYc battery management systems] (BMS) we generally recommend using as much of the OEM BMS as possible. Sometimes the [[:Category:OEM|OEM]] BMS comes as an all-in-one solution that measures cell data and spits out state of charge and power limit information. In other cases the BMS is split into module units that measure the physical data (voltages, temperatures) and a central unit that calculates the high level information.

Sometimes we managed to reuse the complete system which is generally the safest as you can rely on the manufacturers well tested charge and discharge limits as well as reliable state of charge information (i.e. how much energy is left in the battery at any given time). In other cases we only managed to reuse the module units. This adds the convenience of having a well tested piece of hardware with the matching connector but required us to calculate all high level battery data ourselves. This also incudes [https://www.youtube.com/watch?v=RGYLPOlT45A cell balancing].
{| class="wikitable"
|+
!Manufacturer
!Model
!BMS usability
!Energy Content
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model 3 Battery|Model 3]]
|Module and high level [WIP]
|60-80 kWh ?
|-
|
|[[Batteries#OEM modules|Model S]]
|Unknown
|85-100 kWh
|-
|[[:Category:Nissan|Nissan]]
|[[Nissan Leaf BMS|Leaf/NV200]]
|High Level
|24-40 kWh
|-
|[[:Category:VAG|VW]]
|[[VW Hybrid Battery Packs|Passat/Golf]]
|Module Level
|8.7-36 kWh
|-
|
|[[MEB Batteries|MEB]]
|Module Level
|52-77 kwh
|}

== Onboard chargers and DC/DC converters ==
[[File:PXL_20241020_024043714.jpg|thumb|Onboard charger]]
The DC/DC converter takes energy from your HV traction battery and sends it to the cars 12V systems and 12V battery. It is basically a 1:1 replacement of the former alternator. An onboard charger (OBC) takes AC current from the grid and converts it into DC current to charge the battery. These two devices are often combined in one common enclosure hence why we treat them as one.
{| class="wikitable"
|+
!Manufacturer
!Model
!OBC
!DC/DC
!OBC power
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN2 Charger|Model S and X]] (Gen2)
|yes
|no
|11 kW
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN3 Charger|Model S and X]] (Gen3)
|yes
|no
|22 kW
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X DC/DC Converter|Model S and X]] (DC/DC)
|no
|yes
|
|-
| [[:Category:Tesla|Tesla]]
| [[Tesla Model 3 Charger/DCDC ("PCS")|Model 3]]
|yes
|yes
|11 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt Charger|Volt]]
|yes
|yes
|3.7 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt 2 Charger|Volt 2]]
|yes
|yes
|3.7 kW
|-
|[[Dilong/Cascadia Chargers|Dilong]]
|
|yes
|yes
|6.6 kW
|-
|[[Eltek chargers|Eltek]]
|
|yes
|no
|3 kW
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander DCDC OBC|Outlander / iMiev]]
|yes
|yes
|3.3 kW
|-
|[[:Category:MG|MG]]
|[[MG ZS Charger|ZS / MG4 / MG5]]
|yes
|yes
|6.6 - 11 kW
|}
There are more chargers under investigation, only the proven working ones are listed here. See our [[:Category:Charger|charger listing]] for more.

== Rapid Charging==
[[File:Ccs-socket.jpg|thumb|CCS2 rapid charging socket]]
The above mentioned onboard chargers always have limited power as they space requirements and cost rise with charger power. To overcome this limitation modern EVs offer external access to their HV battery via a so called [[:Category:Rapid Charging|rapid charging]] port. This allows to charge the battery with a much more powerful external charger. As a bonus it also allows [[Bidirectional Charging|taking energy from the HV battery]] and powering appliances with it.

There are 2 rapid charging protocols and 5 connector flavours world wide
{| class="wikitable"
|+
!Connector
!Communication
!Prevalent countries
!Open Source solutions
|-
|[[:Category:ChaDeMo|CHAdeMO]]
|CAN
|Japan, world wide
|[[Chademo with ESP32-Chademo|ESP32]], [[Chademo With Arduino Due|Arduino,]] [[Chademo with Zombieverter|ZombieVerter]]
|-
|CCS Combo1
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|CCS Combo2
|[[Foccci|PLC]]
|Europe
|[[Foccci]], [[pyPLC]], [[BMW I3 Fast Charging LIM Module|I3LIM]]
|-
|NACS
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|GB/T
|CAN
|China
|
|}

== Auxiliary Parts ==
We have now treated all the major building blocks of an EV, but there are many other components to complete the vehicle such as heaters, gear shifters and so on. We will summarize them here.

* [[:Category:HVJB|HV Junction Box]]
* [[:Category:HVAC|HVAC]] (Heating, Air conditioning)
* [[Vacuum Pumps]]
* [[:Category:Power Steering|Power Steering]]
* [[VCU Comparison|VCU]] (Vehicle Control Unit)
* [[Shift Controllers]]

== Additional Reading ==

* [[:Category:Legalities|Legalities]] - Getting a vehicle road legal in your country
* [[Glossary of Terms]]
* [[Common Inverter FAQ]] - questions common to all hardware variants
* [[Tesla Inverter FAQ]] - questions regarding Tesla Large Drive Units and Small Drive Units
* [[Electronics Basics]] - general advice for troubleshooting electronic circuits
* [[I want a cheap ev conversion|cheap EV conversions]] - this entry point for the penny pinchers
* [[I want a powerful ev conversion|performant EV conversions]] - where torque trumps money
* [[Mechanical design database]] - here you will find measurements, models, files, etc for a variety of components such as adapter plates and drive shaft flanges
* [[:Category:OpenInverter|Documentation of all OpenInverter Projects]]
* [[:Category:Tutorials|Tutorials]]

==Who we are==
There is not static team or openinverter company but here we list the most active community members with links to donation or information sites:

*Johannes Hübner, openinverter founder and developer - [https://www.patreon.com/openinverter support on patreon] follow on [https://www.youtube.com/user/EngineersFear youtube] and [https://github.com/jsphuebner/ github]
*Damien Maguire, developer and most active vehicle converter - [https://www.patreon.com/evbmw support on patreon] follow on [https://www.youtube.com/@Evbmw youtube] and [https://github.com/damienmaguire/ github]
*Uwe Hennig, master of CCS - [https://www.patreon.com/uhi22 support on patreon] follow on [https://github.com/uhi22/ github]
*celeron55, developer - support via [https://www.paypal.com/paypalme/celeron55 paypal] follow on [https://www.youtube.com/user/celeron55 youtube] and [https://github.com/celeron55 github]
*Dave Fiddes, active member and developer - Follow on [https://github.com/davefiddes/ github]
*Arber Kramar, long term member and developer - [https://leafdriveblog.wordpress.com/ Follow on blogspot]
*Janosch Oppermann, active member, developer and producer - follow on [https://www.youtube.com/@foxev-content youtube]

Main Page

2024-12-02T13:11:55Z

Johu:

Did you know you can convert your existing fossil powered vehicle to use electricity instead? And that you can even produce that electricity yourself?

Open Inverter is a community of people and projects focused on open source solutions for EV conversions. Founded in 2008 by Johannes Huebner as an open source inverter control firmware, the project has since expended to include the reuse of components from production EVs and hybrids, including inverters, motors, batteries, on-board chargers, and DC-DC converters, as well as the open source implementation of other necessary systems for EV conversions such as DC Fast Charging controllers.

<imagemap>
File:Electric-car.jpg|none|frame|Click on the captions to learn more about the respective system! Image source: https://www.newkidscar.com/

poly 248 166 542 166 542 217 248 217 248 166 [[#Reusing motors and inverters - aka drive trains]]
poly 1041 455 1336 455 1336 506 1041 506 1041 455 [[#Reusing Batteries]]
poly 147 344 428 344 428 391 147 391 147 344 [[#Onboard chargers and DC/DC converters]]
poly 844 624 1118 624 1118 673 844 673 844 624 [[#Onboard chargers and DC/DC converters]]
poly 935 539 1200 539 1200 586 935 586 935 539 [[#Rapid Charging]]
poly 134 435 394 435 394 483 134 483 134 435 [[#Auxiliary Parts]]
</imagemap>

While the project, as the name suggests, started out as an open source implementation of a traction motor inverter it now comprises many other topics as well:

*Reusing complete drive trains
* Reusing batteries including the management electronics (BMS)
*Reusing on board chargers to charge your vehicle from AC outlets
*Reusing DC/DC converters to run your 12V system from the high voltage traction battery
*Reusing A/C compressors and cabin heaters
*Fast charging your vehicle on public rapid charging infrastructure
*Tying all components together with a vehicle control unit (VCU)
* Building small scale PV systems including storage
More on these topics in the detailed sections below. Happy reading!

==Reusing motors and inverters - aka drive trains==
[[File:Tesla_LDU.jpg|thumb]]
The drive train is one of the defining building blocks of your conversion as it defines how well your vehicle picks up speed. Over the years we have reverse engineered many popular drive trains from [[:Category:OEM|production cars]] such as Teslas. As a bonus using such complete drive trains facilitates getting the vehicle [[Legalities|road legal]] in many countries. By now you have a choice of low to medium power drive trains that only cost a few 100€ up to high performance ones at many 1000€.

We have established two methods of running these [[:Category:OEM|OEM]] systems: reverse-engineering their communication protocol and making the drive train "think" it is still in its original vehicle OR swapping out the control electronics for our own open source motor controller. The latter method gives your more control and power but also a steeper learning curve.

Nearly all drive trains are targeted at 400V battery voltage. Run at a lower voltage they will produce proportionally less power.
Here is what we have done so far and how we've done it. Some is still work in progress (WIP)
{| class="wikitable"
|+
!Manufacturer
!Drive Train
!Control Method
! Approximate Power Output
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X Large Drive Unit ("LDU")|Large Drive Unit]]
|Board Swap
|335-475 kW
|-
|
|[[Tesla Model S/X Small Drive Unit ("SDU")|Small Drive Unit]]
|Board Swap
|180 kW
|-
|
|[[Tesla Model 3 Rear Drive Unit|Model 3/Y Rear Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|239 kW
|-
|
|[[Tesla Model 3 Front Drive Unit|Model 3/Y Front Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|121 kW
|-
|[[Nissan]]
|[[Nissan Leaf Motors|Gen1]]
|[[ZombieVerter VCU|CAN spoofing]]
|80 kW
|-
|
| [[Nissan Leaf Gen2 Board|Gen2]]
|[[ZombieVerter VCU|CAN spoofing]]/Board Swap
|80 kW / 130 kW (board swap)
|-
|
|[[Nissan Leaf Gen 3 (2018 up EM57)|Gen3]]
|[[ZombieVerter VCU|CAN spoofing]]/Board Swap [WIP]
|110 - 160 kW
|-
|[[:Category:Toyota|Toyota]]
|[[Lexus GS450h Drivetrain|Lexus GS 450h]]
|[[ZombieVerter VCU|Communication spoofing]]
|250 kW
|-
|
|[[Toyota/Lexus GS300h CVT|Lexus GS 300h]]
|[[ZombieVerter VCU|Communication spoofing]]
|105 kW
|-
|
|[[Toyota Prius Gen2 Inverter|Prius Gen2]]
|[[Toyota Prius Gen2 Inverter Controller|External Control Board]]
|40-70 kW
|-
|
|[[Toyota Prius Gen3 Board|Prius Gen3]]
|Board Swap/[[ZombieVerter VCU|Communication spoofing]]
|100 kW
|-
|
|[[Toyota/Lexus MGR Rear Transaxle Motor|MGR]]
|Prius Gen2 or Gen3 inverter
|18-50 kW (various models)
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander Rear Drive Unit|Rear Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing]]
|60-70 kW
|-
|
|[[Mitsubishi Outlander Front Transaxle|Front Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing]]
|60-70 kW
|-
|[[:Category:BMW|BMW]]
|[[BMW i3 Inverter|i3]]
|Board Swap
|125-135 kW
|-
|[[Chevrolet|Chevy/Opel]]
|[[Chevrolet Volt Inverter|Volt/Ampera]]
|Board Swap
|160 kW
|-
|[[:Category:Ford|Ford]]
|[[Ford Ranger TIM Controller|Ranger]]
|Board Swap
| Unknown
|-
| Renault
|[https://openinverter.org/forum/viewtopic.php?t=4749 Zoe]
|Board Swap [WIP]
|Unknown
|-
|MG
|[https://github.com/damienmaguire/MG-EV-Inverter ZS EV]
|Board Swap [WIP]
|Unknown
|}

==Reusing Batteries==
[[File:A09A7634.jpg|thumb]]
The most expensive and probably equally defining component is the [[Batteries|battery]] that stores all the energy for running your car. Batteries are usually assembled from a number of modules that in turn contain a number of cells. Usually batteries are reused on a module level. In rare cases the battery can be [https://youtu.be/_7l0Y1GsNJ4 reused as is in its original battery] box.

While there are also various [[16-cell BMS|open source implementations]] of [https://www.youtube.com/watch?v=_QsMoCrSTYc battery management systems] (BMS) we generally recommend using as much of the OEM BMS as possible. Sometimes the [[:Category:OEM|OEM]] BMS comes as an all-in-one solution that measures cell data and spits out state of charge and power limit information. In other cases the BMS is split into module units that measure the physical data (voltages, temperatures) and a central unit that calculates the high level information.

Sometimes we managed to reuse the complete system which is generally the safest as you can rely on the manufacturers well tested charge and discharge limits as well as reliable state of charge information (i.e. how much energy is left in the battery at any given time). In other cases we only managed to reuse the module units. This adds the convenience of having a well tested piece of hardware with the matching connector but required us to calculate all high level battery data ourselves. This also incudes [https://www.youtube.com/watch?v=RGYLPOlT45A cell balancing].
{| class="wikitable"
|+
!Manufacturer
!Model
!BMS usability
!Energy Content
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model 3 Battery|Model 3]]
|Module and high level [WIP]
|60-80 kWh ?
|-
|
|[[Batteries#OEM modules|Model S]]
|Unknown
|85-100 kWh
|-
|[[:Category:Nissan|Nissan]]
|[[Nissan Leaf BMS|Leaf/NV200]]
|High Level
|24-40 kWh
|-
|[[:Category:VAG|VW]]
|[[VW Hybrid Battery Packs|Passat/Golf]]
|Module Level
|8.7-36 kWh
|-
|
|[[MEB Batteries|MEB]]
|Module Level
|52-77 kwh
|}

== Onboard chargers and DC/DC converters ==
[[File:PXL_20241020_024043714.jpg|thumb|Onboard charger]]
The DC/DC converter takes energy from your HV traction battery and sends it to the cars 12V systems and 12V battery. It is basically a 1:1 replacement of the former alternator. An onboard charger (OBC) takes AC current from the grid and converts it into DC current to charge the battery. These two devices are often combined in one common enclosure hence why we treat them as one.
{| class="wikitable"
|+
!Manufacturer
!Model
!OBC
!DC/DC
!OBC power
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN2 Charger|Model S and X]] (Gen2)
|yes
|no
|11 kW
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN3 Charger|Model S and X]] (Gen3)
|yes
|no
|22 kW
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X DC/DC Converter|Model S and X]] (DC/DC)
|no
|yes
|
|-
| [[:Category:Tesla|Tesla]]
| [[Tesla Model 3 Charger/DCDC ("PCS")|Model 3]]
|yes
|yes
|11 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt Charger|Volt]]
|yes
|yes
|3.7 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt 2 Charger|Volt 2]]
|yes
|yes
|3.7 kW
|-
|[[Dilong/Cascadia Chargers|Dilong]]
|
|yes
|yes
|6.6 kW
|-
|[[Eltek chargers|Eltek]]
|
|yes
|no
|3 kW
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander DCDC OBC|Outlander / iMiev]]
|yes
|yes
|3.3 kW
|-
|[[:Category:MG|MG]]
|[[MG ZS Charger|ZS / MG4 / MG5]]
|yes
|yes
|6.6 - 11 kW
|}
There are more chargers under investigation, only the proven working ones are listed here. See our [[:Category:Charger|charger listing]] for more.

== Rapid Charging==
[[File:Ccs-socket.jpg|thumb|CCS2 rapid charging socket]]
The above mentioned onboard chargers always have limited power as they space requirements and cost rise with charger power. To overcome this limitation modern EVs offer external access to their HV battery via a so called [[:Category:Rapid Charging|rapid charging]] port. This allows to charge the battery with a much more powerful external charger. As a bonus it also allows [[Bidirectional Charging|taking energy from the HV battery]] and powering appliances with it.

There are 2 rapid charging protocols and 5 connector flavours world wide
{| class="wikitable"
|+
!Connector
!Communication
!Prevalent countries
!Open Source solutions
|-
|[[:Category:ChaDeMo|CHAdeMO]]
|CAN
|Japan, world wide
|[[Chademo with ESP32-Chademo|ESP32]], [[Chademo With Arduino Due|Arduino,]] [[Chademo with Zombieverter|ZombieVerter]]
|-
|CCS Combo1
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|CCS Combo2
|[[Foccci|PLC]]
|Europe
|[[Foccci]], [[pyPLC]], [[BMW I3 Fast Charging LIM Module|I3LIM]]
|-
|NACS
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|GB/T
|CAN
|China
|
|}

== Auxiliary Parts ==
We have now treated all the major building blocks of an EV, but there are many other components to complete the vehicle such as heaters, gear shifters and so on. We will summarize them here.

* [[:Category:HVJB|HV Junction Box]]
* [[:Category:HVAC|HVAC]] (Heating, Air conditioning)
* [[Vacuum Pumps]]
* [[:Category:Power Steering|Power Steering]]
* [[VCU Comparison|VCU]] (Vehicle Control Unit)
* [[Shift Controllers]]

== Additional Reading ==

* [[:Category:Legalities|Legalities]] - Getting a vehicle road legal in your country
* [[Glossary of Terms]]
* [[Common Inverter FAQ]] - questions common to all hardware variants
* [[Tesla Inverter FAQ]] - questions regarding Tesla Large Drive Units and Small Drive Units
* [[Electronics Basics]] - general advice for troubleshooting electronic circuits
* [[I want a cheap ev conversion|cheap EV conversions]] - this entry point for the penny pinchers
* [[I want a powerful ev conversion|performant EV conversions]] - where torque trumps money
* [[Mechanical design database]] - here you will find measurements, models, files, etc for a variety of components such as adapter plates and drive shaft flanges
* [[:Category:OpenInverter|Documentation of all OpenInverter Projects]]
* [[:Category:Tutorials|Tutorials]]

==Who we are==
There is not static team or openinverter company but here we list the most active community members with links to donation or information sites:

*Johannes Hübner, openinverter founder and developer - [https://www.patreon.com/openinverter support on patreon] follow on [https://www.youtube.com/user/EngineersFear youtube] and [https://github.com/jsphuebner/ github]
*Damien Maguire, developer and most active vehicle converter - [https://www.patreon.com/evbmw support on patreon] follow on [https://www.youtube.com/@Evbmw youtube] and [https://github.com/damienmaguire/ github]
*Uwe Hennig, master of CCS - [https://www.patreon.com/uhi22 support on patreon] follow on [https://github.com/uhi22/ github]
*celeron55, developer - support via [https://www.paypal.com/paypalme/celeron55 paypal] follow on [https://www.youtube.com/user/celeron55 youtube] and [https://github.com/celeron55 github]
*Dave Fiddes, active member and developer - Follow on [https://github.com/davefiddes/ github]
*Arber Kramar, long term member and developer - [https://leafdriveblog.wordpress.com/ Follow on blogspot]
*Janosch Oppermann, active member, developer and producer - follow on [https://www.youtube.com/@foxev-content youtube]

Main Page

2024-12-02T13:08:09Z

Johu: Johu moved page Main Page New to Main Page without leaving a redirect

Did you know you can convert your existing fossil powered vehicle to use electricity instead? And that you can even produce that electricity yourself?

Open Inverter is a community of people and projects focused on open source solutions for EV conversions. Founded in 2008 by Johannes Huebner as an open source inverter control firmware, the project has since expended to include the reuse of components from production EVs and hybrids, including inverters, motors, batteries, on-board chargers, and DC-DC converters, as well as the open source implementation of other necessary systems for EV conversions such as DC Fast Charging controllers.

<imagemap>
File:Electric-car.jpg|none|frame|Click on the captions to learn more about the respective system! Image source: https://www.newkidscar.com/

poly 248 166 542 166 542 217 248 217 248 166 [[#Reusing motors and inverters - aka drive trains]]
poly 1041 455 1336 455 1336 506 1041 506 1041 455 [[#Reusing Batteries]]
poly 147 344 428 344 428 391 147 391 147 344 [[#Onboard chargers and DC/DC converters]]
poly 844 624 1118 624 1118 673 844 673 844 624 [[#Onboard chargers and DC/DC converters]]
poly 935 539 1200 539 1200 586 935 586 935 539 [[#Rapid Charging]]
poly 134 435 394 435 394 483 134 483 134 435 [[#Auxiliary Parts]]
</imagemap>

While the project, as the name suggests, started out as an open source implementation of a traction motor inverter it now comprises many other topics as well:

*Reusing complete drive trains
* Reusing batteries including the management electronics (BMS)
*Reusing on board chargers to charge your vehicle from AC outlets
*Reusing DC/DC converters to run your 12V system from the high voltage traction battery
*Reusing A/C compressors and cabin heaters
*Fast charging your vehicle on public rapid charging infrastructure
*Tying all components together with a vehicle control unit (VCU)
* Building small scale PV systems including storage
More on these topics in the detailed sections below. Happy reading!

==Reusing motors and inverters - aka drive trains==
[[File:Tesla_LDU.jpg|thumb]]
The drive train is one of the defining building blocks of your conversion as it defines how well your vehicle picks up speed. Over the years we have reverse engineered many popular drive trains from [[:Category:OEM|production cars]] such as Teslas. As a bonus using such complete drive trains facilitates getting the vehicle [[Legalities|road legal]] in many countries. By now you have a choice of low to medium power drive trains that only cost a few 100€ up to high performance ones at many 1000€.

We have established two methods of running these [[:Category:OEM|OEM]] systems: reverse-engineering their communication protocol and making the drive train "think" it is still in its original vehicle OR swapping out the control electronics for our own open source motor controller. The latter method gives your more control and power but also a steeper learning curve.

Nearly all drive trains are targeted at 400V battery voltage. Run at a lower voltage they will produce proportionally less power.
Here is what we have done so far and how we've done it. Some is still work in progress (WIP)
{| class="wikitable"
|+
!Manufacturer
!Drive Train
!Control Method
! Approximate Power Output
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X Large Drive Unit ("LDU")|Large Drive Unit]]
|Board Swap
|335-475 kW
|-
|
|[[Tesla Model S/X Small Drive Unit ("SDU")|Small Drive Unit]]
|Board Swap
|180 kW
|-
|
|[[Tesla Model 3 Rear Drive Unit|Model 3/Y Rear Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|239 kW
|-
|
|[[Tesla Model 3 Front Drive Unit|Model 3/Y Front Drive Unit]]
|Board Swap/Board reprogramming [WIP]
|121 kW
|-
|[[Nissan]]
|[[Nissan Leaf Motors|Gen1]]
|[[ZombieVerter VCU|CAN spoofing]]
|80 kW
|-
|
| [[Nissan Leaf Gen2 Board|Gen2]]
|[[ZombieVerter VCU|CAN spoofing]]/Board Swap
|80 kW / 130 kW (board swap)
|-
|
|[[Nissan Leaf Gen 3 (2018 up EM57)|Gen3]]
|[[ZombieVerter VCU|CAN spoofing]]/Board Swap [WIP]
|110 - 160 kW
|-
|[[:Category:Toyota|Toyota]]
|[[Lexus GS450h Drivetrain|Lexus GS 450h]]
|[[ZombieVerter VCU|Communication spoofing]]
|250 kW
|-
|
|[[Toyota/Lexus GS300h CVT|Lexus GS 300h]]
|[[ZombieVerter VCU|Communication spoofing]]
|105 kW
|-
|
|[[Toyota Prius Gen2 Inverter|Prius Gen2]]
|[[Toyota Prius Gen2 Inverter Controller|External Control Board]]
|40-70 kW
|-
|
|[[Toyota Prius Gen3 Board|Prius Gen3]]
|Board Swap/[[ZombieVerter VCU|Communication spoofing]]
|100 kW
|-
|
|[[Toyota/Lexus MGR Rear Transaxle Motor|MGR]]
|Prius Gen2 or Gen3 inverter
|18-50 kW (various models)
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander Rear Drive Unit|Rear Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing]]
|60-70 kW
|-
|
|[[Mitsubishi Outlander Front Transaxle|Front Drive Unit]]
|[[ZombieVerter VCU|Communication spoofing]]
|60-70 kW
|-
|[[:Category:BMW|BMW]]
|[[BMW i3 Inverter|i3]]
|Board Swap
|125-135 kW
|-
|[[Chevrolet|Chevy/Opel]]
|[[Chevrolet Volt Inverter|Volt/Ampera]]
|Board Swap
|160 kW
|-
|[[:Category:Ford|Ford]]
|[[Ford Ranger TIM Controller|Ranger]]
|Board Swap
| Unknown
|-
| Renault
|[https://openinverter.org/forum/viewtopic.php?t=4749 Zoe]
|Board Swap [WIP]
|Unknown
|-
|MG
|[https://github.com/damienmaguire/MG-EV-Inverter ZS EV]
|Board Swap [WIP]
|Unknown
|}

==Reusing Batteries==
[[File:A09A7634.jpg|thumb]]
The most expensive and probably equally defining component is the [[Batteries|battery]] that stores all the energy for running your car. Batteries are usually assembled from a number of modules that in turn contain a number of cells. Usually batteries are reused on a module level. In rare cases the battery can be [https://youtu.be/_7l0Y1GsNJ4 reused as is in its original battery] box.

While there are also various [[16-cell BMS|open source implementations]] of [https://www.youtube.com/watch?v=_QsMoCrSTYc battery management systems] (BMS) we generally recommend using as much of the OEM BMS as possible. Sometimes the [[:Category:OEM|OEM]] BMS comes as an all-in-one solution that measures cell data and spits out state of charge and power limit information. In other cases the BMS is split into module units that measure the physical data (voltages, temperatures) and a central unit that calculates the high level information.

Sometimes we managed to reuse the complete system which is generally the safest as you can rely on the manufacturers well tested charge and discharge limits as well as reliable state of charge information (i.e. how much energy is left in the battery at any given time). In other cases we only managed to reuse the module units. This adds the convenience of having a well tested piece of hardware with the matching connector but required us to calculate all high level battery data ourselves. This also incudes [https://www.youtube.com/watch?v=RGYLPOlT45A cell balancing].
{| class="wikitable"
|+
!Manufacturer
!Model
!BMS usability
!Energy Content
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model 3 Battery|Model 3]]
|Module and high level [WIP]
|60-80 kWh ?
|-
|
|[[Batteries#OEM modules|Model S]]
|Unknown
|85-100 kWh
|-
|[[:Category:Nissan|Nissan]]
|[[Nissan Leaf BMS|Leaf/NV200]]
|High Level
|24-40 kWh
|-
|[[:Category:VAG|VW]]
|[[VW Hybrid Battery Packs|Passat/Golf]]
|Module Level
|8.7-36 kWh
|-
|
|[[MEB Batteries|MEB]]
|Module Level
|52-77 kwh
|}

== Onboard chargers and DC/DC converters ==
[[File:PXL_20241020_024043714.jpg|thumb|Onboard charger]]
The DC/DC converter takes energy from your HV traction battery and sends it to the cars 12V systems and 12V battery. It is basically a 1:1 replacement of the former alternator. An onboard charger (OBC) takes AC current from the grid and converts it into DC current to charge the battery. These two devices are often combined in one common enclosure hence why we treat them as one.
{| class="wikitable"
|+
!Manufacturer
!Model
!OBC
!DC/DC
!OBC power
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN2 Charger|Model S and X]] (Gen2)
|yes
|no
|11 kW
|-
|[[:Category:Tesla|Tesla]]
| [[Tesla Model S/X GEN3 Charger|Model S and X]] (Gen3)
|yes
|no
|22 kW
|-
|[[:Category:Tesla|Tesla]]
|[[Tesla Model S/X DC/DC Converter|Model S and X]] (DC/DC)
|no
|yes
|
|-
| [[:Category:Tesla|Tesla]]
| [[Tesla Model 3 Charger/DCDC ("PCS")|Model 3]]
|yes
|yes
|11 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt Charger|Volt]]
|yes
|yes
|3.7 kW
|-
|[[:Category:Chevrolet|Chevrolet]]
|[[Chevrolet Volt 2 Charger|Volt 2]]
|yes
|yes
|3.7 kW
|-
|[[Dilong/Cascadia Chargers|Dilong]]
|
|yes
|yes
|6.6 kW
|-
|[[Eltek chargers|Eltek]]
|
|yes
|no
|3 kW
|-
|[[:Category:Mitsubishi|Mitsubishi]]
|[[Mitsubishi Outlander DCDC OBC|Outlander / iMiev]]
|yes
|yes
|3.3 kW
|-
|MG
|[[MG ZS Charger|ZS / MG4 / MG5]]
|yes
|yes
|6.6 - 11 kW
|}
There are more chargers under investigation, only the proven working ones are listed here. See our [[:Category:Charger|charger listing]] for more.

== Rapid Charging==
[[File:Ccs-socket.jpg|thumb|CCS2 rapid charging socket]]
The above mentioned onboard chargers always have limited power as they space requirements and cost rise with charger power. To overcome this limitation modern EVs offer external access to their HV battery via a so called [[:Category:Rapid Charging|rapid charging]] port. This allows to charge the battery with a much more powerful external charger. As a bonus it also allows [[Bidirectional Charging|taking energy from the HV battery]] and powering appliances with it.

There are 2 rapid charging protocols and 5 connector flavours world wide
{| class="wikitable"
|+
!Connector
!Communication
!Prevalent countries
!Open Source solutions
|-
|[[:Category:ChaDeMo|CHAdeMO]]
|CAN
|Japan, world wide
|[[Chademo with ESP32-Chademo|ESP32]], [[Chademo With Arduino Due|Arduino,]] [[Chademo with Zombieverter|ZombieVerter]]
|-
|CCS Combo1
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|CCS Combo2
|[[Foccci|PLC]]
|Europe
|[[Foccci]], [[pyPLC]], [[BMW I3 Fast Charging LIM Module|I3LIM]]
|-
|NACS
|[[Foccci|PLC]]
|US
|[[Foccci]], [[pyPLC]]
|-
|GB/T
|CAN
|China
|
|}

== Auxiliary Parts ==
We have now treated all the major building blocks of an EV, but there are many other components to complete the vehicle such as heaters, gear shifters and so on. We will summarize them here.

* [[:Category:HVJB|HV Junction Box]]
* [[:Category:HVAC|HVAC]] (Heating, Air conditioning)
* [[Vacuum Pumps]]
* [[:Category:Power Steering|Power Steering]]
* [[VCU Comparison|VCU]] (Vehicle Control Unit)
* [[Shift Controllers]]

== Additional Reading ==

* [[:Category:Legalities|Legalities]] - Getting a vehicle road legal in your country
* [[Glossary of Terms]]
* [[Common Inverter FAQ]] - questions common to all hardware variants
* [[Tesla Inverter FAQ]] - questions regarding Tesla Large Drive Units and Small Drive Units
* [[Electronics Basics]] - general advice for troubleshooting electronic circuits
* [[I want a cheap ev conversion|cheap EV conversions]] - this entry point for the penny pinchers
* [[I want a powerful ev conversion|performant EV conversions]] - where torque trumps money
* [[Mechanical design database]] - here you will find measurements, models, files, etc for a variety of components such as adapter plates and drive shaft flanges
* [[:Category:OpenInverter|Documentation of all OpenInverter Projects]]
* [[:Category:Tutorials|Tutorials]]

==Who we are==
There is not static team or openinverter company but here we list the most active community members with links to donation or information sites:

*Johannes Hübner, openinverter founder and developer - [https://www.patreon.com/openinverter support on patreon] follow on [https://www.youtube.com/user/EngineersFear youtube] and [https://github.com/jsphuebner/ github]
*Damien Maguire, developer and most active vehicle converter - [https://www.patreon.com/evbmw support on patreon] follow on [https://www.youtube.com/@Evbmw youtube] and [https://github.com/damienmaguire/ github]
*Uwe Hennig, master of CCS - [https://www.patreon.com/uhi22 support on patreon] follow on [https://github.com/uhi22/ github]
*celeron55, developer - support via [https://www.paypal.com/paypalme/celeron55 paypal] follow on [https://www.youtube.com/user/celeron55 youtube] and [https://github.com/celeron55 github]
*Arber Kramar, long term member and developer - [https://leafdriveblog.wordpress.com/ Follow on blogspot]
*Janosch Oppermann, active member, developer and producer - follow on [https://www.youtube.com/@foxev-content youtube]

Main Page Old

2024-12-02T13:07:58Z

Johu: Johu moved page Main Page to Main Page Old without leaving a redirect: superseded, this is a backup

The openinverter project mainly aims to reuse existing components from production electric vehicles. We also aim to give some general guidelines on how to convert a vehicle to electric drive.

= Before you begin: =
'''Please take the time to read.'''

You undertake '''your''' project at '''your own risk.''' Make sure you're aware of the risks of working with high voltage and [[HighVoltageSafety]]

'''Developers's time is best spent developing;''' '''Support is best found in the forums''' - Developers of various projects are often bombarded with private messages and emails. Managing these emails and questions is a extremely large undertaking. Please read, and take the time to understand the information available here and across the web if you don't understand a topic. Developers are not your personal support team, unless you want to pay them directly for their time.

Read more about [[Application Support]].

'''Consider donating to the many developers''' that have made all this possible and to help keep making things possible:

[https://www.patreon.com/openinverter www.patreon.com/openinverter],

https://www.evbmw.com/,

https://www.paypal.com/paypalme/celeron55

[https://openinverter.org/forum/index.php '''Always check the forums'''], new developments and solutions are coming along every day, questions being answered, or perhaps you can answer. we work better as a community sharing our knowledge...

'''...update this wiki.''' Answers and solutions should find their way here so they don't remain buried in a 30 page long support thread. To edit the wiki, login with your forum credentials.

'''Welcome to the open inverter community'''

= Legalities=
*[[Legalities|Legalities around conversion projects]]
Different countries have different legislation, if you want your car to certified for the road in your country please take the time to review this section. It might save you going down the wrong direction and creating something that can never be driven, or incur costs.
= Introduction =
The open inverter started as a scratch built inverter and control board led by Johannes Hübner who designed and built his open open source AC motor controller dubbed the "open inverter".

Since then, the community has established and documented hardware and software approaches to reuse OEM inverters with the Open control board, and has more recently started on controlling OEM inverters over CAN, a process which doesn't require replacing any internal parts.

The main goal of the open inverter community is to reverse engineer many of these components for use in a variety of projects such as:

* EV conversion
* Energy storage
* Power generation
* Charging infrastructure
* etc.

Open inverter projects now span over many different areas surrounding PEV, HEV, and PHEV components, such as:
* Motor Controllers
* 1-3 phase power converters
* DC/DC converters
* buck/boost converters
* Battery Management Systems (BMS)
* Vehicle integration
* etc.

As a result, there is a growing collection of open source software and hardware designed for the never ending list of OEM parts.

There's a variety of methods of repurposing these OEM components. Methods here are generally chosen with future proofing in mind , reducing chances of firmware or software updates from the manufacture "bricking" or blocking the open source control efforts.

such efforts include:

* Mainboard/brain replacement
*[[Getting started with CAN bus|CANBUS/LINBUS]]
*[[wikipedia:Synchronous_serial_communication|Sync serial]]
*[[wikipedia:FlexRay|FlexRay]]
*[[wikipedia:Pulse-width_modulation|PWM]]
* Sirmware/software reprogramming
* etc.

Resulting in many bespoke boards running the main open inverter software or other open/semi-open source code designed to ether replace OEM motherboards or VCUs.

This has lead to a large collection of different boards and software, many with redundant features. To unify many of these development projects, the community at large is focused on making a set of standard VCUs and replacement control boards which handle the ever growing list of OEM components.

=== Many of the VCU and replacement boards consist of these 3 main parts: ===
{| class="wikitable"
|+
!Hardware
!Firmware
!Web Interface
|-
|The design and development of the [[Main Board Version 3|control hardware]] based around an STM32F103 chip. This provides the control signals to the power stage and on to the attached components.
|The development of the code that goes on the STM32F103 chips and determines, amongst other things what signals are sent to the power stage and the attached components.
|Using an ESP8266 chip, the development of a simple [[Web Interface|web based interface]] to adjust the parameters on the firmware chip and to display values returned from the chip, for example motor speed (RPM).
|}

= Getting Started =

'''Please note:''' Performing a 'full' EV conversion can often be more straight forward than trying to make small modifications to OEM vehicles - an OEM system will normally require a set of components all talking to each other and keeping each other happy! Trying to, for example, add a different battery charger, or bypassing certain restrictions will often require significant reverse engineering of the existing system to ensure that the new component(s) do not cause errors or problems in the system which can avalanche into significant problems! A full EV conversion, in comparison, can usually focus on just keeping one component happy at a time (although integrating these different components can still require a lot of work).

The Community is focused on the electrical systems required for an EV, and may not be best placed to assist with mechanical issues specific to your vehicle.

===Glossary of Terms===
It is recommended you read the '''[[Glossary of Terms]]''' before you begin. Often you'll find TLAs (three letter acronyms) peppered through the support forum and on this wiki, take the time to familiarise yourself with them before hand, remember this exists, or bookmark/favourite it so you can referent back to it.

===EV conversions:===
A few main parts are needed for an EV conversion, such as:
*[[Motors]]
*[[:Category:Inverter|Inverter]]
**('''Note:''' [[ZombieVerter VCU|ZombieVerter]] projects require a matched pair of Inverter and Motor as they would have come out of a vehicle)
*[[Batteries]]
*[[:Category:Charger|Chargers / Charge Controllers]]
*[[:Category:DC/DC|DC/DC Converters]]
*[[:Category:HVJB|HV Junction Box]]
*[[Heaters]]
*[[:Category:HVAC|HVAC]]
*Brake Assist
**[[Vacuum Pumps]]
**Electronic Brake Boosters
*[[:Category:Power Steering|Power Steering]]
*[[Rapid Charging]]
*[[VCU Comparison]]
*[[Shift Controlers]]

Existing information on these items can be found on the [[EV Conversion Parts]] page.

A collection of various connector part numbers can be found here: [[Connector Part Numbers]]

===OEM Parts: ===
A variety of [[:Category:OEM|OEM]] parts members of the community have reversed engineered for custom use cases:
*[[:Category:BMW|BMW]]
*[[:Category:Chevrolet|Chevrolet]]
*[[:Category:Ford|Ford]]
*[[:Category:Hyundai|Hyundai]]
*[[Isabellenhütte Heusler]]
*[[:Category:Land Rover|Land Rover/Jaguar]]
*[[:Category:Mercedes-Benz|Mercedes-Benz]]
*[[:Category:MG|MG]]
*[[:Category:Mitsubishi|Mitsubishi]]
*[[Nissan]]
*[[:Category:Opel|Opel/Vauxhall]]
*[[:Category:Peugeot|Peugeot]]
*[[Renault]]
*[[:Category:Tesla|Tesla]]
*[[Toyota|Toyota/Lexus]]
*[[:Category:VAG|VAG (VW, Audi, Skoda, Seat, Porsche, ...)]]
*[[:Category:Volvo|Volvo]] 

===Required skills/Knowledge===
[[Category:Request_for_Review]]
To perform a successful EV conversion, you may require the following skills and/or knowledge (this is not an exhaustive list)

* You will need to have the skills, knowledge and tools required to perform significant mechanical work on your vehicle. A service or workshop manual will be useful.
*Basic DC electrical knowledge, such as using a multimeter, soldering, identifying components.
*A willingness and ability to troubleshoot problems (mechanical, electrical, code...).
* Safety in relation to high voltage DC systems. '''HV DC can be more dangerous than AC mains voltages!'''
*Basic understanding on the purposes of various EV components (motor, inverter, DC-DC...)
*A grasp of 3 phase motor control concepts can be useful (especially if using an openinverter control board)
*An understanding of CAN (and other digital communication systems) will be very useful
*The legal restrictions and requirements for your country/state

===FAQ===

*[[Common Inverter FAQ]] - questions common to all hardware variants
*[[Tesla Inverter FAQ]] - questions regarding Tesla Large Drive Units and Small Drive Units
*[[Electronics Basics]] - general advice for troubleshooting electronic circuits
*[[I want a cheap ev conversion|cheap EV conversions]] - this entry point for the penny pinchers
*[[I want a powerful ev conversion|performant EV conversions]] - where torque trumps money

= Mechanical Design Database =
[[Mechanical design database|'''Mechanical design database''']]

here you will find measurements, models, files, etc for a variety of components such as:

* adapter plates
* motor couplers
*drive shaft flanges
*battery mounts
*etc.

= Cooling System Components =

=== Water Pumps ===
[[Water Pumps|https://openinverter.org/wiki/Water_Pumps]]

=== Coolant Fittings ===
[[Coolant Fittings|https://openinverter.org/wiki/Coolant_Fittings]]

=== Coolant Valves ===
[[Coolant Valves|https://openinverter.org/wiki/Coolant_Valves]]

=Open Inverter Projects=

===Open Inverter (Core Project/s)===
{| class="wikitable"
!
!Description / Notes
|-
|'''ZombieVerter VCU'''
*[[ZombieVerter VCU]]
*[[Web Interface (ZombieVerter VCU)|Web Interface]]
*[[OEM component compatibility]]
|Designed around a matched pair of Inverter and Motor taken from the original OEM vehicle the ZombieVerter is there to make those two components believe they are still in the original vehicle and are fed necessary commands to act as if they still are and interpret and responses back from the equipment for feedback (regen / rpm / etc)
|-
|'''Open Inverter Hardware'''
*[[Hardware Theory of Operation]]
*[[Schematics and Instructions]] - for the "vanilla" inverter kit.
*[[Mini Mainboard]]
*[[Foccci]] (CCS interface)
*[[Main Board Version 3]]
*[[Main Board Version 2]]
*[[Main Board Version 1]]
*[[Sense Boards]]
*[[Gate Driver]]
*[[Sensor Board|Legacy Sensor Board]]
*[[OEM Repurposing]]
| Quite flexible in its application. The Open Inverter can be used to build a custom inverter itself where you supply the high power and high voltage components to create your own inverter, or to be used as the basis to take over control of OEM inverters so that they can drive nearly any attached motor to that inverter.
|-
| rowspan="3" |'''Open Inverter Software'''
*[[Using FOC Software]]
*[[Downloads]]
*[[Features]]
*[[Web Interface]]
*[[Battery Charging]]
*[[Errors]]
*[[CAN communication]]
*[[Parameters]] (Tune your inverter)
*[[Configuration Files]]
*[[Software Theory of Operation]]
*[[Open Inverter Testing]]
|Two of the more important software aspects to master are below.
|-
|'''CAN communication'''

Common across boards is the ability to communicate with a CAN Bus, which is a 'control area network' or a technical way of saying how various components, sensors, controls, etc communicate with one another within the car. '''Read more about [[CAN communication|CAN Communication]]'''

There is also a project to standardise the messages across the various control boards, [[Introduction CAN STD|read more]]
|-
|'''Parameters'''

The openinverter firmware uses a set of about 70 parameters to adapt it to different inverter power stages, motors and position feedback systems. Also it lets you calibrate the throttle pedal, change regenerative braking settings and so on.

Parameter definitions can be found here: [[Parameters]]

Working parameter sets can be found in the [https://openinverter.org/parameters openinverter parameter database]
|}

=== Open Inverter Related Projects (Control Boards/VCUs)===
{| class="wikitable"
|+
! Project
!Description / Notes
|-
|'''[[Tesla|Tesla Small Drive and Large Drive Units:]]'''
|Commonly there is a large drive unit and small drive unit available from the Model S. 
These combine the inverter and motor into a single package.

The control boards for these replace the existing control board within them.
|-
|'''[[Lexus GS450h Drivetrain]]:'''
| The GS450h contains a gearbox (where the motors are located).
Using the [[ZombieVerter VCU]], the inverter and the gearbox itself provide

a powerful set up suitable for rear wheel drive set ups, replacing the existing longitudinally mounted gearbox.
|-
|'''[[Toyota Prius Gen3 Board|Prius Generation 3 Inverter:]]'''
|A cheap available inverter from the popular Prius hybrid, this
board goes inside that inverter and allows you to control the features of it.
|-
|'''[[Auris/Yaris Inverter:]]'''
|Similar to the Prius board, there's subtle differences between them
and therefore the need for a separate board.
|-
|'''[[Nissan Leaf Gen2 Board]]'''
|Replaces the nissan OEM logic board with a rev 3 openiverter main board
|-
|[[Ford ranger ev board|'''Ford ranger ev board''']]
|openinverter kit for the ford ranger ev
|-
| colspan="2" |[[OEM Repurposing|'''All Control Boards / OEM Inverters''']]
|}

===Use inverter as a battery Charger===
Both the open inverter and some OEM inverters can be used as a battery charger, further saving on component costs. You can read more about how the open inverter and the theory of charging [[Battery Charging|here]].

===Open Inverter Renewables Projects===
Recently added to the forums are projects and discussions around turning the Open Inverter project towards capturing, storing and using renewable energy.

=Open Inverter CAN std.=
*[[Introduction CAN STD|Introduction]]
*[[CAN table CAN STD|CAN table]]
*[[Getting started with CAN bus]]
*[[CAN communication|Setting up Open Inverter CAN Communication]]

=Conversion Projects=
*[[VW Polo 86C Conversion]]
*[[Touran Conversion]]
*[[Audi A2 Conversion]]
*[https://openinverter.org/forum/viewtopic.php?f=11&t=326&hilit=gt86 toyota gt86 nissan leaf motor]
*[https://openinverter.org/forum/viewtopic.php?f=11&t=210 Porsche Boxster 986 Tesla conversion]
*[[VW Beetle 2003 Budget Conversion]]
*[https://openinverter.org/forum/viewforum.php?f=11 Further Projects on the forum]