Add data "age" attribute to sensor sysfs #81
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I would like to propose a workaround for ev3dev/ev3dev#1401 . A new sysfs attribute is exported:
bin_data_age
. It contains the number of milliseconds elapsed since the raw data received from given sensor last changed. This enables userspace to detect conditions like ultrasonic sensor not being able to measure distance at the current position. Thanks tomode_info
separation present in current drivers, this also works across mode switches - if the same stale data are received after switch, the timestamp of last data update is not reset.I think the naming (
bin_data_age
) is a bit unfortunate, but I don't know a better alternative. "Age" implies that the sensor did not send any new data during this time, but this may not be true. Sensor may still be sending data, but if they are the same as the old values, "age" is not reset to zero. I would likebin_data_msec_since_last_change
more, but that is likely too long.This patch also can't report age of individual values. One use I currently see is for detecting freezes on individual EV3 IR seeker channels. This would mean exporting age for each value separately, which may (or may not) be what is best for ev3dev.
The EV3 color sensor needs a different workaround - here the sensor sends new data, but they aren't accurate yet.