QCA7000 Foccci+Clara User thread

[uhi22]

I see room for improvements:
- It is not clear, how to adjust the two threshold values. It does NOT help to adjust them to exactly the measured values in both states, because then we just get random behavior. We need to define whether they shall be set below or above the measured values. Or set them to the measured values, and add a tolerance band in software.
- It is not even clear, why two values are necessary. If we have a feedback consisting of two resistors and a switch, we can only have two possible values: one for "on" and one for "off". So one single threshold parameter would be sufficient to divide the range into the two possible states.
- It is not clear, what type of feedbacks we want to support. The code looks like "poti" feedback, it checks for delta U over time. There may be such kind of locks in the fields, but there are also single-switch (with 0, 1 or 2 resistors) and double-switch (with 1 or 2 or 3 resistors) which are able to distinguish between "unlocked", "locked", "more than locked, no plug detected". I propose to start with some typical lock types, and make them working in all use cases.
- I was not able to find the timeout handling for the motor actuation, for the case that the position feedback is bad. We should stop actuation the motor, in both directions, after a (short) time, to avoid overheating. Maybe even make a retry after one or two seconds, so that the user hears that the lock is trying but not succeeding. I can fully imagine that a small 12V motor, driven by permanent 12V while mechanically blocked, with let out the smoke after 10 to 30 seconds. Sorry @muehlpower, that we managed this in your case.
I'm planning to make a test setup on desk, to test the different scenarios. Which resistance values do you have in your actuator, in case of locked and unlocked, @muehlpower?

[tom91]

- It is not clear, how to adjust the two threshold values. It does NOT help to adjust them to exactly the measured values in both states, because then we just get random behavior. We need to define whether they shall be set below or above the measured values. Or set them to the measured values, and add a tolerance band in software.

Agree, best have auto offset added based on the other threshold. should be easy to work into the code. so like 200bit offsets as standard.

- It is not even clear, why two values are necessary. If we have a feedback consisting of two resistors and a switch, we can only have two possible values: one for "on" and one for "off". So one single threshold parameter would be sufficient to divide the range into the two possible states.

Some have Hall sensors/ analogue feedback, not often but it does exist.

I'm planning to make a test setup on desk, to test the different scenarios. Which resistance values do you have in your actuator, in case of locked and unlocked, @muehlpower?

Let me dig in my notes and get you some more info on what I have found over my time looking at actuators.

"most" common is 1K+10K (open or closed), 1K (so 10K bypassed) (open or closed) then an overtravel where we end up at 11K again.
Or the Simple switch kind.

[tom91]

TE have discrete switch positions.

This spec explains all the vairants they offer including HALL based ones

https://www.te.com.cn/commerce/Document ... F2323264-1

[uhi22]

The currently implemented range detection is:
- We have two cases: (A) "closed" is higher resistance and (B) "open" is higher resistance.
- For (A):
if AdcLockFeedback is low (between 0 and <LockOpenThresh), we detect OPEN.
if AdcLockFeedback is middle (between LockOpenThresh and LockClosedThresh), we keep the last detected state. (or detect "in progess"???)
if AdcLockFeedback is high (above LockClosedThresh), we detect CLOSED.
Example parametrization: AdcLockFeedback is 100 while open, and 1000 while closed. The parameters shall be LockOpenThresh=300 and LockClosedThresh = 800.

- For (B):
if AdcLockFeedback is low (between 0 and <LockCloseThresh), we detect CLOSED.
if AdcLockFeedback is middle (between LockClosedThresh and LockOpenThresh), we keep the last detected state. (or detect "in progess"???)
if AdcLockFeedback is high (above LockOpenThresh), we detect OPEN.
Example parametrization: AdcLockFeedback is 500 while closed, and 3000 while open. The parameters shall be LockClosedThresh=700 and LockOpenThresh = 2700.

[muehlpower]

Which resistance values do you have in your actuator, in case of locked and unlocked, @muehlpower?

My port is from Duosida. The locking mechanism is a screwed-on part with an electromagnet and a switch. Four cables are routed out, two for the magnet and two for the switch. The switch is closed when the plug is locked. I have connected one wire from the switch to GND, the other to foccci. As a result, I expect a value of 4000 when open and close to zero when closed. This is what the manufacturer says “Working cycle:On: 5%ED activation ＜300-500 ms,continue 3 seconds max”. Not much time for experiments. It can also be unlocked mechanically, which of course also activates the switch, which means that the mechanical unlocking does not go unnoticed.

[muehlpower]

Now I have the next problem. I have now set LockRunTime to 700 and the treshhold both to zero. I plug in an AC EVSE. My VCU sends AcObcState = lock. Foccci recognizes everything correctly, PortState is ready, Lock remains open, but my VCU waits for Closed!

[tom91]

what is the version of your firmware on the Foccci?

Param enable needs to be set to do any kind of charging, even going out of the ready state.

[uhi22]

A UdcOffset parameter in addition to the UdcDivider would also be good, as the BMW measuring system, for example, does not output 0V at 0V HV.

Just added the parameter UdcOffset (in digits) and a spot value AdcInletVoltage for easy calibration. Have set the default values to fit (nearly) to your board, so only small adjustments should be necessary.

Github issue: https://github.com/uhi22/ccs32clara/issues/23
Git commit: https://github.com/uhi22/ccs32clara/com ... d26e4ce966
Binary and hex: https://github.com/uhi22/ccs32clara/act ... 4802357088
Wiki: https://openinverter.org/wiki/Foccci#Parameters

Ready for testing.

[uhi22]

Regarding the lock motor control and feedback variants, created a separate issue for the detailled discussions.
https://github.com/uhi22/ccs32clara/issues/51

[muehlpower]

what is the version of your firmware on the Foccci?

0.44.95.B

It appears that enable must be sent and a 10% -90% PWM must be applied to the CP for the lock to change to closed. How does this work with a wallbox that is not sending PWM? I think this is the case when a wallbox is controlled by the photovoltaic system and there is no sunshine. The car is connected to the wallbox, should be locked and start charging at sunrise. Why can't I lock without PWM, e.g. after plugging in?

[tom91]

Correct, if PWM is out of bounds it is decided that it is not a "plausible" charging session. This is a difficult edge case to manage, specially from ensure not draining the 12V system of a vehicle.

[muehlpower]

I have just tried it on my OEM car. It locks even with a naked cable only with a resistance from PP to PE.

[tom91]

So?

Are you proposing to always lock a plug when it is detected?

[muehlpower]

Why not? Locking only needs power when locking, after that it doesn't matter. If I don't want it, I don't need to send AcObcState= Lock

[tom91]

It is possible, we can rework the locking logic fully then.

Have it pulled apart from the "valid charging session" requirement.

[muehlpower]

This is how I imagine charging with the OBC: The cable is plugged in. Foccci and my charging controller wake up. Foccci reports cable plugged in, my controller sends lock and waits for a valid PWM. When PMW starts further controllers for cooling etc. and the high voltage is switched on with Pre Charge procedure. My charge controller changes AcObcState to Charging. The EVSE switches on the current and my charge controller checks on which phases 230V are present, cable and EVSE limit, and generates the CAN message for the OBC and switches the enable lines. Now we are charging. The EVSE limit continues to be monitored and the CAN message for the OBC is adjusted if necessary. If the PWM stops, the charging current is reduced to zero and everything except foccci and charge controller is switched off. When the PWM returns, it starts all over again. When the charging process is finished, everything is switched off and the PWM is ignored. It remains locked until my charge controller sends unlock.

[Zieg]

You'd have to have it stay awake to continually monitor the dead plug for PWM starting, wouldn't you?

Also I haven't tried it with a dead plug but with AcObcState not mapped it just locks and asks the EVSE for power on its own. OBC starts charging, and if I want to end the session early I press the button, it unlocks and turns off the EVSE.

[muehlpower]

At the end of the charging process, my charge controller and Foccci are also switched off. My current requirement is 600mA in the waiting phase. This is low enough for 3 days on my 12V battery. I will set up a timout that stops everything if no charging has started for 24 hours. I will set the timer for each charging event so that it stays ready for another 24 hours.

[uhi22]

How to kill the lock motor? Just tested, and found:
Preconditions: LockClosedThresh=2000, LockOpenThresh=1900. LockRunTime 1500ms. Feedback line open, so it is at high level, I get AdcLockFeedback=4036.
Action: Power-on.
Observed: Lock motor is controlled into direction "unlock" for ever.
Expected: Lock motor is not actuated at all, or the actuation stops after 1.5s.

Same problem into the other direction:
Precondition: as above, but pull the feedback line to ground.
Action: Actuator test "LOCK"
Observed: Lock motor is actuated into direction "lock" for ever.

[uhi22]

Oh, and when you're testing it I suggest doing so with an actual plug rather than through the web interface. For some reason it doesn't always want to respond to open/close commands there. So you could find yourself confused why it's not working, only to realize it's actually working just fine once you plug in.

There was a feature implemented, which inhibits the actuator test as soon as a plug is inserted or a DC charging session is ongoing. This was a kind of protection feature, to avoid dangerous things while power is flowing. However, now I implemented an exception, that the actuator test for lock and unlock works always. I think this is needed, because it makes sense to test the locking with a real plug.
Also cleaned-up the actuator test. In the old versions, when setting actuatortest to "lock", it executed the locking, but immediately unlocked by application. So inspecting the mechanic in locked state was not possible. Now with the new software, the actuator test is able to go into a stable "locked" and "unlocked", and when leaving the actuator test, the application takes over again.

To avoid killing the lock motor in case of wrong feedback, I propose to use time-based locking (by setting LockClosedThresh and LockOpenThresh to 0), until all remaining improvements are implemented.

Commit: https://github.com/uhi22/ccs32clara/com ... 7077211da2
Binaries: https://github.com/uhi22/ccs32clara/act ... 4823846865

[Zieg]

Oooh, that makes sense. Thank you!

[muehlpower]

How to kill the lock motor?

This is consistent with my observations. The immediate jump back to “open” also irritated me.

A few more ideas on inlet voltage and contactor: If a separate measuring device is selected for inlet voltage, this should not replace the voltage transmitted by the DC EVSE, but should only be compared with it and trigger an error and stop charging if there is a deviation of e.g. 20V. This makes it redundant.
If the ActuatorTest is extended to include separate control of the two DC contactors, an external controller (mine) could perform a weld test when unplugged.

Translated with DeepL.com (free version)

[uhi22]

Good ideas.

- For the separate control of the DC contactors via ActuatorTest, created issue https://github.com/uhi22/ccs32clara/issues/53 and implemented the feature. Binaries available in the continuous integration build #99 on https://github.com/uhi22/ccs32clara/actions

- For the inlet voltage plausibilization, created issue https://github.com/uhi22/ccs32clara/issues/52

[uhi22]

For the inlet voltage plausibilization, implemented a draft. It works like this:
- The voltage measured by the hardware board is always reported in spot value InletVoltageHw.
- The voltage reported by the charging station is available in spot value EvsePresentVoltage.
- If the hardware measurement is selected by parameter InletVtgSrc = AnalogInput, we calculate the absolute difference between InletVoltageHw and EvsePresentVoltage, and store the result in spot value InletVoltageDeviation.
- If the InletVoltageDeviation is bigger than the parameter InletVoltageTolerance (default 20V), we set an error flag.
- If we see during the charging loop this error flag, we stop the charging with stopreason STOP_REASON_INLET_VOLTAGE_DEVIATION.

Potential issues:
- nearly untested at the moment.
- detection could be too fast, maybe we should add a debouncing, so that a short voltage deviation does not abort the charging session.

Commit: https://github.com/uhi22/ccs32clara/com ... c802d61d65
Binaries: CI#100 at https://github.com/uhi22/ccs32clara/actions

[muehlpower]

I have now made tests with the version 0.44.100.B. The offset parameter works well. The UdcDevider is too coarse. After setting the offset to 561, I applied 318V, resulting in AdcInletVoltage of 1425. With UdcDevider = 3 I get 288V and 432V with UdcDevider = 2. My suggestion is dig/100V. "InletVoltageHW= (AdcInletVoltage-UdcOffset)*100/UdcDevider"
With UdcDevider = 272, the result would be 317V.