为什么加速度计日志包含一个时间戳的两个 x、y、z 值?

Why the accelerometer logs contains two x,y,z values for one timestamp?

我正在查看示例 movesense 应用程序完成的日志,加速度计日志包含如下值:

{
    "Body": {
        "Timestamp": 110033,
        "ArrayAcc": [{
            "x": 0.60114991664886475,
            "y": 6.7324004173278809,
            "z": 3.0943653583526611
        }, {
            "x": 0.78317141532897949,
            "y": 7.0437526702880859,
            "z": 3.3697926998138428
        }]
    },
    "Uri": "ECKIAEBA141A/Meas/Acc/26",
    "Method": "PUT"
}

为什么数组包含一个时间戳的两个值?

这是因为精度 Hz 以毫秒为单位的时间戳。

13Hz 应包含 1 个值。

26Hz - 2 个值。

52Hz - 4 个值。

104Hz 和 + - 8 个值。

更新: @Dotevo 请再次检查,因为我在 post.

中看到了正确的值

52Hz 示例:

  Mds SDSInternalCallback()  taskId:20 sdsCallType:2 header:
SdsHeader{status=0, uri='MDS/EventListener/20', reason='CUSTOM_STATUS', contentLength=415, contentType='null', location='', taskId=0}
 dataBody:{"Body": {"Timestamp": 916161, "ArrayAcc": 
    [{"x": -0.1892065554857254, "y": -0.29937744140625, "z": 10.03513240814209}, 
    {"x": -0.25387206673622131, "y": -0.3544628918170929, "z": 10.071057319641113}, 
    {"x": -0.19878663122653961, "y": -0.32572266459465027, "z": 10.049502372741699}, 
    {"x": -0.16286133229732513, "y": -0.31135255098342896, "z": 10.075847625732422}]},
 "Uri": "ECKI89CB9A98/Meas/Acc/52", "Method": "PUT"}

104Hz:

Mds SDSInternalCallback()  taskId:20 sdsCallType:2 header:
 SdsHeader{status=0, uri='MDS/EventListener/20', reason='CUSTOM_STATUS', contentLength=742, contentType='null', location='', taskId=0} dataBody:{"Body": {"Timestamp": 725, "ArrayAcc":
 [{"x": -0.21076172590255737, "y": -0.26345217227935791, "z": 10.063872337341309}, 
 {"x": -0.23950196802616119, "y": -0.30656251311302185, "z": 9.9680719375610352}, 
{"x": -0.22992187738418579, "y": -0.33530274033546448, "z": 10.061477661132812},
 {"x": -0.19399659335613251, "y": -0.26345217227935791, "z": 10.025551795959473},
 {"x": -0.15328125655651093, "y": -0.28021728992462158, "z": 10.054292678833008}, 
 {"x": -0.19399659335613251, "y": -0.28021728992462158, "z": 10.008787155151367},
 {"x": -0.19878663122653961, "y": -0.32572266459465027, "z": 10.013577461242676},
 {"x": -0.19160157442092896, "y": -0.30656251311302185, "z": 10.02076244354248}]}, 
 "Uri": "ECKI89CB9A98/Meas/Acc/104", "Method": "PUT"}

@Esperanz0 写的差不多了。它有点复杂,由于 BLE 吞吐量,包被加入桶中。重要的是探针的数量可以不同。例如,如果某些 ResourceClient 正在请求带有“204Hz”的数据,那么另一个:

104Hz 有 4 个值

52Hz 有 2 个值

26Hz 有一个值

13Hz 有一个值

e.t.c.

所以无论如何你都应该准备好不同大小的桶。

上面的回答很好。为了(希望)澄清这种情况:在一个只有一个时间戳的包中进行多次测量的原因是在许多层面上节省了计算资源:

  • 传感器内部的 RAM 非常宝贵,这样可以避免每个结果副本占用 0-7 * 4 个字节。
  • 使用 DataLogger 存储数据时,每次测量额外的 28 个字节将花费大约 20% 的数据存储空间
  • BLE 带宽也是有限的资源,从移动端订阅时需要通过 BLE 传输相同的数据。这里也是每个字节计数
  • 我们考虑过每个通知只返回一个测量值的替代方案,但在采样率很大 (>400Hz) 的情况下,它会导致每秒通知过多,这可能会导致系统性能不佳。上面的内存节省也会丢失。

根据所有这些判断,必须为剩余测量值插入 ts 的缺点被认为成本要低得多。

完全披露:我在 Movesense 团队工作