Python based Host MPU Application for the use with 8DEVICES WHITE-BEET Embedded ISO15118 Module modules to realize IEC/ISO15118 and DIN70121 conform charging communication between electric vehicles (PEV) and elevtric vehicle supply equipment (EVSE). FreeV2G can e.g. been used with a Raspberry Pi.
License: Other
There appears to be 2 issues regarding the RDY signal for SPI communication on Whitebeet EI
The first, if I am loading code via the JTAG to my host processor with the RDY pin connected, then it occasionally fails to function at all, remaining low all the time. Resetting the board and powering it off does nothing and it will not function again until it has been left powered off for some time ( over 30 minutes ).
The second
The second issue is during operation where the RDY signal stays asserted when I believe it should not. I attach a screen grab from my oscilloscope showing this operation.
D0 MISO
D4 RDY
D5 MOSI
D6 NSS
D7 CLK
As you can see, after completion of a transaction the RDY pin stays high so the next transaction begins but the header from the whitebeet is not populated in a meaningful way and then the payload is filled with 0xaa. My code checks the RDY before starting the transaction using it to throttle the SPI link, as it is already high then the CS deasserted is quite short.
Renegotiations are defined in ISO15118-2 as follow; see Annex I for sequencing information.
renegotiation - messaging for updating the agreement on the charging schedule between EV and EVSE during a V2G
Communication Session by retransmitting the parameters SASchedule and ChargingProfile
How does the V2G Service handle renegotiating charge target settings and scheduling during a charging loop? Is the host ever notified of such a renegotiation? Is the host able to initiate a renegotiation? Any details you have would be appreciated.
Hello,
We have test each module-EI and module-PI using SPI interface.
But the result shows that MISO data always return wrong data even if MOSI line matches the timing (Refer to User Guide 9.2.6).
Could you give some suggestions for this issue
[Module-EI]
Firmware version - 01_01_06
[Module-PI]
Firmware version - 01_00_04
Thanks.
JoeChen
Is there a software "test mode" that ensures the following behavior?
Such a mode would enable PSD calibration which is important for tuning SLAC attenuation parameters. Thanks for your time.
Hi,
Currently, I want to test the newest version(V.02_00_00) in module-EI.
Because there's only one module-EI board to test, I want to make sure whether the module-EI could be upgrade and downgrade if I want ?
Thanks.
BR
JoeChen
Earlier this year I inquired about TLS and you mentioned future firmware version where PnC is supported:
Hi Zach,
for ISO15118-2 EIM TLS is not mandatory and thus not supported in the current White Beet. We will release a White Beet EVSE PnC Version where TLS is supported for both PnC and EIM.
BR
Originally posted by @ttu-stx in #12 (comment)
To that end, do you know when firmware with PnC support will be available? I am eager to integrate Whitebeet into our metering platform and validate the message sequencing.
Thanks,
Zach
Das Problem bei ChargeLoopParameters ist folgendes, anbei ein Wireshark Mitschnitt (Aufgrund von Vmware tauchen meine erzeugten Pakte immer dreimal im Trace auf, so dass Paket 2-4, 5-7, 8-9 und 11-13 jeweils als ein Paket zusehen sind):
Verzögere ich die Antwort um 30ms kommt „busy try later“ direkt. Um das Try Later zu berücksichtigen sende ich anschließend 10x im 3ms Abstand die Nachricht erneut. Hilft jedoch auch nicht.
Woran habe ich nicht gedacht bzw. was mache ich falsch?
Gibt es eventuell ein Software Update? GetFirmwareVersion sagt V01_00_01
Dieses Verhalten tritt bei mir in der Simulation am Schreibtisch sowie an realer Hardware (Ladegerät + Auto) auf.
Hello,
We are planning to connect Whitebeet E1 with host controller via SPI interface. Can we enable port mirror on eth interface?
Both SPI and Eth interface will work togather? SPI as normal communication interface with host and ETH as port mirror with GreenShark when ever needed?
I have a WB-CARRIER-BOARD-EI and have successfully began charging an EV with it. I also have a WB-CARRIER-BOARD-PI. For further development and trouble shooting, I'm wondering if the I one WB module could be configured in a passive (listen-only) mode to act as sniffer of communication between existing EV-EVSE, where it does not send any messages or participate in slac negotiation, and it only acts as a bridge to pass through PLC communication? I'm aware of the port mirror mode. Can this mode be operated as described?
Hello to everyone,
I have been working on the WB-CARRIER-BOARD-EI ISO 15118(EVSE) module for a while. The vehicle I tested on is the Renault Zoe. I am running the host software on Eclipse.
Looking at the debug outputs and system steps, I reach a certain stage and then I get a "Session Stopped Received" message from the module. Every time I see the message “No EVSE ID available” on the terminal screen. In this case, what is the factor that causes the session to be terminated?
I look forward to your feedback on the matter.
The software version I use in Whitebeet: Sevenstax_WHITEBEET_ISO15118_EVSE_SW_V01_01_05
I am using VM (Ubuntu 20.04) to run FreeV2G software.
I am sharing the outputs of the study in the attachment.
A1: Wireshark capture on running test
A2: Module debug interface outputs
A3: FreeV2G terminal outputs
Hi,
I am trying Codico WB-CARRIER-BOARD-EI board for ISO15118 charging. RIght now I'm using FreeV2G python demo app from sevenstax.
I observed that the application stops at the pre-charge stage and does not send some required information to start the charging.
Could you please have a look on to the logs? (Bothe command line and serial port logs are attached.)
Firmware used in the board is Sevenstax_WHITEBEET_ISO15118_EVSE_SW_V01_01_02 (as updated in codico documentation area ).
codico_commandline_log_003.txt
codico_serial_debug_log_003.txt
-Ganesh LD
Hi,
We want to test module-PI for plug and charge and connect to module-EI (V 02_00_00 PnC version).
Has the official version for PnC of module-PI been released yet ? If not yet, do you know when firmware will be available?
Thanks for the supports.
BR
JoeChen
According to the user manual and the response code from whitebeet, it seems that there is no longer a means to start or stop the V2G service. The FreeV2G test application (tag EVSE_v2.0.0_0) still opens the session with a "stop v2g service" command, but as you can see in the Wireshark capture below, the response code from whitebeet is "Sub-ID is unknown".
Are the start/stop service commands intentionally left out? If so, how should one interact with the service? I raised a similar question a while back in issue #23, where the following guidance was provided:
V2G Service
After startup, you only need to configure the service once.
When the service is started the listen ports for V2G (TCP) and SDP (UDP) are opened.
When the service is stopped an open connection and the ports are closed.
I would recommend to start the service after plug-in and stop it after plug-out.
Can you provide new guidance for safely and reliably interacting with this service? Thanks for your help
This is a query about user manual.
It is clear that the request to stop charging session comes from EV side is handled inside EVSE and session is stopped.
It is not clear how user can manually stop the charging from EVSE.
Is it using v2gstop(), slacStop() and controlPilotStop() ?
There is API in EVSE configuration - Set Stop Charging Status - i.e. in response to the EV request to stop charging but no specific command obvious from manual, for stopping charging from EVSE.
Es kommt gelegentlich vor das eine Antwort auf eine Anfrage ausbleibt, diese aber mit der nächsten Anfrage mit beantwortet wird. Zum verdeutlich was ich meine (als zeitliche Abfolge zubetrachten):
Mir ist das beim synchronen Abfragen von Informationen aufgefallen, hier kam dann leider kein neuer Request so dass ich immer in den internen Timeout in meinem Programm gelaufen bin.
It seems that Whitebeet struggles to communicate by way of DIN SPEC 70121. We have tested with and without our power electronics system, both with and without a real EV in the mix and cannot seem to get past the ServiceDiscoveryReq/ServiceDiscoveryRes message pair. As far as I can tell from your documentation, DIN SPEC 70121:2012 is supported and ServiceDiscoveryReq is handled by the Whitebeet EI application, without a direct response required from the host. Why would Whitebeet send “ResponseCode=FAILED” in ServiceDiscoveryRes? Does the Whitebeet-EI firmware support DIN SPEC 70121?
For your reference, I have attached an archive din70121-fail.zip which contains the following:
I configure whitebeet just as done in the FreeV2G application, and this same behavior was observed running on our real system with a real EV, running on our real system with an EV emulator platform, and running with FreeV2G python application driving Whitebeet to EV emulator. The data I captured was running v01_01_02 firmware, but I have updated to v01_01_05 and observed the same results. I noticed someone with similar issues posted to the FreeV2G GitHub Issues forum and made an attempt at port mirroring for sniffing the QCA700x traffic, but the result code 0x02 indicated that the Sub ID was not recognized (see port_mirror_fail.pcapng). I eagerly await your response, and thanks again for your help.
Hi,
We are working on car charging system. We are testing on zoe vehicle. We use freeV2G. We are coming to stage of request charge loop parameters. But we are getting the warning on v2gSetDcChargeLoopParameters.
Can you look at the txt? And Why are we getting the warning?
whitebeet debug:
debug.zip
wireshark:
test.zip
In 9.1.3
Hier wird angegeben:
„When sending messages not related to any particular request by the host controller, the WHITE beet –module will set the Request ID to 0xFF.“
Stimmt allerdings nicht für das V2G Module dort ist der Broadcast 0x00.
In 10.3.1
Aufbau undeutlich, es müsste sein:
Code uint8
String Len uint8
Version string
Dies betrifft auch 10.3.2, 10.3.5 etc. alle wo eine String Variable definiert ist.
In 15.10.1 und 15.10.2
Example: Hex Wert für „2 protocols“ falsch. 0 -> 2
In 15.1.
Eventuell Type boolean hinzufügen und dass es sich um uint8 mit 1 = true und 0 = false handelt.
Bei Type exponential hinzufügen das der Exponent nicht kleiner als -3 sein darf. Zum Beispiel bei DiscoverChargeParameters->PeakCurrentRipple von 20000 * 10^-4, was laut Definition gültig sein müsste, bricht der Ladevorgang ab. Hoch -3 geht
In 15.12.10
Die Boolean Variable ob die nachfolgende Info existiert fehlt.
Hi,
Although we have done the both module-EI and module-PI with SPI interface, we're curious about the timeout issue in handleRequestChargeLoopParameters command.
[NOTICE] V2GDIN12: Message performance timeout of 75ms reached.
Could we manually set this timeout by ourselves if we need it longer than 75ms ?
If yes, where should we modify because we didn't find any parameter to set this timeout ?
Many Thanks for your support.
BR
JoeChen
Hello,
We connected module-EI and module-PI using ethernet.
[Python code]
module-EI: https://github.com/Sevenstax/FreeV2G
module-PI: https://github.com/lukhof/FreeV2G/tree/EV-support
[Situation]
Now, After module-EI send "Set_Discovery_Charge_Parameters" command, each board received "Session Stop" command from each module.
[Question]
Please refer to the attachments including Module debug, Application debug and Wireshark debug
BR
JoeChen
PEV_DBG.zip
EI_DBG.zip
Hello,
I'm using the Gloquad PLC module to interface with the Whitebeet PEV module.
Also, we are interfacing the white beet module with an Ethernet interface.
When I have started the repository I got a response up to CP voltage.
Create a new charging session
ControlPilot duty cycle: 5.5
after this message, the white beet PEV module should send SessionStarted (C0) status and SessionSetupReq to EVSE.
But when we checked its response. we are unable to get it.
I am sending the results that we got after running the code.
Python code Output messages:-------------------------------------------------------------------
Initiating framing interface
iface: enp4s0, mac: C4:93:00:21:56:64
Ev configuration: {'mac': 'C4:93:00:21:56:64', 'ev': {'evid': 'C4:93:00:21:56:64', 'protocol_count': 2,
'protocols': [0, 1], 'payment_method_count': 1, 'payment_method': [0],
'energy_transfer_mode_count': 2, 'energy_transfer_mode': [0, 4]}, 'battery': {'timestep': 10000,
'capacity': 50000, 'level': 49000, 'full_soc': 100, 'bulk_soc': 80, 'max_current': 100, 'max_power':
12000, 'max_voltage': 300, 'target_current': 40, 'target_voltage': 200, 'target_voltage_delta': 10,
'max_current_AC': 0, 'max_voltage_AC': 0, 'min_current_AC': 0}}
Set the CP mode to EV
Start the CP service
Set SLAC to EV mode
Start SLAC
Wait until an EVSE connects
cp_dc = 5.5
EVSE connected
Start SLAC matching
SLAC matching successful
Set V2G mode to EV
Set V2G configuration
Set DC charging parameters
Set AC charging parameters
Start V2G
Change State to State C
controlPilotSetResistorValue res = 0
Create new charging session
ControlPilot duty cycle: 5.5
White beet debug log
Can you please help us to rectify and solve this issue.
Wie kann ich den Ladevorgang als Ladegerät regulär beenden? Also EVSE_Shutdown und nicht EVSE_EmergencyShutdown
Versucht habe ich bisher in Set Charge Loop Parameters den Code auf "EV parameters invalid" oder "Unable to deliver EVSE parameters" zu setzen bzw. die Anfrage nicht zu beantworten (Timeout). Jeder dieser drei Abbrüche sieht aber nach EmergencyShutdown aus. Was meiner Meinung nach bei der Namensgebung der Status Codes auch richtig ist.
Ich komme darauf das es EmergencyShutdown sein müsste weil ich kein Shutdown Request vom Auto im Trace sehe. Von Charge Loop Parameter geht es direkt zum CP State B.
Die Fahrzeuge VW eUp und Hyundai Kona melden diesen Abbruch nicht als Fehler zum Anwender. Der BMW i3 regagiert hierauf Rot blinkend und gibt mehrere Warntöne von sich.
Gibt es noch eine Möglichkeit? Ein Stop Knopf an einer Ladesäule ist ja vermutlich nicht unüblich und sollte ja nicht zu einer Fehlersignalisierung beim Anwender führen.
From ISO 15118-2 section 8.4.1, we have the following:
In ISO 15118 a V2G Communication Session pausing is controlled by the parameter ChargingSession in SessionStopReq with its values “Terminate” and ”Pausing”. The parameter can be used independently from the charging profile. This means that an EV can initiate a pausing at any time after sending PowerDeliveryReq with ChargeProgress equal to 'Stop' and according to [V2G2-739].
How can EVSE know that a charging session is being paused by EV? Here's my best guess at how this might go down:
0x8b from WB0x800x810x8cIf the above sequence is what is to be expected from WB, the host has no way to positively identify that we are "paused". One could imagine a scenario where host receives Request Stop Charging 0x8b from WB, and we have loss of communication for some reason. There's really no way to differentiate between a paused V2G session and loss of comm. Is it possible that WB provide a field within a message to indicate what the standard refers to as the parameter ChargingSession ? Perhaps a new message pair could be added to EVSE host<==>WB side that mirrors SessionStop.Req/Res on the WB<==>EV side.
In particular, keep Session Stopped 0x81 to indicate that the TCP link is actually down, but add something like Request Session Stop 0x8d where we have a field called ChargeSession that takes on the values [ Terminate 0x00 | Pause 0x01 ] so that EVSE host can understand what's going on.
0x81.0x80.Hi @jpo-stx,
I'm trying to adapt the host controller SW to the new version of WB V.02_00_00 (EVSE). Most of the V2G Service commands are changed or new, so I have to rewrite the charging process almost entirely.
Again many details are missing from the user manual, therefore I need some information about how the new introduced V2G commands are working:
Due to the above issues (at the first test), I am stuck and cannot continue to implement the new version. Please help!
Thank You,
Ionel Fratila
Hello ,
I'm beginning adventure with White Beet and at the start I have issue with simple communication over SPI.
I have evalboard WB-CARRIER-BOARD-PI(EV and ISO15118) and I configured him to SPI interface, power supply over USB.
After sending simple SPI transfer, device doesn't react. What I found on user Manual, line after chip select to low, should set line RxReady also to low and in during transfer of data on MOSI line, on MISO we should also see some transfer of data. I attached images and logs(Saleae) from this situation. In my case is completly silence
After reset I have such traces and it is all:
APPLICATION:<\n>
Name: ISO15118 (EV)<\n>
Version: V01_00_03<\n>
Target: WHITE-BEET<\n>
CPU: STM32F745<\n>
<\n>
PRODUCT VERSION:<\n>
String: SEVENSTAX_LIB_V_10_02_01<\n>
Hex: 0x000a0201<\n>
Dec: 100201<\n>
<\n>
Hostcontroller Interface: SPI!<\n>
<\n>
APPLICATION RUNNING ...<\n>
[ 0.004] [NOTICE] APL-MAIN: BOOT-CFG: Boot QCA7005 firmware from host<\n>
[ 0.005] [NOTICE] APL-MAIN: BOOT-CFG: FW2<\n>
[ 0.005] [NOTICE] APL-MAIN: BOOT-CFG: Module configured to EV<\n>
[ 0.006] [NOTICE] Q7KCOM: Boot from host selected<\n>
[ 0.007] [NOTICE] SLAC: stxSLAC_Init()<\n>
[ 0.008] [NOTICE] APL-ETH: MAC of NIC[0]:<9>c4:93:00:21:55:de<\n>
[ 5.286] [NOTICE] APL-ETH: MAC of NIC[1]:<9>c4:93:00:21:55:dd<\n>
[ 5.292] [NOTICE] V2GCPS: stxV2GCPS_RegisterCallback()<\n>
[ 5.502] [NOTICE] Q7K: QCA7K_SPI_REG_SIGNATURE = 0xAA55<\n>
[ 5.502] [NOTICE] Q7K: ==
=======================================<\n>
[ 5.503] [NOTICE] Q7K: QCA700x is READY<\n>
[ 5.504] [NOTICE] Q7K: =========================================<\n>
[ 5.504] [NOTICE] Q7KCOM: Reset QCA700x<\n>
[ 5.506] [NOTICE] Q7K: =========================================<\n>
[ 5.507] [NOTICE] Q7K: CPU ON RECEIVED<\n>
[ 5.507] [NOTICE] Q7K: =========================================<\n>
[ 5.508] [NOTICE] Q7K: QCA7K_SPI_REG_SIGNATURE = 0xAA55<\n>
[ 5.509] [NOTICE] Q7K: =========================================<\n>
[ 5.510] [NOTICE] Q7K: QCA700x is READY<\n>
[ 5.510] [NOTICE] Q7K: =========================================<\n>
[ 6.348] [NOTICE] Q7KCOM: ======================================= <\n>
[ 6.348] [NOTICE] Q7KCOM: FW and PIB was loaded successful <\n>
[ 6.863] [NOTICE] Q7K: =========================================<\n>
[ 6.864] [NOTICE] Q7K: CPU ON RECEIVED<\n>
[ 6.865] [NOTICE] Q7K: =========================================<\n>
[ 6.865] [NOTICE] Q7KCOM: ======================================= <\n>
[ 6.866] [NOTICE] Q7KCOM: BOOT FROM HOST READY <\n>
[ 6.867] [NOTICE] Q7K: QCA7K_SPI_REG_SIGNATURE = 0xAA55<\n>
[ 6.868] [NOTICE] Q7K: =========================================<\n>
[ 6.868] [NOTICE] Q7K: QCA700x is READY<\n>
[ 6.869] [NOTICE] Q7K: ===============
==========================<\n>
[ 7.035] [NOTICE] Q7KCOM: Own QCA7K MAC = C4:93:00:21:55:D
I have found that tx_ready pin deasserts once during the first transaction and then remains asserted constantly after that.
This may be because there is always one transaction outstanding due to the way SPI works. Is there a "null" transaction that will not result in a response? Even the ping requires another transaction to get the ping return.
I have implemented the suggested solution from my previous ticket #29 .
This has led to a new problem in that after a few transactions the whitebeet returns error headers, instead of the normal 0x5555 they are 0xaaaa. The second header appears to be correct as it has a length included which the actual header does not.
Here is the SPI listing
As you can see the transaction starting at line 21 has whitebeet returning incorrect headers.
I have lengthened the pause time to 500ms and the problem takes a couple of more transactions to occur but it still occurs.
I have tried terminating the host transaction with a 0xc1 but the behaviour is the same.
Hello All,
I have been working on the WB-CARRIER-BOARD-EI ISO 15118(EVSE) module for a while. The vehicle I tested on is Hyundai Kona. On running the Application.py file and observing the logs the session stops after "SET EVSE ID". The format is "0" so I set the EVSE ID in "+49XXXXXX*XXX" format as mentioned in the Sevenstax Usermanual.
This seemed similar to issue #16 so I tried by changing Energy Transfer modes. I also tried to set EVSE ID as 0 which also did not help in the process. I had not faced any such issues while testing with Tata Nexon.
Firmware version used: Sevenstax_WHITEBEET_ISO15118_EVSE_EIM_V01_01_06
Code used is the latest FreeV2G code
I have attached screenshots for the log observations -
Initial Log
When EVSE ID was set to "0"
When Energy Transfer Mode was set to "1"
When Transfer modes were set as [0,1,2,3]
Hello,
In during implementation of post charging phase, I found, that WhiteBeet(EV) doesn't send notfication(0xCC) to host.
Could You check, what can be reason?
Traces from WhiteBeet:
APPLICATION:
Name: ISO15118 (EV)
Version: V01_00_04
Target: WHITE-BEET
CPU: STM32F745
PRODUCT VERSION:
String: SEVENSTAX_LIB_V_10_02_01
Hex: 0x000a0201
Dec: 100201
Hostcontroller Interface: SPI!
APPLICATION RUNNING ...
[ 0.005] [NOTICE] APL-MAIN: BOOT-CFG: Boot QCA7005 firmware from host
[ 0.005] [NOTICE] APL-MAIN: BOOT-CFG: FW2
[ 0.006] [NOTICE] APL-MAIN: BOOT-CFG: Module configured to EV
[ 0.008] [NOTICE] Q7KCOM: Boot from host selected
[ 0.011] [NOTICE] SLAC: stxSLAC_Init()
[ 0.013] [NOTICE] APL-ETH: MAC of NIC[0]: c4:93:00:21:55:de
[ 5.291] [NOTICE] APL-ETH: MAC of NIC[1]: c4:93:00:21:55:dd
[ 5.297] [NOTICE] V2GCPS: stxV2GCPS_RegisterCallback()
[ 5.510] [NOTICE] Q7K: QCA7K_SPI_REG_SIGNATURE = 0xAA55
[ 5.511] [NOTICE] Q7K: =========================================
[ 5.511] [NOTICE] Q7K: QCA700x is READY
[ 5.512] [NOTICE] Q7K: =========================================
[ 5.513] [NOTICE] Q7KCOM: Reset QCA700x
[ 5.515] [NOTICE] Q7K: =========================================
[ 5.515] [NOTICE] Q7K: CPU ON RECEIVED
[ 5.516] [NOTICE] Q7K: =========================================
[ 5.517] [NOTICE] Q7K: QCA7K_SPI_REG_SIGNATURE = 0xAA55
[ 5.518] [NOTICE] Q7K: =========================================
[ 5.519] [NOTICE] Q7K: QCA700x is READY
[ 5.519] [NOTICE] Q7K: =========================================
[ 6.385] [NOTICE] Q7KCOM: =======================================
[ 6.386] [NOTICE] Q7KCOM: FW and PIB was loaded successful
[ 6.901] [NOTICE] Q7K: =========================================
[ 6.901] [NOTICE] Q7K: CPU ON RECEIVED
[ 6.902] [NOTICE] Q7K: =========================================
[ 6.903] [NOTICE] Q7KCOM: =======================================
[ 6.903] [NOTICE] Q7KCOM: BOOT FROM HOST READY
[ 6.905] [NOTICE] Q7K: QCA7K_SPI_REG_SIGNATURE = 0xAA55
[ 6.905] [NOTICE] Q7K: =========================================
[ 6.906] [NOTICE] Q7K: QCA700x is READY
[ 6.907] [NOTICE] Q7K: =========================================
[ 7.071] [NOTICE] Q7KCOM: Own QCA7K MAC = C4:93:00:21:55:DF
[ 8.527] [NOTICE] SLAC: stxSLAC_Start()
[ 21.013] [NOTICE] V2GCPS: Changed Max Current EV State (1)
[ 21.013] [NOTICE] V2GCPS: stxXBAR_V2GCPS_NotifyHandler()
[ 21.014] [NOTICE] V2GCPS: stxXBAR_V2GCPS_NotifyHandler()
[ 21.015] [NOTICE] V2GCPS: # V2GCPS_INFOTYPE_CP_DUTY_CYCLE
[ 21.015] [NOTICE] V2GCPS: Duty cycle is 56 permill
[ 21.081] [NOTICE] SLAC: stxSLAC_StartSlacMatchingProcess()
[ 21.274] [WARN ] SLAC: # SLAC_STATE_RECV_SLAC_PARAM_CNF - TIMEOUT
[ 24.481] [NOTICE] Q7KCOM: PIB File was updated => Download PIB without reset
[ 27.230] [NOTICE] Q7KCOM: PIB File was updated => Download PIB without reset
[ 27.409] [NOTICE] APL-ETH: Got link:
[ 27.410] [NOTICE] APL-ETH: Interface: eth0
[ 27.410] [NOTICE] APL-ETH: MAC: C4:93:00:21:55:DE
[ 27.411] [NOTICE] SLACSERV: # NC_SLAC_SUCCESS
[ 27.717] [NOTICE] V2GSVC: Starting in EV mode.
[ 29.119] [NOTICE] APL-MAIN:
[ 29.119] [NOTICE] APL-MAIN: =============================
[ 29.120] [NOTICE] APL-MAIN: NEW LAN CONFIGURATION (IPv6):
[ 29.120] [NOTICE] APL-MAIN: for IP Config handle [fe00]
[ 29.121] [NOTICE] APL-MAIN: IPv6 Addresses:
[ 29.122] [NOTICE] APL-MAIN: Link-Local: fe80:0:0:0 : c693:ff:fe21:55de
[ 29.123] [NOTICE] APL-MAIN: Local: 0:0:0:0 : 0:0:0:0
[ 29.123] [NOTICE] APL-MAIN: DNS1: 2001:4860:4860:0 : 0:0:0:8888
[ 29.124] [NOTICE] APL-MAIN: DNS2: fd00:0:0:0 : be05:43ff:fe44:5280
[ 29.125] [NOTICE] APL-MAIN: =============================
[ 29.126] [NOTICE] APL-MAIN:
[ 29.377] [WARN ] V2GSVC: Security options satisfied, connect!
[ 29.383] [NOTICE] V2GSVC: TCP: Connected to server without TLS
[ 31.311] [NOTICE] V2GAPP: Received event 'Session started'
[ 31.883] [NOTICE] V2GAPP: Received event 'Schedule received'
[ 31.884] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 31.885] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 31.886] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 31.887] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 31.888] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 31.889] [NOTICE] V2GAPP: Received event 'Ready for cable check'
[ 32.340] [NOTICE] V2GAPP: Received event 'Cable check finished'
[ 32.340] [NOTICE] V2GAPP: Received event 'Ready for pre charging'
[ 32.746] [NOTICE] V2GAPP: Received event 'Ready for charging'
[ 33.151] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 33.152] [NOTICE] V2GAPP: Received event 'Ready for charging'
[ 33.556] [NOTICE] V2GAPP: Received event 'Charging started'
[ 33.711] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 33.712] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 33.713] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 33.714] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 33.866] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 34.021] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 34.176] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 34.331] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 34.486] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 34.641] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 34.797] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 34.951] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 35.106] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 35.262] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 35.418] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 35.572] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 35.726] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 35.881] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 36.037] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 36.193] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 36.348] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 36.503] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 36.659] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 36.814] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 36.969] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 37.124] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 37.127] [WARN ] APL-ETH: # Unhandled Ethernet notifycode 365
[ 37.279] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 37.435] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 37.591] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 37.746] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 37.901] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 38.056] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 38.211] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
PLC sniffs
Hello
I am trying to test whitebeet dev board with Tesla Model 3. on the v2g stage I cant pass evse id requested part.
I am trying with raspberry pi. Output firstly, said "No EVSE ID available" and I added this line
if message['format'] == 0:
evseid = "+90123456*789"
in this case said session stopped after send evseid here you can see output message. also I added attachment output message with serial debug messages.
Here I share output both network and serial debug. Where am I doing wrong?
Welcome to Codico Whitebeet EVSE reference implementation
Initiating framing interface
iface: eth0, mac: C4:93:00:21:4E:96
Set the CP mode to EVSE
Set the CP duty cycle to 100%
Start the CP service
Start SLAC in EVSE mode
Wait until an EV connects
EV connected
Start SLAC matching
Set duty cycle to 5%
SLAC matching successful
Set V2G mode to EVSE
Start V2G
128 b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x06\x98\xed\\x8a\x0b\xdb'
"Session started" received
Protocol: 0
Session ID: 0000000000000000
EVCC ID: 98ed5c8a0bdb
130 b'\x00\x00\x06\x08\x00'
"Request EVSE ID" received
Set EVSE ID: +90123456*789
129 b''
"Session stopped" received
EVSE loop finished
Goodbye!
[ 1255.341] [NOTICE] SLAC: stxSLAC_Start()
[ 1255.376] [NOTICE] V2GCPS: Change State from B to A
[ 1255.380] [NOTICE] V2GCPS: stxXBAR_V2GCPS_NotifyHandler()
[ 1255.386] [NOTICE] V2GCPS: # V2GCPS_INFOTYPE_CP_STATE
[ 1255.391] [NOTICE] V2GCPS: STATE A
[ 1257.346] [NOTICE] APL-ETH: Lost link:
[ 1257.349] [NOTICE] APL-ETH: Interface: eth0
[ 1257.354] [NOTICE] APL-ETH: MAC: C4:93:00:21:4E:97
[ 1257.360] [NOTICE] APL-MAIN:
[ 1257.362] [NOTICE] APL-MAIN: =============================
[ 1257.368] [NOTICE] APL-MAIN: LAN CONFIGURATION DELETED:
[ 1257.373] [NOTICE] APL-MAIN: for IP Config handle [fe00]
[ 1257.378] [NOTICE] APL-MAIN: IPv6 Addresses:
[ 1257.382] [NOTICE] APL-MAIN: Link-Local: 0:0:0:0 : 0:0:0:0
[ 1257.388] [NOTICE] APL-MAIN: Local: 0:0:0:0 : 0:0:0:0
[ 1257.393] [NOTICE] APL-MAIN: DNS1: 0:0:0:0 : 0:0:0:0
[ 1257.399] [NOTICE] APL-MAIN: DNS2: 0:0:0:0 : 0:0:0:0
[ 1257.404] [NOTICE] APL-MAIN: =============================
[ 1257.409] [NOTICE] APL-MAIN:
[ 1257.412] [NOTICE] Q7KCOM: PIB File was updated => Download PIB without reset
[ 1259.356] [NOTICE] APL-ETH: Got link:
[ 1259.360] [NOTICE] APL-ETH: Interface: eth0
[ 1259.364] [NOTICE] APL-ETH: MAC: C4:93:00:21:4E:97
[ 1261.543] [NOTICE] V2GCPS: Change State from A to B
[ 1261.547] [NOTICE] V2GCPS: stxXBAR_V2GCPS_NotifyHandler()
[ 1261.553] [NOTICE] V2GCPS: # V2GCPS_INFOTYPE_CP_STATE
[ 1261.558] [NOTICE] V2GCPS: STATE B
[ 1261.720] [NOTICE] SLAC: stxSLAC_StartSlacMatchingProcess()
[ 1262.190] [WARN ] SLAC: Unexpected message!
[ 1262.214] [WARN ] SLAC: Unexpected message!
[ 1263.571] [NOTICE] Q7KCOM: PIB File was updated => Download PIB without reset
[ 1263.774] [NOTICE] SLACSERV: # NC_SLAC_SUCCESS
[ 1264.361] [NOTICE] V2GSVC: Starting in EVSE mode.
[ 1264.366] [NOTICE] V2GSVC: TCP: Listen on port 58550 for non-TLS
[ 1264.586] [NOTICE] V2GSVC: TCP: A client connected on the TCP port
[ 1264.593] [NOTICE] V2GDIN12: EV requested to start session.
[ 1268.524] [NOTICE] APL-MAIN:
[ 1268.527] [NOTICE] APL-MAIN: =============================
[ 1268.532] [NOTICE] APL-MAIN: NEW LAN CONFIGURATION (IPv6):
[ 1268.537] [NOTICE] APL-MAIN: for IP Config handle [fe00]
[ 1268.543] [NOTICE] APL-MAIN: IPv6 Addresses:
[ 1268.547] [NOTICE] APL-MAIN: Link-Local: fe80:0:0:0 : c693:ff:fe21:4e97
[ 1268.554] [NOTICE] APL-MAIN: Local: 0:0:0:0 : 0:0:0:0
[ 1268.559] [NOTICE] APL-MAIN: DNS1: 2001:4860:4860:0 : 0:0:0:8888
[ 1268.565] [NOTICE] APL-MAIN: DNS2: fd00:0:0:0 : be05:43ff:fe44:5280
[ 1268.572] [NOTICE] APL-MAIN: =============================
[ 1268.577] [NOTICE] APL-MAIN:
[ 1268.742] [NOTICE] V2GSVC: TCP: Client disconnected or connection closed by server
[ 1268.750] [NOTICE] V2GSVC: TCP: Listen on port 58550 for non-TLS
[ 1268.791] [NOTICE] V2GSVC: TCP: Client disconnected or connection closed by server
[ 1269.010] [NOTICE] SLAC: stxSLAC_Stop()
When running ISO15118 firmware as EVSE on a whitebeet carrier board, I observe seemingly random fluctuations in CP state. I made note of this with an engineer from CODICO several months ago. Since then, as a result of our communications, there was a new firmware release to address this issue. However, I am still observing the same behavior. Below are some facts regarding my setup followed by questions/remarks.
[ 7030.898] [ERROR ] V2GCPS: UNKNOWN - 4648
The definition for "Request Start Charging" does not match the example provided. I have outlined the problems below.
The table that associates the field name to the data type to a description of the field contains fewer entries than the example shows. For example, the field that follows "Start of profile from now on in seconds" is labeled "duration of this entry". I have to assume "start of the profile from now on in seconds" is what the table refers to as "Start" (uint32), but according to the next line in the table we would expect the next entry to be "Power". However, in the description for "Charging profile entries count" a parameter named "Interval" is invoked, yet not discussed elsewhere in the table. On the other hand, going back to the example, we have "Duration of this entry" which seems to logically match the "Interval" field. This "Interval" field has been a component of the schedule tuple provided by the secondary actor (SA), so it makes sense to me that this field would still be included. In previous versions of this message, we had an 64-bit field called "time anchor" that seems to be similar in kind to the new field "Start" except half the size.
"Schedule tuple ID" is advertised as a signed 16-bit integer, but appears to be 8 bits in the example.
a. Also, why is this field treated as signed number? Should we expect negative tuple IDs?
"Charging profile entries count" is advertised as an unsigned 8-bit integer, but appears to be 16 bits in the example.
Perhaps I am not being clear, but I am quite confused by this particular change. Ultimately all I want to know is how to correctly parse the message, and how to construct an appropriate response. I have attached a screenshot of the usermanual with some of my notes as a visual aid to provide more clarity. Thanks for your time.
If one inspects the example for the Set Schedules command, it appears that it does not include the schedule ID as part of the payload (see image 1 below). However, in the Request Start Charging command, we see the parameter schedule ID appear again, only this time the data type is different: we have uint8 instead of uint16 (see image 2 below). What should I expect from each command?
In user manual r2.2, a command was added for joining a HPGP logical network using network id (NID) and network management key (NMK).
How does the host obtain NID and NMK?
What is the intended use case for such a command?
I have a strange problem related to White-Beet-EI module, not the FreeV2G software, but the guys from CODICO advised me to put this issue here.
I'm using a WB-EI module which I updated to V01_01_02 version to interface the CCS EV with a host controller for which I'm developing the firmware.
I have started by sending the commands for initialization and start of the CP, SLAC and V2G services (the others do not seem to be useful for running the EV charging process). When connecting the EV, all the messages seemed to be transmitted as in the user manual (with some minor differences, but the message sequence was OK), I was receiving the SLAC successful message (ModID=0x28, SubID=0x80) and then the V2G Session Started message (ModID=0x27, SubID=0x80), followed by the request for EVSE ID with Format=1 (ModID=0x27, SubID=0x82).
-Here I tried several times to find the correct format for EVSE ID, because the information in the manual and even in IEC 15118 / DIN SPEC 70121 or DIN SPEC 91286 is very brief and unclear, in my opinion. At the Set EVSE ID command (ModID=0x27, SubID=0x68) I always received the result code = 0x04 and unfortunately I could not test this command except by resuming the connection with the car each time, otherwise WB does not accept the command (result code 0x05). Each time, the communication with the car was interrupted after the Session Setup Response message (Failed).
-At one point during these tests, for no apparent reason, I started not to receive the EVSE ID Request message (ModID=0x27, SubID=0x82) from the WB module. Now I’m receiving each time Session Stopped message (ModID=0x27, SubID=0x81) directly after Session Started (ModID=0x27, SubID=0x80). Between these two messages I only receive some messages with type 0x86DD (IPv6 messages). I wonder if it is normal for WB to send these messages to the Host controller. On the CCS analyzer I can see that EV is sending the Session Setup Request message with Session ID other than 0 (I think it is the same value all the time), which is contrary to the standard CEI15118 / DIN SPEC 70121 - the EV has just been connected. Moreover, from this moment on, WB module no longer communicates with the host controller, nor does it even send CP status change messages when the EV is disconnected, only after the Power-On reset. That's why I suspect that WB sends certain information to the EV, which causes it to send a session ID other than 0 in the Session Setup Request message.
I’m using for test one Skoda CitiGo, but this behavior of the WB module is the same also with another car. With both cars, charging starts normally at another charging station.
Please tell me if you have any idea regarding this strange behavior and if the WB module configuration can somehow be reset to default initial values.
Thank You.
sind die Pakete doppelt in der "requirements.txt" ?
ich musste Sie löschen um das Update durchzuführen.
Als Nicht-Python Programmierer dürfte der Abschnitt auch etwas ausführlicher ausfallen.
I have several questions about the V2G service API for the new plug-and-charge firmware. As others in this forum have pointed out, the V2G service has undergone a major overhaul. Migrating to this new update will come at a great cost time-wise, so to mitigate the inherent risk, I would appreciate your insight into the new design. I have several disjoint questions regarding the new FW, which I will try to keep organized within this thread. Please consider these questions a follow-on to issue #49.
There are two distinct though very similar EVSE configuration commands regarding DC charging parameters. Can you please illustrate the differences between them, describe when to use one versus when to use the other?
27 6227 63Speaking of 27 63 Update DC Charging Parameters, I am confused about when the host should send this command to WB. Usage is not explicitly prescribed in the user manual. The only context for using the command is in section 21.8. It looks like once Cable Check is requested by the vehicle, host should periodically send this message every x milliseconds until the end of the session.
x determined?
V2G_EVCC_Msg_Timeout interval is 250ms for main charge loopI have driven the new firmware with your FreeV2G application. After combing thru the ethernet frames, I notice your usage of the command V2G: Update DC Charging Parameters 27 63 actually first occurs before Cable Check is requested (see line 352 in wireshark log1). It looks as though this is sent in response to certain messages sent by EV, but is repeated at somewhat irregular intervals (sometimes as short as 3ms apart if wireshark is to be believed). To put my cards on the table, here's my best guess at when this command should be used, please tell me what you think:
27 85 DC Charging Parameters Changed27 63 (i.e. Isolation Level, Present Voltage/Current, EVSE Status Code, Vmax, Pmax, Imax)27 70 was sent 2x by host with valid response code 00 from WB (see lines 382-385 in wireshark log1). Is there a reason for this? It seemed like a command that would only need to be sent once if the response code was OK.27 8e with decimal error code 23. Only error codes 0-22 are defined in the user manual. Can you tell me what this means? Consider the following sequence (~line 377 in log1)
27 88 - Precharge started27 63 - Update d.c. charge parameters27 8c - Session stopped (terminate)27 8e - Session error (errcode=0x17)Thats all for now, thanks for your time
Requirements for loss of communication with respect to SLAC and CP are defined in ISO 15118-3 in section 7.5. I am wondering if these requirements are satisfied internally by Whitebeet or if it is up to the host? Here's an example of what I'm talking about:
Thoughts?
Hello,
I'm using evalboard ISO 15118 EV and SW V_01_00_04. and SPI interface.
I started V2G session (Chapter 19.9.2 Start Session) and I observed that WhiteBeet doesn't send extra two status messages.
Additionally WhiteBeet should send also Cable Check Ready . I'm noticing only positive respond "Session Started" and it is all.
In logs from device I see such events, but it looks, that this events are not forward to SPI interface.
I did small experiment and I sent "Start Cable Check" but WhiteBeet nothing answer.
Traces from WhiteBeet
APPLICATION:
Name: ISO15118 (EV)
Version: V01_00_04
Target: WHITE-BEET
CPU: STM32F745
PRODUCT VERSION:
String: SEVENSTAX_LIB_V_10_02_01
Hex: 0x000a0201
Dec: 100201
Hostcontroller Interface: SPI!
APPLICATION RUNNING ...
[ 0.005] [NOTICE] APL-MAIN: BOOT-CFG: Boot QCA7005 firmware from host
[ 0.005] [NOTICE] APL-MAIN: BOOT-CFG: FW2
[ 0.006] [NOTICE] APL-MAIN: BOOT-CFG: Module configured to EV
[ 0.008] [NOTICE] Q7KCOM: Boot from host selected
[ 0.012] [NOTICE] SLAC: stxSLAC_Init()
[ 0.013] [NOTICE] APL-ETH: MAC of NIC[0]: c4:93:00:21:55:de
[ 5.291] [NOTICE] APL-ETH: MAC of NIC[1]: c4:93:00:21:55:dd
[ 5.297] [NOTICE] V2GCPS: stxV2GCPS_RegisterCallback()
[ 5.510] [NOTICE] Q7K: QCA7K_SPI_REG_SIGNATURE = 0xAA55
[ 5.511] [NOTICE] Q7K: =========================================
[ 5.511] [NOTICE] Q7K: QCA700x is READY
[ 5.512] [NOTICE] Q7K: =========================================
[ 5.513] [NOTICE] Q7KCOM: Reset QCA700x
[ 5.515] [NOTICE] Q7K: =========================================
[ 5.515] [NOTICE] Q7K: CPU ON RECEIVED
[ 5.516] [NOTICE] Q7K: =========================================
[ 5.517] [NOTICE] Q7K: QCA7K_SPI_REG_SIGNATURE = 0xAA55
[ 5.518] [NOTICE] Q7K: =========================================
[ 5.519] [NOTICE] Q7K: QCA700x is READY
[ 5.519] [NOTICE] Q7K: =========================================
[ 6.385] [NOTICE] Q7KCOM: =======================================
[ 6.386] [NOTICE] Q7KCOM: FW and PIB was loaded successful
[ 6.901] [NOTICE] Q7K: =========================================
[ 6.901] [NOTICE] Q7K: CPU ON RECEIVED
[ 6.902] [NOTICE] Q7K: =========================================
[ 6.903] [NOTICE] Q7KCOM: =======================================
[ 6.903] [NOTICE] Q7KCOM: BOOT FROM HOST READY
[ 6.905] [NOTICE] Q7K: QCA7K_SPI_REG_SIGNATURE = 0xAA55
[ 6.905] [NOTICE] Q7K: =========================================
[ 6.906] [NOTICE] Q7K: QCA700x is READY
[ 6.907] [NOTICE] Q7K: =========================================
[ 7.073] [NOTICE] Q7KCOM: Own QCA7K MAC = C4:93:00:21:55:DF
[ 18.290] [NOTICE] SLAC: stxSLAC_Start()
[ 29.428] [NOTICE] V2GCPS: Changed Max Current EV State (1)
[ 29.428] [NOTICE] V2GCPS: stxXBAR_V2GCPS_NotifyHandler()
[ 29.429] [NOTICE] V2GCPS: stxXBAR_V2GCPS_NotifyHandler()
[ 29.430] [NOTICE] V2GCPS: # V2GCPS_INFOTYPE_CP_DUTY_CYCLE
[ 29.430] [NOTICE] V2GCPS: Duty cycle is 56 permill
[ 29.495] [NOTICE] SLAC: stxSLAC_StartSlacMatchingProcess()
[ 29.602] [WARN ] SLAC: # SLAC_STATE_RECV_SLAC_PARAM_CNF - TIMEOUT
[ 32.809] [NOTICE] Q7KCOM: PIB File was updated => Download PIB without reset
[ 35.628] [NOTICE] Q7KCOM: PIB File was updated => Download PIB without reset
[ 35.652] [NOTICE] APL-ETH: Got link:
[ 35.653] [NOTICE] APL-ETH: Interface: eth0
[ 35.654] [NOTICE] APL-ETH: MAC: C4:93:00:21:55:DE
[ 35.654] [NOTICE] SLACSERV: # NC_SLAC_SUCCESS
[ 35.973] [NOTICE] V2GSVC: Starting in EV mode.
[ 37.350] [NOTICE] APL-MAIN:
[ 37.350] [NOTICE] APL-MAIN: =============================
[ 37.351] [NOTICE] APL-MAIN: NEW LAN CONFIGURATION (IPv6):
[ 37.351] [NOTICE] APL-MAIN: for IP Config handle [fe00]
[ 37.352] [NOTICE] APL-MAIN: IPv6 Addresses:
[ 37.353] [NOTICE] APL-MAIN: Link-Local: fe80:0:0:0 : c693:ff:fe21:55de
[ 37.354] [NOTICE] APL-MAIN: Local: 0:0:0:0 : 0:0:0:0
[ 37.354] [NOTICE] APL-MAIN: DNS1: 2001:4860:4860:0 : 0:0:0:8888
[ 37.355] [NOTICE] APL-MAIN: DNS2: fd00:0:0:0 : be05:43ff:fe44:5280
[ 37.356] [NOTICE] APL-MAIN: =============================
[ 37.357] [NOTICE] APL-MAIN:
[ 37.608] [WARN ] V2GSVC: Security options satisfied, connect!
[ 37.615] [NOTICE] V2GSVC: TCP: Connected to server without TLS
[ 39.542] [NOTICE] V2GAPP: Received event 'Session started'
[ 40.355] [NOTICE] V2GAPP: Received event 'Schedule received'
[ 40.356] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 40.357] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 40.358] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 40.359] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
Last sniffs from V2G session
**1. EV request **
[-] 10.694932 Eth 1 Charge Parameter Discovery Request Rx v2g FE80::C693:FF:FE21:55DE FE80::11 57843 51111 TP version: 1, Session ID: 17608499347531563676 52
| Session ID 17608499347531563676
[-] DC_EVChargeParameter
[-] DC_EVStatus
| EVReady TRUE
| EVErrorCode NO_ERROR
| EVRESSSOC 50 %
| EVMaximumCurrentLimit 50 A
| EVMaximumPowerLimit 20000 W
| EVMaximumVoltageLimit 400 V
| EVEnergyCapacity 50000 Wh
| EVEnergyRequest 25000 Wh
| FullSOC 100 %
| BulkSOC 80 %
| RequestedEnergyTransferMode DC_core
| MaxEntriesSAScheduleTuple 5
2. EVSE response
[-] 10.995293 Eth 1 Charge Parameter Discovery Response (OK) Tx v2g FE80::11 FE80::C693:FF:FE21:55DE 51111 57843 TP version: 1, Session ID: 17608499347531563676 253
| Session ID 17608499347531563676
| ResponseCode OK
| EVSEProcessing Finished
[-] SAScheduleList
[+] SAScheduleTuple (0)
[+] SAScheduleTuple (1)
[-] DC_EVSEChargeParameter
[-] DC_EVSEStatus
| NotificationMaxDelay 0
| EVSEIsolationStatus Invalid
| EVSEStatusCode EVSE_Ready
| EVSENotification None
| EVSEMaximumCurrentLimit 700 A
| EVSEMaximumPowerLimit 500000 W
| EVSEMaximumVoltageLimit 920 V
| EVSEMinimumCurrentLimit 0 A
| EVSEMinimumVoltageLimit 0 V
| EVSECurrentRegulationTolerance 50 A
| EVSEPeakCurrentRipple 12 A
| EVSEEnergyToBeDelivered 25000 Wh
Hi All,
We're connecting module-EI and module-PI with SPI interface.
Currently, we have some problem in module-EI when sending Request Charge Loop Parameters command.
But the data response from the module-EI is "55 55 00 00 C0 27 70 37 00 01 05 A8 C1".
05 -> Unexpected message; module is not in a state to execute the command
and the message log comes with
[NOTICE] V2GISO13: Message performance timeout of 75ms reached.
We knew that it's the problem about the timeout.
We check for the TX_PENDING pin it shows that we didn't fetch any data when TX PENDING goes high.
It cause we can't fetch the data in real time. What would be the problem ?
BR.
Joechen
The module ID for the Vehicle to Grid (V2G) service is listed as two separate values in version 2.2 of the user manual. The table of module ID's lists it as 0x30, but the V2G chapter lists it as 0x27. I get a typical V2G-like responses using 0x27; What is the expected behavior?
Hello to everyone,
I have been testing on the WB-CARRIER-BOARD-EI ISO 15118(EVSE) module and WB-CARRIER-BOARD-PI ISO 15118(EVSE) module for a while.
I used Sevenstax/FreeV2G/master and /EV support for testing and follow as that README.md.
In testing i got two log, follow as:
Log 1
D:\work\ev\seven_satx\FreeV2G> py .\Application.py "Realtek USB GbE Family Controller #2"
Welcome to Codico Whitebeet EVSE reference implementation
Initiating framing interface
iface: Realtek USB GbE Family Controller #2, mac: C4:93:00:21:51:12
Set the CP mode to EVSE
Set the CP duty cycle to 100%
Start the CP service
Start SLAC in EVSE mode
Wait until an EV connects
EV connected
Start SLAC matching
Set duty cycle to 5%
SLAC matching timed out
EVSE loop finished
Goodbye!
Log 2
[ 331.551] [NOTICE] SLAC: stxSLAC_Start()
[ 331.664] [NOTICE] V2GCPS: Change State from B to A
[ 331.668] [NOTICE] V2GCPS: stxXBAR_V2GCPS_NotifyHandler()
[ 331.674] [NOTICE] V2GCPS: # V2GCPS_INFOTYPE_CP_STATE
[ 331.679] [NOTICE] V2GCPS: STATE A
[ 342.121] [NOTICE] SLAC: stxSLAC_StartSlacMatchingProcess()
[ 342.221] [NOTICE] V2GCPS: Change State from A to B
[ 342.225] [NOTICE] V2GCPS: stxXBAR_V2GCPS_NotifyHandler()
[ 342.231] [NOTICE] V2GCPS: # V2GCPS_INFOTYPE_CP_STATE
[ 342.236] [NOTICE] V2GCPS: STATE B
[ 392.127] [ERROR ] SLAC: Timeout: No SLAC matching within defined time window!
[ 392.134] [NOTICE] SLACSERV: # NC_SLAC_FAILED - 1
[ 392.142] [NOTICE] SLAC: stxSLAC_Stop()
In the log you can see "NC_SLAC_FAILED", can you help me fix this to establish SLAC connection?
I am unable to configure SDP with secure ports. The only configuration I am able to make is either with unsecure ports or take the default. For testing this is not a show stopper, but ultimately TLS is absolutely necessary. How can we resolve?
FYI: have a look at this wireshark capture v2g_cfg.zip
Hello @IonelFratila ,
in the charge loop you can set the response code to either "3: Stop charging" or "4: Renegotiate", see chapter 17.10.17 Set Charge Loop Parameters.
In Pre Charge and Cable Check you can stop by using the stop command 0x43. This forces a TCP disconnect. Do you have any issues with that in the pre charge and charge loop phase? Does the EV needs the EVSE_Shutdown status code?
BR Jan
Originally posted by @jpo-stx in #14 (comment)
Hello,
I have strange issue with one command 17.9.1 Set Configuration
I'm sending request to White Beet and I have response,that SPI frame is malformed.
Request
C0 27 A0 00 00 10 C4 93 00 21 55 DE 02 00 01 01 00 02 00 04 C3 50 D9 C1
Response
C0 27 A0 00 00 01 04 B0 C1
General , I see in example for this chapter , also, that Payload size is incorectly set. Here should be 0F not 10. What is going on??
C0 27 A0 00 00 10 (ReqID: 0; Payload: 18 byte)
01 02 03 04 05 06 (EV ID)
02 00 01 (Protocols DIN70121 and ISO15118 supported)
01 00 (Payment method EIM)
01 01 (Energy transfer mode DC extended)
C3 50 (Battery capacity of 50,000Wh)
00 C1
Response:
C0 27 A0 00 00 01 (Response; ReqID: 0; Payload: 1 byte)
00 (Acknowledgement)
00 C1
When I increased(+1) Payload Size I get ACK :). Strange.
My setup , evalboard EV - ISO15118 - SW 1_00_04
Hello,
i connected whitebeet carrier module EI(EVSE) and PI(EV). The FW on EVSE is updated to the latest.
Host PC is running with:
EI: https://github.com/Sevenstax/FreeV2G
PI: https://github.com/lukhof/FreeV2G/tree/master
I can authorize the ev, please check the logged terminal. A few seconds later there is a timeout.
How can i solve this problem so the charging session will start?
I have been reading through the new revision of the Whitebeet User Manual (r2.2) and have two questions about the Firmware Update Module and associated data types.
PktNum supposed to be?
Data supposed to be?
PktNum ?(i.e. PayloadSize-4 assuming that PktNum is uint32_t) This is what the example seems to indicate.
Thanks for your time
I have Whitebeet module with SPI comm. I have problem with SLAC - after connecting car
this is a log:
DC Controller start 2013-1-1 1:36:47
C0 05 81 FF 00 01 01 F4 WhiteBeet interface UP 2013-1-1 1:36:48
C0 0E 00 BB 00 00 00 C1 2013-1-1 1:36:48
C0 0E 01 BB 00 00 B2 C1 WhiteBeet Synchro OK 2013-1-1 1:36:48
C0 28 43 BB 00 00 00 C1 2013-1-1 1:36:48
C0 10 41 BB 00 00 00 C1 2013-1-1 1:36:48
WhiteBeet FW V01_01_062013-1-1 1:36:48
C0 29 40 BB 00 01 01 00 C1 2013-1-1 1:36:48
C0 29 40 BB 00 01 00 57 C1 CCS CP_Set_mode OK, CCS=init1 2013-1-1 1:36:48
C0 29 44 BB 00 02 03 E8 00 C1 2013-1-1 1:36:48
C0 29 44 BB 00 01 00 53 C1 CCS CP_Set_PWM_duty OK , CCS=init2 2013-1-1 1:36:48
C0 29 42 BB 00 00 00 C1 2013-1-1 1:36:48
C0 29 42 BB 00 01 00 55 C1 CCS CP_start OK, CCS=init3 2013-1-1 1:36:48
C0 28 42 BB 00 01 01 00 C1 2013-1-1 1:36:48
C0 28 42 BB 00 01 00 56 C1 wb_SLAC_start_subID OK , CCS=idle 2013-1-1 1:36:48
This is a resting state, I'm waiting for the car to be connected
C0 29 81 FF 00 01 01 D0 C1 CCS CP state changed to 1 2013-1-1 1:48:12 <-car is connected
C0 28 44 BB 00 00 00 C1 2013-1-1 1:48:12 <-start SLAC matching
C0 28 44 BB 00 01 10 44 C1 2013-1-1 1:48:12 _<- !!! status 0x10 - "Wrong State_
C0 28 43 BB 00 00 00 C1 2013-1-1 1:48:12
C0 28 43 BB 00 01 00 55 C1 wb_SLAC_stop_subID OK 2013-1-1 1:48:12
C0 28 42 BB 00 01 01 00 C1 2013-1-1 1:48:12
C0 28 42 BB 00 01 00 56 C1 2013-1-1 1:48:12
C0 28 44 BB 00 00 00 C1 2013-1-1 1:48:12
C0 28 44 BB 00 01 00 54 C1 wb_SLAC_start_matching_process_subID OK 2013-1-1 1:48:12
C0 29 44 BB 00 02 00 32 00 C1 2013-1-1 1:48:12
C0 29 44 BB 00 01 00 53 C1 CCS CP_Set_PWM_duty OK 2013-1-1 1:48:12
But after restarting SLAC service and car is still connected will never SLAC matching success
What am I doing wrong or is there anything else I can do in addition?
Hi Sevenstax,
We are trying to connect the connect the two WHITEBEET Boards EV/PI and EVSE/EI, in order to understand its functioning, with the latest FreeV2G-master repository (attached).
**_APPLICATION:
Name: ISO15118 (EV)
Version: V01_00_04
Target: WHITE-BEET
CPU: STM32F745
APPLICATION:
Name: ISO15118 (EVSE)
Version: V01_01_06
Target: WHITE-BEET
CPU: STM32F745_**
Testbench
With the following steps:
Terminal
But we have always the same warning output:
Warning: Module did not accept command 27:70, return code: 5
"Session stopped" received
EVSE loop finished
Goodbye!
We would like to know if this warning is normal in the demo application, or it is a problem of our testbench?
Attached: Uart-Log and Terminal-Log for EVSE- EI
WHITEBEET_EVSE-EI_TERMINAL_N2.txt
WHITEBEET_EVSE-EI_UART_N2.txt
WHITEBEET_EV-PI_TERMINAL_N2.txt
WHITEBEET_EV-PI_UART_N2.txt
FreeV2G-master_Beond.zip
When is the correct time to start and stop each service (in relation to a the boundaries of a charge session or in relation to iso15118 request/response message pairs)? How do I restore each service (CP/SLAC/V2G) to a state that is ready for the next session? I find that there is a disparity between what is recommended in the user manual and what works in a practical sense. Before closing development for the Whitebeet host interface, I'd like to get some buy-in from your team to tie up what loose ends I have. This is perhaps an issue with the user manual and not the firmware itself. I am familiar with the Appication Examples section of the user manual, but I find them either lacking in information, or sometimes incorrect. Let's start with CP Service to address what I believe is a mistake, just to get that out of the way, as it's not a major concern of mine.
The message sequence diagram in the user manual instructs the Host EVSE to stop the CP service after high-level communication with the EV is complete. If the service is turned off, it seems to me that we would not be able to detect the next plugin.
Between the user manual, experience with testing, the FreeV2G source code, and threads on this forum, I have been able to piece together correct usage at the beginning and end of a session. On the other hand, it's not clear to me what the "best practices" for V2G service usage are.
For example, in the configuration portion, we set some (but not all) parameters that remain constant to the station. A good example is the EVSEID. We shouldn't expect the EVSEID value to change from session to session, only the format changes according to which protocol is selected (ISO vs DIN). So why not set each value once during configuration, and let it be?
Speaking of only configuring Whitebeet once, from the user manual I would assume that configuration is performed after reset release, but in the FreeV2G application, configuration happens every single charging session!
It is clear to me how to initialize the SLAC service, but not so much how to restore it to a proper idle state. The application example sequence diagrams for CP and V2G at least depicted the end of the charging session, but there is no such diagram for SLAC. My current understanding is to leave SLAC running at the end of charging session until plugout. After plugout, I turn SLAC service off, wait, then turn it back on.
In my first pass as designing the host interface, my assumption was that each service needed to be configured, but only configured once. And after configuration, my assumption was that I would turn the service on once. The only reason I conceived to turn the service off was to re-configure it. However, it seems that each service requires a different approach with respect to (1) configuration and (2) restoring the services to an idle/standby state such that is ready for the next session.
Thanks again for your time,
-Zach
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.