QCA7000 Foccci+Clara User thread

[tom91]

You can set it up to do the ZEVCCS mode it has all required info. If you look at the list of broadcast information it is all you need.

[Zieg]

Awesome. I appreciate the clarification. I figured the values were all there but couldn't tell if the format would be readable. Off to eBay in search of a port!

[P.S.Mangelsdorf]

Ok, I think I posted this before but now don't see it, so I'll try again. I need some help with a wiring question.

I'm wiring up my FOCCCI board to my charge port (Chevy Bolt) and have a few questions regarding matching the Chevy pin descriptions to the FOCCCI descriptions.

Here is the pinout of the port:

There are pins labeled "motor open control" and "motor closed control". Which should go to LOCK_MOT1 and which to LOCK_MOT2 ?

Will FOCCCI be ok with only a single temp sensor? And I presume the "Low reference" should go to ground, does that sound right?

The position sensor has a 5V reference. I presume I could use the FOCCCI 5V supply, since I'm getting voltage over CAN. Is that correct?

The port seems to have two position sensor wires. I'm thinking I just wire up one to FOCCCI?

[tom91]

There are pins labeled "motor open control" and "motor closed control". Which should go to LOCK_MOT1 and which to LOCK_MOT2

Pick one and if it works the wrong way swap them.

The position sensor has a 5V reference. I presume I could use the FOCCCI 5V supply, since I'm getting voltage over CAN. Is that correct?

The port seems to have two position sensor wires. I'm thinking I just wire up one to FOCCCI?

?!? The position sensor for foccci is pull to ground. wiki states this. So your lock position feedback must be resistive based.

Will FOCCCI be ok with only a single temp sensor? And I presume the "Low reference" should go to ground, does that sound right?

You know what sort of temp sensor is in the port? is it a PT1000?

[uhi22]

To avoid increasing time pressure before the race, you can omit the temp sensors, lock motor and lock feedback completely. Foccci will be happy. If you have more time, you can find out the characteristic of the temp sensor, and the polarity of the lock motor. Lowest prio is the lock feedback, because timebased actuation should be fine.

[P.S.Mangelsdorf]

To avoid increasing time pressure before the race, you can omit the temp sensors, lock motor and lock feedback completely. Foccci will be happy. If you have more time, you can find out the characteristic of the temp sensor, and the polarity of the lock motor. Lowest prio is the lock feedback, because timebased actuation should be fine.

Thank you! Great to know, I was stressed about needing to tune this stuff and knowing it will work without is a relief. Obviously, I want it all working but knowing if something isn't it's not a dealbreaker is huge.

Pick one and if it works the wrong way swap them.

Ok cool. I also just saw the option in settings to do the swap there.

?!? The position sensor for foccci is pull to ground. wiki states this. So your lock position feedback must be resistive based.

Missed that in the wiki. I'll play around with what I have. If the latch sensor is similar to the port door, it's an open circuit in one position and provides a resistance in the other, so I may just be able to give "5V reference" ground, and then the latch would pull to ground. Will experiment if I have a chance, but from uhi's post, I may just run w/o it for now.

You know what sort of temp sensor is in the port? is it a PT1000?

I do not know; I went with this port as it has the AC connector I need that is unobtainium otherwise.

[tom91]

I do not know; I went with this port as it has the AC connector I need that is unobtainium otherwise.

If the port has DCFC it will have dedicated PT1000sor something for a thermistor per pin. Do you have a part number or some pictures?

I would always use a lock, never want it being pulled out under power by some unaware bystander or yourself when your tired.

[uhi22]

In theory when pulling out under load the CP will disconnect first and the charger should turn down the current within some 10 milliseconds, before the DC contacts disconnect. In real life I guess nobody knows

[P.S.Mangelsdorf]

If the port has DCFC it will have dedicated PT1000sor something for a thermistor per pin. Do you have a part number or some pictures?

Unfortunately I didn't take close up photos of the port or its components before installing in the car, and it's hard to get to now.

never want it being pulled out under power by ... yourself when your tired.

Fair point.

[P.S.Mangelsdorf]

I'm moving over to using the CHAdeMO CAN mapping and my existing CHAdeMO board to get data to FOCCCI. One question:

The wiki says SOC is purely informational. Will FOCCCI still work correctly if it is not receiving a SOC message?

[uhi22]

Yes, then the charger just shows 0%, no problem.

[celeron55]

Is it possible to set up foccci to set a single bit on CAN as 1 if a connector is plugged in, and to 0 if not? Regardless of which type of connector, and regardless of what is going on.

The bit would disable the inverter in my car, as per regulations and common sense.

I'm not sure what parameter to use for this and how to scale it.

[tom91]

Is it possible to set up foccci to set a single bit on CAN as 1 if a connector is plugged in, and to 0 if not? Regardless of which type of connector, and regardless of what is going on.

The bit would disable the inverter in my car, as per regulations and common sense.

I'm not sure what parameter to use for this and how to scale it.

I have started on this with the parameter "PORTSTAT", currently not rolled out to the CCS charging. It is a WIP, will need some assistance in where to add it in the CCS logic.

At the moment there is also is a bit that forces it to plugged in "1" for plugged in with

Code: Select all

 bool ppValid = Param::GetInt(Param::ResistanceProxPilot) < 2000;
 if(ppValid == 0)
        {
            Param::SetInt(Param::PortState,0x0);
        }
        else //No valid CP but valid PP it means a "dead" plug inserted
        {
            Param::SetInt(Param::PortState,0x1);
        }

Code: Select all

#define PORTSTAT     "0=Idle, 1=PluggedIn, 2=Ready, 3=ChargingAC, 4=ChargingDC, 5=Stopping, 6=Unlock, 7=PortError"

This way you would have a 4 bit number that shows the state, where driving only is allowed if the number is 0.

If you want a "PPvalid" parameter you can Map to CAN we can easily add it in.

[tom91]

Also now on github:
https://github.com/uhi22/ccs32clara/pull/37

The parameter AllowUnlock can be mapped to CAN, this when set to 1 (the default on Foccci flashing) normal functions.

Set this to 0:
1. AC charging stopping over CAN or EVSE side no longer allows unlocking of plug.
2. Stop button is inhibited

This has been added into beta branches of Zombie coding, including auto mapping of CAN for Foccci via Zombie web interface, too by me and I believe already running on Jamies BMW E90. Here the Zombie takes the lock state from the car over CAN and maps it to the relevant location on the CAN for Foccci.

[uhi22]

Is it possible to set up foccci to set a single bit on CAN as 1 if a connector is plugged in, and to 0 if not? Regardless of which type of connector, and regardless of what is going on.

The bit would disable the inverter in my car, as per regulations and common sense.

I'm not sure what parameter to use for this and how to scale it.

Good point, here it comes: https://github.com/uhi22/ccs32clara/com ... 7bebec15b1
[Edit] And the binaries for flashing: https://github.com/uhi22/ccs32clara/act ... 0908675301

[Bigpie]

It is running on my E91, it's working great for AC charging. Not got to DC yet, not wired up yet.

The zombie auto config worked a treat too.

Unlock inhibit when the car is locked is great for when I'm charging in public.

Not too keen on the rapid flashing green to mean charging, maybe a bit slower would give less 'error vibes'

[celeron55]

I don't know how to put this to not sound quite wild, but... I'm pretty sure the Kempower charger I mostly test my car at doesn't connect PP, either at all or at least not during the actual charging session.

Due to this, the current PlugPresent value is useless as it stays at 0.

I just tested with a resistor connected between PP and PE that my foccci is reading the value. Well, it's reading the 150 ohm resistor as something around 500 ohms (ResistanceProxPilot), but that's fine enough for me.

The problem is, at the charger, while charging, PlugPresent stays at 0 and that's because ResistanceProxPilot is 10k which is the highest it will go.

Soo... I would prefer not to dvelve any deeper into this and propose setting the PlugPresent value also, using an || (OR) conditional, based on opmode or LockState or something like that which actually will surely stay active when the communication link is up. I did not record the beginning of the charging session so I don't know how exactly it begins and whether PP is ever activated by the charger.

I did some grepping on previous logs, and I can see that foccci is in opmode=CurrentDemand at lots of times when ResistanceProxPilot=10k. When grepping for which checkpoint has been active during ResistanceProxPilot=10k, I get this, which also indicates charging has happened during those times at multiple occasions:

Code: Select all

$ grep 'ResistanceProxPilot : 10000' *.params.txt -A100 | grep checkpoint | sort -n | uniq -c
    415 oic_2024-06-27_192345.params.txt-checkpoint          : 6 [dig]
     13 oic_2024-06-27_193906.params.txt-checkpoint          : 100 [dig]
      1 oic_2024-06-27_193906.params.txt-checkpoint          : 140 [dig]
      1 oic_2024-06-27_193906.params.txt-checkpoint          : 530 [dig]
      1 oic_2024-06-27_193906.params.txt-checkpoint          : 550 [dig]
      5 oic_2024-06-27_193906.params.txt-checkpoint          : 560 [dig]
      1 oic_2024-06-27_193906.params.txt-checkpoint          : 570 [dig]
    515 oic_2024-06-27_193906.params.txt-checkpoint          : 6 [dig]
    128 oic_2024-06-27_193906.params.txt-checkpoint          : 710 [dig]
      1 oic_2024-06-27_193906.params.txt-checkpoint          : 800 [dig]
      5 oic_2024-06-27_193906.params.txt-checkpoint          : 900 [dig]
      1 oic_2024-06-29_085419.params.txt-checkpoint          : 710 [dig]
     11 oic_2024-06-29_085422.params.txt-checkpoint          : 710 [dig]
     19 oic_2024-06-29_090001.params.txt-checkpoint          : 710 [dig]
    227 oic_2024-10-02_174333.params.txt-checkpoint          : 710 [dig]
     13 oic_2024-10-02_175217.params.txt-checkpoint          : 100 [dig]
    687 oic_2024-10-02_175217.params.txt-checkpoint          : 6 [dig]
    513 oic_2024-10-02_175217.params.txt-checkpoint          : 710 [dig]
      1 oic_2024-10-02_175217.params.txt-checkpoint          : 810 [dig]
      4 oic_2024-10-02_175217.params.txt-checkpoint          : 900 [dig]
      6 oic_2024-10-02_185010.params.txt-checkpoint          : 6 [dig]

I can see similar things in the Omega's logs (these are from the Previa). However, the Omega still is much more work-in-progress so I haven't been worrying about it there.

[johu]

That sounds worrying to me with my PP only wakeup. Kempower isn't common around here. Have you measured their PP with a multimeter?

[uhi22]

From my understanding the PP resistor of 1k5 shall be in the plug, without the possibility to deactivate this. It would be quite dangerous if the plug is in but the vehicle does not see it. Could you check at the plug with a multimeter? I've never seen other values than 1k5 on public chargers.
We need to find out and fix, that you get 500 ohms when you connect 150 ohms. Maybe the same issue causes the 1k5 to be interpreted as >5k. (The 5k I defined as threshold for the PlugPresent detection.)

[asavage]

From my understanding the PP resistor of 1k5 shall be in the plug, without the possibility to deactivate this. It would be quite dangerous if the plug is in but the vehicle does not see it. Could you check at the plug with a multimeter? I've never seen other values than 1k5 on public chargers.
We need to find out and fix, that you get 500 ohms when you connect 150 ohms. Maybe the same issue causes the 1k5 to be interpreted as >5k. (The 5k I defined as threshold for the PlugPresent detection.)

I hate to keep dragging this image up from the J1772 Wikipedia article, but . . . 480 ohms seems correct for the iteration they supplied.

J1772 signalling circuit, PP on EVSE side

Perhaps this is another regional difference? If so, I'd love someone with a cite-able reference to update that Wiki article.

[uhi22]

This is the type1 (US) version with the button. Celeron is Europe, type2, 1k5, no button.

Edit: The differences between CCS types 1 and 2 are shown in the diagrams in the LIM Wiki https://openinverter.org/wiki/BMW_I3_Fa ... ng_circuit

[celeron55]

One issue I'm having is I don't have the schematic file for the 4.5 board. The repo is seemingly blank between 4.2 and 5.0.

Maybe johu's wakeup branch is close?

[uhi22]

Yes, 4.5 was from the wakeup branch. As you say, the version info in the commit is missing, which makes things more difficult. But at least the date (printed on the PCB) and the date of the commit should fit (approximately )

[uhi22]

The PP resistance measurement is disturbed via the path R64 (1k to 12V), D21, PP_WAKE, JP3, PP. As long as the controller sets KEEP_POWER_ON=1, everything is fine, because Q3 pulls the anode of D21 to ground. But if the controller releases the KEEP_POWER_ON, the voltage on the PP rises, and the controller interprets this as increased resistance.

[evMacGyver]

I don't know how to put this to not sound quite wild, but... I'm pretty sure the Kempower charger I mostly test my car at doesn't connect PP, either at all or at least not during the actual charging session.

All logs I have taken from many Kempower it does have normal PP value and no problem charging. Serial logs show AdcProximityPilot ~2460-2470, pretty much the same as every other stations.
I use older version of Clara without plugdet parameter, instead Clara sends pure adc value to zom which detects plugdet.