openinverter forum

Finding 1: The StateC-switching does not work as intended. The controller immediately turns into StateC after power-on. This does not happen with the cube-ide-variant, which changes to StateC when the green-blinking changes to blue-blinking. So it points to a configuration issue of the StateC-pin, which was introduced with the migration to the libopeninv.

[Edit] Finding 2: The TCP retransmission tries to re-transmit, even if the connection is down already. When we connect new to a charger, we send retransmissions already during the SLAC. Solution: In tcp_Mainfunction(), mark the retry-timer as "unused" if the connection level is below 50.

[Edit2] Maybe it's time to create a pull request to bring the libopeninverter-variant back to the main repository, to enable parallel working.

[Edit3] Stored the instructions for setup the tool chain here: https://github.com/uhi22/ccs32clara/com ... a49d8f61a3

Fixed these and created a PR

EDIT: connector locking works only if we have a valid feedback. I guess it could be useful to implement a variant that works without feedback and just runs the motor x ms

With those bugs you mentioned fixed I could finally charge at the Tesla SC
EDIT: One bug: when I stopped the charger via the app Clara stayed in CurrentDemand. I loosened the connector until CP was interrupted, then it turned off.

Was going to test Ionity also but all stalls were taken (Lutterberg)

EDIT: thought this looked kinda cool

Really great. And the third operator in Lutterberg (https://www.goingelectric.de/stromtanks ... -11/80537/) still is not alive? Would be a great site for testing, three different manufacturers within 200 meters

Would like to see a trace in case the supercharger stops, it should announce somehow that it wishes to...

Pushed some improvements: logging time stamp in milliseconds, time-based connector lock, tcp retries increased and logged, docu.

Cool, nice additions.
I wonder if we can make a debug queue that collects the lines and then the idle task prints them. Probably easier to use than having the centralized logging.

You could activate your timed connector lock when the two thresholds are identical.

I will go back to Lutterberg maybe tomorrow and enable the Ethernet frame trace.

A kind of "Crash log" would be nice. Just store the last ten ethernet frames in a buffer, and print them when we reach an error state.
But I also find that logging each frame live should be okay. The protocol has very relaxed timing requirements, so spending 5ms for a print is no issue. Btw: The 0.9Mbaud works perfectly here.

Quick return to hardware. I have populated the second board now but no joy.
Processor runs fine but I see no comms between QCA and STM. STM sends 4 bytes, I think 0xC3 0 0 0 and reply is all zeros. Also on bootup I don't see any activity between SPI flash and QCA.
3V3 and 1V2 measure ok, so at least the voltage reg in the QCA is running.
Powerline RX/TX have the correct resistance between them but don't sit at 1V6

I've reflowed the chip a couple of times and the joints look fine.

Any idea what to check?

SOLVED! L2 was missing, conducting 3V3_D to 3V3_A

Some progress with the web interface. The setup was not easy, I collected my notes here: https://github.com/jsphuebner/esp32-web ... ace/pull/3 Finally it works, I can flash software updates to foccci in the browser, see spot values, can record a graph and change parameters and CAN mapping. All very well prepared, thanks to the openinverter library and tools. Nice

Finding3: The temperature values show zero and do not react on changed voltages on the pins.

Finding4: The make does not see if the param_prj.h is changed. Just calling make (or in my case mingw32-make) should see the changed file compile all dependent files. Unfortunately I'm not the make-file expert, but my impression is, that the .h files somehow should mentioned in the dependencies in the makefile.

I added a logging parameter that lets you select which modules messages you want to see. Also multi selection is possible by adding the flags.

Not all messages are tagged yet, so even with everything turned off you get some messages. I added dumping raw TCP (RX) traffic as one option.

EDIT: I see you worked on the state machine. Will retry Tesla soon.

EDIT2: Finding4 fixed

EDIT3: Finding 3 because temperatures_calculateTemperatures wasn't called. But when called we lack the log() function. There is an ln() function in my_fp.c

EDIT4: it links with "-lm" added to the END of the linker command line. Lets see if it also runs

Early forum release

Really cool. Maybe you could add a fancy RGB button to your box, to see the status as light show and to be able to stop the charging with the button. And the text size in the web interface could be a little bit bigger for the outdoor-video-usecase

Temperature inputs now work (but don't do anything)
https://github.com/uhi22/ccs32clara/com ... 56dce0f856

Went for another charger round

1. Ionity (Tritium) - delivers current for a few seconds then stops. Same behaviour as Audi with pyPLC. Log attached
2. Tesla SC - now stops when stopping in the app (more below)
3. ABB 50 kW at VW dealer - works
4. ABB 175 kW at VW dealer - works
5. Posh looking charger at Porsche - does not work at all. No SLAC, modem goes to sleep (picture attached). One of them had a note "Defekt" maybe the other one is also defekt

The shutdown happens a bit too quickly now for my taste. Like the moment I hit stop in the Tesla App the port relays open. Would like to see a little grace time and verification that current flow has stopped.

Addition: what I like about Ionity is they run in an endless loop. If charging fails they start over without interaction so you won't be zipping your cup of coffee while your car fails to charge.

Addition2: I'm also surprised about evsemaxcur and evsemaxvtg. Voltage always seems a bit low, like 437V on that last HPC wouldn't even cut it for the 108S packs. And also it only reports 200A max current. that way we certainly don't arrive at 175 kW. Interestingly Compleo reports 530V here which seems more plausible.

So overall increased success rate

Sorry about the odd log format, I hope someone can puzzle it together. It's the data after TCP I suppose? so without TCP/IP and Ethernet header

Ouch, hope your contactors are still fine. There is a significant mismatch of the precharge voltage and the actual accu voltage. We are closing the contactors when EVSEPresentVoltage is at 201V (or 220V). And then the voltage jumps to 385V, which is the real battery voltage. This leads to a short but heavy current to charge the capacitor in the charger from 220V to 385V.
But the more interesting part is the ramp-down of the current, followed by a period with zero current, and a short retry up to 3 amps, and zero afterwards. Would be helpful to see also our requests, otherwise it is not clear whether the charger turned the current down (e.g. due to temperature or something), or whether clara requested less current.

Toolchain for decoding and visualization here:
https://github.com/uhi22/pyPLC/blob/mas ... nverter.py
https://github.com/uhi22/pyPLC/blob/master/scope.py

Oh wow, you've written a decoder already. Hmm precharge is pretty quick, maybe there just isn't enough samples? Anyway, I use Gigavac contactors, they are pretty tough. Will measure the charge port nonetheless if there is any voltage on it in off state.

One thing I noticed, I am exporting EVSEPresentVoltage also in CableCheck and there is displays implausible values on all or most chargers. Like 100x to large. Not sure what's up with that.

I can collect the TX data also but would be surprised if we are commanding lower current. Then it should act the same way on all chargers. I charged at Tesla just 2 minutes later and that was ok. What puzzles me is that pyPLC has the same problem on Ionity - what do they have in common? The chargers are super busy like said, so I doubt that they are faulty.

EDIT: On another note I'm trying to understand why the LED outputs are so complicated Would rather straight use the IO pins with 470R or 1k resistors. Leds don't need 20 mA to be bright. Then there would be more options, like common-cathode, common-anode or inverse polarity (two LEDs in parallel with anode and cathode connected)

The LEDs are using the LIM design, 12V, common cathode, because the common RGB buttons have this interface (I was saied). WS2812 would be my favorite.

EDIT

johu wrote: ↑Mon Dec 11, 2023 9:10 am One thing I noticed, I am exporting EVSEPresentVoltage also in CableCheck and there is displays implausible values on all or most chargers. Like 100x to large. Not sure what's up with that.

The dinCableCheckResTypedoes not include EVSEPresentVoltage. Trying to access in a message dinDocDec.V2G_Message.Body.CableCheckRes the other message dinDocDec.V2G_Message.Body.PreChargeRes.EVSEPresentVoltage will lead to undefined results, because just the data of the CableCheckResponse is interpreted as PreChargeResponse, which have completely different layouts. So this part needs to be removed.

EDIT2: Indeed, the cableCheck and the PreCharge are both extremely short. We see:
- In the first CableCheckResponse, the charger says ResponseCode=OK and EVSEProcessing=Finished. This is from my PoV the message "The cable check is finished and fine, just continue with the next step." So Clara immediately goes to the PreCharge.
- In the first PreChargeResponse, the charger reports EVSEPresentVoltage=202V. This seems to fulfil the "difference to the target voltage is small (seems Clara uses the wrong accu voltage 220V). And so for Clara it is fine to go to the next step, powerdelivery, and close the contactors.
So we have two interesting points: 1. The charger seems to decide that it does not need time for cable check. 2: The clara does not have the correct accu voltage during the precharging.

EDIT3:

johu wrote: ↑Mon Dec 11, 2023 9:10 am The chargers are super busy

Indeed, really crazy. Just had a look to https://moovility.me/ and when one is free, than it is occupied two minutes later:

The LIM design goes well with the Fellten button, which I also use.

https://shop.fellten.com/shop/ledrgbcb- ... ge=7#attr=

Ok, thanks for clearing that up (with the LEDs)

Now I wonder where does the voltage of 220V come from? CAN overwrites Param::batvtg with the actual value (I verified it) and hardwareInterface_getAccuVoltage() returns just that value.

EDIT: I'm now explicitly setting evsevtg=0 in CableCheck so we don't use an invalid value in PreCharge

How would you go about opening the relays less suddenly?

johu wrote: ↑Mon Dec 11, 2023 1:46 pm Now I wonder where does the voltage of 220V come from? CAN overwrites Param::batvtg with the actual value (I verified it) and hardwareInterface_getAccuVoltage() returns just that value.

I'd like to see the accu voltage in the logging. One potential root cause is, that from CAN comes bullshit. Not very likely, but who knows.
EDIT: Maybe it comes from here:

johu wrote: ↑Mon Dec 11, 2023 1:46 pm How would you go about opening the relays less suddenly?

I have no idea yet, what is the plan for this scenario. Maybe I find something in the specification, and I have the log from my Ioniq, which could help to understand in which order and with which timing the termination of the session should be done. Or maybe @CCSknowitall can shed some light on it. [Edit] Formulated the question in detailed here: viewtopic.php?p=64715#p64715

uhi22 wrote: ↑Mon Dec 11, 2023 3:29 pm EDIT: Maybe it comes from here:

Like said, I always plug in CHAdeMO first and then verify that it sets the parameters targetvtg, batvtg and soc correctly. Maybe it was a left over bogus value from CableCheck?

Just thinking in function stateFunctionWaitForCurrentDemandResponse() we could wait for evsePresentCurrent<1 before calling pev_enterState(PEV_STATE_WaitForPowerDeliveryResponse);

EDIT: Put on separate branch: https://github.com/uhi22/ccs32clara/com ... 7f146fa06c

What do you think?

The information I have leads to an other solution. Had a look to the Ioniq trace and to the specification. Added the analysis here: https://github.com/uhi22/pyPLC#detaille ... ng-session

The summary:
- PowerDeliveryReq(Stop) is fired under full current.
- The charger needs 1.5s until it confirms with PowerDeliveryRes. Maybe already here, it turns-off the current.
- The car sets stateB, and this is the "fast trigger" to the charger to turn-off the current (I have read somewhere this should be in 20ms, but cannot find this information anymore).
- Here we can simply wait for half a second (conditionless), to give the current some time to fall.
- Open the contactors.
- Wait again 0.5s to give the contactors time to move.
- Send a WeldingDetection. Depending on the charger it will wait (in example 1s, according spec below 1.5s), measure the voltage and report it back in the WeldingDetectionResponse.
- We need to repeat the WeldingDetection loop, until the voltage is not dangerous anymore.
- Then unlocking the connector and send the SessionStop.

As preparation for testing, added the feature "User presses STOP on the charger" to pyPLC and openV2Gx. In pyPLC in EvseMode, by pressing the space button it sends in the currentDemandResponse the EVSEStatusCode = Shutdown, as the Compleo (and most likely other chargers) do.

johu wrote: ↑Mon Nov 13, 2023 1:15 pm .../ or via an ESP32 module that talks CAN.
.... or also with the ESP32 gadget that will be for sale soon

Hello Johu. I have your ESP32 CAN tool and a focci board from UHI. Wifi connection works and the focci board sends via RS232. I connected the CAN lines. How do I get the parameters to the console?

Your foccci doesn't run the OI style firmware.

You need to flash the bootloader: https://github.com/jsphuebner/stm32-CAN ... s/tag/v1.0
And firmware discussed here lately (Attached)

UPDATE: file deleted. Check releases: https://github.com/uhi22/ccs32clara/releases/

uhi22 wrote: ↑Mon Dec 11, 2023 7:54 pm As preparation for testing, added the feature "User presses STOP on the charger" to pyPLC and openV2Gx. In pyPLC in EvseMode, by pressing the space button it sends in the currentDemandResponse the EVSEStatusCode = Shutdown, as the Compleo (and most likely other chargers) do.

Very good, was looking for something like this today.

I hope CCSKnowitAll can analyse that Ionity log. Will go there again maybe tonight to also record TX frames

EDIT: looked at the EXI-ed logfile myself and found DC_EVSEStatus.EVSEStatusCode sits at 1 and ReponseCode="OK" while we still get around 40A and then changes to 6 (EVSE_MalFunction) and "Failed". Current than drops over a couple of 10 messages and reaches 0.

Also the ChargeParameterDiscovery totally doesn't match what I expect. It should be 500A, 1000V and 350 kW but we get 100A, 398V and 98 kW. Is that some sort of fallback? Are we communicating an outdated protocol version or so?