2016-12-08 8 views
1

私は、センサデータ(温度、GPS、加速度計など)を、マイクロコントローラを搭載したデバイスからGSMを介してバックエンドサービスに送信するデータフォーマットを設計する方法を検討しています。IoT用の余分なライトデータフォーマット

私はシンプルなJSON HTTP APIを作成しましたが、ペイロードは非常に重く、基本的にはデバイスのバッテリ寿命を向上させるために、できるだけ軽いものを欲しがります。デバイスの処理時間を節約し、データ量を削減しますこれらのデータを送信するのに必要な時間などが含まれます。

MQTTを使用してテキストメッセージをバイナリ形式で送信しますが、テキストメッセージのフォーマット方法は? たとえば、CSV形式を使用したり、センサーごとに固定量のバイトを使用したりできます。 変更されたセンサデータのみを送信できました(GPS座標が同じ場合、再度送信しません。日付/時刻は、以前のセンサデータから残りが移動していない場合にのみ秒を送信します)。

私はこれらすべてのニーズに答えるプロトコルを見つけることを期待していました。 BUT only standards I found are xml/json based

これはありますが、私の見解は少し異なります。センサデータ(10秒/ 100x)を(数秒ごとに)送信したいだけです。

私たちは車輪を再発明しないようにこれに答えることは何でも知っていますか?

+0

これがダウンすると、生データを送信するだけではありませんか?おそらくセンチネル値といくつかのパリティビットと?これらのセンサーがどれくらいのデータを生成しているかは、わずか数バイトのように聞こえます。 – Iluvatar

+0

JSONデータは、読みやすさや使いやすさと比べると、それほど効率的ではありません。これは不要な最適化ですか?ちょうど私の2cの価値があります:) – Monza

+1

@ Monza Aldenの美しい答えを見てください。あなたは最初のJSONペイロードのサイズを5で割ることができます:)。私はソフトウェアエンジニアですが、当初は同じと思っていましたが、私はいくつかのハードウェアエンジニアが間違っていると言われました;) – Jeremie

答えて

0

ここにいくつかの考えがあります。

HTTPプロトコルをスキップします。 HTTPはヘッダーに余分なデータを送信し、デバイスが送信しているデータが分かっているので、不要です。 TCPサーバーに接続してデータを送信するだけです。

データをASCIIで表現するのは非効率的です。たとえば、数字4294967295は表現するのに10バイト必要ですが、バイナリでは4バイトしか必要としません。

圧縮しないと、生データはメッセージを正常に送信するために必要なバイト数の最小限の制限です。通常、非常に効率的なプロトコルは、送信されるデータの種類とあらかじめ定義された場所のデータを記述するために、数ビットまたはバイトと同じくらい単純です。

あなたの効率を改善することがトラブルを上回ることが確かであれば、送信者と受信者に既知の1つまたは複数のパケット形式を定義し、TCP接続を介して送信することをお勧めします。 transaction layer for protocols such as PCI Expressを見ると役に立ちます。彼らはあなたが必要とするよりも多くのことを考えていますが、それは一般的にかなりシンプルに保つことです。

{"sensor1":{"coordinates":[12345,12345],"time":"2016-12-9T08:50:11"}"sensor2":{"coordinates":[12345,12345],"time":"2016-12-9T08:50:11"}"sensor3":{"coordinates":[12345,12345],"time":"2016-12-9T08:50:11"}"sensor4":{"coordinates":[12345,12345],"time":"2016-12-9T08:50:11"}} 

同じデータがそうのようなデータストリームと表すことができる:

number of sensors (1 byte) 
sensor1 lat (4 bytes) 
sensor1 lng (4 bytes) 
sensor1 time (4 bytes) 
sensor2 lat (4 bytes) 
sensor2 lng (4 bytes) 
sensor2 time (4 bytes) 
例として

、以下のJSONデータは、おそらく270バイト+ HTTPヘッダの50のバイトを消費します

は、送信ごとにフルタイムを含む合計27バイトです。

あなたが使用している言語を指定した場合は、実際の実装についてより多くのヘルプを得ることができます。

+0

あなたの答えに感謝@Alden! 私はHTTPに同意しますが、そこから抜け出したいが、未処理のTCP接続ではなくMQTTを使用したいと考えています。結局のところ、スケーリング/認証/暗号化を処理するIOTハブソリューションを使用したいので、これに時間を費やすことはありません。 マイクロコントローラのCコード、バックエンド側のJavaスプリングブートアプリケーション 私はPCI Expressを見て、あなたに戻ってきます:) – Jeremie

+1

あなたの答えはみんな! 私は、@ Aldenの提案を組み合わせて使用​​しました。デバイスとバックエンド間の通信用にいくつかのパケットフォーマットを定義し、提供したようにデータを圧縮します。 私はすぐにスティッキングをしたいと思っていたので、標準プロトコル/フレームワークを将来の証明に使用したいと思っていました(そして私はTCP接続を開くことによって車輪を再創造するリスクがありませんでした)。後でMQTTメッセージの本文に入れます – Jeremie

0

GoogleのProtocol Buffersを使用できます。これは、送信されるデータフィールドを含む事前定義されたメッセージに基づいています。データ転送はバイナリで圧縮されています。また、フィールドはオプションとしてマークすることができるので、最後のメッセージ以降に新しいデータを持つものを送る必要があるかもしれません。

1つの欠点は、フレーミングがないことです。 TCP/IPなどのストリーミングを使用している場合は、独自の開始および終了メッセージインジケータを実装する必要があります。

nanopbプロジェクトでは、マイクロコントローラで実行されるメッセージをエンコードおよびデコードするコードを生成できます。