Projekt:Deacon

Deacon Status: unstable
Beschreibung	Diskret aufgebautes Radio für BLE-Beacon
Ansprechpartner	Karsten

Diskret aufgebaute Sender und Emfänger für BLE-Beacons

Übersicht

Da ich mich in letzter Zeit aus diversen Gründen recht viel mit dem BLE-Stack und der Core Spec auseinandergesetzt hab, viel mir auf, dass der Physical Layer, also das Radio und auch der Teil knapp darüber an und für sich ziemlich simpel gestrickt sind (was zugegeben an sich wegen der Anforderungen "Low Energy" und "Low Cost" natürlich eigentlich auf der Hand lag).
Mit binärem (G)FSK könnte die Modulation eigentlich kaum einfacher sein. Das Paketformat für die von Beacons genutze Advertising genutzte Pakete ist recht kompakt und die einzig nötigen Verarbeitungsschritte des Link Layers (CRC-Kalkulation und Whitening) ziemlich überschaubar. Es sollte kein Problem sein mit einem Arduino Uno oder ähnlichem Pakete zurechtzumachen und z.b. per spi-bus mit der benötigen Rate von 1MHz, bzw 1MSymbol/s rauszuhauen.
Obwohl Advertisingpakete normalerweise sequenziell über die 3 dedizierten Kanäle versendet werden, ist es möglich (und sogar von der Spec erlaubt) auf nur einem Kanal zu senden. Da Scanner normalerweise natürlich auch auf allen Kanälen suchen werden sie den Beacon trotzdem finden. Umgekehrt wird auch ein Scanner, der nur einen Kanal absucht normale BLE-Geräte finden, da sie ja auf allen Kanälen unterwegs sind.Das "richtige" Frequency-Hopping findet nur auf den Datenkanälen statt, die erst von verbundene BLE-Devices genutzt werden
Sender und Empfänger können also für einen festen Kanal gebaut werden, was die Geschichte nicht unerheblich vereinfacht. Das einzige wirkliche Problem dürfte der 2,4 Ghz Teil sein.

Das ganze dient vor allem dem Spaß am Experiment und im Erfolgsfall als Teil des Amateurfunk Workshops...und als Ausgangsbasis für ein wesentlich verrückteres Projekt

Was ist zu tun?

Im folgenden arbeiten wir uns durch die Bluetooth Spezifiaktion 5.0 bis wir alles zusammen haben, das wir für den Beacon brauchen. Glücklicher Weise sind nicht all der fast 3000 Seiten relevant: Richtig los gehts mit BLE erst mit Vol.6 auf Seite 2528. Der Teil davor bezieht sich hauptsächlich auf die klassischen Varianten und enthält nur ein paar gemeinsam genutzte Definitionen, wie z.B. das Datenformat fürs Advertising.

Der analoge Teil

Volume 6 beginnt direkt mit dem wichtigsten Teil für dieses Projekt - dem genutzten Frequenzband und der Kanaleinteilung:

The LE system operates in the 2.4 GHz ISM band at 2400-2483.5 MHz. The LE system uses 40 RF channels. These RF channels have center frequencies 2402 + k * 2 MHz, where k = 0, ..., 39. 

So weit so gut..der Frequenzbereich ist wenig überraschen. Interessant ist evtl dass BLE den Bereich in 40 Kanäle einteilt, während das klassische Bluetooth noch 79 Kanäle verwendet hat. Weiter gehts mit der Klasseneinteilung der möglichen Sendeleistung von Geräten, was uns eher weniger interessiert. Als nächstes kommt ab Seite 2537 dann der wichtigste Teil: Teil A - Physical Layer 3.1 Die Modulation.

The modulation is Gaussian Frequency Shift Keying (GFSK) with a bandwidth-bit period product BT=0.5. The modulation index shall be between 0.45 and 0.55. A binary one shall be represented by a positive frequency deviation, and a binary zero shall be represented by a negative frequency deviation.

dazu gibt's folgende nette grafik zu anschauung

und weiter

For each transmission the minimum frequency deviation,
Fmin = min { |Fmin+ | , Fmin- }
which corresponds to a 1010 sequence, shall be no smaller than ±80% of the frequency deviation with respect to the transmit frequency, which corresponds to a 00001111 sequence.
The minimum frequency deviation shall never be less than 185 kHz when transmitting at 1 megasymbol per second (Msym/s) symbol rate and never be less than 370 kHz when transmitting at 2 Msym/s symbol rate. The symbol timing accuracy shall be better than ±50 ppm. The zero crossing error is the time difference between the ideal symbol period and the measured crossing time. This shall be less than ±1/8 of a symbol period.

3.3 geht nochmal ein wenige genauer auf Toleranzen ein

The deviation of the center frequency during the packet shall not exceed ±150 kHz, including both the initial frequency offset and drift. The frequency drift during any packet shall be less than 50 kHz. The drift rate shall be less than 400 Hz/µs.

Damit haben wir die wichtigsten Anforderungen für unseren Sender zusammen...Sendefrequenzbereich, Modulationsart (binäre FM), Frequenzhub , Toleranzen, Symbolrate (1 MSymbol) Nur das mit den Kanälen sollte noch ein wenig genauer festgelegt werden. Die folgenden Angaben zu Störabständen etc ignorieren wir mal vorläufig und auch die Anforderungen für Sende- und Empfangsleistung können uns erstmal egal sein. ..und schon sind wir bei Teil B - Link Layer Die Dokumentation der untersten logischen Schicht beginnt zunächst mit den verschiedenen Zuständen für BLE-Devices, was für uns eher weniger von belang ist, da wir uns nur für den Advertising zustand interessieren. Interessant ist vllt allenfalls der Abschnitt

1.1.2  Devices supporting only some states
Devices supporting only some link layer states or only one of the two roles within the Connection State are not required to support features (including supporting particular PDUs, procedures, data lengths, or HCI commands or particular features of an HCI command) that are only used by a state or mode that the device does not support.

Wenn auch nur von eher theoretischer Art..es ist zumindest nett dass wir vermutlich theoretisch den Standard zumindest in der Hinsicht erfüllen könnten.

Abschnitt 1.4 kommt nochmals auf die eingeteilten Kanäle zurück

1.4   PHYSICAL CHANNEL
As specified in [Vol 6] Part A, Section 2, 40 RF channels are defined in the 2.4GHz ISM band. These RF channels are allocated into three LE physical channels: advertising, periodic, and data. The advertising physical channel uses all 40 RF channels for discovering devices, initiating a connection and broadcasting data. These RF channels are divided into 3 RF channels, known as the "primary advertising channel", used for initial advertising and all legacy advertising activities, and 37 RF channels, known as the "secondary advertising channel", used for the majority of the communications involved. 
The data physical channel uses up to 37 (see Section 4.5.8) RF channels for communication between connected devices. Each of these RF channels is allocated a unique channel index (see Section 1.4.1). The periodic physical channel uses the same RF channels as the secondary advertising channel over the advertising physical channel.
...

Wir erfahren dass 3 der Kanäle für das "primäre" Advertising reserviert sind, während die restlichen 37 Kanäle für Daten und (seit 5.0) für "sekundäres Advertising" genutzt werden. Vor 5.0 war das zugegeben etwas deutlich formuliert. Die Tabelle auf Seite 2561 teilt uns mit, welche der 3 Kanäle für Advertising vorgesehen sind:

Also die Kanäle 0; 12 und 39 - bzw. die Frequenzen 2402 MHz, 2426 MHz und 2480 Mhz. Da im nicht Verbundenen Zustand noch kein fancy Frequenzgehoppel möglich ist wurden die Kanäle so gelegt, dass sie zumindest in den USA in den am geringsten von WLAN belegten Bereichen liegen.

Zusammenfassung: tbd

Der digitale Teil

Jetzt gehts erstmal wieder zurück auf Seite 2555. Hier beschäftigt sich die Spec mit der Bit-Reihenfolge. Dabei gibt es folgende Besonderheit zu beachten: die CRC-Prüfsumme wird in einer anderen Reihenfolge übertragen als der Rest!

1.2   BIT ORDERING
The bit ordering when defining fields within the packet or Protocol Data Unit (PDU) in the Link Layer specification follows the Little Endian format. The 
following rules apply:
• The Least Significant Bit (LSB) corresponds to b0
• The LSB is the first bit sent over the air
• In illustrations, the LSB is shown on the left side
Furthermore, data fields defined in the Link Layer, such as the PDU header fields, shall be transmitted with the LSB first. For instance, a 3-bit parameter X=3 is sent as: 
b0b1b2 = 110

...

Multi-octet fields, with the exception of the Cyclic Redundancy Check (CRC) and the Message Integrity Check (MIC), shall be transmitted with the least significant octet first. Each octet within multi-octet fields, with the exception of the CRC (see Section 3.1.1), shall be transmitted in LSB first order. For example, the 48-bit addresses in the advertising channel PDUs shall be transmitted with the least significant octet first, followed by the remainder of the five octets in increasing order.
Multi-octet field values specified in this specification (e.g. the CRC initial value in Section 2.3.3.1) are written with the most significant octet to the left; for example in 0x112233445566, the octet 0x11 is the most significant octet.

Danach folgen die Device-Adressen. Es existieren verschiedene Typen: öffentliche (kostenpflichtige registrierung bei der BT SIG erforderlich) und zufällige, die wiederum in statisch und privat unterteilt werden. Private Adressen verwenden ein spezielles System durch die sich gekoppelte Geräte trotz regelmäßig von außen betrachtet scheinbar zufällig ändernder Adresse erkennen können, um z.B. Tracking durch Dritte zu vermeiden. Was uns interessiert ist die statische variante - eine einmalig zufällig erzeuge Adresse.

1.3.2.1  Static Device Address
 A static address is a 48-bit randomly generated address and shall meet the following requirements:
• The two most significant bits of the address shall be equal to 1
• At least one bit of the random part of the address shall be 0
• At least one bit of the random part of the address shall be 1
A device may choose to initialize its static address to a new value after each power cycle. A device shall not change its static address value once initialized until the device is power cycled.
Note: If the static address of a device is changed, then the address stored in peer devices will not be valid and the ability to reconnect using the old address will be lost.

Wie wir sehen haben wir im großen und ganzen 46 für unsere Zufallszahl, da die oberen beiden als 1 festgelegt wurden. Die vielleich etwas willkürlich wirkende Anforderung dass 0 und 1 je mindestens ein mal vorkommen sollen hat durchaus einen Hintergrund, auf den ich später noch eingehen werde, wenn wir zu dem sog. Whitening-Verfahren kommen.

Auf Seite 2652 gehts mit Abschnitt 2 ans Eingemachte..das Paketformat

Was das mit den Klammern soll?

The preamble is 1 octet when transmitting or receiving on the LE 1M PHY and 2 octets when transmitting or receiving on the LE 2M PHY. The Access Address is 4 octets. The PDU range is from 2 to 257 octets. The CRC is 3 octets.

Wir verwenden natülich die bewährte 1M-Variante und nicht den neumodischen (seit 5.0 optional verfügbaren) 2M Kram! Die Maximale PDU Größe ist übrigens erst seit 4.2 so hoch, vorher betrug sie ca 30 Byte. ...Und zur Reihenfolge:

The Preamble is transmitted first, followed by the Access Address, followed by the PDU followed by the CRC. The entire packet is transmitted at the same symbol rate (either 1 Msym/s or 2 Msym/s modulation).

Die Spec ist auch so nett, uns den Sinn der Präambel zu erklären

2.1.1  Preamble
All Link Layer packets have a preamble which is used in the receiver to perform frequency synchronization, symbol timing estimation, and Automatic Gain Control (AGC) training. 

dann gibt es Details zur Umsetzung:

The preamble is a fixed sequence of alternating 0 and 1 bits. For packets transmitted on the LE 1M PHY, the preamble is 8 bits; for packets transmitted on the LE 2M PHY, the preamble is 16 bits. The first bit of the preamble (in transmission order) shall be the same as the LSB of the Access Address. The preamble is shown in Figure 2.2.

..oder anders formuliert muss die Präambel immer so Enden dass ein Bitwechsel zwischen Präambel und der darauf folgenden Adresse stattfindet (siehe Bild)!

zum Thema Access Adress gibt es den folgenden Punkt für uns:

2.1.2  Access Address
...
The Access Address for all other advertising channel packets shall be 
10001110100010011011111011010110b (0x8E89BED6). 
....

Wir haben also damit unsere Broadcastadresse. :)
..die Absätze zu PDU (Protocol Data Unit) und CRC verweisen uns auf spätere Abschnitte (2.3 und 3.1.1). Da uns die folgenden erläuterungen des Coded PHY (long range modus von BT 5.0) nicht belangen springen wir also direkt weiter zu 2.3 ADVERTISING CHANNEL PDU (Seite 2567) Dort finden wir sowohl den allgemeinen Aufbau als auch den des Headers

..und eine Tabelle mit den Verfügbaren Typen (eigentlich zwei, aber die zweite enthält nur BT 5 Typen für "erweitertes" advertising)

ergänzender Text von relevanz:

The ChSel, TxAdd and RxAdd fields of the advertising channel PDU that are contained in the header contain information specific to the PDU type   defined for each advertising channel PDU separately. If the ChSel, TxAdd or RxAdd fields are not defined as used in a given PDU then they shall be considered Reserved for Future Use.
The Length field of the advertising channel PDU header indicates the payload field length in octets. The valid range of the Length field shall be 1 to 255 octets.

The Payload fields in the advertising channel PDUs are specific to the PDU Type and are defined in Section 2.3.1 through Section 2.3.4. The PDU Types marked as Reserved for future use shall not be sent and shall be ignored upon receipt.

Within advertising channel PDUs, advertising data or scan response data from the Host may be included in the Payload in some PDU Types. The format of this data is defined in [Vol 3] Part C, Section 11.

Wir müssen uns also erstmal schlau machen welchen PDU Typ wir verwenden wollen um dann herauszufinden, wie das exakte Format aussieht. Außerdem müssen wir einen Abstecher "zurück" zu Volume 3 (zur erinnerung: wir befinden uns in Volume 6) machen, um das Datenformat für die "Nutzdaten" zu erfahren.

Verantwortlicher/Ansprechpartner

Karsten