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

Graphed results inaccurate to the actual values #4

Open
ghost opened this issue Nov 16, 2023 · 3 comments
Open

Graphed results inaccurate to the actual values #4

ghost opened this issue Nov 16, 2023 · 3 comments

Comments

@ghost
Copy link

ghost commented Nov 16, 2023

Sensor values are correctly read and saved by HWinfo, but when graphing they show up wildly incorrect. The tooltip hover shows the values correctly on the site as well, yet the graphing makes no sense.

Untitled

attached csv from hwinfo here:
0 Offset.CSV

@leo-holanda
Copy link
Owner

Hi @chaosmaou! Thanks for creating this issue!

I'm sorry that the chart looks confusing. I downloaded your log and reproduced the problem. What you see is the expected behaviour but I agree that things could be better.

It's important to note that the first field is a "dominant" one. A scale is generated through its data to render the y-axis and the line. Core 1 Clock and the others look wrong because they are being rendered on a scale that isn't the dominant one and isn't tied to the y-axis. Instead, they use their scale which is tied to different data than the Core 0 Clock. That's why you can make Core 1 Clock the dominant field and Core 0 Clock the other one and this behaviour continues but with Core 1 Clock being the dominant and Core 2 Clock the other one it disappears. Because Core 1 Clock and Core 2 Clock share almost the same data, which means the same scale and the same y-axis.

That said, I thought about ways to improve this. I think a straightforward improvement would allow fields that share a common unit, like Celsius and MHz, to use a shared scale. This could solve the problem in this scenario. For fields with different units, the only way I see is to create multiple y-axes, at the same side or opposite sides, which could be kinda confusing.

Do you think this shared-scale solution sounds good?

@ghost
Copy link
Author

ghost commented Nov 18, 2023

Ah, I see what you mean. I wasn't aware that the first field becomes the dominant one. Now that I understand how it works on the back end it's much easier for me to wrap my head around how it's interpreting the values. Having a shared scale for items that share the same units sounds like a great way handle the issue.

@leo-holanda
Copy link
Owner

That's great! 😀 I have taken a look at the code in the past few days and already have an idea of how to implement it. I'm gonna finish some job-hunting things I need to do and then push some commits to fix this issue. When I deploy a new version, I will comment back here to let you know!

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

1 participant