-
Notifications
You must be signed in to change notification settings - Fork 73
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
Table-driven live data interpretation? #90
Comments
I'm not opposed to this, indeed - when merging your latest D2 decoding additions, I was thinking "hmm this looks like it may soon need a table or something, like J1979". Lua sounds like total overkill, but I'm open to ideas. I imagine if some fields need conditional formatting based on e.g. bit fields, something more elaborate may be needed.
I think you are right on track there, one thing I don't want is a reinvented homemade wheel. |
For fields that need conditional formatting that can't be expressed in a formula, we could put in an escape hatch to call a C function instead of using a formula. One thing I'm not entirely satisfied with in my previously proposed table format is how it combines decoding/scaling with presentation. If we were adding other frontends like a dashboard app, then we'd want a way to get speed as a number, not a formatted string. So maybe we want to split into one table for scaling and one for CLI:
|
sure, that might work. Some difficulties arise when you want to render a value to a fixed width field though - I mean how to convey that width accross layers.
I ran into a similar challenge for the "diag_cfgi", where I wanted to abstract configuration items like int, bool, string... ended up with a not very satisfactory Another thing to add to the numeric parameters, that GUIs often like, is an expected min/max range. Nobody wants a temperature gauge that reads from -1E37 to 1E37 : ) |
Currently, we're using C code to decode Volvo live data. It might be nice to instead use a table-driven approach, with a "little language" such as algebraic expressions. We could drop in a small, suitably licensed postfix expression parser. For J1979, we're already using table-driven decoding, but it's too simplistic because it only has a scale and offset for each PID - can't handle bit fields, can't handle multiple values in one response, any "multiple choice" values need individual formatter functions like format_fuel().
Table entries might look something like this:
Or we could embed a Lua interpreter and use Lua expressions for scaling and formatting - although this is kind of going full circle back to code:
This would also apply to scaling for other vehicles we might add in the future. Also, table-driven decoding would make it easier to display in a GUI, return in an API, or log to CSV files if we ever add any of those things.
The text was updated successfully, but these errors were encountered: