¿Un módulo infrarrojo necesita SDK?
Un SDK para módulo infrarrojo no siempre es obligatorio, pero en la mayoría de los proyectos OEM influye directamente en el plazo de desarrollo, la coherencia de la medición térmica y el coste de mantenimiento posterior. La conclusión práctica es clara: si el sistema solo necesita mostrar vídeo, quizá no haga falta un SDK completo; si necesita acceder a datos raw, medir temperatura, controlar lentes, sincronizar una gimbal, ejecutar algoritmos de IA o gestionar calibración en producción, normalmente se necesita un SDK o, como mínimo, una documentación de interfaz equivalente y suficientemente abierta.
¿Para qué sirve un SDK para módulo infrarrojo?
Un SDK suele cubrir cuatro grupos de funciones: control del dispositivo, adquisición de imagen, configuración de parámetros y análisis de datos. Entre los controles habituales están la corrección NUC con obturador, AGC, mejora de detalle DDE, zoom electrónico, paletas de pseudocolor, rangos de temperatura, tiempo de integración, frecuencia de imagen, motor de lente, disparo FFC y lectura del estado interno del módulo.
La capa de datos es todavía más crítica. Un módulo de 640×512, a 16 bit y 30 Hz, genera un flujo bruto aproximado de 640×512×16×30≈157 Mbit/s. En 1280×1024 a 30 Hz, el flujo sube a unos 629 Mbit/s. La interfaz elegida, ya sea MIPI, LVDS, USB, GigE o Camera Link, cambia por completo el diseño del driver, los búferes, la gestión de pérdidas de trama y la sincronización con otros sensores.
Sin SDK, el equipo de ingeniería debe interpretar por su cuenta cabeceras de trama, marcas de tiempo, tablas de píxeles defectuosos, metadatos térmicos y protocolo de comandos. Eso no es imposible, pero alarga las pruebas y aumenta el riesgo de que el prototipo funcione en laboratorio y falle al cambiar de lote, firmware o lente.
Por ejemplo, en un módulo LWIR no refrigerado como SPECTRA L06 640×512 LWIR 12μm, si el proyecto solo requiere salida de vídeo y control básico por menú, una especificación de interfaz puede ser suficiente. Pero si se necesita capturar gris raw de 14/16 bit en la placa principal y aplicar algoritmos propios, el SDK reduce de forma clara el riesgo de integración.
¿En qué casos no hace falta un SDK?
El primer caso es la integración orientada solo a visualización. El módulo entrega BT.656, HDMI, vídeo analógico o vídeo digital ya procesado, y el sistema anfitrión únicamente muestra, graba o retransmite la señal por red. En esta arquitectura, los puntos críticos son alimentación, disipación térmica, fijación mecánica, formato de vídeo y EMC. El software puede limitarse a un control mínimo.
El segundo caso aparece cuando el cliente ya dispone de una cadena ISP o FPGA madura. Algunas arquitecturas reciben directamente LVDS o MIPI en FPGA, resuelven internamente la sincronización de línea y campo, el almacenamiento temporal, el AGC y la mejora de imagen. En ese escenario, lo esencial no es un SDK de alto nivel, sino una tabla de registros fiable, temporización eléctrica y un protocolo de comunicación completo.
El tercer caso son equipos de producción con parámetros fijos. Por ejemplo, el módulo arranca siempre con la misma frecuencia de imagen, la misma paleta, el mismo rango térmico y el host solo lee la imagen de vídeo. Este diseño reduce dependencias de software, pero exige que el proveedor garantice firmware estable, control de versiones y comportamiento repetible.
No usar SDK no significa trabajar sin interfaz. Como mínimo se deben recibir especificaciones eléctricas, temporización, comandos, códigos de error, gestión de versiones y procedimiento de actualización. Sin esos elementos, cualquier cambio de firmware, lente o lote de detectores puede convertirse en un problema difícil de diagnosticar.
SDK para módulo infrarrojo en medición de temperatura: ¿es imprescindible?
En proyectos de medición térmica, la importancia del SDK aumenta mucho. Medir temperatura no consiste en convertir linealmente un nivel de gris en grados Celsius. Intervienen la respuesta del detector, la corrección de no uniformidad, la emisividad, la temperatura reflejada, la temperatura ambiente, la humedad, la distancia, la transmisión atmosférica y la transmisión óptica de la lente.
Para vocabulario y criterios de termografía infrarroja en ensayos no destructivos, puede consultarse ISO 10878:2013. Para características de sistemas y equipos de termografía infrarroja, ISO 18251-1:2017 es una referencia útil. En mantenimiento predictivo y diagnóstico de maquinaria, ISO 18434-1:2008 aborda procedimientos generales, interpretación de datos y compensaciones como emisividad, temperatura aparente reflejada y medios atenuantes.
Si el producto debe entregar punto central, temperatura máxima, temperatura mínima, media por ROI, isotermas o matriz térmica, conviene seleccionar un módulo con SDK de medición. La razón es simple: la cadena térmica debe ser trazable. En inspección eléctrica, un error de 2°C puede cambiar la clasificación de un defecto, la prioridad de mantenimiento o la decisión de detener un activo.
El SDK debería ofrecer, como mínimo, valores térmicos originales, función de conversión a temperatura, configuración de parámetros radiométricos, estadísticas por ROI y lectura de versión de calibración. En la práctica, no basta con preguntar si “mide temperatura”. Hay que preguntar si los parámetros radiométricos pueden escribirse por interfaz, si la matriz térmica puede leerse por trama y si los resultados quedan sincronizados con el vídeo.
MIPI, GigE e IA: cómo elegir la forma de integración
En proyectos embebidos, MIPI CSI-2 es común por su tamaño reducido en placa, baja latencia y buena compatibilidad con SoC. Es una opción habitual para drones, robots móviles y sistemas embarcados en vehículos. En un sistema de doble banda como FUSION LV0625A 640×512+2560×1440 MIPI 35mm, la integración ya no consiste solo en “tomar imagen”: hay que resolver sincronización entre infrarrojo y visible, marcas de tiempo, parámetros ISP y alineación previa a la fusión.
GigE es más adecuado cuando se necesitan cables más largos, PC industriales o despliegues distribuidos. Aunque 1 GbE tiene un ancho de banda teórico de 1000 Mbit/s, el rendimiento efectivo suele ser menor por cabeceras, protocolo, sistema operativo y fluctuación de búferes. Un flujo infrarrojo raw de 1280×1024, 16 bit y 30 Hz ya se acerca a 629 Mbit/s, por lo que la pérdida de tramas debe evaluarse con seriedad. En módulos de alta resolución como SPECTRA L12 1280×1024 LWIR, son especialmente valiosos los mecanismos de cola, callbacks, control de búfer y estadísticas de tramas perdidas dentro del SDK.
Los sistemas con IA añaden otra capa: el formato de entrada del modelo. Si se trabaja con una plataforma como NEXUS LV0619B AI multi-band Ethernet/SDI, el SDK no debe limitarse a entregar imagen. También debería proporcionar alineación multibanda, normalización, salida de inferencia y disparo externo. De lo contrario, el equipo de IA puede acabar dedicando más tiempo a limpiar datos y corregir desincronizaciones que a mejorar el modelo.
Qué preguntar al proveedor antes de comprar
El SDK debe figurar como entregable técnico en la especificación de compra, no como una promesa verbal. Antes de cerrar el diseño, conviene confirmar si soporta Windows, Linux y ARM Linux; si ofrece C/C++, Python o C#; si incluye archivos de cabecera, bibliotecas dinámicas, proyectos de ejemplo y documentación de API; y si permite acceder a datos raw de 14/16 bit.
También hay que verificar si soporta matriz térmica, si documenta seguridad de hilos, si la API mantiene compatibilidad tras una actualización de firmware, si la licencia queda vinculada al dispositivo y si se permite despliegue offline en producción. En proyectos de vida larga, estas preguntas pesan tanto como la resolución o el NETD.
Una estrategia equilibrada es usar el SDK para acelerar el prototipo y, al mismo tiempo, exigir documentación del protocolo de bajo nivel para producción. Así se evita quedar completamente bloqueado por una biblioteca propietaria. Los equipos de solo visualización pueden prescindir de un SDK completo; los proyectos de medición, IA, fusión multibanda, cargas útiles para UAV y mantenimiento a largo plazo deberían elegir módulos con SDK completo, protocolo abierto y versiones trazables. Para principios generales de ensayo termográfico industrial, ISO 10880:2017 también ofrece un marco de referencia útil.
Preguntas frecuentes
P1: Si solo necesito salida de vídeo, ¿hace falta un SDK para el módulo infrarrojo?
R: Normalmente no. Si el formato de vídeo, la resolución, la frecuencia de imagen y el protocolo de control están claros, el host puede limitarse a mostrar o grabar la señal.
P2: Para medir temperatura, ¿siempre debo usar SDK?
R: Es muy recomendable. La medición implica parámetros radiométricos, datos de calibración y lectura de matriz térmica. Inferir temperatura desde gris raw sin documentación completa suele ser arriesgado.
P3: ¿El SDK puede afectar la producción en serie?
R: Sí. Hay que confirmar versión de API, licencias, despliegue offline, compatibilidad con firmware y política de mantenimiento. También conviene pedir el protocolo de bajo nivel.
P4: En un proyecto de IA, ¿es más importante el SDK o el dato raw?
R: Se necesitan ambos. El SDK estabiliza la adquisición y la sincronización; los datos raw de 14/16 bit conservan más información térmica que una imagen de pseudocolor de 8 bit.
P5: ¿Qué señales indican que un SDK no es suficiente para un proyecto OEM?
R: Falta de documentación de errores, ausencia de control de versiones, incompatibilidad tras actualizar firmware, imposibilidad de acceder a datos raw o dependencia de una licencia que no pueda desplegarse en fábrica.
