Develop a QCA7000 board?

[tom91]

The software flow diagram I did for my AC Charge Port controller

The tricky bits are timeouts for things like:

• No CP or Invalid CP
• Vehicle now waking up
• Vehicle not accepting charge
• Errors not healing
• End of Charge

[uhi22]

Basically yes, at least this is the plan. The sequence need some refinement, e.g. what means (3) in detail, and which signals carry which values in these steps. Not all is implemented at the moment.
1. Plug-in is detected with PP, and clara provides the PP resistance and PP current limit.
2. Clara measures the CP PWM, and decides for AC in case of valid AC range. DC at the moment runs in parallel, just using the PLC. No check for 5% PWM at the moment.
3. For AC charging, clara receives the AcObcState, which demands the Locking (not yet routed to the lock motor), the StateC (working), and the LED (working).
4. CP stateC see 3.
5a to be refined
5b Clara receives AcObcState with an other value than CHARGING, and switches to StateB. Is implemented.
6. Unlock: to be refined.
7. Unplugging is signalled via cableCurrentLimit=0, but Clara does not use it internally. To be improved.
8. As 7.

The LED patterns for DC are described in the clara user manual (https://github.com/uhi22/ccs32clara/blo ... k-patterns), and for AC similar, at the moment only described in the code (https://github.com/uhi22/ccs32clara/blo ... BC.cpp#L17), but still work in progress. Can be improved when refining the sequence.

[johu]

Short intermission: I went back to the Tesla SuC now with PP pulled to 12V via 10k (before PP was not at all connected). And it no longer starts I tried two stalls, it just times out. Unfortunately the controller is now kindof buried so I couldn't debug. All other chargers (Abb, Compleo, Ionity/Tritium) still work.

[uhi22]

Thank you, Elon I would say

[muehlpower]

1. Idle/wake/ unlocked - White or Blue Constant
2. Plugged in and waiting + locked - Green Constant
3. Charging started + locked - Green Pulsing
4. Stopped and unlocked - White or Blue Constant
5. Error - Red Constant

I like this color scheme, with white light after waking up. In my case, the LEDs light up the whole area of the fuel filler flap, and it's easier if it's bright when you plug it in.

[uhi22]

Maybe we should introduce a free parametrizable color mapping. Just kidding. But, wait, maybe really.

[johu]

Thank you, Elon I would say

I will change my pull-up to 12V to be more like 3k3 to arrive in the voltage range you measured in your Ioniq. Will also stick a multimeter into various CCS plugs to measure resistance PE-PP when not plugged in

[uhi22]

Yes, this would be interesting. I measured 1k5 in all cases until now.
[Edit] If Elon is really creative (and he is, for sure), he would even make the 1k5 switchable, so the charger could use different pull-downs, and verify not only the voltage which is created by the 330ohm pull-up and the 1k5 pull-down, he could even measure the idle voltage when no pull-down is connected, so he has the opportunity to check two system parameters: voltage and resistance. Super safe.

[johu]

I changed the pull-up to 3k3 now. At 14V that would result in 14*1.5/(1.5+3.3)=4.375V. Too much maybe?
Anyway, no joy and this time I have logs.
Behaviour wasn't consistent, sometimes it didn't communicate sometimes it was stuck in CableCheck.

Tried 2 stalls. Reference charge at Compleo works

[f0ld]

Does the Clara do the follow:
1. detect plugged in
2. determine the CP signal is 5% pwm for DC or above for AC
3. recieve request to charge or verify okay to start
3.lock motor
4. Enable EVSE via CP pull down
5a. stop because EVSE stops, info via CP
5b. stop because EV requests stop via CAN (or however this is implemented) Clara drops CP
6. Unlock unless there is an inhibit unlocking in place (via CAN I would say)
7. Plug removed
8.reset charging session assumptions and wait for plug detected.

No expectation regarding the AC development just a quick thing to consider:
I would add to the list that there is a mode "charging paused for vehicle ventilation". A lot of cars with 22+ kW AC Charging use this. I think in muehlpowers file it is also referenced. My car does use this quit often when it starts the compressor while AC fast charging.

How does the LED work?
The way I have mine working and I believe to some extent the BMW implementation
1. Idle/wake/ unlocked - White or Blue Constant
2. Plugged in and waiting + locked - Green Constant
3. Charging started + locked - Green Pulsing
4. Stopped and unlocked - White or Blue Constant
5. Error - Red Constant

Renault Zoe (only has blue and red. Facelift has also yellow so a bit different there):
1. Blue Constant
2. Blue flashing (fast)
3. Blue pulsing (slow)
4. Blue Constant
5. Red Flashing or Red constant depending on the error type

I like the BMW implementation more then Renaults. If we have RGB we should use it to the fullest extend

[johu]

Tesla charging now works again! I swapped the resistor again now to 4k7. I found when idle there is indeed 1k5 between PP and PE but eventually PP and PE seem shorted, I saw 0V on PP after CableCheck or something.
Summary: PP pulled up to 12 (14)V with 4k7 works on Tesla chargers. All other chargers work with 3k3 and 10k likewise.

[johu]

I just remembered that EnBW offers the AutoCharge feature where you just plug in and the car is apparently just identified by its MAC address. https://www.electrive.net/2021/11/24/en ... ktion-ein/

Not very safe (I think anyone can come near the CCS cable and sniff the MAC address) but really cool Is the MAC address in question the one defined in homeplug.cpp:62 ? Or some hard coded one in the QCA chip?

[uhi22]

Yes, Autocharge is cool. Still waiting until somebody charges at my cost, I would sponsor the first (and maybe second) charge and then disable it. And yes, the homeplug.cpp:62 is the MAC address in question. The other MAC address, the one of the modem, is inside the SPI flash. This one is normally not seen by the charger.

Other topic: I'm slowly going crazy with the supercharger. While I reached the precharge loop after using "correct" PP circuit (https://github.com/uhi22/clara-logs/blo ... ecoded.txt), today on the same site and different stalls always stuck in the cable check. With nothing changed in the hardware. https://github.com/uhi22/clara-logs/blo ... ecoded.txt Really crazy. Maybe it was not even a PP topic, but some other unknown random effect that leads to passing or failing the cable check.

[johu]

Ok, then maybe we can make the last 3 bytes a parameter that defaults to 0. If zero we do something pseudo-random like reading the ADC from a floating pin. Once you save parameters you have a fixed MAC address.

Other topic: I'm slowly going crazy with the supercharger.

Remarkably I NEVER had issues with the SuC while using the CHAdeMO adapter. Two key differences:
- PP left floating
- No tension on cable because the inlet was located at the tailgate - with the socket built into the fuel door there is some tension pulling the CP pin back maybe 3mm

[uhi22]

Or maybe just fully parametrizable 6 bytes MAC address, with a certain default which is a valid MAC, and if somebody wants to use the Autocharge (also Fastnet supports this), he just chooses a "random" personal MAC instead the default. For everybody which is not interested in Autocharge, can just live with the default, because from network point of view there is no risk for collision, because only 4 participants are in the network (two modems, and the EVSE controller, and the clara). So there is no need for a "worldwide unique" MAC address.

[asavage]

I haven't looked into it, but you may need a valid Vendor OID for the first part of the MAC address.

I know next to nothing about OIDs; I frequently use the OID Lookup feature of dd-wrt to find "rogue" IPs on my home LAN, from IoT devices that have snuck inside the house, such as my Blue Air 480i air filter.

[catphish]

Since we don't have a Vendor ID, the best way to generate a valid MAC address is to use a "locally administered" address.
For this to be valid, bit 0 of the first byte should be zero, to indicate a unicast address, and but 1 of the first byte should be one, to indicate locally administered. All other bytes can be any value, but it makes sense to randomize them as much as possible to avoid any (extremely unlikely) conflicts.

Therefore, a good, valid MAC address is: 02:xx:xx:xx:xx:xx where xx is any random 8 bit value.

[johu]

We've also got the chip serial which is unique

[muehlpower]

Can't you just take a MAC address from an old PC network card lying around? That would be genuine and unique.

[f0ld]

ot very safe (I think anyone can come near the CCS cable and sniff the MAC address) but really cool

Well most charging parks have cameras nowadays. So this shouldnt be too big of a problem. And they have actually some kind of detection of fraudulent activitiys. They were catching all those people cloning/guessing charging cards (back in the days when it was still possible). Thats why I would trust them to manage this as well.

Fun Fact: There were some complaints in the early days that VAG Vehicles were so "loud" in their transmitting that it acutally interrupted prototype cars from a different german OEM charging on the neighbouring stall. They fixed it but afaik VAG Vehicles are still very strong on the transmitting side (so if you want to sniff MAC Adresses choose a VW The older ones or those with old software do change their MAC Adress at night though hence why they are not in the AutoCharge Programm ...).

Since we don't have a Vendor ID, the best way to generate a valid MAC address is to use a "locally administered" address.

I agree. I have from a different project a Vendor ID and if it is okay with the other partys involved in the other project I might be able to contribute it if we really need it. With the condition that we have a preassigned block of MAC-IDs for Clara within the vendor assigned block and have a central way of generating/registering those Adresses. As stated above I have to check first since they paid a significant part of the 2.8k it cost to register as a vendor....

If we have to generate them anyway it might be smarter to generate them (from example the chip serial nummer and some magic math) in clara as local administered Adresses and completly avoid the vendorID.
But then I was concerned if EnBW actually accepts those local administered MAC Adresses for AutoCharge. Luckily I know someone that does "Technical Operation & Service Charging Infrastructure" at EnBW and asked him directly

Since the answer was in german here is a shortened version of what ChatGPT translates it to (if your interested in the original I gladly provide a screenshot):
[...]
"So I think I can give an answer here, at least for now. Basically, yes, it's about the modem's Mac in the car with Autocharge. We have a detection on the stations that if too many customer numbers use the same Mac, the backend automatically blocks the Mac, as with smart #1, for example. Everything else doesn't matter for now, the Mac addresses are not examined in detail, only for duplicates. What I can't promise is that it will stay that way and that Alpitronic might not also put a question mark behind the sessions in their data, they have already excluded and/or adjusted some special cases on their software side."
[...]

Can't you just take a MAC address from an old PC network card lying around? That would be genuine and unique.

Yes but this would be something every person would have to do with their own "old" network card. Everybode using the same would certainly result in a block by the AutoCharge Vendor since they cant assign the charging session properly to costumers (and the first to register it would have to pay for all the following users )




To summarize I see 3 ways of handling this issue:

A) We decide we generate those for the users of focci. The easiest way (for now) is to use a local administered adress. There are multiple ways of generating those so we dont have a collision. I personally would suggest to use something like the serial number of the chip (+maybe magic to make it bruteforce/guess safe). This would make it fully automized for clara users and would even work for abberations of focci+clara.
For now this should work.

B) Provide it with a default parameter that the user can change with their own value in the WebInterface. I would suggest leaving the default value empty so nobody accidentaly registers this with autocharge and get the feature blocked for all the other users because they will exclude this type of adress altogether.

C) Not providing a MAC adress period and letting the user fill it in the code (and leave the choice completly to the user). This can be referenced in the user manual and documentation. (And yes I know this is a suboptimal solution with a lot of downside just wanted to note it for completness).


I personally would prefer option A or a combination of option A and B.

[catphish]

We've also got the chip serial which is unique

This sounds good. If we append the STM32 serial number to the 02:: prefix, we should get a nice unique and consistent address.

A) We decide we generate those for the users of focci. The easiest way (for now) is to use a local administered adress. I personally would suggest to use something like the serial number of the chip.

This

[asavage]

Well most charging parks have cameras nowadays.

That is not the situation at almost all public charge stations I've visited (Pacific Northwest, USA).

. . . those with old software do change their MAC Adresss at night though hence why they are not in the AutoCharge Programm ...).

I posted something on this in Apr2023 with a link to a YT video interview with an EVGo rep; they're fingerprinting vehicles based on quirks of their CCSx implementation, as well as MACs.

[P.S.Mangelsdorf]

That is not the situation at almost all public charge stations I've visited (Pacific Northwest, USA).

I'd agree based on my experience in the southeastern US. Way too many stations at the back of large parking lots or tucked around a corner out of the way. I've been sketched out a few times (and I'm a pretty big dude).

If only we as a society had figured out a format for vehicle refueling stations that was well lit, protected from rain, allowed vehicles with different fueling port locations easy access, provided snacks and restrooms... But that would be too simple

[f0ld]

That is not the situation at almost all public charge stations I've visited (Pacific Northwest, USA).

I'd agree based on my experience in the southeastern US. Way too many stations at the back of large parking lots or tucked around a corner out of the way. I've been sketched out a few times (and I'm a pretty big dude).

I always forget how far behind you are in the US in terms of charging infrastructure

Since we were talking about the AutoCharge Feature (which is mainly implemented by EnBW and Fastned those are primarily based in germany and the netherlands) I brasenly assumed those for the statement without remembering EVGo and fully agree with you for the US. I hope the situation will get similar to the one we have over here . If you watch Kyles (OutOfSpec) Videos on his Roadtrips through Germany in a Taycan you can see what I mean by that

You should have Plug&Charge in the US (you mention it in your video as well) which technically is checking the contract via certificate and not identify the vehicle and then sort it internally to the contract. But the whole standardization and implementation according to ISO is a whole clusterfuck in it self

[johu]

I've implemented the chip serial variant now: https://github.com/uhi22/ccs32clara/pull/14

Don't think it'll cause harm because the former hardcoded MAC address was AFFE DEADBEEF

image.png (35.26 KiB) Viewed 864 times

Erm, edit: want to encourage some consistency - some names are now camelCase and some lower case, some state names ALLCAPS. I don't have a preference - so which one should we pick? So far OI projects are all shortened lower case (because back in the day you had to type them into a terminal) but camelCase or CamelCase should improve readability

EDIT2: worked on it https://github.com/uhi22/ccs32clara/com ... f8dd259446