content: entries on bluetooth
This commit is contained in:
parent
5b44022f99
commit
7870d00bab
3 changed files with 59 additions and 0 deletions
|
|
@ -2,6 +2,7 @@
|
||||||
tags:
|
tags:
|
||||||
- networks
|
- networks
|
||||||
- procedural
|
- procedural
|
||||||
|
- bluetooth
|
||||||
- Linux
|
- Linux
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
|
||||||
20
zk/Bluetooth_frequency_hopping.md
Normal file
20
zk/Bluetooth_frequency_hopping.md
Normal file
|
|
@ -0,0 +1,20 @@
|
||||||
|
---
|
||||||
|
tags:
|
||||||
|
- bluetooth
|
||||||
|
- networks
|
||||||
|
- radio
|
||||||
|
---
|
||||||
|
|
||||||
|
# Bluetooth frequency hopping
|
||||||
|
|
||||||
|
Bluetooth transmits on the 2.5GHz frequency band. As this is an unlicenced band
|
||||||
|
there can be interference to the signal and interception.
|
||||||
|
|
||||||
|
To get around this, bluetooth engages in **frequency hopping**. It rapidly
|
||||||
|
switches its channel of transmission between 79 distinct frequences within the
|
||||||
|
2.5GHz band where each channel occupies a bandwidth of 1MHz.
|
||||||
|
|
||||||
|
Each available band is divided into time slots. This allows multiple devices to
|
||||||
|
communicate simultaneously without interfering with each other (that much). The
|
||||||
|
[master device](./Bluetooth_piconet.md) controls the sequencing and
|
||||||
|
synchronisation of the time slots.
|
||||||
38
zk/Bluetooth_piconet.md
Normal file
38
zk/Bluetooth_piconet.md
Normal file
|
|
@ -0,0 +1,38 @@
|
||||||
|
---
|
||||||
|
tags:
|
||||||
|
- bluetooth
|
||||||
|
- networks
|
||||||
|
---
|
||||||
|
|
||||||
|
# Bluetooth piconet
|
||||||
|
|
||||||
|
Bluetooth devices connect via a micro-network known as a "piconet". Devices
|
||||||
|
connect to each other in a master/slave relationship (since renamed
|
||||||
|
"central/peripheral").
|
||||||
|
|
||||||
|
Prior to the establishment of a piconet, devices remain in discoverable/scanning
|
||||||
|
mode.
|
||||||
|
|
||||||
|
At least one master and one slave is required to make a piconet however a master
|
||||||
|
can have multiple slaves simultaneously (e.g. a computer with keyboard, mouse,
|
||||||
|
speakers etc).
|
||||||
|
|
||||||
|
The master controls the connection timing and frequency modulation (necessary
|
||||||
|
for the Bluetooth protocol) and the slave synchronises its clock with the
|
||||||
|
master's. A slave can have its own controls (e.g. a set of headphones with
|
||||||
|
playback controls) but it is the master that orchestrates the action.
|
||||||
|
|
||||||
|
What does this mean?
|
||||||
|
|
||||||
|
Take a mouse as a slave that is sending the click data to the master it is
|
||||||
|
paired with. The mouse's microcontroller controls the click and what it "means"
|
||||||
|
(although this is handled at a level up, in the application layer) but _when_
|
||||||
|
the data is processed is managed by the master. The master controls:
|
||||||
|
|
||||||
|
- when devices can transmit
|
||||||
|
- what frequency they use
|
||||||
|
- the timing and synchronisation of the data exchanged
|
||||||
|
|
||||||
|
So in other words, the mouse waits for the master to give it a timeslot once the
|
||||||
|
click has occurred. Then it's data is handed off to the application responsible
|
||||||
|
on the master device.
|
||||||
Loading…
Add table
Reference in a new issue