Initially I was thinking that all derived signals belong not in the CAN translator, but in the host device. Now I'm rethinking that, since there could be potentially be other devices reading over USB that aren't using the Android library. It makes sense to have a two lists of signals: simple signals (the current list) and derived signals (e.g. fuel economy in mpg). It lowers the barrier for people who want to do apps with fuel economy.
Also, document how we're calculating each derived signal. Could the handlers even be part of the open soure cantranslator project, since they're just dealing with fully transforme OpenXC values?
peplin
commented
11 years ago
Initially I was thinking that all derived signals belong not in the CAN translator, but in the host device. Now I'm rethinking that, since there could be potentially be other devices reading over USB that aren't using the Android library. It makes sense to have a two lists of signals: simple signals (the current list) and derived signals (e.g. fuel economy in mpg). It lowers the barrier for people who want to do apps with fuel economy.
Also, document how we're calculating each derived signal. Could the handlers even be part of the open soure
cantranslatorproject, since they're just dealing with fully transforme OpenXC values?