Yoctopuceセンサーのデータロガーフォーマットの解釈方法は？

Question

YoctopuceのVirtualhub rest APIを使用してセンサーデータロガーからデータを取得したいと思います。センサーのマニュアルにはデータの入手方法が記載されていますが、データの解釈方法は記載されていません。私はそれを理解しようとしてきましたが、100％決定的なものは得られません。

私はどれくらいの距離を取ったかの例の下にあります。多分、ここの誰かが私が間違っている場所を見ているかもしれません。あるいは、すでに誰かが努力していたかもしれない。

---

私の例は光センサーです。私はデータロガーのデータをクリアし、1分に1回ロギングを開始しました。値はLuxで測定された数値です。

まず、データロガーから要約データが必要です。これは、http://hub:4444/bySerial/LIGHTMK1-2ABABA/dataLogger.jsonを呼び出すことによって行われます。これは以下のようにJSON形式のドキュメントを生成する：

[{"id":"lightSensor","unit":"lx","calib":"0,","cal":"*","streams": 
[{"run":0,"utc":1497384000,"dur":1380,"freq":"1/m","val":[0,11,15]} 
,{"run":1,"utc":1497384360,"dur":1800,"freq":"1/m","val":[13,15,16]} 
,{"run":2,"utc":1497387000,"dur":600,"freq":"1/m","val":[14,16,17]} 
,{"run":2,"utc":1497387600,"dur":3600,"freq":"1/m","val":[0,1,18]} 
,{"run":2,"utc":1497391200,"dur":3600,"freq":"1/m","val":[0,0,0]} 
,{"run":2,"utc":1497394800,"dur":3600,"freq":"1/m","val":[0,0,0]} 
,{"run":2,"utc":1497398400,"dur":3600,"freq":"1/m","val":[0,0,0]} 
,{"run":2,"utc":1497402000,"dur":3600,"freq":"1/m","val":[0,0,0]} 
,{"run":2,"utc":1497405600,"dur":3600,"freq":"1/m","val":[0,0,0]} 
,{"run":2,"utc":1497409200,"dur":3600,"freq":"1/m","val":[0,1,12]} 
,{"run":2,"utc":1497412800,"dur":3600,"freq":"1/m","val":[0,1,2]} 
,{"run":2,"utc":1497416400,"dur":3600,"freq":"1/m","val":[2,10,18]} 
,{"run":2,"utc":1497420000,"dur":780,"freq":"1/m","val":[17,17,19]} 
...etc... 
]}] 

最初の行はかなり明白である - センサー（lightSensor）と対策（LX）のその単位のシンボルの名前。 ストリームはデータを保持しているようです。残念ながら私はストリームがどのようなものであるかを知ることができませんでした。どちらもが実行番号を表していません。時間の経過とともに要素が追加されています。残りの部分については、私は推定するutcは、データの開始utcタイムスタンプを表します。 durの時間（秒単位）;それは後の段階で確認される。 フリークエンシーは、実際には1分に1回です。プロパティ値は、要約された最小/平均/最大トリプレットを表すように見えます。

次に、センサーの名前と正確なutc値の1つを指定すると、詳細を要求できます。 http://hub:4444/bySerial/LIGHTMK1-2ABABA/dataLogger.json?id=lightSensor&utc=1497387000呼び出すたとえば、これは最小/平均/最大トリプレットの配列である一見JSON文書

[[16,16,16] 
,[16,16,16] 
,[15,16,16] 
,[14,15,15] 
,[14,15,15] 
,[14,15,15] 
,[15,16,17] 
,[14,17,17] 
,[17,17,17] 
,[16,17,17] 
] 

をもたらします。これは、仮定を確認するdurを秒単位で表します。要素が10個あるため、1分ごとに1つです。 600秒を表します。

それぞれのトリプレットタイムスタンプはutc値+（index * 60）と仮定します。これはすべて意味があるようです。時間の重複を除いて。

最初のサマリー要素はutc 1497384000から始まり、1380秒間続きます。これは、次の要素がutc 1497385380で開始する必要があることを意味します。ただし、utc 1497384360から開始します。より前のタイムスタンプです！ 1020秒のオーバーラップがあります。実際、ラン番号が増分されると、常に重複しているように見えます。

重複する値が同一であることを期待していました。彼らはそうではありません。彼らは実際にはかなり異なっています。だから私はそれらを無視することはできません。

このすべてがデータの解釈方法に疑問を投げかけています。すべてのトリプレットを考慮する必要がありますか？重なりは次の要素の値によって上書きされるべきですか？または逆ですか？多分彼らは合計されるべきですか？

問題は、合理的な疑いを超えて意味のあるデータを解釈する方法を見つけることができないということです。

Answer 1

「実行番号」は、センサが切断（電源オフ）され、再接続されると自動的に増分され、次の測定値が現在のストリームに自然に適合しない場合に自動的に増分されます。通常、センサが再接続された時間が最後のストリームの最後のメジャーより早く表示される場合、この不一致を反映するために新しいストリームが実行されます。

なぜ、これらのタイムスタンプの不一致を取得するのですか...小さなUSB光センサーには内蔵時計がないので、ホスト（PC）からのUSBネゴシエーション中にUSBタイムスタンプを取得します。したがって、異なる時間設定（異なる時間帯または異なる時間帯）で2つの異なるPCにセンサーを接続すると、その種類の問題が発生する可能性があります。別の考えられる原因は、PCクロックが現在NTPによって調整されている場合で、センサクロックがPCと異なる速度になる可能性があります。しかし、これは大きな違いを考えている可能性は非常に高いです...

あなたは問題を簡単に再現することができ、重なりがかなり大きいので、おそらくあなたのPCにクロックを表示し、センサーを接続し、センサーが接続された時間を記録し、20分後に接続を外し、時間を記録し直して問題が再び現れるかどうか確認してください。すべてのRESTデータをダウンロードし、utcタイムスタンプをデコードして、どの値が正しいか、どの値が間違っているかを確認します。