Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Charging math: consistency between modules and building understanding #105

Open
Abby-Wheelis opened this issue Jan 21, 2025 · 6 comments
Open

Comments

@Abby-Wheelis
Copy link
Contributor

Opening a separate issue to track the questions that were raised in #92.

@Abby-Wheelis
Copy link
Contributor Author

Abby-Wheelis commented Jan 21, 2025

Although I have since been told that the power computation is not just a simple multiplication, there needs to be a square root of 3 in there somewhere, so even this is wrong. And, as I pointed out, even the 48 is not consistent, it is 32 in some parts of the system.

The formula for power in a 3-phase AC circuit is Voltage x Current x Power Factor x sqrt(3), where the Power Factor is the "True Power" divided by the "Apparent Power". In purely resistive circuits it is 1.

Assuming 230 V and 16 A per phase, that would be about 6.4 kW = 230 x 16 x sqrt(3), but we see closer to 10 or 11 on the power meter, which would indicate that the power factor is greater than 1, which I'm not entirely sure is possible.

Let's see if I can find where the calculations are performed, and what Power Factor is used.

@shankari
Copy link
Collaborator

shankari commented Jan 22, 2025

@Abby-Wheelis I assume that the sqrt(3) won't apply for DC charging. Maybe the computed power assumes DC and does not work properly for AC? It won't be the first time that the functionality is almost there but has some holes for use cases that are more uncommon. Right now, in the US, DC is way more prevalent than AC in the public charging space because most people use AC/L2 charging at home.

@Abby-Wheelis
Copy link
Contributor Author

I assume that the sqrt(3) won't apply for DC charging.

Right, for DC it is just P = V x I. If it were just using DC we would expect to see 16 x 230 = 3.7 kW which is way lower than what we're seeing. Maybe close to 16 x 3 x 230 = 11 kW (then presumably some loss factor), but that's not how 3 phase works. Maybe we assumed that's how it works?

I still need to find where this is actually calculated, but assuming 230 V and 16 A I would expect to see a little less than 3.7 kW for DC, and a little less than 6.4 kW for AC.

Since the number is higher than that, maybe I'm gleaning the wrong current from the logs, or there is some current that it is defaulting to that is higher?

@Abby-Wheelis
Copy link
Contributor Author

Abby-Wheelis commented Jan 22, 2025

I input a Departure Time of 3600 (1 hour) and an EAmount of 60.

The log message says that the EAmount is in Wh

Message to encode (ns=Namespace.ISO_V2_MSG_DEF): {"V2G_Message": {"Header": {"SessionID": "9152F7DFECF7AFF6"}, "Body": {"ChargeParameterDiscoveryReq": {"RequestedEnergyTransferMode": "AC_three_phase_core", "AC_EVChargeParameter": {"DepartureTime": 3600, "EAmount": {"Value": 60, "Multiplier": 3, "Unit": "Wh"}, "EVMaxVoltage": {"Value": 400, "Multiplier": 0, "Unit": "V"}, "EVMaxCurrent": {"Value": 32000, "Multiplier": -3, "Unit": "A"}, "EVMinCurrent": {"Value": 10, "Multiplier": 0, "Unit": "A"}}}}}}

Then: before adjusting for departure time, max_current 16.000000, nom_voltage 230, pmax 11040, departure_duration 3600, why is the duration already just an hour before adjusting?

And then a few lines later says Requested departure time 3600, requested energy 60000.000000 which would be in milliwatt hours?

Then the messages with the charge parameters has more confusing units, with nominal voltage of 2300 and max current of 160, the pmax is still 11040 (I have a feeling this is what shows on the display, minus some loss factor, just not sure where it comes from).

Decoded message (ns=Namespace.ISO_V2_MSG_DEF): {"V2G_Message":{"Header":{"SessionID":"9152F7DFECF7AFF6"},"Body":{"ChargeParameterDiscoveryRes":{"ResponseCode":"OK","EVSEProcessing":"Finished","SAScheduleList":{"SAScheduleTuple":[{"SAScheduleTupleID":1,"PMaxSchedule":{"PMaxScheduleEntry":[{"RelativeTimeInterval":{"start":0,"duration":3600},"PMax":{"Multiplier":0,"Unit":"W","Value":11040}}]}}]},"AC_EVSEChargeParameter":{"AC_EVSEStatus":{"NotificationMaxDelay":0,"EVSENotification":"None","RCD":false},"EVSENominalVoltage":{"Multiplier":-1,"Unit":"V","Value":2300},"EVSEMaxCurrent":{"Multiplier":-1,"Unit":"A","Value":160}}}}}}

Then the schedules get calculated, which would have the power delivered be much lower, around 1-2 Watts, but we're already pretty sure these schedules are not received properly, so focusing just on the elements of power calculation.

The first ChargingStatusRes indicates that the current is 160 (16A?), confused by this factor of 10 change.

Decoded message (ns=Namespace.ISO_V2_MSG_DEF): {"V2G_Message":{"Header":{"SessionID":"9152F7DFECF7AFF6"},"Body":{"ChargingStatusRes":{"ResponseCode":"OK","EVSEID":"DE*PNX*00001","SAScheduleTupleID":1,"EVSEMaxCurrent":{"Multiplier":-1,"Unit":"A","Value":160},"MeterInfo":{"MeterID":"YETI_POWERMETER","MeterReading":0},"AC_EVSEStatus":{"NotificationMaxDelay":0,"EVSENotification":"None","RCD":false}}}}}

These status messages repeat until the external limit that I sent kicks in, and the Current drops to 130 (13A?)

 Decoded message (ns=Namespace.ISO_V2_MSG_DEF): {"V2G_Message":{"Header":{"SessionID":"9152F7DFECF7AFF6"},"Body":{"ChargingStatusRes":{"ResponseCode":"OK","EVSEID":"DE*PNX*00001","SAScheduleTupleID":1,"EVSEMaxCurrent":{"Multiplier":-1,"Unit":"A","Value":130},"MeterInfo":{"MeterID":"YETI_POWERMETER","MeterReading":381},"AC_EVSEStatus":{"NotificationMaxDelay":0,"EVSENotification":"None","RCD":false}}}}}

Default: 10.6 kW, 16A, 230V
Limited: 8.6 kW, 13A, 230V

@Abby-Wheelis
Copy link
Contributor Author

Abby-Wheelis commented Jan 22, 2025

Then the messages with the charge parameters has more confusing units

The factor of 10 is coming from a call to calc_physical_value which takes a values and a multiplier and returns the value x 10 ^ multiplier. In the case of the current, the multiplier is -1, and 10 ^ -1 is 0.1 ... So the call actually "fixes" the values of 130 to the expected 13, not sure why that's needed, but I think I trust that bit of the math.

And in that context, the messages can be decoded a bit:
From the first ChargeParameterDiscoveryRequest:
60 x 10^3 = 60,000 Wh, which is 60 kWh, which is what I put in
the EV can accept a max of 400V and 32A and a minimun of 10A

Then that aligns with the next message, and resolve my confusion about milliWatt hours

The next ChargeParameterDiscoveryRequest is largely the same as the first, with the addition of PMax, 11040 Wh = 11.04 kWh

The two ChargingStatusRes show 16A then 13A, which tracks with the limit that I put in place.

I thiiink what is happening here is we assume the AC power = 3 x I x V (3 x 16 x 230) = 11040 Wh
When the correct formula is sqrt(3) x I x V = 1.73 x 16 x 230 = 6374 Wh

That should hopefully be a simple enough code change to correct!

@Abby-Wheelis
Copy link
Contributor Author

Yep, here's the line where we're first calculating the pmax

default_params.pmax = default_params.max_current * default_params.voltage * ((req->RequestedEnergyTransferMode == iso2_EnergyTransferModeType_AC_single_phase_core) ? 1 : 3)

We want to swap the 3 for sqrt(3) there, and maybe other places, but this is a start, bookmarking this for when I have build power!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants