Energy Controller including CCS interface

[uhi22]

[uhi22]

And the video summary of the first test session:

[uhi22]

Good news: After some improvements in pyPLC, the Ioniq is happy to provide power for 10 minutes, as we knew it from the past.

The issue was, that pyPLC needed quite some time (above 200ms) to answer the CurrentDemandRequest of the car. It is not fully clear, why this take so long. I disabled some logging and an unnecessary decoding step. Now pyPLC reponds within ~70 to 80ms. This is still quite slow, but seems to be good enough for the Ioniq.

Github commit: https://github.com/uhi22/pyPLC/commit/9 ... 82275d93c3

Maybe other cars are more strict. In case someone can find out the intended message response time from the DIN70121, we could check whether we need further optimizations.

[Edit] I have no timeout values for the DIN spec. But for the ISO15118-2, the values are: V2G_EVCC_Msg_Timeout on EV side for CurrentDemand: 250ms. Expected reaction of station for the CurrentDemand: V2G_SECC_Msg_Performance_Time 25ms. This means, the ISO says that the EV shall detect a timeout if the message needs ten times longer than specified. This is quite relaxed. If we assume, that DIN has the same values, then the 80ms of the latest pyPLC is slower than specified, but still factor 3 below the timeout time. This should be technically fine for the moment.

[uhi22]

Identified some room for optimization: We are responding CurrentDemandResponse.EVSEPresentVoltage = 0V, while the Ioniq is requesting 412V and 66A. This does obviously not matter for the Ioniq, but maybe other cars are more strict. So it would make sense to report the real voltage as EVSEPresentVoltage.

Created issue https://github.com/uhi22/pyPLC/issues/44

[johu]

Good thing I sent you this Maybe it now works with Q4 as well...

[uhi22]

I'm excited to see a log of the next try with it

[johu]

Hard to do with logging turned off Wireshark might also slow it down too much?

[uhi22]

I have tcpdump running in the background, this works fine.
https://github.com/uhi22/DiDeBoCCS/blob ... -a-service

[uhi22]

To bundle some information how to make the basic things running, I created a github repository "Discharge Demo Box" or in short DiDeBoCCS.

The goal is
- to keep an overview about different hardware variants (version 0 with homeplug modem, version 1 with beagleBone+FoccciCape)
- to provide a detailled setup guide for a quick success
- to concentrate on the functionality which is needed for a portable "demonstration box" which can be used for a quick check with every vehicle on any place

The goal is NOT
- to provide a full integration into a home automation / home energy management

https://github.com/uhi22/DiDeBoCCS

For anyone who is thinking to use the FoccciCape solution, please have a look whether this helps. Any feedback welcome. Improvements are ongoing, I think a next senseful step should be the integration of a precharge power supply, to satisfy the cars which are expecting real voltage during precharge.

[OpenCCS]

The goal is
...
- to concentrate on the functionality which is needed for a portable "demonstration box" which can be used for a quick check with every vehicle on any place

The goal is NOT
- to provide a full integration into a home automation / home energy management

That's great, I'm highly interested as this would be hugh step forward to V2H even to "older" eCars.

[uhi22]

Solved the issue with the EVSEPresentVoltage zero. Now we send the battery voltage which we know from the precharge-phase, plus a small random jitter to make it not too boring. The behavior of the Ioniq does not change, it still aborts after 10 minutes. Changed pyPLC and the display software to also show the (faked) present voltage and current.

[jrichl]

To bundle some information how to make the basic things running, I created a github repository "Discharge Demo Box" or in short DiDeBoCCS.

The goal is
- to keep an overview about different hardware variants (version 0 with homeplug modem, version 1 with beagleBone+FoccciCape)
- to provide a detailled setup guide for a quick success
- to concentrate on the functionality which is needed for a portable "demonstration box" which can be used for a quick check with every vehicle on any place

The goal is NOT
- to provide a full integration into a home automation / home energy management

https://github.com/uhi22/DiDeBoCCS

For anyone who is thinking to use the FoccciCape solution, please have a look whether this helps. Any feedback welcome. Improvements are ongoing, I think a next senseful step should be the integration of a precharge power supply, to satisfy the cars which are expecting real voltage during precharge.

I've ordered a beaglebone Black and will try to start this new project for me. Your work helps a lot to understand how everything works together. Already tried your cross compiling descriptions with some modifications on an ubuntu VM with success. We will see If I reach the point to order Johannes FoccciCape.

[jrichl]

https://github.com/uhi22/DiDeBoCCS

For anyone who is thinking to use the FoccciCape solution, please have a look whether this helps. Any feedback welcome. Improvements are ongoing, I think a next senseful step should be the integration of a precharge power supply, to satisfy the cars which are expecting real voltage during precharge.

I managed to install the BeagleBone Black and as well today the famous Foccci Cape. There was one hurdle that I had to pass. In your description at the point "First steps with the QCA" the plctool doesn't work. The reason was the not existing pip on the flash.
With the description here
https://openinverter.org/forum/viewtopi ... 710#p87710
I got it to run, worked perfect.

[jrichl]

For anyone who is thinking to use the FoccciCape solution, please have a look whether this helps. Any feedback welcome. Improvements are ongoing, I think a next senseful step should be the integration of a precharge power supply, to satisfy the cars which are expecting real voltage during precharge.

Todo I tried to connect to my i3, but I don't see anything in der logs that the pyPLC communication would start, although everything looks like in your description in the setup_focccicape.md. I found only one change that was necessary at the installation of the following packages.

pip install pySerial
sudo pip install pySerial
pip install requests
sudo pip install requests

I need to do it with pip3 otherwise pyPLC doesn't start and brought failures.

Because I didn't see any communication I measured the voltage between CP and PE at the foccciCape, and I thought it should be something around 12V but I measure -12V and it moves to something around -9V and -6V and back to -12V - so probably the cppwm Skript is doing his job. I have only a multimeter to measure it, and the frequency I saw was 2kHz. So should this work with these values, or what do I have to change?
At the input of the FoccciCape I use a MeanWell 12V PowerSuply which was necessary, because only a power bank with 5V was not enough for the FoccciCape and the BeagleBone Black. The BeagleBone was in a boot Loop. The measurement at the input is clear +12V how expected from the Power Supply.

As mentioned here https://openinverter.org/forum/viewtopi ... 570#p88570 I changed in the cppwm.py to the following line

f.write("948000") # a little bit below 5% to compensate hardware delay

in case of CP PWM backwardation, and it helped. Now I measure +12V at the CP and also a frequency with 1kHz, but my i3 is still unhappy and doesn't like to communicate with the FoccciCape - any ideas what to check next?

[johu]

The 1k5 resistor between PP and PE is in place?
Try executing the commands from cppwm.py manually to see if they actually run without errors. E. g.

Code: Select all

echo 1000000 > /sys/class/pwm/pwmchip0/pwm0/period

[uhi22]

Regarding the power supply: on my side I have the old FoccciCape which has no 12V-to-5V stepdown converter, so it runs with 5V from USB power bank. The new version with the stepdown needs at least 7V, or, alternatively, a stable 5V can be injected behind the stepdown directly on the 5V rail.
Do you see the cm_set_key and the response in the pcap? This must work also without a car connected.

[jrichl]

The 1k5 resistor between PP and PE is in place?
Try executing the commands from cppwm.py manually to see if they actually run without errors. E. g.

Code: Select all

echo 1000000 > /sys/class/pwm/pwmchip0/pwm0/period

Yes, the 1k5 resistor is in place - but false I think it is between cp an pe, my stupid false, have to change and will report after that.

The 12V power supply is ok for me, because you will have almost in each Car a 12V plug to connect the DiDeBoCCS Box.

Edit:
Now the resistor is between PP and PE and the i3 is communicating with the FoccciCape, but at least it is blinking red. I don't see any communication in the evseNoGui.py session, so something is still not ok. I will attach the journalctl file and the pcap file from tcpdump. Maybe someone could see the problem.

[uhi22]

Is the foto the old or the new state? It shows the wrong behavior. It is in the CP hole, but shows the 1k5 which shall be on the PP.

[uhi22]

Summary of the logs:
- We try to start the tcpdump and pyPLC while the network eth1 is not yet available. So both complain (pyPLC: "Exiting, because it does not make sense to continue without IPv6 address" and since the services are configured to restart automatically, they are restarting. (The restarted pyPLC is not visible in the log, but the pcap shows that it is running fine at the second try.) We need a linux expert to improve this situation. The behavior shall be: wait until eth1 is up, and then start the tcpdump, and then start the pyPLC. But this is just cosmetics, not a problem.
- The error "pwmchip3: /etc/udev/rules.d/81-pwm-noroot.rules:12 Failed to write" sounds like a problem writing the PWM. No idea at the moment.
- In the pcap, we see the CM_SET_KEY.REQ and confirmation. This is good news. It means, that pyPLC is able to talk to the QCA chip, and the QCA is fine.
- We see nothing from the car. The normal case would be: The car sees the 1.5k on PP, and the 12V (and later 5% PWM) on the CP. Then the car shall send SLAC_PARAM.REQ.

I propose: check the wiring, in best case with an oscilloscope. There should be on CP a PWM with +9V and -12V and 5% while the plug is connected. And on the 1.5k PP resistor, there is normally a small voltage while the plug is connected.

[jrichl]

Is the foto the old or the new state? It shows the wrong behavior. It is in the CP hole, but shows the 1k5 which shall be on the PP.

the photo is the old one, it is like the attached now

[johu]

I think for now you want to disable the systemd integration and bring up pyPLC and cppwm.py manually. That way you see the output immediately and don't have to go through journalctl

What do you get as result of

Code: Select all

ls /sys/class/pwm

Finally make sure no management tools interfere on eth1. On my beaglebone I added eth1 to /etc/connman/main.conf

Code: Select all

NetworkInterfaceBlacklist=SoftAp0,usb0,usb1,eth1

[jrichl]

Summary of the logs:
- We try to start the tcpdump and pyPLC while the network eth1 is not yet available. So both complain (pyPLC: "Exiting, because it does not make sense to continue without IPv6 address" and since the services are configured to restart automatically, they are restarting. (The restarted pyPLC is not visible in the log, but the pcap shows that it is running fine at the second try.) We need a linux expert to improve this situation. The behavior shall be: wait until eth1 is up, and then start the tcpdump, and then start the pyPLC. But this is just cosmetics, not a problem.
- The error "pwmchip3: /etc/udev/rules.d/81-pwm-noroot.rules:12 Failed to write" sounds like a problem writing the PWM. No idea at the moment.
- In the pcap, we see the CM_SET_KEY.REQ and confirmation. This is good news. It means, that pyPLC is able to talk to the QCA chip, and the QCA is fine.
- We see nothing from the car. The normal case would be: The car sees the 1.5k on PP, and the 12V (and later 5% PWM) on the CP. Then the car shall send SLAC_PARAM.REQ.

I propose: check the wiring, in best case with an oscilloscope. There should be on CP a PWM with +9V and -12V and 5% while the plug is connected. And on the 1.5k PP resistor, there is normally a small voltage while the plug is connected.

unfortunately I do not have an oscilloscope, and yes there is nothing coming from the car - no SLAC_PARAM.REQ. Is it possible that my cable to the car is to long for the plc communication? it is about 8m.

[jrichl]

I think for now you want to disable the systemd integration and bring up pyPLC and cppwm.py manually. That way you see the output immediately and don't have to go through journalctl

What do you get as result of

Code: Select all

ls /sys/class/pwm

debian@BeagleBone:~/myprogs/OpenV2Gx/Release$ ls /sys/class/pwm
pwmchip0 pwmchip1 pwmchip2 pwmchip3 pwmchip5 pwmchip7

[johu]

Is it possible that my cable to the car is to long for the plc communication? it is about 8m.

Mine is 10m

pwmchip0 pwmchip1 pwmchip2 pwmchip3 pwmchip5 pwmchip7

Ok, now do

Code: Select all

echo 0 > /sys/class/pwm/pwmchip0/export

That should spawn /sys/class/pwm/pwm-0:0

if not you need to troubleshoot whichever error message the above command produces

If it does work:

Code: Select all

echo 1000000 > /sys/class/pwm/pwm-0:0/period
echo 5000 > /sys/class/pwm/pwm-0:0/duty_cycle
echo 1 > /sys/class/pwm/pwm-0:0/enable

[uhi22]

For the PLC communication the 8m should be no problem. Not sure for the PWM. Any chance to try a short cable (2m)? I can recommend the OWON VDS1022I USB oscilloscope, quite cheap and helps a lot in trouble shooting. Even isolated, so not producing ground loops.