1

我正在查看由示例 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"
}

为什么数组包含来自一个时间戳的两个值？

4

3 回答 3

2

楼上的好答案。为了（希望）澄清情况：在一个只有一个时间戳的包中进行多次测量的原因是在多个层面上节省了计算资源：

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

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

全面披露：我为 Movesense 团队工作

于 2017-09-04T16:51:13.163 回答
1

这是因为精确到以毫秒为单位的时间戳。

13Hz 应该包含 1 个值。

26Hz - 2 个值。

52Hz - 4 个值。

104Hz 和 + - 8 个值。

更新： @Dotevo 请再次检查，因为我在帖子中看到了正确的值。

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"}

104赫兹：

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"}
于 2017-07-27T08:48:15.763 回答
0

@Esperanz0 写的几乎都是事实。由于 BLE 吞吐量，它有点复杂，并且包被加入到桶中。重要的是探针的数量可以不同。例如，如果某个 ResourceClient 正在请求“204Hz”的数据，那么另一个：

104Hz有4个值

52Hz 有 2 个值

26Hz 有一个值

13Hz 有一个值

ETC

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

于 2017-07-28T08:40:10.080 回答