OpenMV MicroPython OpenMV MicroPython OpenMV MicroPython
  • Start
  • Handleiding
  • Kernbibliotheken
  • Boards
  • Shields
  • Sensoren
  • Taal
  • CPython
  • Interne werking
  • Wijzigingslog
/
  • dev
  • English
  • العربية
  • 简体中文
  • 繁體中文
  • Hrvatski
  • Čeština
  • Nederlands
  • Suomi
  • Français
  • Deutsch
  • עברית
  • Magyar
  • Bahasa Indonesia
  • Italiano
  • 日本語
  • 한국어
  • Polski
  • Português (Brasil)
  • Português (Portugal)
  • Română
  • Русский
  • Español
  • Svenska
  • ไทย
  • Türkçe
  • Українська
  • Tiếng Việt
  • Discussie
  • Tutorial
    • 1. Snelstartgids
    • 2. Python-overzicht
    • 3. Hardwarebesturing
    • 4. Vision Sensors
    • 5. Beeldverwerking
    • 6. NumPy
    • 7. Machine Learning
    • 8. Asyncio
    • 9. Netwerken
    • 10. Webservers
    • 11. Bluetooth
      • 11.1. Waarom Bluetooth
      • 11.2. De BLE-stack
      • 11.3. De radio en de linklaag
      • 11.4. Adverteren en scannen
      • 11.5. Verbindingen
      • 11.6. Services en kenmerken
      • 11.7. GATT-bewerkingen
      • 11.8. De aioble-module
      • 11.9. Optreden als randapparaat
      • 11.10. Optreden als central
      • 11.11. L2CAP-kanalen
      • 11.12. Gelijktijdige rollen en meerdere verbindingen
      • 11.13. Koppelen en binden
      • 11.14. Afronding
    • 12. Host-protocol
    • 13. Tools
    • 14. Productie
  • Bibliotheken
  • Boards
  • Shields
  • Sensors
  • Taal
  • CPython
  • Interne werking
  • Changelog
  • Licentie

Op deze pagina

  • 11.3.1. De radio
  • 11.3.2. De linklaag
  • 11.3.3. Wat de camera en een peer delen
  • 11.3.4. Wat Python hiervan ziet
micropython-doc 0 0
Deze pagina bewerken
  1. OpenMV MicroPython /
  2. OpenMV Cam-tutorial /
  3. 11. Bluetooth /
  4. 11.3. De radio en de linklaag
Broncode bekijken Openen in ChatGPT Openen in Claude Openen in Perplexity

11.3. De radio en de linklaag¶

De onderste twee lagen van de BLE-stack zijn vanuit het perspectief van Python bijna volledig automatisch – de radio-silicium en de lagen die MicroPython erbovenop draait, regelen alles, van het kiezen van een kanaal tot het opnieuw verzenden van een verloren pakket. Drie van de keuzes die ze maken, komen nog steeds door tot in de gebruikersgerichte API: vermogen, bereik en doorvoer.

11.3.1. De radio¶

BLE gebruikt dezelfde 2,4 GHz Industrial-Scientific-Medical (ISM) band als wifi, magnetrons en de meeste andere draadloze technologie voor korte afstand. De band is opgesplitst in 40 kanalen van 2 MHz breed.

  • Drie van de 40 kanalen zijn gereserveerd voor adverteren – korte uitzendingen die de aanwezigheid van een apparaat aankondigen aan iedereen die luistert. Ze zijn over de band verspreid zodat een luisteraar alle drie snel kan afspeuren en zodat interferentie op een van de kanalen het apparaat waarschijnlijk niet volledig uit de lucht haalt.

  • Zevenendertig zijn data-kanalen. Zodra twee apparaten verbinding maken, wisselen ze pakketten uit op deze kanalen, waarbij ze tussen de kanalen springen volgens een pseudo-willekeurige reeks waarover beide kanten het op het moment van verbinden eens worden. Adaptive frequency hopping laat beide kanten een kanaal als slecht markeren (zware wifi-interferentie, magnetron, naburig BLE-netwerk) zodat de reeks het overslaat.

A horizontal frequency axis from 2400 MHz to 2480 MHz with 40 narrow channel slots drawn on it. Three of the slots, at the bottom edge, middle, and upper edge of the band, are highlighted as "advertising channels". The remaining 37 are labelled "data channels".

De 40 BLE-kanalen op de 2,4 GHz-band. Drie zijn voor adverteren, de rest draagt verkeer op een open verbinding.¶

De radio verzendt korte pakketten – hooguit een paar milliseconden lang – en slaapt ertussenin. Die slaap is wat de technologie energiezuinig maakt. Een typische BLE-peripheral besteedt ruim minder dan één procent van zijn tijd aan daadwerkelijk verzenden; de rest is de radio die uitgeschakeld is tussen geplande gebeurtenissen.

11.3.2. De linklaag¶

De linklaag is de kleinste eenheid van BLE die communiceert met zijn tegenhanger op een ander apparaat. Deze regelt vier taken.

  • Pakketframing. Elk pakket draagt een korte header (channel access address, pakketlengte, controlebits), een payload en een CRC. De ontvanger controleert de CRC en gooit alles wat beschadigd is weg.

  • Adressering. Elk BLE-apparaat heeft een 48-bit apparaatadres dat het identificeert op de radio. Sommige zijn publiek – een hardware-identificator die de fabrikant heeft toegewezen en die voor altijd traceerbaar is. Sommige zijn willekeurig – gegenereerd op het apparaat, periodiek geroteerd en optioneel versleuteld zodat een afluisteraar twee transmissies niet kan koppelen aan dezelfde fysieke hardware. Adressen komen opnieuw aan bod in Adverteren en scannen.

  • Verbindingsplanning. Zodra twee apparaten verbinding maken, plant de linklaag periodieke radiogebeurtenissen op de hopping-reeks – een vast connection interval uit elkaar – en pakt welke gegevens dan ook die in de wachtrij staan van de GATT-laag erboven in elke gebeurtenis. Beide kanten gaan tussen gebeurtenissen weer slapen. Het connection interval is een knop die de applicatie kan opvragen (zie Verbindingen).

  • Betrouwbaarheid. Elk pakket op een verbinding wordt bevestigd door de andere kant. De linklaag verzendt alles opnieuw waarop geen antwoord kwam, zodat de lagen erboven een geordende, verliesvrije bytestroom zien. In tegenstelling tot UDP – verstuur een pakket, hoop op het beste aan de netwerkkant heeft BLE bij normaal gebruik geen aparte onbetrouwbare modus – elk pakket op een open verbinding wordt opnieuw geprobeerd totdat het aankomt of de verbinding als verloren wordt verklaard.

De linklaag is ook waar versleuteling draait zodra een paar apparaten het tijdens het pairen eens is geworden over een sleutel (zie Koppelen en binden). Elk pakket op een versleutelde verbinding wordt bij de ontvanger ontsleuteld voordat de lagen erboven het ooit zien.

11.3.3. Wat de camera en een peer delen¶

De radio’s aan beide uiteinden komen op het moment van verbinden een handvol parameters overeen die het gesprek regelen:

  • Het connection interval – hoe vaak de twee kanten wakker worden om pakketten uit te wisselen, ergens tussen 7,5 ms en 4 s.

  • De peripheral latency – hoeveel opeenvolgende intervallen de peripheral mag overslaan als deze niets te zeggen heeft, om stroom te besparen.

  • De supervision timeout – hoe lang elke kant wacht voordat de verbinding als verloren wordt verklaard wanneer de andere kant stil wordt.

  • De MTU – het grootste enkele pakket dat elke kant aan GATT zal leveren (standaard 23 bytes, kan naar boven worden onderhandeld).

De radio en de linklaag zijn samen verantwoordelijk voor het betrouwbaar en geordend afleveren van pakketten van het ene apparaat naar het andere, terwijl beide radio’s zoveel mogelijk uitgeschakeld blijven. Elke laag erboven is vrij om zich te gedragen alsof er een schoon, privé bytekanaal tussen de twee eindpunten bestaat.

11.3.4. Wat Python hiervan ziet¶

Bijna niets. De bluetooth- en aioble-API’s stellen geen kanalen, hopping-reeksen, pakket-CRC’s of hertransmissietimers bloot; die worden allemaal afgehandeld binnen de BLE-port en de radio. De onderdelen die wel doorkomen, zijn die welke de onderhandeling op het moment van verbinden blootstelt – connection interval, MTU, adrestype.

Vorige
11.2. De BLE-stack
Volgende
11.4. Adverteren en scannen

Voor OpenMV-firmware v5.0.0 · gebaseerd op MicroPython v1.28 · documentatie gebouwd 19 juni 2026 · Copyright © 2014-2026 door OpenMV, Damien P. George en anderen.

Gemaakt met Sphinx met behulp van het Shibuya theme.