加速度計のログに、1つのタイムスタンプに対して2つのx、y、z値が含まれているのはなぜですか？

Question

私はサンプルmovesenseアプリによって行わログをつもりですし、加速度計のログは、このような値が含まれている：

配列は、1つのタイムスタンプから2つの値を含んでいるのはなぜ

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

？

Answer 1

上記の良い回答。 （たぶん）に状況を明らかにする：のみ1つのタイムスタンプを持つひとつのパッケージ内に複数の測定のための理由は、多くのレベルのコンピューティングリソースの節約です：センサー内部

• RAMは貴重であり、これは* 0-7を回避結果の各コピーにつき4バイト。
• DataLoggerを使用してデータを保存する場合、1回の測定で28バイトがデータストレージの約20％のコストとなります。
• BLE帯域幅には制限があり、モバイルから購読する際にBLEで転送する必要があります。側。ここでもまた各バイト数
• 通知ごとに1つの測定値しか戻すことはできませんでしたが、サンプラレートが大きく（> 400Hz）、悪い実行システムにつながる可能性がある場合は、毎秒通知が多すぎます。また、上記のメモリ節約は失われていました。

これをすべて判断することは、残りの測定値に対してtsを補間しなければならないという欠点が、はるかに低コストであるとみなされる。

完全な開示：私はMovesenseチーム

Answer 2

これは、ミリ秒単位の精度Hzからタイムスタンプのためです。

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

104Hz：Esperanz0 @

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

Answer 3

はほとんど真実を書きました。もう少し複雑で、BLEスループットのためにパッケージがバケットに結合されています。プローブの数が異なる可能性があることは重要です。

104Hzを52Hzに26Hz一の値

13Hz一の値

を有する2つの値

を4つの値

を有していた：一部ResourceClientが別次いで "204Hz" のデータを要求している場合、例えば

など

とにかく、別のサイズのバケットに備えておく必要があります。