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
  • Discusión
  • Tutorial
    • 1. Inicio rápido
    • 2. Visión general de Python
    • 3. Control de hardware
    • 4. Sensores de visión
    • 5. Procesamiento de imágenes
    • 6. NumPy
    • 7. Aprendizaje automático
    • 8. Asyncio
    • 9. Redes
    • 10. Servidores web
    • 11. Bluetooth
      • 11.1. Por qué Bluetooth
      • 11.2. La pila BLE
      • 11.3. La radio y la capa de enlace
      • 11.4. Anuncio y escaneo
      • 11.5. Conexiones
      • 11.6. Servicios y características
      • 11.7. Operaciones GATT
      • 11.8. El módulo aioble
      • 11.9. Actuar como periférico
      • 11.10. Actuar como central
      • 11.11. Canales L2CAP
      • 11.12. Roles concurrentes y conexiones múltiples
      • 11.13. Emparejamiento y vinculación
      • 11.14. Resumen
    • 12. Protocolo del host
    • 13. Herramientas
    • 14. Producción
  • Bibliotecas
  • Placas
  • Escudos (Shields)
  • Sensores
  • Lenguaje
  • CPython
  • Internos
  • Registro de cambios
  • Licencia

En esta página

  • 11.3.1. La radio
  • 11.3.2. La capa de enlace
  • 11.3.3. Qué comparten la cámara y un par
  • 11.3.4. Qué ve Python de todo esto
micropython-doc 0 0
Editar esta página
  1. OpenMV MicroPython /
  2. Tutorial de la OpenMV Cam /
  3. 11. Bluetooth /
  4. 11.3. La radio y la capa de enlace
Ver código fuente Abrir en ChatGPT Abrir en Claude Abrir en Perplexity

11.3. La radio y la capa de enlace¶

Las dos capas inferiores de la pila BLE son casi enteramente automáticas desde la perspectiva de Python – el silicio de la radio y las capas que MicroPython ejecuta sobre él gestionan todo, desde elegir un canal hasta retransmitir un paquete perdido. Tres de las decisiones que toman aún se reflejan en la API de cara al usuario: potencia, alcance y rendimiento.

11.3.1. La radio¶

BLE usa la misma banda Industrial-Científica-Médica (ISM) de 2,4 GHz que el Wi-Fi, los hornos microondas y la mayoría de las demás tecnologías inalámbricas de corto alcance. La banda se divide en 40 canales de 2 MHz de ancho.

  • Tres de los 40 canales están reservados para publicidad – breves emisiones que anuncian la presencia de un dispositivo a cualquiera que esté escuchando. Están espaciados a lo largo de la banda para que un oyente pueda barrer los tres rápidamente y para que sea improbable que la interferencia en cualquiera de ellos deje al dispositivo totalmente fuera del aire.

  • Treinta y siete son canales de datos. Una vez que dos dispositivos se conectan, intercambian paquetes en estos, saltando entre ellos según una secuencia pseudoaleatoria que ambos lados acuerdan en el momento de la conexión. El salto de frecuencia adaptativo permite que cualquiera de los lados marque un canal como malo (fuerte interferencia de Wi-Fi, microondas, red BLE vecina) para que la secuencia lo omita.

Un eje horizontal de frecuencia de 2400 MHz a 2480 MHz con 40 ranuras estrechas de canal dibujadas en él. Tres de las ranuras, en el borde inferior, centro y borde superior de la banda, están resaltadas como "advertising channels". Las 37 restantes están etiquetadas como "data channels".

Los 40 canales BLE en la banda de 2,4 GHz. Tres son para publicidad, el resto transportan tráfico en una conexión abierta.¶

La radio transmite paquetes breves – de a lo sumo un par de milisegundos de duración – y duerme entre medias. Ese sueño es lo que hace que la tecnología sea de bajo consumo. Un peripheral BLE típico pasa bastante menos del uno por ciento de su tiempo transmitiendo realmente; el resto es la radio apagada entre eventos programados.

11.3.2. La capa de enlace¶

La capa de enlace es la unidad más pequeña de BLE que se comunica con su homóloga en otro dispositivo. Se encarga de cuatro tareas.

  • Entramado de paquetes. Cada paquete lleva una cabecera corta (dirección de acceso al canal, longitud del paquete, bits de control), una carga útil y un CRC. El receptor comprueba el CRC y descarta cualquier cosa corrupta.

  • Direccionamiento. Cada dispositivo BLE tiene una dirección de dispositivo de 48 bits que lo identifica en la radio. Algunas son públicas – un identificador de hardware que el fabricante ha asignado, rastreable para siempre. Algunas son aleatorias – generadas en el dispositivo, rotadas periódicamente y, opcionalmente, cifradas para que un fisgón no pueda vincular dos transmisiones al mismo hardware físico. Las direcciones vuelven a aparecer en Anuncio y escaneo.

  • Programación de la conexión. Una vez que dos dispositivos se conectan, la capa de enlace programa eventos de radio periódicos sobre la secuencia de saltos – separados por un intervalo de conexión fijo – y empaqueta en cada uno los datos que estén en cola de la capa GATT superior. Ambos lados vuelven a dormir entre eventos. El intervalo de conexión es un parámetro que la aplicación puede solicitar (consulta Conexiones).

  • Fiabilidad. Cada paquete en una conexión es confirmado por el otro lado. La capa de enlace retransmite cualquier cosa que no haya recibido respuesta, de modo que las capas superiores ven un flujo de bytes ordenado y sin pérdidas. A diferencia de UDP – envía un paquete y cruza los dedos en el lado de las redes, BLE no tiene un modo no fiable separado en uso normal – cada paquete en una conexión abierta se reintenta hasta que llega o el enlace se declara perdido.

La capa de enlace es también donde se ejecuta el cifrado una vez que un par de dispositivos ha acordado una clave durante el emparejamiento (consulta Emparejamiento y vinculación). Cada paquete en un enlace cifrado se descifra en el receptor antes de que las capas superiores lo vean siquiera.

11.3.3. Qué comparten la cámara y un par¶

Las radios de ambos extremos acuerdan en el momento de la conexión un puñado de parámetros que rigen la conversación:

  • El intervalo de conexión – con qué frecuencia los dos lados se despiertan para intercambiar paquetes, desde 7,5 ms hasta 4 s.

  • La latencia del peripheral – cuántos intervalos consecutivos puede saltarse el peripheral si no tiene nada que decir, para ahorrar energía.

  • El tiempo de espera de supervisión – cuánto tiempo espera cualquiera de los lados antes de declarar perdido el enlace cuando el otro se queda en silencio.

  • El MTU – el paquete único más grande que cualquiera de los lados entregará a GATT (por defecto 23 bytes, se puede negociar al alza).

La radio y la capa de enlace juntas son responsables de llevar paquetes fiables y ordenados de un dispositivo a otro manteniendo ambas radios apagadas tanto como sea posible. Cada capa superior es libre de comportarse como si existiera un canal de bytes limpio y privado entre los dos extremos.

11.3.4. Qué ve Python de todo esto¶

Casi nada. Las API bluetooth y aioble no exponen canales, secuencias de saltos, CRC de paquetes ni temporizadores de retransmisión; todos ellos se gestionan dentro del puerto BLE y la radio. Las piezas que sí se reflejan son las que expone la negociación en el momento de la conexión – intervalo de conexión, MTU, tipo de dirección.

Anterior
11.2. La pila BLE
Siguiente
11.4. Anuncio y escaneo

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.