Hello, MMONTERO!
I also am not familiar with reading the PLC logs but we can give it a try.
Have you tried DCFC on any other stations besides this one? What do you mean by "none of the Spark EVs that are here are able to DCFC." Are you saying you've spoken to owners in Costa Rica with DCFC and they have the same issue?
Can you take a close-up picture of your charge port, specifically at the top where the retaining lock is? I'd like to see if your vehicle has the chamfer on the walls that guide the latch into the locking well, if you will. If not, the J1772 SAE combo connector may not mate with the receptacle correctly, especially under the weight of heavy liquid-cooled cables, and you might be faced with possible continuity issues. for communication and/or power.
see https://sparkev.blogspot.com/2015/09/solution-problem-with-dc-fast-charge.html?m=1 on this issue. Although you say it DCFC'd fine in the USA, it's worth making sure.
See the following link for the J1772 SAE combo diagram:
https://weberstate.app.box.com/s/wcksjm6j80ubrqdqkqr8sy8o6vhlgr0t
Contact #3,#4, and #5 must have proper contact for connection detection in the case of contact #5, and the control pilot and 1kHz PWM signal for charge control in the case of contact #4. If there is dirt and grime built up in these connectors it could cause issues, so spraying an electronics connector-friendly aerosol cleaner would be a good idea to use for clearing away debris, or compressed air. An O2 sensor cleaner or electronics-grade isopropyl alcohol could be a substitute.
If we get the following lines:
10/12 05:05:51.428 [INFO] CAN: WF_PLUGGED_IN (1), CMD = 3
10/12 05:05:51.466 [NONE] plug trigger
LUGIN
10/12 05:05:51.487 [NONE] pwm trigger:OFFLINE
10/12 05:05:51.508 [NONE] voltage= 8.96
10/12 05:05:51.530 [NONE] dutycycle = 100
Then we can say that Earth ground and proximity detection through contact #5's pull-down resistor in the car are making contact and functioning, great. We know this because 8.96V DC (100% duty) indicates a pull-down resistance of around 2740Ω which is part of the J1772 standard. This can be confirmed in the service manuals as well as on Wikipedia here
https://en.wikipedia.org/wiki/SAE_J1772#Control_Pilot
Next, we get a PWM trigger
10/12 05:06:05.016 [NONE] plug trigger:NONE
10/12 05:06:05.037 [NONE] pwm trigger:HLC
10/12 05:06:05.058 [NONE] 10/12 05:06:05.065 [INFO] Got EVENT (0x8)
10/12 05:06:05.065 [INFO] Get IEC61851 EVENT
B_EVTMASK_IEC61851_PLUG_EVENT(8)
voltage= 8.92
10/12 05:06:05.079 [NONE] dutycycle = 6
In other words the car is sending a PWM signal to the station now and the station is loading or establishing the IEC 61851 charge protocol for what is probably a J1772 SAE combo connection and not a CHAdeMO protocol. This 61851 should be the protocol used in the USA and internationally for slow and fast AC charging with J1772, and DCFC https://en.wikipedia.org/wiki/IEC_61851
We can also see from the Tellus Power charger spec sheet matching in your photo, that IEC 61851 is being used:
http://telluspowergreen.com/wp-content/uploads/2021/08/CE_TPG_160kW_Specs.pdf
Things seem to be going fine until:
10/12 05:06:08.185 [INFO] <-- CM_SLAC_MATCH.REQ
10/12 05:06:08.092 [ERR] invalid MVFLength, will be ignored.
10/12 05:06:17.567 [ERR] timeout wait for VALIDATE.REQ or MATCH.REQ (0)
some time goes by...
10/12 05:06:31.981 [INFO] Got EVENT (0x0)
10/12 05:06:31.988 [ERR] Failed to get data ready, touch gbt27930.
And this is really weird, because GB/T 27930 is the Chinese standard for DCFC. Why is that being referred to here?
After that, it cancels the charging session and reverts contact #4 control pilot state back to an earlier state...
10/12 05:06:32.121 [NONE] data_link : bem error & bem EV error & goto GBT27930_ERROR_PROC !--BEM_ErrorCode=32,BEM_EvErrCode=0
Then things get a little crazy from here since the station is referring to GB/T 27930 and claims the control pilot state is illegal as I assume it is now speaking in CAN rather than PLC as the China GB/T standard communicates with CAN and CCS1 uses PLC.
05:06:33.262 [ERR] 10/12 05:06:33.264 [NONE] CHM cause to CEM error & goto GBT27930_ERROR_PROC
At least that is my interpretation of the logs.
Maybe the accidental switch to GB/T is due to the heavy cables pulling down on the connector in the spark's charge port receptacle, or maybe something is up with the charging station that it switches from a happy IEC61851 event to a very wrong GBT27930. It would be interesting if you could visit another DCFC station to see if this issue persists. Maybe support the connector firmly by hand to see if charging actually begins. If it does, maybe see to modifying the shape of the plastic in front of the latch.
Hope we can get more info. Please correct me on any of my interpretations if you think they are wrong.
