openinverter forum

Created https://github.com/uhi22/ccs32clara/issues/17 regarding missing stack pointer initialization, which is one reason that Clara crashes on the iso-test branch. Any hint welcome.

[Edit] The missing stack pointer initialization is solved now on the iso-test branch. DIN works again, ISO not yet tested and some open todos to resolve.

Slightly off-topic, but does anyone have spare QCA7005 chip to sell, 1-2pcs?

Hello,

after reading until the end of this and other QCA7000 threads it is time to get my hands dirty and kick start my project to upgrade my Nissan Leaf for CCS charging...

One question I have is what is currently the latest release of FOCCI? Looking at GitHub it states 4.2, if you go to the shop it states 4.5 and of course earlier in this thread you read about 4.3. It seems to me GitHub is a bit behind and I wonder if there are plans to keep the versioning kind of in line?
Lastly how far away is the migration of the wakeup branch Johu is working on?

evMacGyver wrote: ↑Wed May 22, 2024 4:53 pm Slightly off-topic, but does anyone have spare QCA7005 chip to sell, 1-2pcs?

Good question, did anybody find a reasonable priced source in the meanwhile? (I'm dreaming of below 10€)

Regarding the versioning: The latest version is on johus wakeup branch. If further tests are turning out that this is stable, we should bring this back to the main.

Hi,
This is my first post and I'm sorry if I'm not adhering to any forum guidelines.

I'm developing a CCS Charger using QCA7005 with STM32F4 microcontroller. I used the Qualcomm PLC utils toolkit.

I'm able to establish an AVLN network after successful completion of SLAC messages (upto SLAC_MATCH_CONF). I'm also able to receive SDP request from the EV car, but I'm not able to get the TCP request as expected. As I'm not using a linux system, I wasn't able to get trace message as shown in previous post. I'll give a few details below and please let me know if you need anything else apart from this
The SDP response payload that my controller sends after receiving the SDP request is as follows
Requesting you to help me with this issue

lalithroshan wrote: ↑Thu May 23, 2024 2:39 pm I'll give a few details below and please let me know if you need anything else apart from this

Hi, is this open source?

lalithroshan wrote: ↑Thu May 23, 2024 2:39 pm As I'm not using a linux system, I wasn't able to get trace message

I recommend to record the SPI traffic, and convert the SPI data into a pcap file, which can be inspected e.g. using wireshark. The workflow is described here: https://github.com/uhi22/Ioniq28Investi ... i-analysis

lalithroshan wrote: ↑Thu May 23, 2024 2:39 pm I'll give a few details below and please let me know if you need anything else apart from this

I think I do not need anything. If you want to give something to the community then you are invited to share your experiences. (Sorry for the clear statement. Maybe it's just a bad translation. The message I got is, that you need support and ask me whether I need information to do your work.)

osch wrote: ↑Thu May 23, 2024 1:46 pm my project to upgrade my Nissan Leaf for CCS charging...

As opposed to one of the off-the-shelf CCS->CHAdeMO adapters?

Finally got around to re-assigning the connector pins and made the flash SPI easier to access. Moved some components around to reflect the new placement also. I'm calling it 4.5b as it is electrically identical to 4.5. Didn't want to burn up another version resistor. Does that make sense?
Here is the new assignment I've "padded" the unused pins with GND. That way, both the contactors + and - lead can be inserted into the Deutsch connector

EDIT: now that I look at it I could swap 5V with GND so contactor pins can be adjacent.... DONE
https://github.com/jsphuebner/foccci/tr ... assignment

That is fantastic Johu....!!!

johu wrote: ↑Fri May 24, 2024 4:26 pm Finally got around to re-assigning the connector pins and made the flash SPI easier to access. Moved some components around to reflect the new placement also. I'm calling it 4.5b as it is electrically identical to 4.5. Didn't want to burn up another version resistor. Does that make sense?

Think it depends if this board will be sold through the shop. Rearranging connector pins is a breaking change if you ask me. It makes it incompatible with previous versions and can cause issues if you are not taking care and double check before using it.

Padding the unused pins is always a good idea and may be best practice?

I'm happy to give this new design a shot and share the ones I don't need. Let me know otherwise...

asavage wrote: ↑Thu May 23, 2024 8:03 pm As opposed to one of the off-the-shelf CCS->CHAdeMO adapters?

Right, I'm aware about these devices. Was thinking about getting one but they are still a bit pricy and if you look at comments from users who have bought them they aren't fully compatible. You rely on what they provide and have to wait for updates from the vendor.

Believe this solution / project is a few steps further down the road and you have the freedom in getting fixing issues on your own or getting help much faster. Of course it requires to mod your car but given my one is more than 5 years old there is no warranty anymore.

Lastly it is more fun this way

Hello everyone.
Tell me, I'm faced with the following not very good situation. When connecting the board to the charger, at the moment the QCA wakes up, there is some kind of surge on the line (or CP or CE) on the side of the charger, such that the controller is reset. Maybe someone has encountered it? What protection options were considered? Has anyone tried to enable TVS protection on the CP-CE line?

Do you have the chance to measure this "surge" with an oscilloscope? We need to understand, where it comes from and where it harms, to fix it. And: You write "controller is reset". You mean the STM32 is reset? This cannot be caused by anything on CP, PP or PE. This would mean that the 3.3V line drops, which is quite unlikely, no matter what is applied on the CP or PP or PE from outside. More likely is power drop on the 12V.
Also it would be interesting when exactly the reset happens. A log of Focccis serial output could help.

Regarding implemented protection measures:
- The 12V power is protected with a TVS against overvoltage.
- The 12V power is protected with a diode against wrong polarity.
- The PLC modem is protected by diode network against high-frequency energy on CP.
- The PLC modem is protected by transformer against low frequency pulses on CP.
- The controller is protected by 47k and 100nF against voltage spikes on PP.
- The controller is protected by D14, R58, D16 against high voltage on CP.

Which additional protections do you intend to add?

I have added a thread for everyone who integrated Foccci into the car: viewtopic.php?t=5077

johu wrote: ↑Fri May 24, 2024 4:26 pm Finally got around to re-assigning the connector pins

Can I just check: the FOCCCI wiki page shows the pinout of versions 4.5 and below, whereas the 4.5b version referred to in the quoted post is 'new' and not currently shown in the wiki page (as of today at least)?

A humble suggestion - going forward it would be useful to include a board version to pinout mapping, ideally in the wiki.

Added a new column with 4.5b mapping
Can you upload the png?

johu wrote: ↑Sun Jun 09, 2024 3:17 pm Added a new column with 4.5b mapping

Thanks.

johu wrote: ↑Sun Jun 09, 2024 3:17 pm Can you upload the png?

I was unable to add a new version of the board pinout image as it claimed the original version was an svg and the image from the post is a png, but I have added the 4.5b version as an additional image.

Thanks, I think it is better to have both versions anyway

Whilst sniffing traffic from Clara and trying to get my head around the ESP32 Web interface tool I note that Clara broadcasts two CAN message IDs, as shown below. IDs 0x596 and 0x616. What are these message please?

First Idea would be the CANopen communication between the web interface and Clara.

Hi Guys.

I'm using the QCA7000 board V4 on the EVSE side. My practical tests are with a TPlink AR7420 using pyPLC as PEV and sometimes with a BMW i3 2014.

In the QCA7000 board I have removed L5 and L7 that was grounding the RX signal.

In my tests with AR7420 the communication works 100% of time, but with the car sometimes the communication doesn't start and I don't know why exactly. I have some doubts:

1. Does the car need some minimal amplitude voltage of high-frequency signal on CP? Does ISO15118 say something about it? My signal is around 1.6 Vpp. (with TPlink AR7420 this signal is 8Vpp).
2. Is anyone using with success the QCA7000 on the EVSE side?

The RF signal level should not matter. Even very weak coupling, which leads to only few millivolts, usually works.
Maybe check the PWM, and make a log to see how far it runs.

Do you plan to publish the Evse software?

Started a new thread for OBC integration viewtopic.php?t=5127

Also worked on the wiki article a bit more. I start to think that from a user perpective it makes more sense to have all information on one page, not divided up into HW and SW. Opinions?

I agree. Because for some topics it's difficult do sort it into the one or the other cathegory.

New feature is implemented now: When the temperature of the charge port increases, we reduce the charge current, to avoid overheating. If the temperature still increases much above the configurable limit, we stop the charging session completely.

github commit: https://github.com/uhi22/ccs32clara/com ... 8c720b1ece
github issue: https://github.com/uhi22/ccs32clara/issues/21
binaries: https://github.com/uhi22/ccs32clara/act ... 9670778971
wiki: https://openinverter.org/wiki/Foccci (search for MaxAllowedPinTemperature)