Runs fine on Raspberry Pi. Runs but fails on Beaglebone Black

[hughsheehy]

Runs fine on Raspberry Pi. Runs but fails on Beaglebone Black

[shalinnijel2]

From a quick look at the log:
On the EVSE side:

INFO 2022-11-30 11:01:37,290 - iso15118.shared.exi_codec (299): Decoded message (ns=urn:iso:15118:2:2010:AppProtocol): {"supportedAppProtocolReq":{"AppProtocol":[{"ProtocolNamespace":"urn:iso:15118:2:2013:MsgDef","VersionNumberMajor":2,"VersionNumberMinor":0,"SchemaID":1,"Priority":1},{"ProtocolNamespace":"urn:iso:std:iso:15118:-20:AC","VersionNumberMajor":1,"VersionNumberMinor":0,"SchemaID":2,"Priority":2}]}}
INFO 2022-11-30 11:01:37,295 - iso15118.shared.comm_session (234): supportedAppProtocolReq received
INFO 2022-11-30 11:01:37,303 - iso15118.shared.exi_codec (245): Message to encode (ns=urn:iso:15118:2:2010:AppProtocol): {"supportedAppProtocolRes": {"ResponseCode": "OK_SuccessfulNegotiation", "SchemaID": 1}}
INFO 2022-11-30 11:01:37,877 - iso15118.secc.states.sap_states (146): Chosen protocol: ISO_15118_2
INFO 2022-11-30 11:01:37,880 - iso15118.shared.comm_session (420): Sending supportedAppProtocolRes

EVSE seems to have responded within ~600ms of receiving supportedAppProtocolReq from the EV - which looks good.

However on the EV side, a timeout error is thrown after 2 seconds after waiting for supportedAppProtocolRes. Timeout for supportedAppProtocolReq is 2 seconds.

INFO 2022-11-30 11:01:34,784 - iso15118.shared.comm_session (420): Sending supportedAppProtocolReq
INFO 2022-11-30 11:01:36,799 - iso15118.shared.comm_session (390): The data link will terminate in 2 seconds and the TCP connection will close in 5 seconds.
INFO 2022-11-30 11:01:36,801 - iso15118.shared.comm_session (394): Reason: TimeoutError occurred. Waited for 2.0 s

Maybe worth checking if there are any services on the EV side if there are any other services running. Also maybe worth checking on the EVSE side perhaps the pcap file to see if it was indeed sent out within 600ms?

[hughsheehy]

Will do.

I wonder if it's also a possibiilty that the poor Beagle Bone Black just isn't able to run both the SECC and the EV code at the same time without so much latency that it times out. Poor thing isn't very fast.

Would it/might it be possible to run - for instance - the SECC code on the Beagle Bone and the EV code on a Pi if they're on the same network and subnet?

[hughsheehy]

So, interesting. And puzzling.

I'm running the code on a Beagle Bone and on a Raspberry Pi, both connected to the same network.
If I run the Pi as the EV and the BeagleBone as the SECC, I get timeout errors. (see link )

If I run the Pi as the SECC and the BeagleBone as the EV, it works fine. Or at least it goes to the CurrentDemandReq and gets a CurrentDemandRes and then repeats. But it does that much. (see link )

I have TLS turned off in the .env file on both sides.

[hughsheehy]

It looks as if the BeagleBone is taking too long to respond to the first "supportedAppProtocolReq". As in it takes three seconds to even decode the message, and in the meantime the EV side (which will only wait 2.0 seconds) has given up and closed the TCP connection.

Now a BeagleBone isn't a fast machine, but it seems odd that decoding such a short message takes three seconds. That feels as if it might be a bug in the code that's holding things up somewhere. A Pi is a lot faster and if the code is running on any other machine then the problem might not be noticed at all.

[hughsheehy]

I changed all the 2.0 second timeouts in the various files to be 20 seconds instead. Then ran everything again.

It all worked until it got to one where the timeout limit was still set at 5.0 seconds.

But looking at the logs, the BeagleBone takes up to 10 seconds to respond to requests from the EV side. That seems a long time for such a response.. Watching the resource monitor on the BeagleBone, it's running java at 98% of the CPU and 10-15% of the RAM.

++++++++++++++++++++++++++++++++++++++++++++++++++++

INFO 2022-12-01 13:13:22,017 - iso15118.shared.exi_codec (299): Decoded message (ns=urn:iso:15118:2:2010:AppProtocol): {"supportedAppProtocolRes":{"ResponseCode":"OK_SuccessfulNegotiation","SchemaID":1}}
INFO 2022-12-01 13:13:22,018 - iso15118.shared.comm_session (231): supportedAppProtocolRes received
INFO 2022-12-01 13:13:22,020 - iso15118.evcc.states.sap_states (142): Chosen protocol: ISO_15118_2
INFO 2022-12-01 13:13:22,021 - iso15118.shared.exi_codec (245): Message to encode (ns=urn:iso:15118:2:2013:MsgDef): {"V2G_Message": {"Header": {"SessionID": "00"}, "Body": {"SessionSetupReq": {"EVCCID": "E45F01B2CCCB"}}}}
INFO 2022-12-01 13:13:22,372 - iso15118.shared.comm_session (415): Sending SessionSetupReq
INFO 2022-12-01 13:13:22,373 - iso15118.shared.states (137): Entered state SessionSetup
DEBUG 2022-12-01 13:13:22,373 - iso15118.shared.states (141): Waiting for up to 20.0 s
INFO 2022-12-01 13:13:32,889 - iso15118.shared.exi_codec (299): Decoded message (ns=urn:iso:15118:2:2013:MsgDef): {"V2G_Message":{"Header":{"SessionID":"3D1DADCFE788C382"},"Body":{"SessionSetupRes":{"ResponseCode":"OK_NewSessionEstablished","EVSEID":"UK123E1234","EVSETimeStamp":1669900407}}}}
INFO 2022-12-01 13:13:32,890 - iso15118.shared.comm_session (231): SessionSetupRes received
INFO 2022-12-01 13:13:32,891 - iso15118.shared.exi_codec (245): Message to encode (ns=urn:iso:15118:2:2013:MsgDef): {"V2G_Message": {"Header": {"SessionID": "3D1DADCFE788C382"}, "Body": {"ServiceDiscoveryReq": {}}}}
INFO 2022-12-01 13:13:33,134 - iso15118.shared.comm_session (415): Sending ServiceDiscoveryReq
INFO 2022-12-01 13:13:33,135 - iso15118.shared.states (137): Entered state ServiceDiscovery
DEBUG 2022-12-01 13:13:33,135 - iso15118.shared.states (141): Waiting for up to 20.0 s

[hughsheehy]

Would it be hard to use the C++ or JS EXI codecs instead?

[hughsheehy]

So - on this - it seems the Beagle Bone is just too slow to run the Java EXI codec.

[tropxy]

Hi Hugh,

Yeah, the Java EXI codec is a real bottleneck for embedded devices, that is why in the josev_pro offer we use the Rust EXI codec instead.