RT:
先插个眼,看懂了在来写…
2023年07月19日13:25:20 更新
sample rate: 器件的采样率
report rate: 上报率
首先,进入 QSensorTest ,长按会进入一个 sensor strean rate 界面
sample period: 这个就是 sample rate
report period: 这个就是 report rate .
假设
sample period: 500
report period: 1000
表示的是 每隔 500ms 进行一次数据的采集, 每隔 1000ms 进行一次数据的上报.
可以看到的是,sensor 默认情况下,并不是实时的进行数据上报…
但是,我们想要进行测试,不是个简单的事情,因为 sensor 可能会有其他的地方在调用,会对你的测试进行干扰。所以第一步先干掉其他 在调用sensor 的地方
输入指令:
adb shell dumpsys sensorservice restrict SensorFlushListener
我们测试下 accel
参数设置:
sample period: 500
report period: 1000
log 如下:
07-12 06:26:45.408 1033 12977 D sensors-hal: handle_sns_client_event:432, accel_sample(accelcal_available:0): ts=10116304852192 ns; value = [0.120377, 0.179646, 9.764373], status=3
07-12 06:26:45.408 1033 12977 D sensors-hal: handle_sns_client_event:432, accel_sample(accelcal_available:0): ts=10116794727400 ns; value = [0.121298, 0.179094, 9.764005], status=3
怎么计算是否 设置的正确呢?
因为 sensor 上报的数据,都会有个 timestamp , 也就是 log 后面的 ts .
两个 ts 相减,然后在除以 1000,000,000 转换为 秒
当然设置的话,是要这个 sensor 器件支持的odr
这种类似的命令,可以看下sensor 器件支持的最大的 odr
see_workhorse -sensor=accel -sample_rate=50 -duration=1 -display_events=1
可以看到如下信息:
20:25:45.109 is NOT POR.
20:25:45.109 has max_rate: 15 hz
最大是 15HZ ,表示一秒中最多出15 个数据
软件中的设置。 同时也可以看的到: 这个odr 的概念,只在 poll 模式下才有的东西
类似这种
values[1].has_flt = true;
values[1].flt = STK3A5X_SENSOR_ALS_ODR_15;
可以看到模式有2中:
SNS_STD_SENSOR_STREAM_TYPE_ON_CHANGE 和 SNS_STD_SENSOR_STREAM_TYPE_STREAMING
像 SNS_STD_SENSOR_STREAM_TYPE_STREAMING 这个模式 在 hal 层的说法是 continue 模式
on_change 模式: 指的是数据变化了就上报,比如: proximity /light sensor 为代表的一类sensor
stream: 数据持续的不断输出.
所以 QSensorTest 中 sensor stream Rate: 这个只能测试 stream 类型的 sensor. 如果不是,可以看到即使你输入数据,也是不会生效的。。
batch 函数
{
auto it = _sensors.find(handle);
auto& sensor = it->second;
sensor_params params;
params.max_latency_ns = max_report_latency_ns;
params.sample_period_ns = sampling_period_ns;
try {
sensor->set_config(params);
}
return 0;
}
可以看到 这个函数没有做啥,
这里有两个参数: max_report_latency_ns /sampling_period_ns 这两个概念。
max_report_latency_ns:最大延时报告。 就是我们在 QSensorTest 中设置的 report period. 就是数据上报率,多长时间把数据进行上报
sampling_period_ns: 就是数据的采样率
核心是在这里: sensor->set_config
来到 sensor.cpp 中
void sensor::set_config(sensor_params params)
{
// 看样子 像是与延迟数据上报,p/l sensor 没有延迟上报,所以都为0
// 有延时上报的 可能需要 FIFO
/* clamp the sample period according to the min and max delays supported by
sensor.*/
uint64_t min_delay_ns = _sensor_info.minDelay < 0 ? NSEC_PER_MSEC:
_sensor_info.minDelay * NSEC_PER_USEC;
uint64_t max_delay_ns = _sensor_info.maxDelay < 0 ?
SEC_PER_HOUR * NSEC_PER_SEC:
_sensor_info.maxDelay * NSEC_PER_USEC;
else {
// on-change sensor case, we will convert sample_period to batch_period
// since, there is no min/max Delay for on-change sensor type so, accept sample_period value as it is
sns_logi("no need to adjust sample_period_ns due to on_change_sp_enabled = %d or reporting_mode = %u",
_is_on_change_sp_enabled, get_reporting_mode());
}
/* if new params are same as existing params, no update required. */
if (!(params == _params)) {
_params = params;
/* if sensor is active, update configuration */
/* sensor activate的时候更新,那么如果sensor 刚打开的时候,不能一起下发参数?? */
if (is_active()) {
update_config();
}
}
}
先看 on-change sensor 的处理
else {
// on-change sensor case, we will convert sample_period to batch_period
// since, there is no min/max Delay for on-change sensor type so, accept sample_period value as it is
sns_logi(“no need to adjust sample_period_ns due to on_change_sp_enabled = %d or reporting_mode = %u”,
_is_on_change_sp_enabled, get_reporting_mode());
}
从注释中可以知道,on_change sensor 没有所谓的什么最大、最小的延迟。 只有采样率。 也就是说: 只要环境发生了改变,数据有变化,就马上上报。
看下是怎么更新这些参数的
ssc_sensor.cpp
void ssc_sensor::update_config()
{
lock_guard<mutex> lk(_mutex);
send_sensor_config_request();
}
void ssc_sensor::send_sensor_config_request()
{
........
uint32_t batch_period_us = get_params().max_latency_ns / NSEC_PER_USEC;
uint32_t flush_period_us = 0;
/* To support Android Hi-Fi requirements for non-wakeup sensors, if
batch period is less than the time required to buffer
fifoReservedEventCount number of events, we need to set flush period
according to the fifoReservedEventCount. For streaming sensors,
this will be derived from the sample_period and for non-streaming
sensors, flush period will be set to a max value */
if (_wakeup_type == SENSOR_NO_WAKEUP) {
if (get_reporting_mode() == SENSOR_FLAG_CONTINUOUS_MODE) {
uint32_t batch_period_max_us =
(get_params().sample_period_ns / NSEC_PER_USEC) *
get_sensor_info().fifoMaxEventCount;
if(batch_period_us > batch_period_max_us) {
sns_logi("dt=%s, asked batch_period_us : %u adjusted_us : %u",
_datatype.c_str(),
(unsigned int)batch_period_us,
(unsigned int)batch_period_max_us);
batch_period_us = batch_period_max_us;
}
}
// 实际最后的值是 0
else {
flush_period_us = 0;
}
} else {
}
if (_is_on_change_sp_enabled && get_reporting_mode() == SENSOR_FLAG_ON_CHANGE_MODE) {
uint64_t sample_period_us = get_params().sample_period_ns/NSEC_PER_USEC;
if (sample_period_us > UINT32_MAX) {
sns_logi("sample_period_us is larger than acceptable value");
batch_period_us = UINT32_MAX;
} else {
// 赋值
batch_period_us = sample_period_us;
}
}
// 准备发送到 adsp 那边去
pb_req_msg.mutable_request()->mutable_batching()->
set_batch_period(batch_period_us);
pb_req_msg.mutable_susp_config()->set_delivery_type(get_delivery_type());
pb_req_msg.mutable_susp_config()->
set_client_proc_type(SNS_STD_CLIENT_PROCESSOR_APSS);
pb_req_msg.SerializeToString(&pb_req_msg_encoded);
_resampling);
....
if (_is_sync_request_enabled) {
send_sync_sensor_request(pb_req_msg_encoded);
} else {
// sensor is activate 的时候,发送
if (is_active()) {
_ssc_conn->send_request(pb_req_msg_encoded, false);
}
}
}
可以看到 batch_period_us 与 sample_period_us 是相等的
没有写完, 后面继续--------------------------------------