mirror of
https://github.com/isometimes/rpi4-osdev
synced 2024-11-22 02:00:40 +00:00
Fixing part7 typo
This commit is contained in:
parent
10ecd8ca76
commit
f52c4079a9
1 changed files with 1 additions and 1 deletions
|
@ -124,7 +124,7 @@ If you look in _kernel.c_, you'll see the main bulk of our scanning code. Exactl
|
||||||
|
|
||||||
There may be one or more **ad report** in each event, and each contains the 48-bit Bluetooth address of the associated device e.g. `AA:BB:CC:DD:EE:FF` (bd_addr) as well as the data. I found a great article on the [Advertising Data Format from Silicon Labs](https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/02/10/bluetooth_advertisin-hGsf). Reading this will help you interpret my decode routines.
|
There may be one or more **ad report** in each event, and each contains the 48-bit Bluetooth address of the associated device e.g. `AA:BB:CC:DD:EE:FF` (bd_addr) as well as the data. I found a great article on the [Advertising Data Format from Silicon Labs](https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/02/10/bluetooth_advertisin-hGsf). Reading this will help you interpret my decode routines.
|
||||||
|
|
||||||
Right now, I'm just printing the bd_addr (using the convenient `uart_hex` routine added to _io.c_), the ad report type & length, and the friendly/full device name if received (ad_type 0x08 & 0x08 respectively).
|
Right now, I'm just printing the bd_addr (using the convenient `uart_hex` routine added to _io.c_), the ad report type & length, and the friendly/full device name if received (ad_type 0x08/0x09 respectively).
|
||||||
|
|
||||||
Proof of life!
|
Proof of life!
|
||||||
--------------
|
--------------
|
||||||
|
|
Loading…
Reference in a new issue