-
Notifications
You must be signed in to change notification settings - Fork 7
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
Comments
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? |
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. |
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! |
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.
attached csv from hwinfo here:
0 Offset.CSV
The text was updated successfully, but these errors were encountered: