QCA7000 Foccci+Clara User thread

[uhi22]

The actuator test only works if the charge cable is not plugged in. Detection is done based on the PP resistance and the highlevel communication state.
https://github.com/uhi22/ccs32clara/blo ... e.cpp#L618

[Zieg]

Ah, that would do it, thank you. For some reason it's reporting a PP resistance of ~1860 ohm with nothing plugged in. I checked with my multimeter right at the connector and I'm reading the correct 2.7k. 5V supply is reading 5V. I checked current from PP to ground and got 15mA so I think that means the 330R is good.

Just as a test, I changed the pullup resistor setting to Foccci4.2_5V_330up_3000down and then it was reading 10k and all of the tests worked. Actual hardware version is 5.1 and I had it on the Foccci4.5_5V_330up_no_down option prior to this test.

So, how might I go about fixing the issue of the low reading? I recall seeing discussion of this before but not sure if it's actually the same issue,or if there was a solution.

Edit: For what it's worth, spot value reading is ~130 ohm with cable connected (j1772 type 1). I think that's also slightly low, should be around 140 with the parallel resistance of the port's 2k7 resistor and the plug's 150R resistor?

[uhi22]

Seems we need to check the resistence calculation. Your physical measurements make sense, the rest is software work. The best setting at the moment is the 330up 3000down, if you have the 2k7 connected.

[Zieg]

Okay sounds good, thanks. I've also checked all my grounds and cables as well as verified input impedance, all looks good. Happy to check/test anything else if needed!


Edit: Aha, could it be the resistors in my voltage divider? R28 is reading 33k and R57 is 36k. The numbers printed on them are correct for 47k, so maybe measuring them in-circuit is throwing things off. But, redoing the math seems to almost perfectly match the values I am seeing. Might compile a new bin to see what it does.

[uhi22]

I checked with my multimeter right at the connector and I'm reading the correct 2.7k.

Is this 2.7k integrated in the charge port, and measurable while Foccci is completely disconnected from the charge port? Or is it coming due to R60 (the integrated 3k3 pulldown in Foccci, which can be enabled with a solder jumper)?

[Zieg]

It's integrated in the charge port. I also verified it by unplugging Foccci and probing the connector directly.

[uhi22]

So we will add a configuration option 330up 2700down for PPvariant.

[Zieg]

Okay, that makes sense. I suppose that should apply to most type 1 ports. Does that explain the low reading of the 2k7 when set to 330 up no down? I'm still a but suspicious of these voltage divider resistors.

[uhi22]

Yes, if Foccci is configured to have 330up no down, and it sees the 2k7, then this 2k7 is treated as "external" and that's why shown as resistance (but not very accurate).
I just added new PP variants to consider the following cases:
- Foccci 5 with no pull down at all
- Foccci 5 with 2k7 pull down (in the inlet)
- Foccci 5 with 3k3 pull down (on the PCB if the solder jumper to R60 is closed)
Tested okay so far, but with some tolerances, due to:
- the voltage drop over D20 depends on the current. This is not modeled in the software.
- The regulators for 5V and 3.3V have tolerances, which are not compensated by the software.
- Finally also the involved resistors have tolerances.
The overall accuracy of the measured PP resistance is better than 10%, this should be fine.

Review appreciated: https://github.com/uhi22/ccs32clara/blo ... C.cpp#L105

[Zieg]

Sounds good, thankyou. Should be able to test later today.

[Zieg]

Okay, looks good! I was getting about 160Ω with the cable plugged in, 500Ω with the handle's button pressed, and 10k with the cable unplugged. This is great because now it doesn't think there's always a plug inserted. Thank you! Now just a bit more work on the CAN side and I'll be ready to try a CCS session!

[muehlpower]

I have saved an early board from uhi22, version 2023-08-17. The web interface shows a firmware 0.21B. I think this is not the current version What is the latest version, does it run on this board, where do I get it from, and how do I get it onto the board?

[johu]

The latest binary is here: https://github.com/uhi22/ccs32clara/actions (you need to log in). You need an esp32 web interface to flash the firmware and yes all versions run on all boards

[muehlpower]

Is there a reliable way to transfer parameters to the foccci board without a “web” interface? Maybe with ST-Link?

[Zieg]

Not sure about the st-link. According to the wiki, this command line tool should work : viewtopic.php?t=2907

[muehlpower]

Not sure about the st-link. According to the wiki, this command line tool should work : viewtopic.php?t=2907

I read that too, but I seem to be too stupid to install it. I have python, at least I think so. when I enter 'python' in the comandline I get a version number. After typing 'pip install openinverter_can_tool' it seems to install something. And now?

[muehlpower]

Can someone explain to me how the locking mechanism works? I can set both treshholds to the same value, then the motor opens or closes the set time. If I set different values, the motor opens or closes until the feedback. If the plug is not fully inserted, I have the choice between “I don't notice that it's not locked” and “the motor smokes because it doesn't switch off”.

[Zieg]

Are you on the latest version? There's a setting for the max time it will power the motor, though in an old version apparently it was being ignored.

You can also remove the feedback threshold values and take a time based approach, simply relying on the motor to cycle and then time out. That's what I've been doing for now, no issues. Also remember to set the duty cycle to something reasonable for the motor's rated voltage.

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.

[uhi22]

If the plug is not fully inserted, I have the choice between “I don't notice that it's not locked” and “the motor smokes because it doesn't switch off”.

Good point. Need to check what happens in case of not fully inserted plug. The goal would be: do not allow charging, set an error to make the problem transparent in a spot value, and blink red to show the user that something went wrong. Would this make sense?

[muehlpower]

In my opinion, the most important thing would be not to deactivate the “LockRunTime”, then I wouldn't need a new locking motor. On the car side, an incomplete locking process could be recognized by “closing” instead of “closed”. The OBC and the enable signal can then be controlled accordingly.

[Zieg]

So, I guess if lockruntime has passed but the lock threshold has not been reached, throw an error?

Side question - does it matter if the value for locked is higher (or lower) than the value for unlocked? Does Foccci care?

[muehlpower]

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.

does it matter if the value for locked is higher (or lower) than the value for unlocked?

I have also not yet found out what there are two parameters for. I destroyed my actuator during the tests. Since my feedback is a contact on GND when locked, I expect adc values less than 100 for locked and greater than 3800 for unlocked. I think phoenix uses three states: locked, unlocked and in between. In addition, Phoenix high and low are reversed.

[Zieg]

Oh I think it makes sense that there are two values so it knows when it's crossed one threshold or the other, I'm just not sure if it expects the 'locked' value to always be higher than unlocked, for example. My port is also from Phoenix but it's one of the universal ones.

[muehlpower]

Now I still don't know what to set if I have 100 and 3800, for example. One to 3600, the other 400? Which one to what? or both to approx. 2000? Or even set one to 0 and the other to 4095? And will the actual position then be shown in the spot values, regardless of how the lock got there, e.g. manually?

[tom91]

https://openinverter.org/wiki/Foccci#Parameters

You read this right?

You set LockClosedThresh to the value of the feedback value for when the lock is the locked position.

If you can move the lock by hand, move it and use the spot value to determine the value. AdcLockFeedback

LockOpenThresh is for the threshold which its open.

The latest software determines based on Open vs Closed if the thresholds are above or below the value.

What version are you on for firmware?

If you start with baseline parameters I would be surprised if you destroy your lock motor. Check your LockDuty and LockRunTime