OpenMV MicroPython OpenMV MicroPython OpenMV MicroPython
  • Home
  • Tutorial
  • Libraries
  • Boards
  • Shields
  • Sensors
  • Language
  • CPython
  • Internals
  • Changelog
  • License
/
  • English
  • 简体中文
  • 繁體中文
  • Deutsch
  • 日本語
  • Español
  • Русский
  • Français
  • 한국어
  • Italiano
  • Português
  • Nederlands
  • Română
  • Hrvatski
  • Čeština
  • Polski
  • Suomi
  • Svenska
  • Magyar
  • Türkçe
  • Discussion
  • Tutorial
    • 1. Guida rapida
    • 2. Panoramica di Python
    • 3. Controllo dell’hardware
    • 4. Sensori di visione
    • 5. Elaborazione delle immagini
    • 6. NumPy
    • 7. Machine Learning
    • 8. Asyncio
    • 9. Networking
    • 10. Web Server
    • 11. Bluetooth
      • 11.1. Perché Bluetooth
      • 11.2. Lo stack BLE
      • 11.3. La radio e il link layer
      • 11.4. Advertising e scanning
      • 11.5. Connessioni
      • 11.6. Servizi e caratteristiche
      • 11.7. Operazioni GATT
      • 11.8. Il modulo aioble
      • 11.9. Agire come periferica
      • 11.10. Agire come central
      • 11.11. Canali L2CAP
      • 11.12. Ruoli concorrenti e connessioni multiple
      • 11.13. Pairing e bonding
      • 11.14. Riepilogo
    • 12. Protocollo host
    • 13. Strumenti
    • 14. Produzione
  • Librerie
  • Schede
  • Shield
  • Sensori
  • Linguaggio
  • CPython
  • Aspetti interni
  • Changelog
  • Licenza

On this page

  • 11.3.1. La radio
  • 11.3.2. Il link layer
  • 11.3.3. Cosa condividono la camera e un peer
  • 11.3.4. Cosa vede Python di tutto questo
micropython-doc 0 0
Edit this page
  1. OpenMV MicroPython /
  2. Tutorial di OpenMV Cam /
  3. 11. Bluetooth /
  4. 11.3. La radio e il link layer
View Source Open in ChatGPT Open in Claude Open in Perplexity

11.3. La radio e il link layer¶

I due livelli inferiori dello stack BLE sono quasi interamente automatici dal punto di vista di Python – il silicio della radio e i livelli che MicroPython esegue al di sopra di esso gestiscono tutto, dalla scelta di un canale alla ritrasmissione di un pacchetto perso. Tre delle scelte che essi compiono trasparono comunque nell’API rivolta all’utente: potenza, portata e throughput.

11.3.1. La radio¶

Il BLE utilizza la stessa banda Industrial-Scientific-Medical (ISM) a 2,4 GHz del Wi-Fi, dei forni a microonde e della maggior parte degli altri dispositivi wireless a corto raggio. La banda è suddivisa in 40 canali larghi 2 MHz.

  • Tre dei 40 canali sono riservati all”advertising – brevi trasmissioni broadcast che annunciano la presenza di un dispositivo a chiunque sia in ascolto. Sono distanziati lungo la banda in modo che un ascoltatore possa scansionarli tutti e tre rapidamente e in modo che l’interferenza su uno qualsiasi di essi difficilmente metta del tutto fuori uso il dispositivo.

  • Trentasette sono canali dati. Una volta che due dispositivi si connettono, scambiano pacchetti su questi, saltando tra di essi secondo una sequenza pseudo-casuale che i due lati concordano al momento della connessione. L”adaptive frequency hopping consente a ciascun lato di contrassegnare un canale come scadente (forte interferenza Wi-Fi, microonde, rete BLE vicina) in modo che la sequenza lo salti.

Un asse orizzontale delle frequenze da 2400 MHz a 2480 MHz con 40 stretti slot di canale disegnati su di esso. Tre degli slot, ai bordi inferiore, centrale e superiore della banda, sono evidenziati come "advertising channels". I restanti 37 sono etichettati come "data channels".

I 40 canali BLE sulla banda a 2,4 GHz. Tre servono per l’advertising, gli altri trasportano il traffico su una connessione aperta.¶

La radio trasmette brevi pacchetti – al massimo lunghi un paio di millisecondi – e dorme negli intervalli. Quel sonno è ciò che rende la tecnologia a basso consumo. Un tipico peripheral BLE trascorre ben meno dell’uno percento del proprio tempo trasmettendo effettivamente; il resto è la radio spenta tra gli eventi pianificati.

11.3.2. Il link layer¶

Il link layer è la più piccola unità del BLE che comunica con la propria controparte su un altro dispositivo. Si occupa di quattro compiti.

  • Framing dei pacchetti. Ogni pacchetto contiene un breve header (channel access address, lunghezza del pacchetto, bit di controllo), un payload e un CRC. Il ricevitore verifica il CRC e scarta qualsiasi cosa corrotta.

  • Indirizzamento. Ogni dispositivo BLE ha un device address a 48 bit che lo identifica sulla radio. Alcuni sono pubblici – un identificatore hardware assegnato dal produttore, tracciabile per sempre. Alcuni sono casuali – generati sul dispositivo, ruotati periodicamente e opzionalmente cifrati in modo che un intercettatore non possa collegare due trasmissioni allo stesso hardware fisico. Gli indirizzi vengono ripresi in Advertising e scanning.

  • Pianificazione della connessione. Una volta che due dispositivi si connettono, il link layer pianifica eventi radio periodici sulla sequenza di hopping – a un connection interval fisso di distanza – e impacchetta in ciascuno di essi qualsiasi dato sia in coda dal livello GATT superiore. Entrambi i lati tornano a dormire tra un evento e l’altro. Il connection interval è una manopola che l’applicazione può richiedere (vedi Connessioni).

  • Affidabilità. Ogni pacchetto su una connessione viene confermato dall’altro lato. Il link layer ritrasmette qualsiasi cosa non abbia ricevuto una risposta, in modo che i livelli superiori vedano un flusso di byte ordinato e senza perdite. A differenza di UDP – invia un pacchetto e spera per il meglio sul lato networking, il BLE non dispone di una modalità non affidabile separata nell’uso normale – ogni pacchetto su una connessione aperta viene ritentato finché non arriva o finché il collegamento non viene dichiarato perso.

Il link layer è anche il punto in cui viene eseguita la cifratura una volta che una coppia di dispositivi ha concordato una chiave durante il pairing (vedi Pairing e bonding). Ogni pacchetto su un collegamento cifrato viene decifrato dal ricevitore prima che i livelli superiori lo vedano.

11.3.3. Cosa condividono la camera e un peer¶

Le radio a entrambe le estremità concordano al momento della connessione una manciata di parametri che governano la conversazione:

  • Il connection interval – ogni quanto i due lati si svegliano per scambiare pacchetti, da 7,5 ms a 4 s.

  • La peripheral latency – quanti intervalli consecutivi il peripheral può saltare se non ha nulla da dire, per risparmiare energia.

  • Il supervision timeout – per quanto tempo ciascun lato attende prima di dichiarare il collegamento perso quando l’altro tace.

  • L”MTU – il pacchetto singolo più grande che ciascun lato consegnerà al GATT (il valore predefinito è 23 byte, può essere negoziato verso l’alto).

La radio e il link layer insieme sono responsabili di far arrivare pacchetti affidabili e ordinati da un dispositivo all’altro mantenendo entrambe le radio spente il più possibile. Ogni livello superiore è libero di comportarsi come se tra i due endpoint esistesse un canale di byte pulito e privato.

11.3.4. Cosa vede Python di tutto questo¶

Quasi nulla. Le API bluetooth e aioble non espongono canali, sequenze di hopping, CRC dei pacchetti o timer di ritrasmissione; sono tutti gestiti all’interno della porta BLE e della radio. Gli elementi che trasparono sono quelli esposti dalla negoziazione al momento della connessione – connection interval, MTU, tipo di indirizzo.

Previous
11.2. Lo stack BLE
Next
11.4. Advertising e scanning

For OpenMV firmware v5.0.0 · based on MicroPython v1.28 · docs built 16 Jun 2026 · Copyright © 2014-2026 by OpenMV, Damien P. George, and others.

Made with Sphinx using the Shibuya theme.