Close connection due to broken connection #14
Comments
|
@uhi22, I think this might be due to me using direct electrical connections (alligator clips) to the car and not a plug. |
|
You could use your standard type2 charging cable to trick the car. |
|
I will test the type2 plug with the extension cable that come with the car. Can you tell me where these values are encoded to respond to the EV, and can i change them to more closely align with the EV response.? Also, can i make the isolation status valid at this step of charge param discovery.? |
|
These values are hardcoded in the OpenV2Gx, in function encodeChargeParameterDiscoveryResponse(). You can adapt the values there, and re-compile the openV2Gx. If the values are needed to be changed dynamically, they could given via command line parameter from the pyPLC to the OpenV2Gx, similar like done for the EVRESSSOC in encodeCableCheckRequest(). |
|
In the pcap above, the car actively closes the connection after the chargeParameterDiscoveryResponse, ~30ms after it acknowledge the response. This means, it is not a broken connection, it is intentionally closed connection. Normally, according to https://github.com/uhi22/pyPLC#example-flow after the ChargeParameterDiscoveryResponse (checkpoint 545), the car would change to StateC and lock the connector. I think it is unlikely, that it comes within 30ms to the conclusion, that the connector lock failed. So more likely is, that something with the voltage/resistors on the CP line is wrong, and that the car is unhappy with this. Or the PP line. I use 1.5kOhms, which I also measured on public chargers. |
|
its not the plug unfortunately . |
|
note also, i am also using 1.5kohms on the PP to Earth. |
|
Cannot promise that the listen-mode really helps. It was intended for exactly this purpose, but not maintained since a long time. The goal is to extract the key from the slac sequence, set the key in sniffer modem, so it can decode the traffic. Would be interesting what "encrypted traffic" you see, and using which modem type. Maybe this brings the sniffing topic further... |
|
I didn't have the DC Connections shorted through from the plug to the car, just the CP, PP and Earth so naturally at some point this was going to fail. It was a pretty messy session with regard to loose connections and the like, but i believe the major part of Listen Mode is demonstrated with regard to getting through SLAC at line 138 and then seeing Encrypted Payload at lines 142, 144, 145, 147 & 148. |
|
We see parts of the SLAC sequence, this is good and bad. Ideally, we would see all the SLAC messages from both sides, but mostly we see the car (with the Panasonic MAC address). The last message of it is the SLAC_MATCH.REQ, so it wants to pair with the charger (with the DeltaEle MAC). The charger does most likely confirm with a SLAC_MATCH.CNF (Checkpoint 155 in https://github.com/uhi22/pyPLC#example-flow) . But we do not see this in the trace, most likely it is just filtered-out by the sniffer modem, because it is no broadcast, but an unicast from the DeltaEle to the Panasonic. The pitty is, that the SLAC_MATCH.CNF contains the network key (NMK), that we would need to setup in the sniffer modem, to join the AVLN. The idea is: The pyPLC takes the NMK from the SLAC_MATCH.CNF, and sends a Set_Key with this NMK to the modem. But this does not work, if there is no SLAC_MATCH.CNF received. |
|
Do you think it is possible, to make the pyPLC modem have the same mac address as the car and listen in on the conversation that way. Then as the EVSE sends to NMK, the pyPLC can listen to it and decode the rest of the conversation from the EVSE. It might miss some messages from the PEV to the EVSE, but it would be able to receive all the messages from the EVSE and then the pyPLC could be made to answer the PEV similar to the EVSE. |
|
Noting the IX3 uses DIN standard and i think it doesn't support SASchedules, can you advise an understanding of the ChargeParameterDiscoveryRes response with regard to SASchedules. or the response should be fed back as: SAScheduleList.SAScheduleTuple.array[0].SAScheduleTupleID | 0 I noted some reported pcap files from other cars gave the more detailed list with zeros, but i haven't found a wireshark trace for a DIN standard car giving this parameter in a successful run. |
|
@uhi22 @MarkG-PE My car is ix3 and I got the same error. Did you find a solution? |
|
I have tried a lot of variations in parameter settings to match a more typical charger, but no luck yet.
I am stuck on this at the moment.
On 15 Jan 2024, at 22:52, Mustafa Ağören ***@***.***> wrote:
@uhi22<https://github.com/uhi22> @MarkG-PE<https://github.com/MarkG-PE> My car is ix3 and I got the same error. Did you find a solution?
The tool output is as follows. Also, when I use the software as a simulation, DC_EVSEStatus.EVSEIselationStatus=0 is set to 0, I want to change it to 1, and I also send the EVSE maximumpowerlimit value as 10. How can I change these values in the pyPlc software?
"msgName": "ChargeParameterDiscoveryReq",
"info": "36 bytes to convert",
"error": "",
"result": "",
"schema": "DIN",
"g_errn": "0",
"header.SessionID": "0102030405060708",
"header.Notification_isUsed": "0",
"header.Signature_isUsed": "0",
"EVRequestedEnergyTransferType": "3",
"EVChargeParameter_isUsed": "0",
"DC_EVChargeParameter_isUsed": "1",
"DC_EVStatus.EVRESSSOC": "71",
"DC_EVStatus.EVReady": "0",
"EVCabinConditioning_isUsed": "1",
"EVRESSConditioning_isUsed": "1",
"EVErrorCode": "0",
"DC_EVErrorCodeText": "NO_ERROR",
"EVMaximumCurrentLimit.Value": "5000",
"EVMaximumCurrentLimit.Multiplier": "-1",
"EVMaximumCurrentLimit.Unit_isUsed": "1",
"EVMaximumCurrentLimit.Unit": "3",
"EVMaximumPowerLimit_isUsed": "1",
"EVMaximumPowerLimit.Value": "25000",
"EVMaximumPowerLimit.Multiplier": "1",
"EVMaximumPowerLimit.Unit_isUsed": "1",
"EVMaximumPowerLimit.Unit": "7",
"EVMaximumVoltageLimit.Value": "5000",
"EVMaximumVoltageLimit.Multiplier": "-1",
"EVMaximumVoltageLimit.Unit_isUsed": "1",
"EVMaximumVoltageLimit.Unit": "5",
"EVEnergyCapacity_isUsed": "0",
"EVEnergyCapacity.Value": "0",
"EVEnergyCapacity.Multiplier": "0",
"EVEnergyCapacity.Unit_isUsed": "0",
"EVEnergyCapacity.Unit": "0",
"EVEnergyRequest_isUsed": "0",
"EVEnergyRequest.Value": "0",
"EVEnergyRequest.Multiplier": "0",
"EVEnergyRequest.Unit_isUsed": "0",
"EVEnergyRequest.Unit": "0",
"FullSOC_isUsed": "1",
"FullSOC": "80",
"BulkSOC_isUsed": "1",
"BulkSOC": "80",
"debug": "Line9057Line9090Line9169Line9226Line9260Line400"
}
[127458ms] [EVSE] Received ChargeParameterDiscoveryReq. Extracting SoC parameters via DC
[127478ms] [EVSE] responding (55bytes) = 01 FE 80 01 00 00 00 2F 80 9A 02 00 40 80 C1 01 41 81 C2 10 80 00 48 00 40 00 00 C0 C3 20 04 0C 0E 01 40 60 A1 84 06 06 06 00 20 60 A1 90 02 03 03 00 50 30 30 05 10
[127481ms] [EVSE] from 4 entering 4
[SNIFFER] EXI from 49154 to 15118 (36bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 71 90 00 00 08 E0 40 61 10 4E 04 07 0A 8C 30 10 20 50 88 27 12 80 50 00
[SNIFFER] EXI from 15118 to 49154 (47bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 80 00 48 00 40 00 00 C0 C3 20 04 0C 0E 01 40 60 A1 84 06 06 06 00 20 60 A1 90 02 03 03 00 50 30 30 05 10
[127519ms] connection closed
[127538ms] [EVSE] re-initializing fsmEvse due to broken connection
[127539ms] [EVSE] re-initializing fsmEvse
[127539ms] Trying to reset the TCP socket
[127548ms] pyPlcTcpSocket listening on port 15118
[129972ms] [CONNMGR] 9 0 0 0 0 0 0 --> 5
[132758ms] [CONNMGR] 9 0 0 0 0 0 0 --> 5
[135501ms] [CONNMGR] 9 0 0 0 0 0 0 --> 5
—
Reply to this email directly, view it on GitHub<#14 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BBSLYS5GML6CCO3LWHF23CLYOUKATAVCNFSM6AAAAAA4SH5SRKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJSGAZDENBRGY>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
You wonder why what is happening? That the Zoe reaches the precharge? I guess each car manufacturer has some own understanding which plausibilizations are necessary, and which reaction is necessary. And obviously, the Zoe is happy with the data provided by pyPLC, and also others, which are documented here: https://openinverter.org/forum/viewtopic.php?t=3551 (Ioniq, MG4, Tesla, BYD atto). For the Everest project there are also "mixed" results, documented here: https://github.com/EVerest/logfiles
|
|
@uhi22 @MarkG-PE The first message part is zoe, the second message part is bmw ix3 zoe precharge, but it stays in the bmwix3 chargeparameterdiscovery part and the charging ends.The following charge parameter belongs to the discovery zoe vehicle I want to switch to the precharge section with a BMW ix3. I had the opportunity to try Togg and I stuck to the chargeparameter section with Togg. [25299ms] [EVSE] { [127457ms] [EVSE] { ZOE CHARGE PARAMETER DISCOVERY [20789ms] [EVSE] { |
|
I noted in https://github.com/EVerest/logfiles that there is a BMW IX (doesn't say IX3 but assume its the same car modem in any case), that they have charge parameter discovery request on Line 27 and then start cable check on Line 28. In the above log at line 28, it indicates the EVSE initiates to "start cable check" |
|
When I examine the logs, the charge parameter section opens the current and voltage values of the power module, and in the cablecheck section, the dc + d - terminals of the vehicle are actually energized. Could this be an error? Could it be that the device is terminating the session because it cannot see a voltage at its terminals? |
|
During the CableCheck, the charger puts voltage on the DC pins, to measure the isolation resistance. In theory, the car could check whether it sees this voltage, and could abort, if it does not see any. But this would be only relevant, if the car would come to CableCheck. My understanding is, that the BMW ix3 and the Togg both are failing during the ChargeParameterDiscovery, this is BEFORE the CableCheck is initiated. The ChargeParameterDiscovery is just a "software" step, the connector is still not locked, no voltage is applied to the DC pins. I propose three actions:
|
|
Regarding 2: The iX log from everest (https://github.com/EVerest/logfiles/tree/main/BMW/iX_fw_11_2022.64/din_spec_70121/2023-03-30T06%3A24%3A26.582Z_din_spec) contain the |
|
@uhi22 i can confirm on item 3 i have tried and tested these issues. I don't believe they are the issue. |
|
That' the comparision. Surprisingly, the everest sends a much shorter message, containing less parameters, and it has success (or we have an independent issue). I looked to logs of Ionity charger, they send all the data which also pyPLC sends, end even longer messages (68 byte ChargeParameterDiscoveryResponse). Strange, but maybe we just should try the "very short" version of everest to at least see whether it makes a difference. |
|
@uhi22 @MarkG-PE thank you answer |
|
One idea: The BMW announces EVMaximumVoltageLimit=399V. The pyPLC responds with EVSEMaximumVoltageLimit=450V. It is not clear, what is the meaning of the EVSEMaximumVoltage. My understanding is, that it is the maximum voltage (hardware limitation) which the charger can provide. But maybe it is intended as a limiting parameter, commonly agreed between car and charger, and the charger shall report the minimum of EVMaximumVoltageLimit and the chargers hardware limit. If this is the case, the car may stop with the current implementation, because it announced a max of 399V and the charger violated this by reporting 450V. Maybe the same for EVSEMaximumCurrentLimit.
|
(Quick and dirty) I copied the exi byte stream from the logs (everest html log and the textlog above in this discussion), added them into the "demo" section of my python exi connector (c0bc567) and ran this with "python exiconnector.py". The script calls the openV2Gx, which decodes the content into json. Then copied the decoder results from the command window into two separate text files, and used a diff tool to show the differences of the two files. But the handwritten command line interface of OpenV2Gx does the decoding only partially, not all fields are implemented in the decoder, only the essential ones. (I'm a little bit lazy ;-) ) So using the wireshark decoder is much better, but requires the pcap. Do you use the Wireshark decoder on Windows? I tried to understand how to install it, but did not get it. A "beginners description" would really help me. |
The maximum voltage value that BMW sent me is 500 Volts. "EVMaximumCurrentLimit.Value": "5000", |
|
And another path: The SAScheduleList indeed may be an issue. I do not have the DIN spec, but at least in the ISO it is marked as "optional", but with the explanation that omitting is only allowed during EVSEProcessing is ongoing. This would mean, that the SAScheduleList is mandatory in our case, when the EVSEProcessing is Finished. If the car strictly checks this, then it is a reason to abort. Will try to push an update. |
|
And here we go. Added encoding and some basic decoding of the SAScheduleList in ChargeParameterDiscoveryResponse. Now we have one entry in the schedule, with relative start time 0 (means immediate) and no duration (means endless, I guess). The everest and an other charger which I checked also use relative start time 0, but also set the duration to 86400 (assumingly seconds, is one day). But for the moment let's keep the things simple and let's test whether this already works. |
|
@uhi22 Thank you very much for your reply. I will update the latest version of the main_commandlineinterface.c file. I will compile OpenV2Gx with its current version and try it in the Togg tool tomorrow. Especially what should I set the maximum power value for Evse? It's currently written as 10, which is a value in kW, right? Should I update the maximum voltage and maximum current values or should I end the compilation process with the old values? |
|
The PMax scaling is not clear. The everest sends 10000, so they seem to assume Watts. But the data type is int16, so limited to 32767, which is too small for Watts. So I assumed it is kW, and have set it to 10. On a log of a public charger I saw a negative value, so it is confusing. I just assume that it does not matter. |
|
Somebody patched the PowerLimit to 20 Gigawatts. Multiplier 3 and value 20000, means 20000*10^3 :-) |
|
@uhi22 I fixed it and updated it to 20 again and today I tested it with the togg tool and went to the precharge step, thank you. |
|
Great, one issue solved. Hopefully also the BMW is happy now... |
|
@uhi22 What exactly is the difference between Din Spec 70121 and ISO 15118? Does Pyplc software support iso15118? |
|
The DIN is a older version then the ISO. Many things seem to be similar, but there are significant differences in message structures. A comparision is difficult, my only reference is the source code of the exi decoder (openV2G). |
|
@uhi22 Thank you for your answer. |
|
For the ISO15118 discussion, opened a new issue: #24 |
|
Found the tesla topic here: #9 |
|
@uhi22 After the precharge phase, to move to the power delivery and current demand phase, does the vehicle continue by measuring the dc + and dc- terminals or does it take the evsepresentvoltage value as reference? |
|
The end criteria for the precharge phase is, that the chargers voltage has reached the battery voltage with some tolerance. Basically the car has the option to use the EVSEPresentVoltage for this decision, or it can physically measure the inlet voltage, or a combination of both. |
|
@uhi22 When the vehicle sends target voltage = 450 volts and target current = 100 amps, can I charge values such as 50 volts, 100 volts, 20 amps and 50 amps to the vehicle? Do the vehicles want values close to the target voltage and target current they send? |
|
For the voltage, the charger has no choice, the actual voltage is the accu voltage, example 350V. The vehicle sends targetvoltage eg 400V, which only means that if the accu gets fuller, the charger shall not provide more than 400V. So yes, it is a normal case that the presentvoltage is below the target voltage. So basically yes, you can charge with lower values. But not with 50V or 100V, because usual cars have above 250V even battery is empty. |
|
@uhi22 The issue is now resolved for me on the BMW iX3. Just to be very transparent also, as i was downloading the pyPlc i noted in your setup instructions there was a section at the start for downloading open-plc-utils to then flash the modem. I did that also and flashed the QC7000 modem as an EVSE. I don't believe that was needed, but i did it anyway. So the raspberry pi had open-plc-utils installed, then pyPlc and openV2Gx. I noted that latest version of python was 3.11.2 but that was giving me issues with installing things on the raspberry pi, so i reverted it to version 3.9.2 and it was all very straight forward. I captured a wireshark log of it, if you would like it then i can send it to you for record. Great Job. ! |
|
@MarkG-PE Congratulations. |
|
@Mustafa19981903 , I detailed it here |
|
Assuming the original topic is clarified in the meanwhile. Closing. |
@uhi22
Brought this issue over from SmartEVSE/SmartEVSE-3#25 (comment).
I tested the latest update with change to OpenV2gx on BMW Ix3.
The connection performs the same as previous with a shutdown after charge parameter discovery.
Wireshark log attached.
120ohmPP.pcapng.txt
I note that the SOC was 80%, but given the previous 45% SOC performed the same, i think this issue is not related to the EV's SOC value.
The text was updated successfully, but these errors were encountered: