Bürokraten, mitglieder, Administratoren
1.042
Bearbeitungen
Projekt:Deacon: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
notdeacon implementierung; theorie soweit vollständig
Keine Bearbeitungszusammenfassung |
(notdeacon implementierung; theorie soweit vollständig) |
||
| Zeile 28: | Zeile 28: | ||
Die BT bezieht sich auf die Form des Gauß-Filters, den wir vorläufig ignorieren. Der Modulationsindex gibt den Abstand zwischen negativ und positiv gehobener Frequenz bezogen auf die Symbolrate an. Mit der Symbolrate von 1MSymbol/s ergibt sich damit ein Abstand zwischen 450 kHz und 550 kHz, bzw. ein '''Frequenzhub zwischen 225 kHz und 275 kHz'''. | Die BT bezieht sich auf die Form des Gauß-Filters, den wir vorläufig ignorieren. Der Modulationsindex gibt den Abstand zwischen negativ und positiv gehobener Frequenz bezogen auf die Symbolrate an. Mit der Symbolrate von 1MSymbol/s ergibt sich damit ein Abstand zwischen 450 kHz und 550 kHz, bzw. ein '''Frequenzhub zwischen 225 kHz und 275 kHz'''. | ||
Dazu gibt's folgende nette Grafik zu Anschauung (sog. "Augendiagramm") | |||
[[File:gfskparam_corespec.JPG|400px]] | [[File:gfskparam_corespec.JPG|400px]] | ||
| Zeile 116: | Zeile 116: | ||
zum Thema Access Adress gibt es den folgenden Punkt für uns: | zum Thema Access Adress gibt es den folgenden Punkt für uns: | ||
2.1.2 Access Address | '''2.1.2 Access Address''' | ||
... | ... | ||
The Access Address for all other advertising channel packets shall be | The Access Address for all other advertising channel packets shall be | ||
| Zeile 123: | Zeile 123: | ||
Wir haben also damit unsere Broadcastadresse. :)<br> | Wir haben also damit unsere Broadcastadresse. :)<br> | ||
..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 | ..die Absätze zu PDU (Protocol Data Unit) und CRC verweisen uns auf spätere Abschnitte (2.3 und 3.1.1). | ||
'''2.1.4 CRC''' | |||
The PDU is followed by a 24-bit CRC. It shall be calculated over the PDU. The CRC polynomial is defined in Section 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 | Dort finden wir sowohl den allgemeinen Aufbau als auch den des Headers | ||
| Zeile 135: | Zeile 140: | ||
[[File:advpduheaderfields2_corespec.JPG|400px]] | [[File:advpduheaderfields2_corespec.JPG|400px]] | ||
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 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 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. | ||
| Zeile 144: | Zeile 149: | ||
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.<br> | 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.<br> | ||
Der Folgende PDU-Typ sieht vielversprechend aus: | |||
'''2.3.1.3 ADV_NONCONN_IND''' | |||
The ADV_NONCONN_IND PDU has the Payload as shown in Figure 2.8. The PDU '''shall be used in non-connectable and non-scannable undirected advertising events'''. The TxAdd in the advertising channel PDU header indicates whether the advertiser’s address in the AdvA field is public (TxAdd = 0) or random (TxAdd = 1). | |||
The Payload field consists of AdvA and AdvData fields. The AdvA field shall contain the advertiser’s public or random device address as indicated by TxAdd. The AdvData field may contain Advertising Data from the advertiser’s Host. | |||
[[File:ADV_NONCONN_IND_corespec.JPG|250px]] | |||
Der Informationsgewinn aus dem Supplement hält sich in Grenzen: | |||
'''1.2 LOCAL NAME''' | |||
1.2.1 Description | |||
The Local Name data type shall be the same as, or a shortened version of, the local name assigned to the device. The Local Name data type value indicates if the name is complete or shortened. If the name is shortened, the complete name can be read using the remote name request procedure over BR/EDR or by reading the device name characteristic after the connection has been established using GATT. | |||
A shortened name shall only contain contiguous characters from the beginning of the full name. For example, if the device name is ‘BT_Device_Name’ then the shortened name could be ‘BT_Device’ or ‘BT_Dev’. | |||
=> Local Name is der Name; shortened Name ist der gekürzte Name...you don't say | |||
..Auf jeden Fall werden wir den Datentyp verwenden, da dieser praktsich von allen Scanapps angezeigt wird. | |||
Unpraktsicher Weise hat man sich aus irgendeinem Grund dagegen entschieden, die zugehörigen Zahlenwerte nicht in das Dokument selbst aufzunehmen, sondern auf eine Website zu packen: | |||
The values for the data types are listed in Assigned Numbers. | |||
..Dabei bleibt es einem selbst überlassen herauszufinden, welche der etlichen Assigned-Numbers-Listen die richtige ist (die Lösung: "Assigned numbers and GAP"). Hier ist ein Auszug der Liste: | |||
[[File:bleassignednumbers_web3.JPG|800px]] | |||
Für uns sinnvoll wären also die Werte 0x08 oder 0x09. | |||
Damit haben wir also alles für den Inhalt zusammen. Zurück zu den oben erwähnten CRC und Whitening. Das führt uns zu Sektion 3 "Bitstream Processing" | |||
[[File:bitstream_corespec.JPG|600px]] | |||
Da wir Advertising betreiben und entsprechend natürlich keine Verschlüsselung angwenden ergeben sich für uns also nach dem "Zusammenpacken" der Daten 2 Arbeitsschritte, bevor wir diese endlich rausfunken dürfen: | |||
Es muss eine CRC-Prüfsumme über die PDU berechnet und anschließend ein Whiteningverfahren durchgeführt werden. | |||
'''3.1.1 CRC Generation''' | |||
The CRC shall be calculated on the PDU field in all Link Layer packets. If the PDU is encrypted, then the CRC shall be calculated after encryption of the PDU has been performed. | |||
The CRC polynomial is a 24-bit CRC and all bits in the PDU shall be processed in transmitted order starting from the least significant bit. '''The polynomial has the form of x24 + x10 + x9 + x6 + x4 + x3 + x + 1'''. For every Data Channel PDU, the shift register shall be preset with the CRC initialization value set for the Link Layer connection and communicated in the CONNECT_IND PDU. For the AUX_SYNC_IND PDU and its subordinate set, the shift register shall be preset with the CRCInit value set in the SyncInfo field (see Section 2.3.4.6) contained in the AUX_ADV_IND PDU that describes the periodic advertising. '''For all other Advertising Channel PDUs, the shift register shall be preset with 0x555555'''. | |||
Position 0 shall be set as the least significant bit and position 23 shall be set as the most significant bit of the initialization value. '''The CRC is transmitted most significant bit first''', i.e. from position 23 to position 0 (see Section 1.2). | |||
Figure 3.3 shows an example linear feedback shift register (LFSR) to generate the CRC. | |||
[[File:crc_corespec.JPG|600px]] | |||
Das zu verwendende Polynom ist also x^24 + x^10 + x^9 + x^6 + x^4 + x^3 + x + 1 und der Initialwert ist in unserem Fall 0x555555. | |||
'''3.2 DATA WHITENING''' | |||
Data whitening is used to avoid long sequences of zeros or ones, e.g. 0000000b or 1111111b, in the data bit stream. '''Whitening shall be applied on the PDU and CRC fields of all Link Layer packets''' and is performed after the CRC in the transmitter. De-whitening is performed before the CRC in the receiver (see Figure 3.1). | |||
The whitener and de-whitener are defined the same way, using a 7-bit linear feedback shift register with the '''polynomial x7 + x4 + 1'''. '''Before whitening or dewhitening, the shift register is initialized with a sequence that is derived from the channel index''' (data channel index or advertising channel index) in which the packet is transmitted in the following manner: | |||
• Position 0 is set to one. | |||
• Positions 1 to 6 are set to the channel index of the channel used when | |||
transmitting or receiving, from the most significant bit in position 1 to the least significant bit in position 6. | |||
For example, if the channel index = 23 (0x17), the positions would be set as follows: | |||
Position 0 = 1 | |||
Position 1 = 0 | |||
Position 2 = 1 | |||
Position 3 = 0 | |||
Position 4 = 1 | |||
Position 5 = 1 | |||
Position 6 = 1 | |||
[[File:whitening_corespec.JPG|400px]] | |||
Das Whitening ist also mit der PDU sowie auch den zuvor generierten CRC Daten durchzuführen. Das Polynom ist x^7+x^4+1. Der Initialswert hängt von gerade verwendeten Kanal ab. Dabei ist zu beachten, dass der "Channel Index" nicht das gleiche wie die Channel No. ist! Der "erste" Kanal bei 2402 MHz ist nicht etwa Channel Index 0, sondern 37! (Vergleiche Tabelle weiter oben) | |||
Warum das Whitining? Das Verfahren dient dazu, sicherzustellen, dass keine zu lange Aneinanderreihung von Nullen oder Einsen zu übertragen sind. Das macht die Demodulation vor allem für simple Empfängertypen deutlich einfacher.<br> | |||
Beispielsweise kann man FSK sehr bequem mit einem sog. Flankendiskriminator Demodulieren: Das Signal wird wie der Name bereits andeutet so in einen Filter geführt, dass dieses frequenzabhängig unterschiedlich stark gedämpft wird, da es sich eben in der "Flanke" und nicht im normalen Durchlassbereich befindet. Dadurch wird aus der Frequenzmodulation eine Amplitudenmodulation. Diese kann dann sehr einfach demoduliert werden, indem man den durchschnittlichen Pegel mit dem aktuellen vergleicht. Das funktioniert aber nur, solange der Pegel nicht zu lange konstant bleibt (nur 1en oder 0en übertragen werden) und der Durchschnitt daher zu weit abdriftet. | |||
=== Zusammenfassung === | |||
Es gilt also folgendes zu tun: <br> | |||
Wir "packen" ein Datenpaket, bestehend aus 1 Byte Praeamble (0b10101010) gefolgt von 4 Byte Broadcast-Adresse (0x8E89BED6). Dann kommt die PDU, die ihrerseits aus 2 Byte Header (1 Byte PDU-Typ = 0b0010, txaddr random =1; 1 Byte Länge der PDU), und der Payload, die wiederum aus der (zufällig gem. obiger Vorgaben) generierten Hardwareadresse unseres Beacons (6 Byte) und den Advertisingdaten besteht. In unserem Fall ist das nur der Devicename den wir zur Textübermittlung einsetzen. Diese bestehen somit aus einem Byte für die Länge (für Typ+Daten), einem Byte mit dem Typ (0x09) und anschließend dem Text im ASCII-Format.<br> | |||
Anschließend wird die CRC für die PDU berechnet (Initalwert 0x555555), womit das Paket vollständig ist. Vor dem Versenden muss für PDU + CRC noch das Whiteningverfahren durchgeführt werden (Initialwert abhängig von Kanal). Die dabei resultierenden Bits können direkt an den Modulator / den Sender geführt werden.<br> | |||
Dieser arbeitet (mindestens) auf einem der Adverstingknaäle (z.B. Kanal 37 auf 2402 MHz) mit einem Frequenzhub on 250 kHz. Der im Standard Vorgegebenen Mindestabstand für Advertisingpakete beträgt dabei 20ms + 0-10ms Zufallsintervall. | |||
== Umsetzung == | |||
=== (absolutely) notDeacon === | |||
Ich habe mich entschieden als ersten Schritt genau das Gegenteil des eignetlichen Plans zu machen: Den Beacon praktisch vollständig in Software umsetzen.<br> | |||
Ziel dabei ist zum Einen zu checken, ob meine Interpretation des Standards soweit korrekt ist und zum Anderen damit eine Referenzimplementierung zu schaffen, gegen die ich Teilschritte der eigentlichen Implementierung testen kann.<br> | |||
Ursprünglich war mein Plan den Nordic Chip auf meinem von der Bachelorarbeit verbliebenen Evaluationboard als Sender zu verwenden, da dessen Transceiver auch direkt angesteuert werden kann. Da ich ja aber inzwischen meine LimeSDR Hardwarer herumliegen habe (mit der ich onehin spielen wollte), hab ich diese verwendet. Das ermöglicht mir ein bisschen mehr mit der Modulation zu spielen und evtl später Hardwareansätze damit näherungsweise zu Simulieren und auf Brauchbarkeit zu testen. Außerdem konnte ich daher Evaluationboard mit der entsprechenden Firmware von Nordic als BLE-Sniffer mit Wireshark zur Fehlerdiagnose verwenden :-). | |||
Nach anfänglicher Problemchen aufgrund von Verwirrung wegen der Bitorderproblematik und Huddelei meinerseits hab ich den Code inzwischen zum laufen bekommen. Hier zu sehen Wireshark aufnahmen mit dem BLE-Sniffer mit Fehlerhafter wie korrekter CRC sowie das Suchergebnis einer BLE-Scan-App auf meinem Handy. | |||
[[File:notdeacon_crcerr.PNG|600px]][[File:notdeacon_crcok.PNG|600px]][[File:notdeacon_handy.png|200px]] | |||
Code folgt | |||
==Quellen== | ==Quellen== | ||
* [https://www.bluetooth.com/specifications/specs/core-specification-5/ Bluetooth Core Specification v5.0] | |||
* Bluetooth Core Specification v5.0 | * [https://www.bluetooth.com/specifications/specs/?status=all&keyword=supplement&filter= Supplement to the Bluetooth Core Specification v8] | ||
* Supplement to the Bluetooth Core Specification v8 | * [https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile/ Assigned Numbers and GAP (Bluetooth SIG)] | ||
==Verantwortlicher/Ansprechpartner== | ==Verantwortlicher/Ansprechpartner== | ||
Karsten | Karsten | ||