説明
デバイスの外観と、説明されていない回路の種類。 ロシア語を含むインターネットでは、記載されている無線モジュールに関する情報が満載です。 私の場合、NXP LPC1343マイクロコントローラーが制御に使用されたとしか言えません（そのため、ファームウェアを以下に示します）。
いつものように、奇跡は起こりません。この例は「現状のまま」の形で動作することを望みませんでした。 まず、ページに明確なフォーマットの損傷があり、次に、長さバイトに問題があることがすぐにわかります。 他のタイプミスや不正確な記述は説明にありますが、私は推測できました。 ただし、短い編集の後、すべてが機能しました。
BLEデバイスは他のすべての「青いクローブ」とは非常に異なります。Androidの標準的なデバイス検索ではBLEが検索されないことに言及するだけで十分です。閲覧するには別のアプリケーションが必要です。 BLEデバイスは、Bluetoothテクノロジーの独立した部門であり、実際、これは別の標準です。 どうやら、2.4 GHzの低電力トランシーバーの機能に着目して開発されたようです。 したがって、最終的な類似性。
また、類似点は次のとおりです。
- 同じ動作周波数は2.4GHzで、1Mbps速度とクロスオーバーチャネルグリッドをサポートしています。
- 同一バイトの開始バイトは10101010または01010101（プリアンブル）です。
- 同じ信号変調： GFSK
- 4バイト単位でnRF24l01アドレッシングを設定する機能。
ただし、違いは次のとおりです。
- さまざまなCRCアルゴリズム。 幸いなことに、nRF24l01では、それをオフにして、マイクロコントローラーでプログラムによって計算を行うことができます。
- nRF24l01は、各送信後にPLLを無効にします。 これにより、プロトコルの実装にブタが配置されます。 PLLの再起動にはかなりの時間がかかります。
- BLEは、最大39バイトのデータパケットをサポートします。 nRF24l01の場合、この値は32バイトに制限されています。
本格的なBLEプロトコルの最後の段落のために、上げることはできません。 ただし、デバイス検索プロセスに関係する正しいブロードキャストパッケージをコンパイルできます。
パッケージコード：
buf[L++] = 0x42; //PDU type, given address is random buf[L++] = 0x11; //17 bytes of payload buf[L++] = MY_MAC_0;//0xEF buf[L++] = MY_MAC_1;//0xFF buf[L++] = MY_MAC_2;//0xC0 buf[L++] = MY_MAC_3;//0xAA buf[L++] = MY_MAC_4;//0x18 buf[L++] = MY_MAC_5;//0x00 buf[L++] = 2; //flags (LE-only, limited discovery mode) buf[L++] = 0x01; buf[L++] = 0x05; buf[L++] = 7; //name buf[L++] = 0x08; buf[L++] = 'n'; buf[L++] = 'R'; buf[L++] = 'F'; buf[L++] = ' '; buf[L++] = 'L'; buf[L++] = 'E'; buf[L++] = 0x55; //CRC start value: 0x555555 buf[L++] = 0x55; buf[L++] = 0x55; //... btLePacketEncode(buf, L, chLe[ch]); // crc calculate
プログラムが行うことは1つだけです。特別な方法で無線モジュールを初期化し、パケットをコンパイルして送信します。 これは、電話が検索中のデバイスを表示するのに十分です。
使い方
電話がアプリケーションを見た後、すぐに疑問が生じました。この「偽物」をどうにかして使用することは可能ですか？
nRF24l01チップの制限により、本格的なBLEプロトコルを上げて、電話が何かを「見る」という事実で終わることはできませんが、何らかの方法で動作することはできません。 したがって、デバイスへのデータ転送はすぐに記録されますが、電話へのデータ転送はどうですか？ 電話は名前とポピーの住所を決定しますが、これはすでに何らかの情報です。
また、データを転送することもできます。 これを行うには、バッファにフィールドを追加します。 タグMANUFACTURER_DATA = 0xFFはこれに最適です。 一度に転送できるデータは32バイト以下（nRF24l01モジュールの制限）であり、データの一部はBLEサービス構造の送信に費やされます。 約32-6-3-3 = 20バイトがネットに残ります。 これらのうち、2バイトがヘッダーに送られるため、18バイトの「私たちの」データが存在する可能性があります。 しかし、匿名デバイス用にこの計算を行ったことを考慮する価値があります。
用途
理論的には、このハッキングは実際のデバイスで使用できます。 nRF24l01のコストは、True-BLEモジュールよりも大幅に低くなっています。 スマートフォンは任意のセンサーからデータを送信でき、BLEの場合のように、センサーはバッテリー駆動です。
最も原始的なATtiny13とnRF24l01を束ねると、ペニーデバイスが手に入ります。 これらの数十個または数百個を大きな部屋（ショッピングセンターなど）に配置したら、アプリケーション内で電話の所有者がどこにいるかを正確に示すローカルポジショニングシステムを展開できます。
残念ながら、質問は私に開かれています。スマートフォン自体の消費量はどうなりますか。 それでも、デバイスとの通信は確立されず、常にスキャンする必要があります。 誰かがこのトピックに精通していて、コメントできるかもしれません。
ANT +
さらに、nRF24l01とANT +デバイスの相互作用を実装する可能性を調査しました。 ここでは、残念ながら、すべてが失われます。 BLEとnRF24l01の同期バイトが同じ場合、ANTプロトコルの場合は何も機能しません。後者は、それらとは異なるベクトルを持ちます。
参照資料
- オリジナル記事： 「ビットバンギング」Bluetooth Low Energy
- BluetoothLeGattユーティリティの修正バージョン。 検索時のパッケージ本体の出力が追加されました。 この本文では、アプリケーションによって送信されたデータが表示されます。 ユーティリティ操作画面は上に表示されています。
- モジュールを操作するためのソースコード 。
- ファームウェアマイクロコントローラーLPC1343（USB-SPIブリッジ）とのバイナリ 。