First-Time Config of FOCCI And CCS1 vehicle charging

[uhi22]

I have a couple of questions on the Clara parameters:

1) UdcDivider: Is this only used if InletVtgSrc is set to 1? If it is being used, it should be mapped as a 'Receive' message?

2) What is the purpose of InletVoltage? If I supply it via CAN, I must measure across the charge inlet DC pins and not assume it's the same as my battery voltage?

3) what value should I use for ppvariant? I have FOCCCI 4.2.

1a) Yes. 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.
(1b) 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.

2) 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, the inlet voltage is physically identically to 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). For detailed analysis of the cable losses, it could make sense to measure the inlet voltage physically, so you have during charging three voltages: on the charger, on the inlet and on the battery. Normally they are all nearly the same, but a detailled look could help to investigate cable loss issues. So only for very curious users.

3) ppvariant = 1 is fine for Foccci 4.2 (technically, for Foccci with 330 ohm pull-up to 5V and a 3k pull-down and a 47k by 47k divider)

Edit: Extended the parameter description in the wiki, to be more clear. Reviews and improvements are always welcome. https://openinverter.org/wiki/CCS32Clara

[MoonUnit]

When using the ESP32 Web interface tool for configuring Clara / FOCCCI with regards to the charge port actuator there is a very handy 'test' mode for testing if the contactors work, and opening/closing the charge port lock etc. The documentation says that if the LockClosedThresh and LockOpenThresh are set to the same value, the lock is operated for a speficied time (LockRunTime), rather than using a feedback mechanism.

When I was testing this using the web interface, I can verify that sending 'Open' or 'Close' will operate the lock, but the supplied voltage is not turned off after LockRunTime.

Question: does the test mode only test if the lock opens or closes, or should it also test that the motor operates for LockRunTime?

Thanks in advance.

[uhi22]

Question: does the test mode only test if the lock opens or closes, or should it also test that the motor operates for LockRunTime?

The implemented behavior is not really consistent. The answer is yes and no. As long as the ActuatorTest is OpenLock or CloseLock, the lock motor is controlled. The timer which is configured with LockRunTime elapses, but the actuation does not end, because the ActuatorTest still demands the same direction. So by letting the ActuatorTest be set, in worst case the lock motor could overheat. Not good, created an issue for this: https://github.com/uhi22/ccs32clara/issues/20.
When changing the ActuatorTest to None, the time will be considered and after the time elapses, the actuation stops. When leaving the actuator test by setting it to None, there is one single unlocking which should respect the configured time.

[Edit] Fixed with https://github.com/uhi22/ccs32clara/com ... 9da49db305. Now the lock motor is actuated once for t=LockRunTime, each time the ActuatorTest is set to OpenLock or CloseLock.

[MoonUnit]

I am hoping to do a 'light bulb test' this weekend using the Foccci v4.2.

I have verified the contactors and the actuator lock work using the web interface.

Before I try the test, can I check that I must set the following parameters in flash before starting:

DemoControl = Standalone
DemoVoltage = 230
TargetVoltage = 230

Do I need to set anything else, like ChargeCurrent, MaxVoltage etc.?

I assume Foccci/Clara will start with Enable=1, as there is no CAN control from me in this demo?

Can I expect to see spot values in the Web Interface, ie is Foccci/Clara reporting values via CANbus in the demo?

Does/should the Button stop the charging in the Standalone mode?

Many thanks in advance.

[uhi22]

Sounds good. Nothing else is needed. Enable is 1 per Default. The web interface will show the spot values, the Stop button will work.

[MoonUnit]

I seem to have a problem setting TargetVoltage using the webinterface. I set it to 230 and the click 'save parameters to flash'. The value shows as set correctly but if I power cycle the FOCCCI board, the TargetVoltage is reset to zero. Same for BatteryVoltage. However, I can set MaxCurrent successfully this way and the value is remembered after the power cycle.

Is this intended? I want to try the light bulb test so I am not sending any values to FOCCCI via CANbus. Do I need to manually set the TargetVoltage to 230 using my laptop in situ, and then connect the charger without power cycling the FOCCCI?

Thanks in advance.

[uhi22]

The TargetVoltage and BatteryVoltage are intended to be received from CAN, if CAN is used.
In your case, just for the light bulb demo without CAN signals, you select DemoControl=STANDALONE and set DemoVoltage=230V (or anything else between 150V and 250V). Safing the parameters to flash will permanently store the DemoControl and DemoVoltage. Clara will take this DemoVoltage and write it into TargetVoltage during run time. Same for the BatteryVoltage, also this will be taken from DemoVoltage.

In other words: After setting DemoControl=STANDALONE and a valid DemoVoltage and saving the parameters, you can power cycle as often as you want, and connect and disconnect to the chargers as you want. There is no need to set TargetVoltage or BatteryVoltage via the web interface. The configured DemoVoltage will be copied into the TargetVoltage and into the BatteryVoltage, as soon as Clara needs these values. BatteryVoltage latest during the PreCharge, TargetVoltage latest during the CurrentDemand.

[MoonUnit]

clara20240707153805.log

(82.37 KiB) Downloaded 103 times

Light bulb test failed. The charger gave an error message saying 'vehicle battery under voltage detected, service code 17'. It was a BP Pulse 50 charger. I have a log file, attached, which seems to show that Clara is sending CurrentDemand and has passed through precharge, but the charger is not happy, clearly.

The inlet source is set to ChargerOutput in the web interface. Maybe this charger type insists on measuring the battery voltage itself? I don't know enough about how they work.

Any help gratefully received!

[uhi22]

No, the charger is not interested in the battery voltage. I would rate the log as success. Because the current demand loop is reached. Now the charger would regulate the voltage and current according to the requests. But not all chargers are able to regulate the corner case "no load connected". Eg the alpitronics regulate quite well, but Ionity tritium overshoot the voltage and shut down. The tested charger most likely has similar regulation problems. They should disappear when connecting a real battery. Maybe you can find another charger type which provides a constant voltage in the lightbulb configuration. You could also plot the EVSEPresentVoltage, to get an impression how the regulation works.

[MoonUnit]

Apologies but I thought I had sent this yesterday ... I tried another charger, a Kempower one, and that worked perfectly!

Log file attached in case it's of interest.

clara20240707165207.log

(206.22 KiB) Downloaded 145 times

[tom91]

On boards that I ship now I flash CHAdeMO CAN mapping. If you have an earlier one you have to add this yourself. https://openinverter.org/wiki/CCS32Clar ... e_CAN_side

Right now the CAN mapping must be updated once by refreshing the page. So after you enter nodeid 22 refresh once. Then you see the existing mapping, if any

Is there an overview of this "standard" mapping you flash?

I am looking at the Zombie implementation and wondering if I should include a small function to flash a Focci to a set CAN setup so it works with the Zombie expected messages. It would be great if we could create an agreed CAN map.