You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So far, the signals in the vehicle are being sampled at discreet points in time only, triggered by arbitrary events like a timer firing (e.g. every 5s) or the engine being started etc.
This seems to be in line with the requirements of the rFMS spec but also means that the data points being transferred to the back end are quite sparsely distributed over time and do not allow for more than very basic analysis.
On the other hand, continuously sampling the signals at a high frequency, say 10 Hz, could potentially lead to a lot of (duplicate) data being transferred to the back end. A reasonable compromise might be to apply the curve algorithm to sampled data as suggested by GEOTAB.
There also is an example implementation in Python available on GitHub which could potentially be ported to Rust and employed in the FMS Forwarder.
The text was updated successfully, but these errors were encountered:
sophokles73
changed the title
Support of signals in vehicle at higher frequency
Support sampling of signals in vehicle at higher frequency
Jul 28, 2023
I've successfully lobbied for us at Geotab to open source a Rust implementation that Sven inquired about as well as the accompanying error thresholds for the signals in the Commercial Vehicles recommendations signals list
I'm still trying to get time from the developer who wrote that version, typical resources/priority conversation but hope to streamline.
For comparison purposes and in case there is delay, it might be worth having both the current sampling guidelines and then add curve when I can line things up.
So far, the signals in the vehicle are being sampled at discreet points in time only, triggered by arbitrary events like a timer firing (e.g. every 5s) or the engine being started etc.
This seems to be in line with the requirements of the rFMS spec but also means that the data points being transferred to the back end are quite sparsely distributed over time and do not allow for more than very basic analysis.
On the other hand, continuously sampling the signals at a high frequency, say 10 Hz, could potentially lead to a lot of (duplicate) data being transferred to the back end. A reasonable compromise might be to apply the curve algorithm to sampled data as suggested by GEOTAB.
There also is an example implementation in Python available on GitHub which could potentially be ported to Rust and employed in the FMS Forwarder.
The text was updated successfully, but these errors were encountered: