Open source CCS using AR7420

[celeron55]

I pushed my changes here if you want to take a look. Basically I just have a yet another protocol to the hardware. Mine uses a line based "name=value" format at 115200 baud. Feel free to use any parts or ideas. Eventually I would like to be able to run the pyPLC upstream on my car but currently it's lacking features I need as you can see.

Of course all of these features could be added as-is under yet another configuration option. I haven't had the time or motivation to do that yet.

https://github.com/celeron55/pyPLC

EDIT: Quickly looking at the log, the charger appears to indicate its wish to quit charging by setting the status "DC_EVSEStatus.EVSEStatusCode": "2", "EVSEStatusCode_text": "EVSE_Shutdown".

[uhi22]

Very good. I think I will integrate your changes using another configuration option, to keep everything together and have the chance to test further improvements in the different hardware environments.

[uhi22]

the charger appears to indicate its wish to quit charging by setting the status "DC_EVSEStatus.EVSEStatusCode": "2", "EVSEStatusCode_text": "EVSE_Shutdown".

Good point. The status codes are not yet handled by pyPlc, this needs to be improved. The meaning of EVSE_Shutdown is "Charger Shutdown, Customer Initiated Shutdown", so this seems to be the normal way if the user stops the charging on the charger. This is in contrast to "EVSE_EmergencyShutdown", which means "Charging System Incompatibility, Emergency Shutdown or 'E-Stop'
button pressed at charging station."

[Edit] Started to integrate the reaction on status codes, https://github.com/uhi22/pyPLC/commit/8 ... 777a190c58

[uhi22]

It appears a pyPLC timeout occurs during WaitForCurrentDemandResponse (a bit more than 1 second?), after which pyPLC... starts to search for a modem? All the while the actual charger was apparently displaying an ongoing charging session on its screen.

[55139ms] 11:WaitForPowerDeliveryResponse entering 12:WaitForCurrentDemandResponse
[56694ms] [PEV] from 12:WaitForCurrentDemandResponse entering 99:SequenceTimeout
[60751ms] [CONNMGR] ConnectionLevel changed from 100 to 5
[60752ms] [ModemFinder] Starting modem search

The modem search after successful communication looks strange, but is "normal". The strategy is, that if something goes wrong, e.g. timeout of the high-level communication, the ConnectionManager will notice this, and adjust the ConnectionLevel accordingly. And if it comes to the conclusion, that it has no TCP, SDP, SLAC and modems seen for some time, it just starts from the beginning, with the modem search. This is the point, where either the charger will treat the requests as a new session, or, if the charger does not do this, because it still sees the CP line in state B, the user needs to unplug and re-plug, to convince the charger, that a new session shall start.

A better handling would be, just to display a message "Charging failed, please unplug", and just wait until the CP line goes to zero volts. But this would require that we measure the CP voltage, which is additional hardware. That's why the ugly workaround is, to just begin with the modem search and SLAC again.

[celeron55]

Another thing that a new state needs to be created (or an existing state expanded) is the locking of the connector before precharging is allowed. The hardware has to lock the connector using a lock motor and confirm from the lock freedback line that the connector is actually locked. Only then can voltage to be allowed on the connector. From that point on the connector has to stay locked until the session ends. I think the hardware will have to keep the connector locked until CP is released back to the original state B, which disallows the charger from applying current or voltage. The hardware also has to open the inlet contactors when transitioning back to CP state B.

I will be attempting to implement some sort of locking logic today before doing more tests but I do expect it to be more or less hacky. My goal will be just to get the connector to lock and stay locked during the charge session so that some dumbass doesn't come pull the plug at 250A and get their face vaporized. Locking during precharge isn't as critical so I might do this purely in hardware for now, as the hardware can monitor the current via the BMS and the inlet voltage via the inlet voltage sensor.

EDIT: The only problem I'll have is that if the hardware starts seeing current or voltage but the connector isn't pushed all the way in, and as a result it cannot lock the connector, the only safe option at that point is to cancel the charge session which is very inconvenient. Or, well, I guess I can just lock the connector right away as it is connected and then unlock it by pressing a button inside the car which also forces CP to state B and the contactors open. It seems worth it to figure out the simplest safe solution here and stick with it. We definitely want safety, but we definitely don't want unnecessary complication. Unnecessary complication can discourage someone from using the safety.

EDIT: I think I'm going with locking the connector right away based on the PP line, and unlocking by pressing a vehicle button. It allows you to push the connector in while the lock motor is operating, which ensures the highest chance of getting it locked, and it gives you a very clear, always available method of unlocking the connector. It will also work as-is with AC charging. It also does not need almost any extra support from pyPLC as the hardware can just refuse to transition CP to state C if locking the connector failed. Of course pyPLC will want to be able to eventually fine tune its behavior based on lock status, but it's not high priority (on my HW, lock status will be "lock=0/1").

[uhi22]

Fully agree, that safety becomes a topic now, and connector lock is an essential safety measure.
My original Ioniq is behaving like this:
- You can plug and unplug, as long as the authorization is not finished. E.g. you come to a charger, find out that it does not accept your payment, just unplug and drive to the next.
- It locks before the cable check is started, this is after authorization and chargeparameterDiscovery. Somehow at the same point where also the stateC is applied (Checkpoint550). This makes sense, because cable check applies 500V, and nobody should be able to touch the contacts in this state.
- It unlocks, as soon as the charging is finished, no matter whether it has been stopped by the car (battery full) or by charger (user stop request) or error. (There is a configuration option in the car, that the connector stays locked until unlocking the car by key, but this does not make much sense.)
- I'm not sure about the exact point of unlocking, I would assume after the WeldingDetection, but there are other cases to consider, when just the communication is lost or PowerDeliveryStop did not work or so.

In best case, the connector-lock-success feedback contact could be wired to the CP line, so that an unlocked connector always ends the stateC, and the charger would use this as hardware channel to shutdown the current, no matter what happens in the communication channel.

Fun fact: There are different implementations of the "lock-success" in the field: My Ioniq just drives the lock pin, and is happy to close the contactors, no matter whether a connector is physically present or just some crokodile clamps. The Taycan has a mechanical plug-presence detection, and does not even start the SLAC if there is not a correct connector inserted.

[celeron55]

Here's a charging log from the 50kW Tritium Veefil.

I think the last time I tried this charger I was pressing the wrong buttons on the charger, or possibly did something in the wrong order. The UI on them is extremely confusing.

You can also see some updates on my github repo. I'll be rebasing my stuff on top of yours as you move forward. Hopefully my stuff on top decreases in size over time.

You will also notice I added a pp_mv report to my hardware, and that the voltage is totally off from what it should be. I don't know why that is and don't have time to figure it out now, but just something to keep in mind. I also added plugged_in=0/1 which I use to exit from pyPLC on unplug, for which I added a setting, so that I can automatically split logs per charging session using a simple manager that launches pyPLC based on connector presence.

[uhi22]

You can also see some updates on my github repo. I'll be rebasing my stuff on top of yours as you move forward. Hopefully my stuff on top decreases in size over time.

Wow, that's impressive. While I was still thinking whether it makes sense to create separate hardwareinterface files for each variant, you already created a common one, which treats all three. Seeing the result I'm convinced that this is the better approach. Many thanks for this.

I think I need a git training, to understand how you did this "rebase". Did the tool most of the work, or did you need to decide for each of your changed lines and my changed lines by your own what you want to keep and what you want to throw away? Git has so many features, I think most of them could be very helpful, but I did not proceed behind the very basic things. Much to learn for me

[celeron55]

Yeah I think it'll work out fine like that.

One specific thing I'd like to see changed in hardwareInterface is that showOnDisplay() shouldn't take in strings but rather some kind of structured format, preferably just a set of numerical values, which it could then give to the hardware as a set of numerical values instead of strings. That can then accomodate all kinds of display devices, from singular LEDs, to 7 segment LEDs, up to fancy color displays with graphics.

[celeron55]

I'm going to go test on a Tesla supercharger in a couple of hours. If you have any last minute changes for that then hurry up now

[uhi22]

Great, no, no updates planned this morning. Happy testing.

[celeron55]

Logs from today. I added the user's perspective descriptions of what happened during each.

2023-05-05_124_siemens.zip

(16.41 KiB) Downloaded 41 times

This was an awful experience. It's a charger with a big super unresponsive touchscreen and unclear instructions for how to use it. I think it couldn't even get to the precharge stage, not sure if it was trying or not. I don't think it detected the car at all?

EDIT: No PLC comms seen in log.

2023-05-05_125416_tritium_75kW.zip

(80.19 KiB) Downloaded 37 times

Worked nicely.

2023-05-05_125750_alpitronic_225kW.zip

(49.96 KiB) Downloaded 38 times

Worked nicely, EXCEPT that when I started my charging session, it stopped the charging session of the car that was already charging on the other plug. When a new session was started for the other car, mine stopped charging. Super weird.

2023-05-05_172_circontrol_50kW.zip

(27.46 KiB) Downloaded 34 times

Didn't work. The UI seemed to indicate it was trying to establish comms. I also tested Chademo which worked fine.

EDIT: No PLC comms seen in log.

2023-05-05_17_abb_50kW.zip

(142.55 KiB) Downloaded 42 times

Didn't work. It gave the classic cryptic ABB "waiting for the grid to return" error message. (not the exact wording, translated from Finnish) Also looking at the logs it somehow semi-permanently confused my session management and logging system into repeatedly launching pyPLC (this is supposed to be based on the PP line - weird). I also tested Chademo which worked fine.

2023-05-05_181727_kempower.zip

(2.34 MiB) Downloaded 40 times

Worked nicely. Car was pulling 250A for a long time. Current was varyingly limited by other cars sharing the capacity and finally by my battery getting full.

2023-05-05_20_tesla.zip

(142.06 KiB) Downloaded 38 times

This was a Tesla v2 supercharger. Seemed to work nicely, except that the charger only charged for some seconds before ending the session. This could be repeated with no apparent differences. I also did a third session on a different stall requesting only 100A but that didn't change the behavior.

EDIT: Looks like Tesla has figured out the most efficient and non-disagreeable way to end a charging session: Just stop all comms right there and then. The car will figure it out no doubt and the engineers can be assigned to more productive tasks. But this doesn't give much clue why it stops. DM Musk on Twitter to get the logs?

The only thing I can think of is the charger assigns some sort of window the car's SoC report has to stay within and my super bouncy SoC doesn't fit inside said window. This seems far fetched though. I hope you have better ideas.

[celeron55]

Quick news: I literally just extended the stateWaitForCurrentDemandResponse timeout and V2 Supercharger works perfectly now. Looks like it simply transitions into a slower update interval after some time of charging. Anyone know the required intervals by the standard?

Eh... Well, not so fast. It abruptly stopped again, but later than before. Interesting. Looks like that's not what happened but instead the session otherwise continued longer, or at least felt like it. Well I'll collect logs and post later. Makes no sense to try to analyze here on the spot as there are so many distractions and things to deal with.

EDIT: Looks like there are some gaps in comms coming from the charger, and if I lower the current by a lot the gaps get smaller and rarer. At 20A I think I'm looking at a continuous session. EDIT: Ah well, just as I pressed enter it stopped.

EDIT: To me it seems to be acting like SNR is just slightly too bad or something and the signal sometimes drops out for too long. I think it's the signal going to the charger that's dropping out, not the signal coming from the charger.

EDIT: I could easily remove about 30cm of the signal ground wire between the CCS inlet and the car and did just that. Didn't help... Wait, I think that was just for the lock feedback?

EDIT: I think I might have to look into the electrical characteristics of my CP line. What exactly is the recommended set-up for it?

EDIT: Answering myself, the circuit diagram is shown on the DieterLV topic here https://github.com/uhi22/pyPLC/blob/mas ... ardware.md

[celeron55]

Here are the logs as described in the previous post.

EDIT: I think I have a 4.7 nF capacitor and no series resistor. Good enough? Well... I suppose kind of, but I'll swap something closer to the spec.

EDIT: Swapped in a 220 ohm series resistor and a 1nF capacitor that looks like it's about 50 years old. Hello from the Good Enough Lab! I figure not having a series resistor could have resulted in some reflections on the line? Not sure about the capacitor, the exact capacitance doesn't seem very important to me.

EDIT: I think what's worst about pyPLC's timeout is that it ends up breaking 250A current using the contactors.

I think it would make sense to attempt to wait it out longer than the charger so that the charger is likely to stop the current first, in case packets are dropping on their way to the charger.

To handle the case where packets are dropping on their way from the charger to pyPLC, pyPLC should first set a 0A current request and only after a second or so open the contactors.

[uhi22]

I think what's worst about pyPLC's timeout is that it ends up breaking 250A current using the contactors.

I think it would make sense to attempt to wait it out longer than the charger so that the charger is likely to stop the current first, in case packets are dropping on their way to the charger.

To handle the case where packets are dropping on their way from the charger to pyPLC, pyPLC should first set a 0A current request and only after a second or so open the contactors.

The plan was, that in case the pyPlc detects a timeout, it goes to the Safe-shutdown-sequence. This starts with setting the CP state from C to B. I read somewhere, that if the charger does not see state C anymore, it shall shut-down very fast (do not remember the exact time, something like 20ms or 50ms iirc). In the article they wrote, that not all charger models fulfull this, they needed longer time. In the pyPlc there are at the moment 2s delay from the state B until in stateFunctionSafeShutDownWaitForChargerShutdown the contactors are opened. Hope this time should be sufficient for the charger to shut down, but we do not know this. Would make sense to do some measurements, how long it takes from the state B until the current is off, on different charger models...

Edit: In 2023-05-06_180656_pevNoGui.log we see, that the safe-shutdown-sequence does not work as intended. It starts well: [120480ms] [PEV] from 99:SequenceTimeout entering 111:SafeShutDownWaitForChargerShutdown, but the connectionManager too early re-initializes the PEV state machine, so that it does not reach contactor-opening and connector-unlocking-states. Could be fixed, by increasing the time in the connection manager, to stay happy for 10 seconds after the last correct message.

Edit2: Pushed two changes, which give the safe-shutdown-sequence the needed time to finish.

[uhi22]

Strange data loss in the tesla case: 2023-05-06_180656_tcpdump.pcap
[2023-05-06 17:08:26.720938] the pyPlc sends the last CurrentDemandReq.
[2023-05-06 17:08:26.729208] and
[2023-05-06 17:08:26.898489] and six (!) further times the SuC answers, but the pyPlc does not evaluate the response. The pyPlc sniffer part sees the responses, but they do not arrive in the state function WaitForCurrentDemandResponse.

Looking to the pcap in WireShark, my understanding is, that the SuC sends a correct message (at 90.291s), but the TCP of the car does not send the ACK for it. That's why the TCP in the SuC repeats the same message multiple times, but also there no ACK is sent. This is an error of the TCP state machine.

In contrast, the good case is visible at 90.224s: The SuC sends a message, and at 90.250s the TCP sends an ACK.

At the moment I do not have an idea, why the TCP is ignoring the obviously received frames. This is not a functionality of the pyPlc. The TCP is part of the operating system.

[celeron55]

Not able to check right now, but I suppose the OS is Armbian 23.02. Recent bog-standard Linux. I do wonder if there are any kernel parameters to play with.

Does the car send the ack to one of the attempts but not the rest? Some sort of ack rate limiting or something? I'm not experienced with networking at this level. Just trying to think of something that would make sense.

[uhi22]

Had a look to some of the tesla supercharger logs. Somehow the point in time, where the communication is disturbed, is nearly the same, but the details are different. In the same time range, the car is sending a DHCP (which is not necessary for our purpose), also RouterSolicitation. For me this looks like, that the OS decided to check the connectivity of the Ethernet port, and that this action disturbs the ongoing TCP connection. What I see is, that not the SuC is the guilty one. It makes the retransmissions, and is very fast in each response.
In the last of the four logs, the procedure continues, but still with big gaps in the interesting time range.
Maybe there are possibilities to configure the DHCP or whatever in a way, that it does NOT check the connectivity, to avoid the disturbance.

Code: Select all

# 2023-05-05_200520_tcpdump.pcap

45.401s: SuC sends CurrentDemandResponse
45.426s: TCP ACK
45.511s: DHCP request
47.715s: next pyPlc message

# 2023-05-05_200824_tcpdump.pcap

45.429s: SuC sends CurrentDemandResponse
45.515s: DHCP request
45.640s: SuC retransmit
46.140s: SuC retransmit

# 2023-05-05_203955_tcpdump.pcap

45.140s: SuC sends CurrentDemandResponse
45.232s: DHCP request
45.313s: SuC retransmit
45.713s: SuC retransmit

# 2023-05-06_180656_tcpdump.pcap

45.279s: SuC sends CurrentDemandResponse
45.359s: DHCP request
45.458s: SuC retransmit
45.858s: SuC retransmit
46.458s: SuC retransmit
47.618s: pyPlc sends CurrentDemandRequest
...sequence continues correctly...

[celeron55]

Ah yes. I might not have added eth0 to the ignore list of networkmanager, that's definitely a possible source of problems.

Why isn't the problem occurring on other chargers though?

EDIT: Or I guess maybe it does occur, but the timings are a bit different and/or the other chargers look a bit different in the eyes of the DHCP client.

This is the definite downside of a full GNU/Linux system. It's ridiculously powerful to the extent of being able to run many applications at the same time and host various tools to inspect its own behavior, but it's also such a circus of services and options. But what am I to complain, I need networkmanager to automatically set up my wifi network for monitoring and updating the system.

EDIT: So far tested the new capacitor and resistor on the Kempower and 50kW Tritium Veefil. No issues. But also, those worked fine before. I need to find the time to go to one of the ABBs or Circontrols, or the horrible Siemens.

[celeron55]

Did a long test run today. It was miserable. Nothing worked. I'll try to describe the events, attach the logs and hopefully we can draw some conclusions. I will be marking chargers for my own reference using letters inside [].

You will not find a single EXI message being received by pyPLC in any of these logs. It's that bad.

The changes I had done prior to this test run is:
- Changing the CP line 4.7nF capacitor to 1nF and adding the 220 ohm series resistor
- Adding two more battery modules, which increased the total pack voltage.

I had tested both of these changes on two chargers already two days ago. I reported it here in my edit to the previous post. The last charger for today was one of these.

Before the first charging attempt, I added eth0 to the unmanaged list of NetworkManager and made sure nmcli showed it as unmanaged.

17:37 ABB [h]

2023-05-10_173726_abb_h.zip

(12.94 KiB) Downloaded 36 times

- I haven't tested this unit before, but I have tested the same model
- CCS displayed the classic cryptic ABB error message
(- Chademo didn't work but I had a Chademo configuration issue. It did add to the misery though.)

18:23 Alpitronic [h]

2023-05-10_182_alpitronic_h.zip

(15.46 KiB) Downloaded 33 times

- I haven't tested this unit before, but I have tested the same model
- Didn't work. There seemed to be no succesful communication.

18:36 Delta [r]

2023-05-10_18_delta_r.zip

(22.42 KiB) Downloaded 33 times

- I haven't tested this model before
- Didn't work. There seemed to be no succesful communication.

At this point I noticed there was an issue decoding the ipv6 address. For some reason the interface now had an address with a shortened 16-bit field in it, which needed to be padded with zeroes. It seemed likely it was due to NetworkManager being told to not poke at the interface. I made a quick fix to the address parsing and I think it works correctly but I'm not sure. You can find it here: https://github.com/celeron55/pyPLC/commits/master

18:53 Delta [r]

2023-05-10_19_delta_r.zip

(24.07 KiB) Downloaded 38 times

- Still no charging. The ipv6 address parsing issue should be gone though

19:15 Circontrol [r]

2023-05-10_191503_circontrol_r.zip

(10.52 KiB) Downloaded 33 times

- I tested a different unit but same model before with no luck
- Didn't charge
(- Chademo didn't work but I had a Chademo configuration issue. It did add to the misery though.)

20:22 ABB [h]

2023-05-10_202_abb_h.zip

(12.61 KiB) Downloaded 40 times

- Revisit of the first charger
- Now the display showed the CCS socket as being taken even while it was plugged into nothing. Couldn't test. However, I did connect it to the car and got logs.
(- Chademo didn't work even though I had fixed my Chademo configuration issue. It is unclear whether this was my fault or the charger's fault this time. The charger blamed the car like they generally do.)

After this time I started playing with the networkmanager's managed status of the network interface because it was unclear whether it was contributing to the problems or not. In terms of log files, whether it's managed or not in each log file is basically random.

20:37 Alpitronic [h]

2023-05-10_203_alpitronic_h.zip

(13.38 KiB) Downloaded 32 times

- This is the same Alpitronic that I visited as the second charger today.
- Did not start charging.

20:53 Tesla supercharger [k]

2023-05-10_2_tesla_k.zip

(58.89 KiB) Downloaded 37 times

- Tried two stalls. They seemed to want to charge, but I don't think there were any comms happening.

21:37 Kempower [m]

2023-05-10_21_kempower_m.zip

(36.42 KiB) Downloaded 40 times

- This is the Kempower on which I did the first ever succesful charge.
- Didn't work
- Two days ago this DID work with the CP capacitor and resistor modification and the increased pack voltage. I reported it here in my edit to the previous post.
(- Didn't test Chademo, things were totally hopeless by this point)

This all seemed bizarrely unlucky. My assumption was that both of the changes would only make things better. Instead, what happened was, everything became much worse. I literally couldn't manage to charge a single time, on any of the chargers I visited. (Not managing to even get Chademo working a single time was a "nice" cherry on top.)

So. What's the conclusion? Do we blame my messing with NetworkManager, or do we blame my messing with the CP line capacitor and resistor?

If nobody has any ideas, then I will revert back to my previous 4.7nF + no resistor configuration.

Not sure what I will do with NetworkManager. Could temporarily setting the interface as unmanaged have caused some kind of permanent effects? I also need to check if there are other states than "managed" and "unmanaged" that it may have been in previously...

[uhi22]

What I see from the logs:
1. Good: The physical layer looks fine, the SLAC is working. This means, the coupling network can stay as it is.
2. Bad: The network manager disabling seem to have more effects than wanted. I do not yet have the complete picture, something goes wrong with the IP address. In 2023-05-10_213715_pevNoGui.log we see "[addressManager] ERROR: setSeccIp: invalid ip address len 32". Normally this should be the 16 byte IP address which comes from the charger in the SDP response, and should NOT depend on the network manager at all. Seems we have an unconsistent initialization of self.SeccIp in pyPlcIpv6.py. This needs a deeper look. (Update) Yes, there was a mix-up between PevMode and EvseMode regarding the chargers IP address, which has caused that the changes regarding the local IP address was influencing the chargers IP, which should have come from the SDP. Finally this prevented a TCP connection.
I pushed an update: https://github.com/uhi22/pyPLC/commit/1 ... f03b0fa9cb

[Edit] Regarding the behavior of the network manager, we need some support of the linux-experts. The requirements are:
(I) The eth port shall have a link-local IPv6 address, and keep this stable at least over one charging session. Reason: IPv6 is needed for the V2GTP communication.
(II) The device shall support the NeighborSolicitation / NeighborAdvertisement on the eth port. Reason: Some chargers insist on having NeighborDiscovery, otherwise they do not establish a TCP connection.
(III) The device shall NOT try DHCP on this eth port. Reason: DHCP may confuse the charger.
(IV) The device shall NOT disturb / delay established TCP connections on the eth port. Reason: Delay or interrupt of TCP causes charging session terminiaton.
(V) The device shall NOT try to establish an connection to the internet on the eth port. Reason: May confuse the charger.

[johu]

I have indeed observed that the various managers in default config do not consider a connection as established as long as there is no internet connectivity and after some minutes will tear down the connection and try to bring it up again. They can be configured otherwise though, like if you set a fixed IP address in the GUI the connection is up immediately, no DHCP is done and no internet connection is expected.

I found connections are stored in /etc/NetworkManager/system-connections
I added a new connection with IPv6 link.local and get

Code: Select all

>cat CCS\ Test.nmconnection 

[connection]
id=CCS Test
uuid=70230b03-722e-43ed-af71-a2c2c623a634
type=ethernet
interface-name=enp2s0

[ethernet]
mac-address=E8:03:9A:DC:DE:EF

[ipv4]
method=disabled

[ipv6]
addr-gen-mode=stable-privacy
method=link-local

[proxy]

My BeagleBone doesn't use NetworkManager, so I guess it's not an issue there. Not sure who brings up eth0. It shows like this

Code: Select all

> ifconfig eth0

eth0: flags=-28669<UP,BROADCAST,MULTICAST,DYNAMIC>  mtu 1500
        ether e4:15:f6:f6:6b:0a  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 55 
        

[celeron55]

On the Kempower now. I confirm that uhi's commit and johu's NetworkManager config example seem to be working.

[EDIT: No, turns out I didn't have uhi's latest commit in use here yet...]

I need to look at the pcap file and see if any DHCP requests are going on now. If I don't see any, I need to go to the Supercharger to see what happens there.

As an aside, when testing chargers, I can recommend having two phones with you:
- Use one to create the car-wide LAN, giving your laptop and CCS controller access to the internet and SSH access from your laptop to your CCS controller, and leave it in the glovebox giving it continuous USB power.
- Use the other one for authenticating to chargers, streaming music over bluetooth and taking photos. Playing music is important. You need to establish your presence on the charger. I recommend Bomfunk MC's. Turn the bass up.

I was trying to do with one previously and it was kind of painful. A phone is not very good at being a wifi router, music player and a camera (and whatever else) at the same time.

EDIT: Attached the logs of the Kempower session. DHCP requests can still be seen. About one every 65 seconds. I think that's just like before?

2023-05-11_191549_kempower_m.zip

(1.65 MiB) Downloaded 39 times

EDIT: Ah I don't have the interface "connected" to the connection I added. It's has "Wired connection 1" instead of "CCS" which I added. Let's see...

EDIT: Managed to do that by running something like

Code: Select all

nmcli con add connection.interface-name eth0 type ethernet connection.id CCS

and then editing the created file by hand to represent more of what johu said, the important parts being the ipv4 method=disabled and ipv6 method=link-local, then restarting NetworkManager and then

Code: Select all

nmcli con up CCS

Now I have:

Code: Select all

$ nmcli device status
DEVICE         TYPE      STATE         CONNECTION  
wlan0          wifi      connected     My wifi 
eth0           ethernet  connected     CCS        

EDIT: Now going to the Kempower, I get this and cannot start a charging session:

Code: Select all

May 11 20:12:49 orangepizero pevfgmanager.sh[2526]: [addressManager] ERROR: invalid length of
IPv6 string. Expected be 16 bytes, means 32 hex characters. Found 30

EDIT: However, now I do not find any DHCP requests in the log which is about 3 minutes long. I have attached it too now:

2023-05-11_201205_kempower_m.zip

(13.18 KiB) Downloaded 37 times

I think this is where I now need uhi22's newest change. For some reason I don't have it even though I thought I did... Wait what. I need _my_ change? Why didn't I have that? I hate it that the easiest way to reproduce any of this is to go to the charger repeatedly, makes it really slow to figure out what's wrong. Is this a new problem?

EDIT: Yes, I now have a charging session. I hope I get no DHCPs in the pcap now.

[celeron55]

The final log for the day.

It is a 1020 second log, of a succesful charging session, where no DHCP requests can be found. I think I'm set for a new attempt at the Tesla Supercharger. That'll be for another day though.

Overall this is definitely the smarter method to this. Always test changes on this nearby charger first until it works, and then make no changes before going for a longer test run.

[uhi22]

image.png (9.6 KiB) Viewed 12382 times

This is the charge graph of the above trace file. It is created from the 2023-05-11_205813_tcpdump.pcap, by running

Code: Select all

python pcapConverter.py

and

Code: Select all

python scope.py

(Just a very drafty version at the moment, many things to be improved.)