Radial gauge inaccurate for larger numbers
tvr256 opened this issue · comments
Hi. Thanks for reporting this issue.
It appears you are working with tanks from Derived Data plugin? Can you provide more information please so we can recreate the issue. I am interested as to how you get to such a high number!
- What path are you using and what kind of data is it sending (numeric, ration, string, etc)?
- If the path data comes from a plugin, what plugin and what configuration do you have for this plugin?
- What gauge setting did you apply?
Hi @godind , I'm using a BME680 sensor which includes an air quality measurement, along with the signalk-raspberry-pi-bme680 plugin.
The plugin outputs the sensor resistance in Ohms, anything above 100 kOhms is good air quality. The highest I've seen is 150 kOhms so I set the radial gauge to read from 0 to 160000.
If you don't have a BME680 you should be able to inject an XDR sentence with suitable values. I can create a sample XDR tomorrow if it helps?
The plugin outputs the value as unitless (currently 34553.48400703593). I've set up the radial gauge to unitless and 0 decimal places, it's currently pointing at around 38000.
Is the path using units?
You can see this configuration in SK Admin's Data Browser page. Check the Meta Data
toggle, search for your path and share the details please.
Are you on Discord? Maybe faster to chat!
No units defined in SignalK, metadata shows the following:
{
"description": "This regex pattern is used for validation of the identifier for the environmental zone, eg. engineRoom, mainCabin, refrigerator"
}
You'll find me as: david_29482
Or just post on the #kip chanel
I've tried the following:
Gauge setup:
As-Is numeric value
with no formatting1
Minimum Integer Places0
Maximum Decimal Places0
Minimum Value and160000
Maximum Value
Path:
- Unitless
134553.48400703593
value
It shows the proper value on both needle indicator and value displayed. I'm not sure how to recreate the problem.
Setup a Radial Gauge and Numeric widget side-by-side with the same path and configuration.
To troubleshoot when you see the problem:
- Look at
Signal K's - Data Browser
to what is emitted. That will tell us what value is sent. - Look at
KIP's - Data Browser
to see what KIP receives. - See if both widget display the proper value.
That will tell us a bit more!
XDR sentence
I don't think the XDR sentence will help - unless the problem is with processing the XRD sentence it's self. All this is handled on the SK side using plugins, before SK updates Path values.
KIP only reads from Signal K path value outputs. With the troubleshooting steps above, it could help find the problem.
If you are using a plugin, you can probably enable logging and see in SK server logs what it does with value.
Apologies, I'm not on Discord. I'm busy tonight but I'll join up tomorrow if I can help.
I've just checked, both SignalK and KIP data browsers show unitless 34206.34699614607. Meanwhile the radial gauge is configured to display "As-is numeric value" and points to roughly 38000.
I think I might have found the problem. My gauge is configured to 0 - 150000, but it actually displays 0 - 160000. Can you reproduce if you change the maximum to 150000?
I'm convinced the number scale is the problem. Configure the gauge to 0 - 150000, the scale shows 0 - 160000. Then input 75000, the needle will point straight up at 80000 on the scale.
Good find. I'll check!
That's it! Weird that this was never reported before. I need to find a solution...
Thanks for the assistance.
The problem is only visible when ticks can't be nicely rounded to set max range. The gauge pushes the scale to the next roundable range so it can divide ticks in nice increments. It's visible if your min/max can't be divided by 10 (max number of ticks). Especially visible with uneven ranges.
I have a fix coming. The scale will auto-adjust to the next upper rounded number above set max, as it did before but, the value will follow properly.
Also fixed the ticks labels when they are fractional numbers. Obvious with scale from 0 - 1.
Weird that no one reported this for over 3 years!
Thanks for the troubleshooting. Hopefully it's all good now.