DIN: 'No EVSE ID available'

[Bobbybigears]

Hi,

I'm having an issue with using the DIN70121 protocol in conjunction with 2 Whitebeet ISO15118 Carrier Boards. One board is an EV board running firmware V01_00_06 and the other a EVSE board running firmware V01_01_07. The python EVSE repository is tagged as EVSE_v1.1.7_0. The host is a PIC microcontroller using SPI as the communication protocol.

The issue seems to be related to the ServiceDiscoveryReq interaction between the boards, i.e. the EVSE board rejects the 'ServiceDiscoveryReq' message.

I have used the energy transfer mode options in accordance with the recommendations in the user manual, but I get the same error whichever mode I have selected, i.e. 0, 1, 2, 1&2. I have provided a code snippet of the V2G Set Configuration routine.

bool BMS_WHITEBEET_MOD_V2G_RequestSetConfiguration(void) { bool bIsRequestSent = false; uint8_t u8ModId = BMS_WHITEBEET_V2G_MOD_ID; uint8_t u8SubId = BMS_WHITEBEET_V2G_SUB_ID_SET_CONFIGURATION; uint8_t u8ReqId = (u8SubId + 1U);
uint16_t u16PayloadSize = 15;

if(tBmsWhitebeetModV2GData.bIsInitialised)
{
    // MAC Address of system
    u8BmsWhitebeetModV2GPayloadData[0] = 0xc4; // mac address - byte 0
    u8BmsWhitebeetModV2GPayloadData[1] = 0x93; // mac address - byte 1
    u8BmsWhitebeetModV2GPayloadData[2] = 0x00; // mac address - byte 2
    u8BmsWhitebeetModV2GPayloadData[3] = 0x34; // mac address - byte 3
    u8BmsWhitebeetModV2GPayloadData[4] = 0xcf; // mac address - byte 4
    u8BmsWhitebeetModV2GPayloadData[5] = 0xf8; // mac address - byte 5

    // Supported protocols

    u8BmsWhitebeetModV2GPayloadData[6] = 1; // number of protocols
    u8BmsWhitebeetModV2GPayloadData[7] = 0; // DIN

    // Supported payment methods

    u8BmsWhitebeetModV2GPayloadData[8] = 1; // number of payment methods
    u8BmsWhitebeetModV2GPayloadData[9] = 0; // EIM (External Identification Means)

    // Supported energy transfer modes

    u8BmsWhitebeetModV2GPayloadData[10] = 1; // number of energy transfer modes
    u8BmsWhitebeetModV2GPayloadData[11] = 1; // DC Extended

    // Amount of energy in Wh that can be stored in the battery
    // Currently set for 10,000 Wh

    u8BmsWhitebeetModV2GPayloadData[12] = 0x00; 
    u8BmsWhitebeetModV2GPayloadData[13] = 10; 

    u8BmsWhitebeetModV2GPayloadData[14] = 0x03; 

    bIsRequestSent = BMS_WHITEBEET_CORE_SendRequest(u8ModId, u8SubId, u8ReqId, &u8BmsWhitebeetModV2GPayloadData[0], u16PayloadSize,
            &tBmsWhitebeetModV2GData.u16SendDataBytes, &tBmsWhitebeetModV2GData.u16ReturnDataBytes);
}

return bIsRequestSent;

}

I've also attached the UART debug log from the EV board for your perusal.

The output from the python code for the Whitebeet EVSE board is as follows:

.venv) bob@raspberrypi:~/FreeV2G $ sudo .venv/bin/python3 Application.py "eth0" -m c4:93:00:34:ab:5d -r EVSE Welcome to Codico Whitebeet EVSE reference implementation Initiating framing interface iface: eth0, mac: c4:93:00:34:ab:5d 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 "Session started" received Protocol: 0 Session ID: 542c4eab507e4ea1 EVCC ID: c4930034cff8 "Request EVSE ID" received No EVSE ID available "Session stopped" received EVSE loop finished Goodbye!

I can see from the EVSE.py code that 'message['format'] from the parse routine determines whether the EVSE ID gets set as 'None' or the specified ID, i.e. DEABCE0000101.

When I run similar code using the ISO15118 protocol (with all DC Energy Transfer Modes included), 'message['format']' returns as non-zero and the EVSE ID is set to the ID outined above.

I would be most grateful for any help you can provide with regard to this issue.

Best regards, Rob

ev-service-discovery-req.txt

[Bobbybigears]

Update: the same code works on a charger (Aqua Superpower Mobile Charger). Is there a way I can bypass this problem? Cheers Rob

[lho-stx]

Hey @Bobbybigears,

can you please also attach a wireshark log of the communictaion between FreeV2G and EVSE Whitebeet for both cases with PortMirror enabled? I then can have a look what differs in the communication!

Thank you and with best regards, lho

[Bobbybigears]

Pardon my ignorance. Never had to use wireshark before. Is there a guide on how to configure the Whitebeet for this use case? Cheers Rob

[lho-stx]

Oh I am sorry I did not know that you did not work with wireshark yet.

Regardaing teh port mirror:

You need to put evse.whitebeet.networkConfigSetPortMirrorState(1) in the line above evse.loop() in Application.py. Then start wireshark and let it listen to the interface connected to your EVSE Whitebeet. Start your session until it fails, then stop the logging, and save the file (goto File>Save as...).

If you have any problems please let me know!

Thank you, lho

[Bobbybigears]

Hi lho, Hopefully, I've captured the right information for you. The ISO15118 log, should show information up-to the 'CableCheck' states, whilst the DIN log will stop just after 'StartSession'. Let me know if the info is incorrect and I'll try again. Many thanks, Rob wireshark-log.zip

[lho-stx]

Hey,

yes the logs are helpful, thank you!

In frame 280 of din-log.pcapng the message payload send to the EVSE is 0x40 0x00 0x01 0x02 0x03. This means that the supported energy modes are all DC modes, but with DIN you need to disable mode 3: DC unique in the EVSE. Please disable DC unique in the EVSE Whitebeet and try again!

Thank you and best regards, lho

[Bobbybigears]

HI lho, Thanks for the prompt reply. I'm a little confused at the moment. The DIN config should only show 1 energy transfer mode, i.e. 1- DC Extended. The ISO15118 config should show all DC energy transfer modes. I may have inadvertently captured the wrong config. Won't have time today, but will confirm everything first thing in the morning.

Thanks for all you help with this. Much appreciated.

Rob

On Tue, Jan 31, 2023 at 3:03 PM lho-stx @.***> wrote:

Hey,

yes the logs are helpfull, thank you!

In frame 280 of din-log.pcapng the message payload send to the EVSE is 0x40 0x00 0x01 0x02 0x03. This means that the supported energy modes are all DC modes, but with DIN you need to disable mode 3: DC unique in the EVSE. Please disable DC unique in the EVSE Whitebeet and try again!

Thank you and best regards, lho

— Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/144#issuecomment-1410524544, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3HQFEJSTAUCBK3BJPYZ6CTWVESVZANCNFSM6AAAAAAULIQPNM . You are receiving this because you were mentioned.Message ID: @.***>

-- Rob Davies (Software Engineer)

Treharne Automotive Engineering Ltd Treharne Workshops Llanelli Gate Dafen Llanelli Carmarthenshire SA14 8LQ

Tel: 01554 775938

[Bobbybigears]

Hi lho, Got my head around it finally (takes a while these days). Modified EVSE.py so that energy transfer modes [0,1,2] were being passed to 'self.whitebeet.v2gSetEnergyTransferModes'. Also modified v2gSetEnergyTransferModes in Whitebeet.py so that the 'modes_allowed' list = [0,1,2] and also to print out both the allowed list, i.e. 'modes_allowed' and the 'modes_list' passed in from EVSE.py. On the host front, only configured 1 energy transfer mode which was DC Extended. Still had the same problem when I ran everything. I've attached both the Wireshark Log from this run together with the console output from the python code. Many thanks, Rob. evse-python-out.zip

[lho-stx]

Hey @Bobbybigears,

thank you for your effort! The setup looks promising now. I checked the FreeV2G issue tracker and there are indeed more people with this issue. I ask you to have a look especially into the issues #16 and try the proposed solution (and maybe create the EVSE UART log of this session too). If it still does not work, I need to replicate your setup, this will take some time but I am sure I can accomplish it this week.

Thank you, lho

[Bobbybigears]

Hi lho,

Thanks for your reply. The solution outlined in issue #16 is basically the configuration I'm using now. The allowable energy transfer modes in the EVSE python code have been changed to [0,1,2]. As far as my host application is concerned, I only set the DC Extended energy transfer mode when I set the V2G configuration prior to starting the V2G service. The code is provided below:

bool BMS_WHITEBEET_MOD_V2G_RequestSetConfiguration(void) { bool bIsRequestSent = false; uint8_t u8ModId = BMS_WHITEBEET_V2G_MOD_ID; uint8_t u8SubId = BMS_WHITEBEET_V2G_SUB_ID_SET_CONFIGURATION; uint8_t u8ReqId = (u8SubId + 1U); uint16_t u16PayloadSize = 15;

if(tBmsWhitebeetModV2GData.bIsInitialised)
{
    // MAC Address of system
    u8BmsWhitebeetModV2GPayloadData[0] = 0xc4; // mac address - byte 0
    u8BmsWhitebeetModV2GPayloadData[1] = 0x93; // mac address - byte 1
    u8BmsWhitebeetModV2GPayloadData[2] = 0x00; // mac address - byte 2
    u8BmsWhitebeetModV2GPayloadData[3] = 0x34; // mac address - byte 3
    u8BmsWhitebeetModV2GPayloadData[4] = 0xcf; // mac address - byte 4
    u8BmsWhitebeetModV2GPayloadData[5] = 0xf8; // mac address - byte 5

    // Supported protocols

    u8BmsWhitebeetModV2GPayloadData[6] = 1; // number of protocols
    u8BmsWhitebeetModV2GPayloadData[7] = 0; // DIN
    //u8BmsWhitebeetModV2GPayloadData[8] = 1; // ISO15118-2:2014

    // Supported payment methods

    u8BmsWhitebeetModV2GPayloadData[8] = 1; // number of payment methods
    u8BmsWhitebeetModV2GPayloadData[9] = 0; // EIM (External

Identification Means)

    // Supported energy transfer modes

    u8BmsWhitebeetModV2GPayloadData[10] = 1; // number of energy

transfer modes u8BmsWhitebeetModV2GPayloadData[11] = 1; // DC Extended //u8BmsWhitebeetModV2GPayloadData[12] = 2; // DC Combo Core //u8BmsWhitebeetModV2GPayloadData[13] = 1; // DC Extended //u8BmsWhitebeetModV2GPayloadData[14] = 2; // DC Combo Core //u8BmsWhitebeetModV2GPayloadData[15] = 3; // DC Unique

    // Amount of energy in Wh that can be stored in the battery
    // Currently set for 10,000 Wh

    u8BmsWhitebeetModV2GPayloadData[12] = 0x00;
    u8BmsWhitebeetModV2GPayloadData[13] = 10;

    u8BmsWhitebeetModV2GPayloadData[14] = 0x03;

    bIsRequestSent = BMS_WHITEBEET_CORE_SendRequest(u8ModId, u8SubId,

u8ReqId, &u8BmsWhitebeetModV2GPayloadData[0], u16PayloadSize, &tBmsWhitebeetModV2GData.u16SendDataBytes, &tBmsWhitebeetModV2GData.u16ReturnDataBytes); }

return bIsRequestSent;

}

I'll compile the hardware configuration I'm using and send it to you later on.

Again, many thanks for your help with this. Rob

On Wed, Feb 1, 2023 at 1:19 PM lho-stx @.***> wrote:

Hey @Bobbybigears https://github.com/Bobbybigears,

thank you for your effort! The setup looks promising now. I checked the FreeV2G issue tracker and there are indeed more people with this issue. I ask you to have a look especially into the issues #16 https://github.com/Sevenstax/FreeV2G/issues/16 and try the proposed solution (and maybe create the EVSE UART log of this session too). If it still does not work, I need to replicate your setup, this will take some time but I am sure I can accomplish it this week.

Thank you, lho

— Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/144#issuecomment-1412047795, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3HQFEOF4V6VDGGO4ZDE3TTWVJPHHANCNFSM6AAAAAAULIQPNM . You are receiving this because you were mentioned.Message ID: @.***>

-- Rob Davies (Software Engineer)

Treharne Automotive Engineering Ltd Treharne Workshops Llanelli Gate Dafen Llanelli Carmarthenshire SA14 8LQ

Tel: 01554 775938

[lho-stx]

Hey @Bobbybigears,

I apogolgize for being unclear: I want you to chang the EVSEID in Evse.py. Because in your log it shows that it uses all zeros as EVSID. I want to see what happens if you change the EVSE ID.

Thank you for your effort, lho

[Bobbybigears]

Hi lho,

Apologies. Didn't read issue#16 all the way through.

Tried the suggested fix. But got the same result. Get a 'Session Stopped received' immediately after trying to set the EVSE ID.

Many thanks, Rob

[Bobbybigears]

Hi lho,

I've attached a document outlining the development configuration.

Many thanks Rob whitebeet_config.txt

[lho-stx]

Hey @Bobbybigears,

Thank you for your effort.

I found the problem with the setup:

If you are using DIN mode, you can only use one charging mode (according to the standard). You need to enable only DC extended on your EVSE Whitbeet.

We are working on a fix, so you can enable more DC charging modes when using DIN and ISO simultaneously in the new Whitebeet firmware.

Best regards, lho

[Bobbybigears]

Hi lho,

That worked a treat! Very much appreciate the help. Diolch yn fawr as the Welsh would say! Cheers Rob