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

Gauges are always in sync with current, but not with power #1045

Open
mr-manuel opened this issue May 10, 2024 · 9 comments
Open

Gauges are always in sync with current, but not with power #1045

mr-manuel opened this issue May 10, 2024 · 9 comments
Assignees
Labels
high_prio High priority

Comments

@mr-manuel
Copy link
Collaborator

I observed a very strange gauge behaviour. When the units are set to Current (Amps) then all is working fine. When the units are set to Power (Watts) then the gauges seem to not use the power value, but the amp value. This creates an inconsistency between gauge movement and value.

Since I did not understand why there is this difference I investigated a bit. After checking the values I noted, that the current is correct, but the power is not. This is because the true power is shown an not the apparent power, which makes totally sense. Just in case anyone else is also questioning the same.

This results, that if the units are switched, the gauges have to switch also the source data.

venus-os-gauges

@kwindrem
Copy link
Collaborator

What you are seeing is the ultra sensitive gauge due to auto ranging with small values for min and max. As you can see in the GuiMods view of the same values the amount of power involved is so small that there is no bar shown at all. Also there is some delay in the gauge to smooth changes. Notice that a value change is nearly instantaneous but the gauge ramps to the new value. I'm not sure why Victron felt that this was necessary but this does account for discrepancies in the gauge value as the power fluctuates.

There has been a previous discussion about how to handle the AC in gauge. The max value for the AC input gauge should be the AC input current limit which is set in amps. What was decided (and makes sense to me) is that the gauge would use watts if the limits were set in watts or use amps if the limits were set in amps.

Limits for other gauges are set in watts. So in all cases there is a limit for either watts or amps even though the user can select the alternate power value.

For the AC input gauge In GuiMods, I convert the AC input current limit to a power value based on the the current and voltage. This calculation won't be accurate if a high power factor is involved which would be the same difference seen between a gauge using currents and a numeric value shown in watts. There is no perfect answer here.

@mr-manuel
Copy link
Collaborator Author

Hello Kevin, the gauge is not auto ranging in this case. See #1037. You can also see in my screen recording, that the gauge is moving correctly when amps are selected, but not when power is selected. If power is selected, the gauge moves based on the amp values.

@kwindrem
Copy link
Collaborator

The gauge may not be currently auto ranging but the difference between min and max is pretty small. If you manually set max and min to realistic limits, then the gauge behavior should be more like that shown in GuiMods. But the problem will probably still exist when large changes in power occur rapidly.

If you watch the values in gui-v1 with GuiMods AC input tile you will also see the same difference in the numeric display of watts vs amps. I don't think this is an issue of amps differing from watts, rather in the timing of the measurement or the reporting of watts and amps values. The Multi/Quattro makes the measurements then forwards them to the GX device. There, systemcalc processes them and provides the values used for the display. Most processing in the Victron ecosystem is done at 1 second intervals, however a slight delay in the reporting/prococessing path means watts may be calculated for a different measurement than that for amps.

Tracking of gauge vs numeric value could be improved by using the same unit (amps vs watts) for both, but then calculating limits for that value: watts limit = amps limit * voltage; amps limit = watts limit / voltage

@jpetrell
Copy link
Contributor

Gauges are always in sync with current, but not with power

@jepefe commented earlier here that "For AC IN and AC OUT we use current as it is easy to match to the current limit settings and and circuit breakers are rated in amps. The gauges must use the current reading for scaling also when the numerical value is displayed in watts."

Apparently the amps range is similar to the watts range, so similar that it should be ok to always use amps for the load graph, which is purely visual.

What I wonder is how are the users that only care about the power and usually see electrical values as watts on the display (Brief, Overview, etc.) supposed to (know how to) adjust the min/max settings defined in amperes. But I guess the manual configs are for the power users anyhow.

@kwindrem
Copy link
Collaborator

A gauge showing amps and a gauge showing watts won't be substantially different. The issue here is timing. The amps and watts values are out of sync and can differ substantially when the values are changing rapidly (one being positive and the other negative sometimes) due to the time the samples were taken and/or processing delays.

Therefore, I'm recommending that the gauge should display the chosen parameters (watts or amps) and the limits scaled appropriately by the current voltage.

For a limit is set in amps and the gauge displays watts, then the gauge maximum should be current limit * voltage. Autoranging can use the existing logic and ignore the selected watts/amps selection.

For a limit set in watts and the gauge displaying amps the gauge maximum should be the watts limit / voltage.

@mr-manuel
Copy link
Collaborator Author

A gauge showing amps and a gauge showing watts won't be substantially different.

This is not true at all. This is only true, if the reactive power and the apparent power are nearly the same, which in my and many other situations is not the case.

grafik

In an AC circuit, the product of the rms voltage and the rms current is called apparent power. When the impedance is a pure resistance, the apparent power is the same as the true power. But when reactance exists, the apparent power is greater than the true power.
https://www.techtarget.com/whatis/definition/apparent-power

This can result in situations where the active power is positive and the apparent power is negative as in my case. This causes the gauges to show a different state as the values are.

Reactive-Power-Beer

@mr-manuel
Copy link
Collaborator Author

Here another example:

venus-os

@chriadam
Copy link
Contributor

chriadam commented Jun 6, 2024

You are correct about the potential mismatch between current and power (FWIW it reproduces easily with Demo: "Boat/Motorhome demo 1", check the "Grid" (AcInputs) gauge in the Side Panel of the Brief Page), but I think another reason which will affect more people is the animation delay. I had previously thought that the side gauges used the same animation period as the bar gauges, but I was incorrect. I've added a commit to #1191 to substantially reduce the animation time for both. Even with this change, there will be some cases of non-synchronicity:

The way I do the animations avoids ugly jumps, but it effectively serialises any two consecutive changes which occur within a single animation time period. So, for example, if there are three changes (labeled A,B,C) to the value: from A = from 1 to 2 at t=0.00, B = from 2 to 8 at t=0.01, C = from 8 to 6 at t=0.22, then if the animation takes 0.2 sec you will see the following: animates from 1 to 2 finishes at 0.2, animates from 2 to 8 finishes at 0.4, animates from 8 to 6 finishes at 0.6. This results in an apparent delay to the value of 0.38s, which is problematic. This issue would NOT be seen if C occurred at t=0.19 as then the transition to B would simply be omitted.

I need to think about how this can be improved. Reducing the animation time will already be helpful, so I don't think this should block the release.

@kwindrem
Copy link
Collaborator

kwindrem commented Jun 6, 2024

Again, for whatever reason, amps and watts are changing at different times. Some time ago I suggested that the gauge could always display amps but this animation proves this is not as good as it could be.

Right now, the system uses current for the max value of the gauge and for the active length. I'm suggesting that this be changed when displaying watts:

if displayingCurrent:
barLength = current / maxCurrent
else (displaying watts):
barLength = watts / voltage / maxCurrent

This way the bar length will track the numeric value displayed (watts or amps).

Yes, the animations do delay the bar a bit relative to the numeric value. In GuiMods there is no animation: the bar tracks the value and it does jump a bit when the value changes rapidly. I don't see this as a bad thing since it graphically shows the spike which is not understandable with rapid numeric changes. Smoothing the gauge is less jarring to look at but hides these spikes.

There will also be differences in the two based on power factor but that's a different matter.

@mpvader mpvader added high_prio High priority and removed low_prio labels Jun 13, 2024
@chriadam chriadam removed this from the Version 1.0.0 milestone Jun 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
high_prio High priority
Projects
None yet
Development

No branches or pull requests

6 participants