CCS32Clara: Difference between revisions

From openinverter.org wiki
Jump to navigation Jump to search
m (moved refs to bottom)
(Moved all content from here to Foccci page)
Tags: Replaced Visual edit
Line 1: Line 1:
Disclaimer: This Page is still work in progress!  Any information written here is a draft only and should be handled as such.  Contributions are more than welcome.  If you have questions, please ask them in the discussion section of the page or in the OpenInverter Forum.
The information on this page has been transferred to [[Fully Open CCS Charge Controller (FOCCCI)]]
 
This page is about the reference software for the [[Fully Open CCS Charge Controller (FOCCCI)|Fully OpenSource CCS Charge Controller (Foccci)]].  CCS32Clara (also referred to as "Clara") is currently under development by the OpenInverter Community.
 
Here you will find documentation (or reference) on how to setup Clara, News on the development, diagrams, open ToDos, etc.
 
[https://github.com/uhi22/ccs32clara Clara on GitHub.]
 
[https://openinverter.org/forum/viewtopic.php?t=3727 Clara in the OpenInverterForum.]
 
[https://openinverter.org/shop/index.php?route=product/product&product_id=79 Foccci for sale on OpenInverter Shop]
 
== Integrating Clara with your car/BMS ==
Depending on your use case Clara has to communicate with one or more components in your car. All in-car communication happens via a single CAN bus.
 
=== Basic communication considerations ===
Clara 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 Clara can communicate, or more precisely, listen to the BMS. Clara 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. ''Clara 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 Clara 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).
 
== Configuring Clara via CAN ==
Clara 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 Claras 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 Clara 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 Clara 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/Clara) 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 Clara 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. "1" is correct for the latest hardware (Foccci 4.2 and above) Technically, ppvariant=1 is the correct setting for Foccci with the PP circuit with 330 ohm pull-up to 5V and a 3k pull-down and a 47k by 47k divider.
|-
|WakeupPinFunc
|
|0
|4
|0
|Configure what the wakeup pin does. TODO: describe below
|-
| 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 will loose communication to the ESP web interface!'''
|-
| colspan="6" |'''Charge Parameters'''
|-
|MaxPower
|kW
|0
|1000
|100
|Absolute maximum charge power. Clara 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. Clara 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. Clara will announce this value in the ChargeParameterDiscoveryRequest, in the element EVMaximumCurrentLimit. The charger may or may not respect this limitation.
|-
|TargetVoltage
|V
|0
|1000
|0
|Charge target voltage (volatile)
|-
|ChargeCurrent
|A
|0
|500
|0
|Instantaneous current setpoint (volatile)
|-
|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)
|-
|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
|-
|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
|
|
|-
|checkpoint
|
|
|-
|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 Clara 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 Clara 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 Clara. 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 Clara 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 Clara'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
 
'''<u>Attention:</u>''' with this mapping the error flags are ignored, e.g. voltage or current mismatch.
 
 
== Making Clara talk to boostech BMS ==
[[File:Can mapping boostech.png|thumb|Can mapping boostech]]
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 370V.
 
''As of now this mapping is preliminary and has to be confirmed. will then remove this note''
<references />
[[Category:ChaDeMo‏‎]]  
[[Category:ChaDeMo‏‎]]  
[[Category:CCS]]  
[[Category:CCS]]  
[[Category:Rapid Charging]]
[[Category:Rapid Charging]]
__FORCETOC__
__FORCETOC__

Revision as of 08:13, 25 June 2024

The information on this page has been transferred to Fully Open CCS Charge Controller (FOCCCI)

Retrieved from "https://openinverter.org/wiki/index.php?title=CCS32Clara&oldid=4668"