Elegir el protocolo adecuado

01 · Objetivo

No hay un mejor protocolo

Cada tecnología del curso es la respuesta óptima a un problema distinto, y ninguna lo es a todos. SPI es lo más rápido entre chips de una placa y no sirve a dos metros. I²C comparte dos hilos entre decenas de chips y no aguanta un cable largo. RS-485 cruza una planta y lleva pocos bytes por segundo. CAN prioriza mensajes críticos en un vehículo. Ethernet mueve megabits y necesita un cable por equipo. Wi-Fi llega a todos lados y gasta la batería en días. BLE dura años con una moneda y alcanza un teléfono. LoRa cubre kilómetros a razón de unos pocos bytes por minuto. Elegir mal tiene un costo muy concreto: un sistema que anda en el escritorio y falla en la planta, un nodo a pila que dura un mes en lugar de dos años, una red cuyo cableado cuesta más que los sensores.

La buena noticia es que la elección es en buena parte mecánica si se hace en el orden correcto. Los requisitos con un número que ninguna tecnología puede cumplir eliminan opciones sin discusión: no hay RS-485 que lleve un megabit por segundo a un kilómetro, ni BLE que cubra tres kilómetros. Lo que sobrevive a esa criba suele ser un puñado de opciones, y entre ellas se decide por costo, consumo, facilidad y seguridad. Lo que rara vez funciona es elegir primero por costumbre («siempre usé Wi-Fi») o por el dato de catálogo más vistoso («1 Gbit/s»).

02 · Qué preguntar

Los criterios, con números

Un requisito sin número no se puede verificar. «Debe ser rápido» no sirve; «debe llevar 40 bytes por segundo con un margen de tres» sí. La tabla recoge los criterios que deciden casi todos los proyectos, qué pregunta responde cada uno y cómo se obtiene el número:

Dos de estos criterios son eliminatorios de una forma que los otros no: la distancia con la velocidad (se compran una con otra) y la alimentación (un dispositivo con batería no puede usar una tecnología que consume miliamperios permanentes). Los demás se negocian entre sí: se acepta algo más de costo para ganar facilidad, o algo menos de velocidad para ganar alcance.

03 · Una imagen del curso

El mapa de distancia y velocidad

El mapa resume el curso en una página y tiene tres lecciones. Primera: cada región es una familia. Entre chips de una placa (verde) están los buses de unos metros, rápidos y sin protección alguna contra el ruido: SPI, I²C y UART. Por cable entre equipos (oscuro) están los que llegan lejos, a costa de velocidad: RS-232, RS-485 y CAN, y Ethernet en la zona de las altas velocidades. Por aire (naranja), la radio cubre de metros a kilómetros y su velocidad cae con el alcance, hasta LoRa, que en el extremo lleva unos cientos de bits por segundo. Segunda: las barras de velocidad y de distancia no se combinan libremente. El RS-485 llega a 1200 m y a 10 Mbit/s, pero no a la vez: son dos extremos de una curva en la que la velocidad por la distancia es casi constante. Por eso la herramienta 1 trabaja con puntos de operación y no con rangos. Tercera: hay huecos. No hay nada que lleve megabits a kilómetros sin infraestructura (para eso está la fibra óptica, el 4G o 5G, o los enlaces de microondas, fuera del curso), y nada que lleve kilómetros con una pila de años, salvo LoRa, a muy bajas velocidades.

04 · Una tabla para tener a mano

Tablas comparativas

Las dos tablas siguientes ponen lado a lado las tecnologías del curso. Los números son típicos y orientativos: dependen del chip, del cable, del entorno y de la configuración, y la hoja de datos de cada componente es la que manda.

Mirando las dos tablas aparecen pares que se disputan los mismos proyectos y conviene saber con qué se desempatan. RS-485 o CAN: ambos son diferenciales y robustos; RS-485 es más simple y barato y tiene el ecosistema Modbus; CAN trae arbitraje por prioridad, detección de errores integrada y es multimaestro, lo que lo hace mejor cuando importan los tiempos de reacción de eventos y peor cuando se necesita un maestro que sondea. BLE o Zigbee: BLE cuando el interlocutor es un teléfono; Zigbee o Thread cuando hay muchos nodos y se necesita una malla. Wi-Fi o LoRa: Wi-Fi si hay corriente y se necesitan megabits; LoRa si hay batería y se necesitan kilómetros. Ethernet o Wi-Fi: Ethernet es más fiable, determinista y puede alimentar el dispositivo (PoE); Wi-Fi ahorra el cable y pierde las tres cosas.

05 · Donde se instala

Ruido, entorno e instalación

Las tecnologías de la sección 4 tienen la misma tasa de error en un laboratorio y diferencias enormes en una planta. La robustez al ruido (tema 43) sale de cuatro decisiones de diseño, y se pueden reconocer en la tabla:

• Señal diferencial (RS-422/485, CAN, Ethernet): el ruido que llega igual a los dos hilos se cancela en la resta. Es lo que permite 1200 m junto a motores. Las señales «de un hilo y masa» (UART TTL, SPI, I²C, 1-Wire) no tienen esa defensa y su cable debe ser corto o estar lejos de las fuentes de ruido.
• Aislación galvánica: Ethernet lleva transformadores en cada puerto; los transceptores RS-485 y CAN aislados se consiguen; las masas de dos edificios o de dos máquinas pueden diferir en voltios, y unirlas con un cable puede quemar un puerto. Entre equipos en distintos tableros, la aislación es lo normal.
• Detección y control de errores en el protocolo: CAN detecta y reintenta solo; Ethernet descarta con CRC-32 y deja que TCP lo repare; Modbus usa un CRC-16 y el maestro reintenta; UART TTL, SPI e I²C no tienen nada (o solo paridad) y la aplicación debe agregarlo (temas 44 y 45).
• Espectro ensanchado y saltos de frecuencia en radio: LoRa, BLE y Bluetooth clásico esquivan interferencias; el Wi-Fi comparte el canal con otros y se degrada con la congestión; el nRF24 sin cuidado se pisa con el Wi-Fi (los canales de los temas 35 y 39).

Y dos aspectos de la instalación que se subestiman. El cableado: tender un cable a un equipo en una pared existente cuesta más que el cable y, a veces, más que el equipo; por eso la radio gana en instalaciones existentes aun cuando pierda en robustez. En una obra nueva, un cable es casi gratis y gana. Y el mantenimiento: un nodo a pila reemplazado cada dos años en 300 puntos son 150 visitas por año; un nodo con cable no se visita. Para el RF, las paredes de hormigón, el metal y el agua (el cuerpo humano, las plantas con riego) reducen el alcance a una fracción del que da el catálogo, y la única forma de saberlo es probar en el lugar con el nodo real (tema 34).

06 · Años con una pila

Consumo y batería

Cuando un nodo va a batería, el protocolo importa menos por su velocidad que por cuánta carga cuesta cada mensaje, y esa carga depende tanto de la tecnología como del chip que la implementa. La cuenta es la del tema 40: la corriente media es el consumo del sueño más la carga por mensaje repartida en el período, y la duración, la capacidad útil dividida por esa media. Los órdenes de magnitud de la carga por mensaje:

Dos mensajes se desprenden de la tabla, y los dos contradicen lo que se supone. Primero, la tecnología no alcanza para predecir el consumo: el chip importa tanto. El mismo BLE cuesta 19,9 mC en un ESP32 y centésimas de mC en un SoC de BLE, una diferencia de cientos de veces, porque el ESP32 despierta un procesador grande y arranca su pila de radio en cada ciclo. Una pulsera con una pila de moneda de 220 mAh, que reporta cada 10 s, dura 2,9 años con un SoC de BLE y 3,7 días con un ESP32 (herramienta 4). Segundo, «de bajo consumo» no significa «a pila durante años»: LoRa gasta poco por mensaje, pero un mensaje de 144 ms en el aire con SF9, repetido cada 10 s, drena igual (y rompe el ciclo de trabajo del 1 % de la banda de 868 MHz). La duración depende de la tecnología, del chip, del tamaño del mensaje y de la frecuencia, juntos.

El otro extremo también es una decisión: si hay corriente en cada nodo, el consumo no es un criterio y se elige por las otras razones. Un nodo alimentado por Ethernet con PoE o por una fuente de pared puede usar Wi-Fi, Ethernet o RS-485 sin pensar en la batería. Y entre los que van por cable, el consumo igual existe: un transceptor RS-485 o CAN consume miliamperios aun en reposo, razón por la cual no se los usa en nodos a pila.

07 · Anunciado frente a útil

Lo que la velocidad anunciada no dice

La velocidad que figura en una tecnología es la de la línea: cuántos bits por segundo salen al medio. La velocidad que importa es la útil: cuántos bits de datos por segundo llegan, después de descontar encabezados, bits de control, confirmaciones, silencios, preámbulos y reintentos. Para mensajes largos, la diferencia es chica (SPI aprovecha 99 % de la línea con 100 bytes). Para mensajes cortos, que son los de un sensor, es enorme. La herramienta 2 calcula el tiempo y la eficiencia de transferir un mensaje en cada protocolo. Con 4 bytes de datos (una medición) y con 100:

Cuatro conclusiones. (1) El gasto fijo domina los mensajes cortos: un paquete UDP de 4 bytes ocupa 84 bytes en el cable de Ethernet (46 de encabezados, el relleno hasta el mínimo de 64 y los 20 del preámbulo y la separación); una lectura Modbus de 2 registros usa 17 bytes de línea y silencios; LoRa gasta un preámbulo de 12 símbolos antes del primer dato. (2) Agrupar es la mejor optimización: enviar 10 lecturas de 4 bytes en un solo mensaje cuesta mucho menos que 10 mensajes, en tiempo, en energía y en tráfico. Es el consejo del tema 33 (el tráfico de un nodo MQTT es casi todo encabezado) aplicado a todas las tecnologías. (3) La velocidad útil puede estar muy por debajo de la anunciada: un sensor Modbus sondeado a 9600 baudios con 4 bytes entrega 1,2 kbit/s útiles de los 9,6 anunciados. (4) Hay que calcular con el caso real: un nodo LoRa SF12 envía 10 bytes en casi un segundo de aire y, con el ciclo de trabajo del 1 %, solo puede hablar una vez cada cien segundos.

08 · De los requisitos a la decisión

Un método para decidir

Una elección se puede hacer en siete pasos, y cada uno protege contra un error típico:

1. Escribir los requisitos con números. Una hoja con una línea por criterio de la sección 2: distancia máxima, bytes por mensaje y frecuencia, cantidad de nodos hoy y en cinco años, latencia máxima, entorno, alimentación, presupuesto, necesidades de seguridad, sistemas existentes con los que hay que hablar. Si un requisito no tiene número, se le pone uno y se confirma con quien encarga el proyecto. Protege de: descubrir el requisito real cuando ya está instalado.
2. Separar lo obligatorio de lo deseable. «Tiene que llegar a 400 m» es obligatorio. «Estaría bueno que se vea desde el teléfono» es deseable. Solo lo obligatorio elimina opciones. Protege de: descartar la solución correcta por un capricho.
3. Eliminar. Aplicar los obligatorios a la lista de tecnologías: medio, nodos, ruido, alimentación y, al final, distancia y velocidad juntas (herramienta 1). Lo que queda son los candidatos. Si no queda ninguno, ningún requisito se puede cumplir con una sola tecnología: se afloja uno, o se parte el sistema en tramos con una puerta de enlace (sección 10). Protege de: comparar opciones que nunca iban a funcionar.
4. Comparar los candidatos. Con una matriz de decisión ponderada (herramienta 5): se asigna un peso a cada criterio blando según el proyecto, se puntúa cada candidato y se suma. Lo valioso es el ejercicio de explicitar los pesos: dos personas que discuten «cuál es mejor» suelen discutir en realidad pesos distintos. Si los dos primeros quedan a menos de tres puntos, la matriz no decide y hay que mirar lo que ella no ve: lo que ya hay instalado, la experiencia del equipo, la disponibilidad de los componentes. Protege de: elegir por intuición y justificar después.
5. Probar el mayor riesgo. De todos los supuestos de la decisión, se identifica el más incierto y más caro si falla: el alcance real de la radio en el edificio, la duración real de la batería, el comportamiento con los motores prendidos. Se construye el prototipo más chico que lo verifique y se mide (con las herramientas del tema 48). Un fin de semana de prueba cuesta menos que una instalación rehecha. Protege de: la sorpresa del campo.
6. Decidir y escribir la decisión. Una nota corta: el contexto (requisitos), las opciones consideradas, la decisión, por qué, qué se espera que ocurra y qué hechos cambiarían la decisión («si el alcance medido es menor a 150 m, pasar a una malla»). Protege de: que dentro de un año nadie sepa por qué es así, y de que se discuta lo ya decidido sin datos nuevos.
7. Diseñar para poder cambiar. La tecnología de transporte cambia con más frecuencia que el mensaje. Si el formato de los datos (tema 46), el control de errores (temas 44 y 45) y la seguridad (tema 49) se separan del medio en capas, cambiar de RS-485 a LoRa es cambiar una capa y no rehacer todo. Protege de: quedarse atado a una decisión que fue buena hace tres años.

El método tiene una trampa conocida: la matriz de decisión como coartada. Si se la usa antes de eliminar, favorece a las opciones que lucen bien en muchos criterios sin cumplir el que decide. En la herramienta 5, con los pesos de una planta ruidosa, LoRa queda primera con 85 puntos y RS-485 segunda con 84, cuando LoRa ni siquiera alcanza los 9600 bit/s que pide el caso (la herramienta 1 la descarta). El orden importa: primero se elimina, después se compara. La otra trampa es la precisión falsa: los puntajes son juicios, y una diferencia de dos puntos entre dos opciones no significa nada. La matriz sirve para ordenar la discusión, no para zanjarla.

09 · Aplicación

Cuatro casos resueltos

Cada caso sigue el método. Los números salen de las herramientas del laboratorio.

Caso A: un invernadero con 200 sensores

Requisitos. 200 nodos con temperatura y humedad en tres hectáreas, hasta 300 m del punto central; un mensaje de 10 bytes cada 5 minutos; sin electricidad en el campo, a pila de 2000 mAh durante 2 años; ruido moderado, sin motores. Eliminación (herramienta 1: 300 m, 500 bit/s, 200 nodos, entorno medio, batería): quedan LoRa; Wi-Fi, BLE, ESP-NOW y nRF24 caen por cantidad de nodos, RS-485 y Ethernet por la batería, y Zigbee por alcance de un salto (con malla podría cubrir, pero sus enrutadores no duermen y necesitan alimentación). Verificación numérica. Un mensaje de 10 bytes por LoRa SF9 dura 144 ms en el aire; cada 5 minutos es un 0,05 % de uso, muy por debajo del 1 % permitido. Con un ESP32, 7,8 mC por ciclo y 15 µA de sueño, la media es de 41 µA y la batería dura 4,4 años al 80 % de aprovechamiento. Decisión. LoRaWAN con una puerta de enlace en el centro. Riesgo a probar: el alcance real entre las plantas (la vegetación mojada absorbe la radio): un fin de semana de prueba con dos nodos a la distancia máxima.

Caso B: una planta con 30 equipos

Requisitos. 30 equipos con sensores en una planta, hasta 400 m; 4 registros por equipo cada segundo, a 19 200 bit/s; motores y variadores; alimentación disponible. Eliminación (400 m, 19 200 bit/s, 30 nodos, entorno industrial): quedan RS-485 y CAN. Comparación. Con Modbus RTU a 19 200, una consulta de 4 registros y su respuesta ocupan 16 ms; con 5 ms de proceso por esclavo, 21 ms por equipo y 631 ms por ronda de 30: cabe en 1 s con el 37 % de margen. CAN a 125 kbit/s también llegaría (500 m) y permitiría que cada equipo avise solo ante una alarma, con prioridad. Decisión. RS-485 con Modbus RTU: es más barato, el ecosistema es enorme y los equipos que ya existen lo hablan. CAN sería preferible si las alarmas necesitaran reaccionar en milisegundos sin esperar el turno del sondeo. Riesgo a probar: la terminación y la polarización con los 400 m reales, y el ruido de los variadores (tema 24).

Caso C: una pulsera que mide y avisa al teléfono

Requisitos. Un dispositivo que se lleva puesto, a menos de 8 m del teléfono; una lectura cada 10 s; una pila de moneda de 220 mAh que dure 2 años. Eliminación (8 m, 20 kbit/s, 2 nodos, batería, sin cable): quedan BLE y Zigbee, y como el teléfono es el interlocutor, solo BLE sirve. Verificación numérica. Con un ESP32, un ciclo de 19,9 mC cada 10 s son casi 2 mA de media: la pila dura 3,7 días. Con un SoC de BLE de bajo consumo (0,05 mC por ciclo, 2 µA de sueño), son 7 µA de media y 2,9 años. Decisión. BLE, pero con un SoC diseñado para ello, no con el ESP32. Es el caso en que elegir la tecnología no alcanza y hay que elegir también el silicio.

Caso D: una máquina con 12 sensores en movimiento

Requisitos. 12 nodos distribuidos a lo largo de 30 m de una máquina móvil, 250 kbit/s en total, con vibración, arranque de motores y alimentación disponible; los eventos críticos (parada de emergencia) deben llegar rápido. Eliminación (30 m, 250 kbit/s, 12 nodos, entorno industrial, por cable): RS-485 (120 m a 1 Mbit/s), CAN (40 m a 1 Mbit/s) y Ethernet. Decisión. CAN: el arbitraje por prioridad garantiza que la parada de emergencia pase delante de cualquier otro mensaje sin esperar ni sondear, los conectores y transceptores están pensados para vibración y es el estándar de la maquinaria móvil. Ethernet quedaría para llevar los datos de la máquina a la red de la planta mediante una puerta de enlace. Riesgo a probar: el bit timing y el cable con la máquina en marcha (tema 28).

10 · Cuando una no alcanza

Combinar tecnologías

Es frecuente que ninguna tecnología cumpla todos los requisitos, y entonces se compone una arquitectura en tramos, cada uno con la tecnología que le conviene, unidos por una puerta de enlace (gateway). El patrón más común: los nodos hablan con lo que les sirve (RS-485 en una planta, LoRa o BLE a pila, I²C dentro de cada nodo), y la puerta de enlace, con corriente y red, habla Wi-Fi o Ethernet hacia un servidor MQTT en la nube. El tema 51 construye una de estas arquitecturas.

La puerta de enlace es útil y a la vez un punto delicado. Sus funciones: traducir formatos (de binario compacto a JSON), guardar los datos si se cae el enlace con la nube, poner la hora a lo que llega, adaptar las velocidades (puede recibir ráfagas de muchos nodos y enviar de a poco) y fijar el límite de seguridad entre redes. Sus riesgos: es un punto único de falla (si se cae, se pierde todo el tramo: conviene un perro guardián, un reinicio automático y, si es crítico, una segunda); si termina el cifrado de los nodos, ve los datos en claro y tiene que protegerse como tal, mientras que un cifrado a nivel de mensaje de extremo a extremo (tema 49) deja pasar los datos sin que la puerta de enlace los lea; y suma latencia y su propio consumo. Se diseña con la misma disciplina que el resto: contadores de lo que recibe, de lo que descarta y de lo que reenvía, y el informe periódico del tema 47.

11 · Con el microcontrolador

Medir lo que promete el papel

Los números de las tablas son cuentas. Antes de apoyar una decisión en ellos, conviene medirlos en el hardware que se va a usar, porque entre la cuenta y la realidad está el software: el controlador de la API, la cola de salida, el tiempo de vaciar el búfer. El programa siguiente mide, en una sola placa y sin conectar nada, cuánto tarda en salir una ráfaga de 16 bytes por una UART (a 9600 y a 115 200 baudios), por un SPI (a 1 y a 10 MHz) y la dirección de una transacción I²C a una dirección en la que no hay nadie (a 100 y a 400 kHz), y lo compara con la cuenta de la herramienta 2.

#include <SPI.h>
#include <Wire.h>

// Mide cuánto tardan de verdad una UART, un SPI y un I2C, y lo compara con la cuenta.
// No necesita ningún dispositivo conectado.
const uint8_t N = 16;                                          // bytes de la prueba
uint8_t tx[N], rx[N];

void medirUart(uint32_t baudios) {
    Serial1.begin(baudios, SERIAL_8N1, 16, 17);                // RX = GPIO 16, TX = GPIO 17 (sin conectar)
    delay(20);
    uint32_t t0 = micros();
    Serial1.write(tx, N);
    Serial1.flush();                                           // espera a que salga el último bit
    uint32_t dt = micros() - t0;
    Serial.printf("UART %6lu baudios, %u bytes: esperado %7.1f us, medido %7lu us\n", baudios, N, N * 10.0e6 / baudios, dt);
    Serial1.end();
}

void medirSpi(uint32_t hz) {
    SPI.beginTransaction(SPISettings(hz, MSBFIRST, SPI_MODE0));
    uint32_t t0 = micros();
    SPI.transferBytes(tx, rx, N);
    uint32_t dt = micros() - t0;
    SPI.endTransaction();
    Serial.printf("SPI  %7lu Hz,      %u bytes: esperado %7.1f us, medido %7lu us\n", hz, N, N * 8.0e6 / hz, dt);
}

void medirI2c(uint32_t hz) {
    Wire.setClock(hz);
    uint32_t t0 = micros();
    Wire.beginTransmission(0x50);                              // una dirección en la que no hay nadie
    uint8_t error = Wire.endTransmission();                    // inicio, dirección + NACK, parada: unos 11 bits
    uint32_t dt = micros() - t0;
    Serial.printf("I2C  %7lu Hz, dirección sola: esperado %7.1f us, medido %7lu us (error %u: 2 = NACK, lo esperado)\n", hz, 11.0e6 / hz, dt, error);
}

void setup() {
    Serial.begin(115200);
    for (uint8_t i = 0; i < N; i++) tx[i] = 0xA5;
    SPI.begin();
    Wire.begin();
    delay(500);
    Serial.println("--- tiempos reales contra la cuenta ---");
    medirUart(9600);
    medirUart(115200);
    medirSpi(1000000);
    medirSpi(10000000);
    medirI2c(100000);
    medirI2c(400000);
}

void loop() {}

Qué esperar y qué hay que notar:

• UART: con flush() el programa espera a que salga el último bit, así que lo medido es cercano a la cuenta: 16 bytes × 10 bits / 9600 = 16 667 µs, y 1389 µs a 115 200, más una pequeña demora de llamada. Es el caso en que la cuenta del papel es casi exacta, porque el hardware es una UART con su cola.
• SPI: los 16 bytes a 1 MHz son 128 µs de bits; a 10 MHz, 12,8 µs. Es probable que lo medido sea mayor que lo esperado, sobre todo a 10 MHz, porque la llamada a la biblioteca (preparar la transferencia, esperar su fin) cuesta decenas de microsegundos que no dependen de la velocidad del reloj. La lección es importante: subir la velocidad del reloj de un bus rápido deja de acelerar las cosas cuando el tiempo del software supera al de los bits; para mover mucho, se usan bloques grandes y transferencias por DMA.
• I²C: una transacción que solo envía la dirección y recibe un NACK ocupa unos 11 bits: 110 µs a 100 kHz y 27,5 µs a 400 kHz. También es de esperar que lo medido sea mayor, porque el controlador agrega su propio tiempo de preparación y de espera. El código de error 2 que devuelve endTransmission() es el NACK de la dirección que se busca (tema 17).
• Los valores que aparecen en un chip concreto no se conocen de antemano. Cuáles sean no es lo importante, sino la diferencia con la cuenta, que dice cuánto del tiempo es del protocolo y cuánto del software, y que es la información que ni las hojas de datos ni las tablas dan.
• Con un analizador lógico (tema 48) sobre TX, SCLK o SCL se pueden medir los tiempos reales de la línea y separarlos del tiempo que ve el programa. Es la comparación que permite decidir si un cuello de botella es del cable o del código.

12 · Analogía con programación

Un asesor de protocolos en Python

El modelo siguiente es el asesor del laboratorio hecho programa: una tabla con los puntos de operación de cada tecnología, la función que descarta lo que no cumple, el tiempo en el aire de LoRa con la fórmula del fabricante, el tiempo de una consulta Modbus y la vida de una batería. Se aplica a los casos de la sección 9 y a algunos números del tema.

import math

# nombre: (puntos de operación [(metros, bit/s)], nodos, ruido 1-3, pila 0-2, con cable)
TECNOLOGIAS = {
    "UART": ([(5, 9600), (2, 115200), (0.5, 1e6)], 2, 1, 2, True),
    "SPI": ([(1, 1e6), (0.3, 10e6), (0.1, 50e6)], 8, 1, 2, True),
    "I2C": ([(3, 100e3), (1, 400e3), (0.5, 1e6)], 112, 1, 2, True),
    "1-Wire": ([(100, 15.4e3), (10, 125e3)], 100, 2, 2, True),
    "RS-232": ([(15, 20e3), (5, 115.2e3)], 2, 2, 0, True),
    "RS-485": ([(1200, 100e3), (120, 1e6), (12, 10e6)], 256, 3, 1, True),
    "CAN": ([(1000, 50e3), (500, 125e3), (250, 250e3), (100, 500e3), (40, 1e6)], 110, 3, 0, True),
    "Ethernet": ([(100, 1e9)], 1000, 3, 0, True),
    "Wi-Fi": ([(30, 20e6), (100, 5e6), (150, 1e6)], 100, 2, 0, False),
    "BT clásico": ([(10, 2e6), (100, 700e3)], 7, 2, 0, False),
    "BLE": ([(10, 2e6), (50, 1e6), (200, 125e3)], 10, 2, 2, False),
    "Zigbee": ([(30, 250e3), (100, 250e3)], 1000, 2, 2, False),
    "nRF24": ([(30, 2e6), (100, 1e6), (800, 250e3)], 6, 1, 2, False),
    "ESP-NOW": ([(100, 1e6)], 20, 2, 1, False),
    "LoRa": ([(10000, 300), (5000, 1100), (2000, 5500)], 1000, 3, 2, False),
}


def candidatos(distancia, velocidad, nodos, ruido=1, pila=False, cable=None):
    """Descarta lo que no cumple un requisito numérico. Lo que queda son los candidatos."""
    quedan = []
    for nombre, (puntos, n_max, robustez, ahorro, con_cable) in TECNOLOGIAS.items():
        if cable is not None and con_cable != cable:
            continue
        if n_max < nodos or robustez < ruido or (pila and ahorro < 2):
            continue
        if any(d >= distancia and v >= velocidad for d, v in puntos):      # distancia y velocidad a la vez
            quedan.append(nombre)
    return quedan


def aire_lora(carga, sf, bw=125000):
    """Tiempo en el aire de un paquete LoRa (preámbulo de 8, encabezado explícito, CRC, CR 4/5)."""
    t_sim = 2 ** sf / bw
    de = 1 if sf >= 11 else 0
    n_sim = 8 + max(math.ceil((8 * carga - 4 * sf + 28 + 16) / (4 * (sf - 2 * de))) * 5, 0)
    return (8 + 4.25 + n_sim) * t_sim


def modbus_s(bytes_datos, baud):
    """Una consulta y su respuesta, con 11 bits por carácter y dos silencios de 3,5 caracteres."""
    registros = math.ceil(bytes_datos / 2)
    return (11 * (8 + 5 + 2 * registros) + 2 * 3.5 * 11) / baud


def vida_anios(capacidad_mah, sueno_ua, carga_mc, periodo_s, uso=0.8):
    media_ua = sueno_ua + carga_mc / periodo_s * 1000
    return capacidad_mah * uso / (media_ua / 1000) / 24 / 365, media_ua


print("planta, 500 m, 9600 bit/s, 30 nodos, ruidosa:", candidatos(500, 9600, 30, ruido=3))
print("invernadero, 300 m, 500 bit/s, 200 nodos, pila:", candidatos(300, 500, 200, ruido=2, pila=True))
print("pulsera, 8 m, 20 kbit/s, 2 nodos, pila, sin cable:", candidatos(8, 20000, 2, ruido=2, pila=True, cable=False))
print("1 km a 1 Mbit/s, 10 nodos:", candidatos(1000, 1e6, 10))

print("4 bytes por Modbus a 9600:", f"{modbus_s(4, 9600) * 1000:.1f} ms", "| a 19 200:", f"{modbus_s(4, 19200) * 1000:.1f} ms")
for sf in (7, 9, 12):
    print(f"10 bytes por LoRa SF{sf}: {aire_lora(10, sf) * 1000:.1f} ms en el aire")

anios, media = vida_anios(2000, 15, 19.9, 300)
print(f"BLE con ESP32 cada 5 min: {media:.1f} uA de media, {anios:.1f} años")
anios, media = vida_anios(2000, 15, 7.83, 600)
print(f"LoRa SF9 con ESP32 cada 10 min: {media:.1f} uA de media, {anios:.1f} años")
anios, media = vida_anios(220, 2, 0.05, 10)
print(f"SoC de BLE con pila de 220 mAh cada 10 s: {media:.1f} uA de media, {anios:.1f} años")

Resultado: la planta de 500 m, 9600 bit/s, 30 nodos y entorno ruidoso deja ['RS-485', 'CAN']; el invernadero de 300 m, 500 bit/s, 200 nodos y batería deja ['LoRa']; la pulsera a 8 m, 20 kbit/s y sin cable, ['BLE', 'Zigbee']; y pedir 1 km a 1 Mbit/s con 10 nodos no deja ninguna ([]). Cuatro bytes por Modbus tardan 27,5 ms a 9600 y 13,8 ms a 19 200. Diez bytes por LoRa tardan 41,2 ms en SF7, 144,4 ms en SF9 y 991,2 ms en SF12: cada paso de factor de ensanchamiento casi duplica el tiempo en el aire, y de SF7 a SF12 son 24 veces más. Las baterías de 2000 mAh con el ciclo de BLE del ESP32 cada 5 minutos son 81,3 µA de media y 2,2 años; con el ciclo de LoRa SF9 cada 10 minutos, 28,1 µA y 6,5 años; y la pila de 220 mAh con un SoC de BLE cada 10 s, 7,0 µA y 2,9 años.

Dos lecciones del modelo. Primera: el filtro es una función de unas pocas líneas. Elegir con criterio no necesita herramientas sofisticadas, sino requisitos escritos con número y una tabla de datos honesta. Segunda: el resultado depende de los datos de la tabla, que son típicos y orientativos: si un proyecto está cerca del borde (400 m con una radio que promete 500), el modelo da «sí» y la realidad puede decir «no». Cuando el número queda a menos de un factor de dos del límite, se prueba, no se calcula.

13 · Exploración interactiva

Laboratorio: filtro, tiempos, cables, batería y matriz

El laboratorio tiene cinco herramientas, que siguen el orden del método. La primera descarta las tecnologías que no cumplen los requisitos. La segunda calcula el tiempo real y la eficiencia de mandar un mensaje en cada protocolo. La tercera calcula hasta dónde llega cada cable a una velocidad dada. La cuarta calcula la vida de una batería. La quinta arma una matriz de decisión ponderada con los candidatos. Todos los datos de las tecnologías son valores típicos de los temas del curso, orientativos.

En la herramienta 1, las tecnologías se descartan en este orden: medio, cantidad de nodos, robustez al ruido, batería y, por último, la combinación de distancia y velocidad contra los puntos de operación de cada una (a más velocidad, menos distancia). En la 2, el LoRa usa la fórmula de tiempo en el aire del fabricante con preámbulo de 8, encabezado explícito, CRC y codificación 4/5; Modbus cuenta 11 bits por carácter y dos silencios de 3,5 caracteres, sin el tiempo de proceso del esclavo. En la 3, RS-485 sigue la regla de velocidad por distancia, CAN la tabla clásica, I²C el límite de capacidad del bus y RS-232 su especificación. En la 4, la carga por mensaje incluye arranque, medición y radio. En la 5, los puntajes de alcance, velocidad y nodos salen de los mismos datos que la herramienta 1; el costo y la facilidad son juicios de este curso.

Recorrido guiado

1. En la herramienta 1, con los valores por defecto (500 m, 9600 bit/s, 30 nodos, industrial): cumplen RS-485 (hasta 1,2 km a 100 kbit/s) y CAN (hasta 500 m a 125 kbit/s). Se descartan por los nodos la UART, SPI, RS-232, Bluetooth clásico, BLE, nRF24 y ESP-NOW; por el ruido, I²C, 1-Wire, Wi-Fi y Zigbee; y por distancia y velocidad, Ethernet (100 m) y LoRa (5,5 kbit/s). Con 3000 m, 300 bit/s, 100 nodos, entorno medio y batería: queda solo LoRa. Con 20 m, 5e6 bit/s, 2 nodos, interior tranquilo y solo inalámbrico: solo Wi-Fi. Con 1000 m y 1e6 bit/s: ninguna.
2. En la herramienta 2, con 4 bytes por Modbus RTU a 9600: 264 bits, 27,5 ms, 1,2 kbit/s útiles de los 9,6 anunciados y 12,1 % de eficiencia; con 100 bytes: 137,5 ms y 60,6 %. Con UDP y 4 bytes: 6,7 µs y apenas 4,8 %. Con CAN a 500 kbit/s: 164 µs y 39 %. Con LoRa SF9 y 10 bytes: 144,4 ms en el aire y 31,5 %; con SF12 y 4 bytes: 827 ms. En SPI a 1 MHz con 100 bytes, el 99 % de lo que ocupa la línea son datos.
3. En la herramienta 3, con 500 m a 9600 bit/s (5 dispositivos y 80 pF/m): RS-485 llega a 1,2 km y CAN a 5 km (a 10 kbit/s o menos); I²C solo a 4,4 m y RS-232 a 15 m: no alcanzan. Con 2 m a 400 kbit/s: I²C llega a 3,9 m, RS-232 solo a 75 cm. Con 200 m a 1 Mbit/s: RS-485 llega a 120 m y CAN a 40 m, así que ninguna. Con 40 m a 1 Mbit/s: alcanzan RS-485 y CAN.
4. En la herramienta 4, con los valores por defecto (2000 mAh, 15 µA, BLE con un ESP32 y 19,9 mC cada 300 s): 81,3 µA de media, 27 meses (2,25 años), el 82 % de la energía en comunicar y un período mínimo de 261 s para llegar a los 2 años. Cada hora: 20,5 µA y 8,9 años. Con LoRa SF9 cada 300 s: 41,1 µA y 4,4 años. Con Wi-Fi cada 300 s: 348 µA y 6,3 meses. Con el SoC de BLE cada 300 s: 15,2 µA y 12 años. La pulsera (220 mAh, 2 µA de sueño, cada 10 s): con el ESP32 dura 3,7 días; con el SoC de BLE, 2,9 años.
5. En la herramienta 5, con los pesos por defecto de una planta ruidosa: LoRa 85, RS-485 84, Wi-Fi 80, Ethernet 79, CAN 74; el último es SPI con 46. Los dos primeros quedan casi empatados: la matriz no decide, y LoRa es la primera aunque la herramienta 1 la descartó para ese caso. Con un sensor a pila (alcance 0, velocidad 1, nodos 1, ruido 0, consumo 5, costo 3, facilidad 3, seguridad 2): BLE con 88 puntos y, detrás, UART, SPI e I²C con 81 (son buses de la placa: la matriz sola no sabe que no unen equipos separados). Con una casa (1, 3, 2, 1, 0, 4, 5, 3): Wi-Fi con 89, ESP-NOW con 80 y BLE con 79. Con sensores en el campo (5, 0, 4, 3, 5, 3, 2, 3): LoRa con 92, BLE con 82 y Zigbee con 78.

14 · Comprensión

Confusiones frecuentes

15 · Práctica guiada

Predecí antes de comprobar

1. Eliminar

Un proyecto necesita 2 km de distancia, 1 Mbit/s y 50 nodos con corriente en cada uno. ¿Qué tecnología lo cumple? ¿Qué se puede hacer?

2. La velocidad útil

Un sensor Modbus debe entregar 4 bytes por segundo a 9600 baudios. ¿Cuánto tarda cada consulta? ¿Cuántos sensores soporta un maestro que los sondea uno por uno en ese bus, si cada uno se consulta una vez por segundo y el esclavo tarda 5 ms en responder?

3. Cuánto gasta el mensaje

Un nodo LoRa SF12 manda 10 bytes. ¿Cuánto dura en el aire? ¿Cada cuánto como mínimo puede hablar si la banda limita el ciclo de trabajo al 1 %?

4. Un bus I²C que se alarga

Un bus I²C a 400 kHz tiene 8 dispositivos y un cable de 80 pF por metro. ¿Hasta qué largo de cable llega, según el modelo de la herramienta 3?

5. El mismo BLE, dos chips

Un dispositivo con una pila de 220 mAh reporta cada 10 s. Con un ESP32 (19,9 mC por ciclo, 2 µA de sueño), ¿cuánto dura? Con un SoC de BLE (0,05 mC por ciclo)?

6. Una matriz que no decide

Una matriz da 85 puntos a LoRa y 84 a RS-485 para una planta ruidosa de 500 m a 9600 bit/s. ¿Qué haría falta mirar para decidir?

7. Agrupar lecturas

Un nodo envía 10 lecturas de 4 bytes, una por mensaje, en UDP. Si en cambio manda las 10 en un solo mensaje, ¿cuánto se ahorra en el cable de Ethernet?

8. Escribir la decisión

Elegiste RS-485 con Modbus RTU para una planta. ¿Qué cuatro cosas incluye la nota que dejás escrita?

16 · Síntesis

Ideas para recordar

¿Listo para el siguiente tema?

Antes de avanzar, elegí con el método un enlace para 60 sensores a 250 m en un galpón con soldadoras, cada uno enviando 6 bytes por segundo: escribí los requisitos con números, qué eliminás y por qué, qué calculás para verificar la capacidad, y qué riesgo probarías primero. Si podés justificar cada paso, estás listo para el proyecto final.

En el próximo tema se aplica todo en un proyecto de red de sensores con puerta de enlace: nodos por RS-485 o inalámbricos, un protocolo propio con CRC, reintentos y autenticación, una puerta de enlace con Wi-Fi y la publicación por MQTT. Es la integración de los temas 41 a 50 en un sistema completo.