指向性Bluetoothビーコン(iBeacon)およびフルモバイルファックス

反転は素晴らしいことです! 一つのことを発明し、それを取り出して裏返しにすると、それほど興味深い結果は得られません。 最初に一つのことでこれをやったが、TRIZ(発明の問題を解決する理論)には、「反転または逆の類推」などの手法があることがわかった。 生きて学びます。







しかし、これはすべて理論であり、実践はすべてをその場所に置きます...







Beacons Bluetooth Low EnergyまたはiBeaconは今や異常ではありません。 それらは駅、空港、博物館、ショッピングセンターで見つけることができます。 無線技術者として、私はビーコン、特にビーコン用のアンテナの設計に参加しました。 これは最初は面白いことですが、その後は退屈になります。 目立つものは何もありません。新しいものを発明することはできません。 そして、それは私に夜明けをもたらしました!







私は自分の方向探知機( 1回2回 )を取り、後ろから見ました。 しかし、それをビーコンにしたらどうでしょうか? ここで、この方向探知機は2つのアンテナで構成されていることを読者に思い出させる必要があります。1つは滑らかな放射パターン、もう1つは急激な変化です。







画像







これは放射パターンのスライスです。 3Dでは、次のようになります。













方向探知機は、2つのアンテナ間のレベルの差に「焦点を合わせます」。 詳細に興味がある場合は、 Githubをご覧ください







以下は、方向探知ロジックを備えた小さなコードの一部です。







両方のアンテナからレベルを取得します。 取得したレベルを平均化してから、差を計算する必要があります。 実際、これは信号の違いではなく、それらの関係です。 ただし、 デシベル単位で測定すると、違いが生じます。







バッファへのレベルの書き込み
public boolean handleInfo(WFPacket data) { if (data.apName.equals(ssid) && data.mac.equals(mac)) { int idx = data.antIdx; if (0 <= idx && idx <= 1) { mLevels.get(idx).addLast(data.power); while (mLevels.get(idx).size() > avgCount) { mLevels.get(idx).removeFirst(); } needRecalc = true; print(); } else { Log.d(TAG, "LevelCalculator.HandleInfo() Bad rcvIdx: " + data.antIdx); } } else { return false; } return needRecalc; }
      
      





差の平均化と計算
  public double getAvg() { if (needRecalc) { for (int idx = 0; idx < 2; idx++) { double sum = 0d; for (Double x : mLevels.get(idx)) { sum += x; } int count = mLevels.get(idx).size(); if (count != 0) { sum /= count; } avgLevels[idx] = sum; } avgDiff = Math.pow(10.0, (avgLevels[1] - avgLevels[0]) * 0.1 + 2.5); //    needRecalc = false; } return avgDiff; }
      
      





「差異」の処理。 両方のアンテナのレベルが「強く」異なる場合、ある程度の精度(プラスまたはマイナスの靱皮)でソースに向けられます。 これに等しいものは、現時点では「強い」と判断されている 科学的な突く方法 実験的に。







private void updateLevelDiff(double levelDiff)
  private void updateLevelDiff(double levelDiff) { long deltaTime = System.currentTimeMillis() - lastUpdateTime; int progress = (int) Math.floor(100.0 * levelDiff); //       //   if (deltaTime > TIME_PERIOD) { //        if (progress < mThreshold) { //      ,         addBearing(); numUpdates++; } lastUpdateTime = System.currentTimeMillis(); } //   GUI }
      
      





そして今、私たちは反転します!







1つの番号を持つiBeaconビーコンを1つのアンテナで放射し、もう1つのアンテナで別のアンテナから放射するようにします。 次に、モバイルデバイスで両方のビーコンのレベルを測定し、ビーコンアンテナの焦点にどれだけ近いかによって違いを判断できます。 波の到来方向の位置決めが判明します。







Bluetoothバージョン5規格では、同様の高精度測位の方法である「Angle of Departure」も発表されています。 彼らはまだこの方法の正確な説明に達していません、彼らは将来のバージョンで約束します。







洗練された形で、作品はローラーで説明することができます: 12







アプリケーションは、レベルの差にしきい値を設定します。これにより、モバイルデバイスが、アンテナの平面の法線と一致する軸を持つ架空の円錐にあると判断されます。













灯台自体は次のようになります。













そして、ここに内部のレンダリングがあります:













ハンサムですね。 WiFi方向探知機、およびBluetooth SoC nRF51822などのアンテナ内部。 しかし、すべてが無駄でした...







さらに、物語はfakapに入ります。これは、Nexus 5スマートフォンで動作し、少なくとも同じように動作する別のガジェットを見つけるのは非常に簡単ではなかったという事実です。 いいえ、Samsung Galaxy S7、Lenovo Phab 2 Proであり、リストはここで終わります。 友人や知人と一緒に見つけるための「良い」ガジェットはもっと失敗しました。 「悪い」のは、Samsung S4 miniに注目することができます。







もちろん、灯台はチェックされました。 最小間隔で2つのアンテナに順番にパケットを送信します。 測定が互いにわずかな間隔の時間に関連するように、短い間隔が必要です。 そうしないと、それらを相互に関連付けることができなくなります。







素晴らしいWireSharkを使用して、Bluetoothスニファーからログが記録されました。 ログを分析すると、すべてが正しく放射され、時間間隔とレベルが正常であることがわかります。 オシロスコープはまた、灯台の出口で不明なものを何も示しませんでした。







ただし、多数のガジェットでは、うまく機能しません。 問題は測定の損失です。 パケットのペアを受信する診断は、 Androidアプリケーションに組み込まれました。 品質指標は、ペアのパッケージの割合でした。 そのため、一部のガジェットでのみ80〜100のインジケータが観察されました。 テストされたモバイルデバイスの残りのサンプルでは、​​インジケータは20〜60でした。動きでは、レベルの比率は正確に測定されませんでした。 パケットの放射の頻度を増やすことによってこれを補う試みがありましたが、これは結果を与えませんでした。 Android内部の何かが通常の測定を妨害します。







このすべての不名誉の源はGithubで利用可能です。







iOSで状況が良くなるという希望はほとんどありません。 モバイルデバイスのスペクトルで少なくともより均一です。







問題が何であるかを理解し、解決策を提供する専門家がいることも期待されています。







そして今、私はこのアイデアが機能しないことを非常に残念に思います。








All Articles