> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/expert-center/es/vehicle-telematics-technology/video-telematics/video-telematics-101/inside-the-dashcam-what-really-powers-video-telematics.md). # Dentro de la cámara de tablero: qué realmente impulsa Vídeo telemática La arquitectura SoC determina la IA, la compresión y las capacidades de la cámara de tablero. Compara chips Novatek de bajo costo y Ambarella premium usados en cámaras de flota.
Imagine que está comparando dos dashcams para su flota. Ambas anuncian una resolución de video similar (digamos 1080p) y capacidad de almacenamiento, pero una cuesta $100 y la otra $200. A primera vista se ven iguales, con el mismo tamaño y las mismas funciones básicas, entonces ¿por qué la gran diferencia de precio? La respuesta está en la *inteligencia* dentro del dispositivo, específicamente el **sistema en chip (SoC)** que actúa como el cerebro de la cámara. La cámara más cara no es solo una caja mejor: es una caja más inteligente, equipada con procesamiento a bordo y capacidades de IA. En las cámaras modernas para flotas, son el SoC y su software los que marcan toda la diferencia en el rendimiento, no solo el lente o la tarjeta de memoria. Los gestores de flotas y los profesionales de telemática suelen centrarse en especificaciones como la resolución o el almacenamiento, pero lo que realmente distingue a una dashcam básica de una cámara de Vídeo telemática inteligente es el SoC. Este pequeño procesador (y sus componentes de soporte) maneja todo, desde capturar imágenes claras hasta analizar eventos de manejo en tiempo real. De hecho, aproximadamente el 65 % de la electrónica de una cámara telemática típica se dedica a la captura de imagen, el procesamiento y la IA: todas tareas que maneja el SoC. En contraste, solo alrededor del 25 % del hardware es para módulos de comunicaciones (como módems LTE y GPS). Por eso la elección del SoC tiene un impacto tan grande tanto en el rendimiento *y* costo del dispositivo. Un procesador de gama alta permite funciones avanzadas como alertas de asistencia al conductor, pero también eleva el precio debido a una mayor complejidad y a las tarifas de licencia (para cosas como la compresión de video H.265/HEVC). Dicho de forma simple: no todas las cámaras para flotas son iguales, aunque por fuera se vean similares. Las diferencias en el diseño interno, como el SoC, el sensor de imagen, el módem, la memoria, etc., afectan directamente la calidad de imagen, la capacidad de respuesta, las capacidades de IA, el rendimiento de la red y la confiabilidad general de la cámara. Una cámara de menor costo quizá haga lo básico (grabar video y subirlo), pero un modelo de gama alta con un SoC más potente puede hacer mucho más: piense en monitoreo del conductor en tiempo real, alertas de abandono de carril, alertas de colisión frontal y otras funciones ADAS. Una plataforma agnóstica al dispositivo como Navixy permite que proveedores mixtos y familias de SoC convivan en un solo entorno, normalizando el video y los metadatos para que los equipos de operaciones elijan el hardware adecuado para cada ruta o papel sin quedar atados a una sola hoja de ruta. #### Dentro de una cámara de tablero inteligente: cómo el video pasa del lente a la nube Para apreciar el papel del SoC (el «cerebro» de la cámara), ayuda saber cómo procesa el video una cámara para flotas paso a paso. Desde el momento en que la luz golpea el sensor de la cámara hasta el momento en que una alerta aparece en su panel, ocurre mucho entre bastidores. A continuación se muestra un recorrido simplificado por el flujo de procesamiento de video dentro de una cámara telemática típica, y la mayor parte de estos pasos son orquestados por el SoC:
Article content

Desde la captura CMOS hasta los paneles de control en la nube, cada etapa define cómo el video se convierte en información útil para la flota

1. **Captura de imagen y procesamiento de señales (ISP).** Todo comienza con el sensor de imagen de la cámara (por lo general, un sensor CMOS) capturando luz y convirtiéndola en datos brutos de píxeles. Esta alimentación en bruto se entrega de inmediato al Procesador de Señal de Imagen (ISP) del SoC, un componente especializado en el chip que limpia y optimiza la imagen. El ISP realiza tareas críticas de procesamiento como debayering (convertir el mosaico crudo de datos de color del sensor en fotogramas de video RGB completos), ajustar el balance de blancos y la exposición, corregir los colores y reducir el ruido. También puede hacer cosas como la combinación de alto rango dinámico (HDR) para manejar la iluminación difícil. El resultado de esta etapa es un flujo de fotogramas de video sin comprimir de alta calidad y la base de todo lo que viene después. 2. **Preprocesamiento y análisis de IA.** En una cámara inteligente, antes de que el video siquiera se comprima o se guarde, el SoC podría hacerlo pasar por una etapa de análisis de IA. Esto lo maneja hardware dedicado en el SoC, como un *DSP* o una *NPU (Neural Processing Unit)* diseñada para tareas de IA. Aquí la cámara puede empezar a ser *inteligente*: busca eventos u objetos de interés en el video en tiempo real. Por ejemplo, la IA podría detectar una advertencia de colisión frontal, notar si el conductor está somnoliento o distraído, o reconocer una señal de alto o un peatón. El sistema también podría hacer extracción de región de interés (ROI), es decir, enfocarse en las partes importantes de la escena (como la carretera al frente o el rostro del conductor), para optimizar lo que necesita transmitirse o guardarse. Puede etiquetar fotogramas con metadatos (por ejemplo, «vehículo detectado» o «el conductor bosteza») para que después los eventos específicos sean fáciles de encontrar. Este preprocesamiento de IA es especialmente importante porque los datos de video en bruto son enormes; analizarlos en el origen ayuda a priorizar y reducir los datos antes de los siguientes pasos. (En una cámara básica con un SoC débil, este paso podría ser muy limitado o omitirse por completo, ya que el dispositivo solo capturaría y enviaría video sin «entenderlo».) 3. **Compresión de video (codificación).** Después, los fotogramas de video preparados pasan al *codificador de video*, otro motor dentro del SoC. Aquí, la cámara comprime el video usando códecs estándar, por lo general H.264 (AVC) o el más nuevo H.265 (HEVC). El video en bruto consume muchísimos datos (el video HD sin comprimir puede ocupar decenas de megabytes *por segundo*), así que la compresión es crítica. El codificador reduce el video a un flujo de datos manejable (a menudo unos cuantos cientos de kilobytes por segundo, según la calidad y la resolución). Muchas cámaras para flotas en realidad generan dos flujos de video: uno de alta calidad almacenado localmente (por ejemplo, en una tarjeta SD) y un flujo de menor tasa de bits para subirlo por redes celulares. El codificador de hardware del SoC maneja ambos al mismo tiempo. Por ejemplo, el motor de video de un SoC Novatek podría guardar una transmisión de resolución completa en la tarjeta de memoria mientras también envía en tiempo real una transmisión comprimida a la nube. Todo esto ocurre sobre la marcha gracias al SoC. (Vale la pena señalar que las licencias para códecs avanzados como H.265 pueden aumentar el costo de los SoC de gama alta, lo que es una de las razones por las que las cámaras premium admiten HEVC mientras las más baratas podrían seguir usando códecs más antiguos.) 4. **Almacenamiento y transmisión.** Una vez codificados, los datos de video se almacenan, se transmiten o ambas cosas. En una cámara típica para flotas, el SoC administrará el guardado de video en el almacenamiento local (como una tarjeta SD o memoria flash eMMC) en un búfer circular. Sobrescribe continuamente las grabaciones más antiguas para que, por ejemplo, siempre queden guardados los últimos 30-60 minutos, garantizando que los eventos recientes estén a la mano. Cuando se detecta un evento importante (frenado brusco, choque, alerta activada por IA, etc.), el sistema puede marcar y conservar ese clip. Muchos sistemas también almacenan en búfer unos cuantos segundos de video antes y después de un disparo de evento para dar contexto previo al incidente. Al mismo tiempo, el SoC pasa el flujo de video codificado al módulo de comunicaciones de la cámara (por ejemplo, un módem LTE) para subirlo. Junto con el video, el dispositivo enviará metadatos como coordenadas GPS, velocidad, datos del acelerómetro y cualquier etiqueta de evento generada por IA. Estos metadatos pueden ir incrustados en el flujo de video o enviarse en paralelo, aportando un contexto rico (por ejemplo, la ubicación exacta de un evento de frenado brusco, la velocidad en ese momento o el hecho de que se detectó que «el conductor está bostezando»). El módem celular (4G/3G, etc.) transmite entonces los datos a la nube. Aunque el módem y la antena son componentes separados, el SoC se coordina con ellos para enviar los datos por el aire de manera eficiente (a menudo usando protocolos para manejar conectividad intermitente, ancho de banda limitado, etc.). 5. **Procesamiento en la nube y en el servidor.** Una vez que el video y los datos llegan a la nube, el trabajo pesado pasa al lado del servidor. En Navixy, las grabaciones se transcodifican para una reproducción confiable, se indexan por etiquetas de eventos y se muestran en una línea de tiempo unificada junto con GPS/IMU. Cuando las cámaras reenvían datos auxiliares, como tramas CAN, paquetes de sensores BLE o bytes RS-485, IoT Logic los decodifica en la ingesta, de modo que las alertas de ADAS/DMS, el comportamiento del conductor y las señales del motor o de la carga permanezcan consultables juntos. El resultado es menos tiempo uniendo sistemas y más tiempo actuando sobre lo que importa. En todo este flujo, el SoC es la estrella en las etapas 1 a 4. Coordina el sensor, ejecuta el ISP, corre algoritmos de IA, codifica el video y administra el flujo de datos hacia el almacenamiento y el módem. No es de extrañar que la mayor parte del diseño (y del costo) de una dashcam se centre en estas tareas de procesamiento. Mientras tanto, otros componentes como el módulo LTE/GPS, aunque importantes, cumplen una función de apoyo. Si pensamos en una cámara telemática como una minicomputadora: el SoC es la CPU/GPU/NPU que hace el cómputo pesado, el sensor de imagen es como los ojos, el módem es el enlace de comunicación y el almacenamiento es la memoria. Un sistema equilibrado es importante, pero sin un «cerebro» de SoC capaz, ni el mejor sensor ni el mejor módem harán inteligente a una cámara. #### Cámaras básicas vs. avanzadas: cómo la elección del SoC define las funciones Ahora que ya vimos lo que ocurre dentro de una cámara, hablemos de las diferencias entre una cámara básica para flotas y una avanzada. En muchos casos, la *mayor* diferencia es qué tan potente es el SoC, especialmente en términos de capacidad de IA. Una dashcam más sencilla (y más barata) puede realizar todos los mismos pasos básicos del flujo, como capturar, codificar, almacenar y transmitir, pero quizá no tenga la inteligencia a bordo para hacer el Paso 2 (análisis de IA) de una manera realmente útil. En esencia actúa como un ojo electrónico, grabando lo que ve y enviándolo, pero dejando el «pensamiento» en la nube o sin hacerlo en absoluto. En cambio, una cámara de gama alta con un SoC potente hará mucho «pensamiento» en el dispositivo: puede detectar eventos, filtrar grabaciones e incluso tomar decisiones en tiempo real (como alertar al conductor) sin esperar a la nube. Considere **las funciones de ADAS y DMS**. Las funciones de ADAS (Sistemas avanzados de asistencia al conductor) incluyen cosas como alertas de salida de carril, alertas de colisión frontal o detección de peatones. Las funciones de DMS (Sistema de monitoreo del conductor) incluyen detectar si el conductor está distraído o somnoliento. Una cámara económica podría anunciarse como «compatible con ADAS», pero en realidad podría ser muy limitada, capaz de manejar solo un algoritmo sencillo con una precisión modesta (por ejemplo, una alerta de salida de carril que solo funciona a velocidades de autopista y con luz diurna clara). Esto suele deberse a que el SoC dentro tiene un procesador de IA muy modesto, si es que tiene alguno. Como se señaló antes, los SoC de menor costo con NPUs básicas solo pueden ejecutar **modelos ligeros de redes neuronales** (del orden de unos cuantos millones de parámetros) en tiempo real. Eso podría ser suficiente para un reconocimiento de patrones simple (como detectar una marca de carril o un vehículo directamente adelante). Pero no *alcanzará* para tareas más complejas como seguir simultáneamente múltiples objetos, identificar puntos de referencia del rostro del conductor (ojos cerrados, cabeza girada) y reconocer señales de tránsito que requieren modelos de IA más grandes y complejos.
Single SoC ingests main + aux feeds, runs per-channel AI, encodes in parallel

Un solo SoC recibe el flujo principal + auxiliar, ejecuta IA por canal, codifica en paralelo

Los SoC de gama alta, por otro lado, vienen con motores de IA mucho más potentes. Por ejemplo, Ambarella (un proveedor líder de SoC en este espacio) incluye su acelerador de red neuronal CVflow® en sus chips, que puede ejecutar CNN más grandes (decenas de millones de parámetros) e incluso varios modelos de IA a la vez. En términos prácticos, esto significa que una sola dashcam premium puede hacer IA multitarea: analizar la carretera para ADAS *y* vigilar al conductor para DMS al mismo tiempo, con precisión, a altas tasas de fotogramas. La cámara puede emitir alertas en tiempo real (zumbadores o advertencias habladas para el conductor) para una variedad de problemas de seguridad. También significa menos falsas alarmas o eventos perdidos, porque los modelos pueden ser más sofisticados. Por supuesto, todo esto requiere más potencia de procesamiento, razón por la cual los SoC de gama alta suelen usar tecnología de chip más avanzada (por ejemplo, fabricación de semiconductores de 10 nm, en lugar de procesos más antiguos de 28 nm o 14 nm) para ofrecer alto rendimiento sin sobrecalentarse ni agotar la batería del vehículo. Otro aspecto a considerar es cuántos canales de video puede manejar el SoC. Las configuraciones para flotas a veces usan cámaras orientadas hacia el frente y hacia el conductor, o incluso sistemas multicámara (laterales, vista trasera, etc.). Un SoC de entrada quizá solo pueda manejar uno o dos flujos de video a resolución completa. Intente agregar más cámaras o mayor resolución, y podría saturarse (tasas de fotogramas bajas, o simplemente no admite entradas adicionales). Un SoC más capaz puede ingerir y procesar varios flujos. Por ejemplo, algunos SoC orientados a MDVR pueden aceptar cuatro entradas de cámara de 1080p (comunes para una cobertura vehicular de 360°), mientras que un SoC automotriz enfocado en ADAS podría admitir una combinación, por ejemplo, de una cámara frontal 4K más una cámara del conductor de 1080p, o incluso varias cámaras de alta resolución para vista envolvente. Una vez más, estas diferencias se deben al diseño interno: el chip de gama alta tendrá un ISP más avanzado que puede manejar mayores tasas de datos e incluso quizá un segundo ISP para entrada de doble cámara, más instancias de codificador, y así sucesivamente. Por eso también muchas flotas estandarizan una sola vista en la nube: Navixy mantiene alineadas las etiquetas de IA, el video y la telemática sin importar qué SoC tenga el vehículo. En resumen, la elección del SoC dicta directamente qué funciones puede ofrecer una cámara: * Un SoC básico = cámara básica. Grabará video, lo comprimirá y lo enviará de forma confiable, pero cualquier «inteligencia» será mínima. Podría obtener una etiquetación de eventos sencilla basada en el sensor G (por ejemplo, detectar un choque mediante un acelerómetro) o alertas al conductor muy rudimentarias, pero no mucho en términos de advertencias o análisis realmente avanzados. * Un SoC avanzado = cámara inteligente. Puede funcionar como un copiloto a bordo, vigilando tanto la carretera como al conductor. Filtra las grabaciones importantes (para que su plan celular no se sature con clips triviales) y aporta datos más ricos a la plataforma de gestión de flotas (como identificar comportamientos o riesgos específicos). Esta cámara, en esencia, tiene un sistema de visión por computadora integrado. La compensación, por supuesto, es el costo. La cámara de gama alta con el chip de IA potente costará más, no solo porque el silicio en sí es más caro, sino también por el desarrollo del software de IA que se ejecuta en él. Mientras tanto, la cámara más simple podría ser muy asequible pero terminar *costando* más de forma indirecta: quizás se pierda eventos críticos o no proporcione las advertencias preventivas que podrían evitar un accidente. La clave es encontrar la combinación adecuada entre sus necesidades operativas y las capacidades de la cámara. Sea cual sea el nivel que implemente, los resultados se mantienen consistentes cuando el backend es agnóstico al dispositivo. Navixy muestra MDVR básicos y cámaras ADAS/DMS premium lado a lado en los mismos paneles, reportes y APIs, así que las actualizaciones no fuerzan cambios de flujo de trabajo. #### Bajo el cofre: comparación de dos ejemplos de SoC (económico vs. premium) Para hacerlo más concreto, comparemos dos plataformas de SoC reales que suelen encontrarse en dashcams y cámaras para flotas. En el lado económico, tenemos el **Novatek NT98321**, un chip que se usa comúnmente en MDVR y dashcams rentables. En el extremo premium, está el **Ambarella CV2**, parte de la serie CVflow de Ambarella, utilizada en cámaras automotrices premium. Estos dos son buenos representantes de sus respectivos niveles: Novatek es conocido por procesadores asequibles y de alto volumen (muchas dashcams de catálogo usan SoC Novatek), mientras que Ambarella es reconocido por chips de gama más alta, centrados en IA, usados en cámaras avanzadas de asistencia al conductor e incluso en sistemas de vehículos autónomos. * **Novatek NT98321** está optimizado para grabación Full HD multicanal a bajo costo. Puede manejar varios flujos de video de 1080p (por ejemplo, una configuración de 4 cámaras a 1080p cada una) y realizar tareas básicas de IA con su NPU integrada. Esto es ideal para un DVR estándar de flota que quizá graba el frente, los laterales y el interior, y hace detecciones básicas de eventos como alertas de colisión frontal o alertas de somnolencia del conductor en uno o dos canales. Está diseñado para ser eficiente en consumo para uso móvil y para mantener bajo el costo total de materiales del dispositivo. * **Ambarella CV2**, por otro lado, es una bestia más potente. Fabricado con tecnología de proceso de 10 nm, integra el motor de IA especializado CVflow de Ambarella, lo que le da muchísima más capacidad de procesamiento de IA (del orden de 20× el rendimiento de red neuronal de la generación anterior de Ambarella). Admite entrada de mayor resolución (hasta 4K a 60 fps), múltiples sensores de imagen (puede recibir flujos de varias cámaras, incluidas configuraciones estereoscópicas) y puede ejecutar redes neuronales avanzadas multimodelo para funciones como detección de carril, reconocimiento de objetos y monitoreo del conductor, todo al mismo tiempo. Esto lo hace ideal para **cámaras centradas en ADAS**, como una cámara frontal inteligente que no solo graba en 4K ultra claro, sino que también identifica salidas de carril, mide la distancia de seguimiento con respecto al vehículo de adelante, lee señales de límite de velocidad y monitorea si los ojos del conductor están en la carretera. La compensación es un costo más alto: el CV2 se ubica en un rango de precios premium (los analistas señalan que estos chips de IA de gama alta tienen precios significativamente más altos que los SoC convencionales). Pero con ese costo viene un salto importante en capacidad. Para una comparación lado a lado, vea la tabla a continuación, que destaca algunas diferencias clave entre una solución basada en Novatek NT98321 y una solución basada en Ambarella CV2:
Article content

Comparación de un SoC enfocado en costo vs. un SoC de alto rendimiento

*Tabla: Comparación de un SoC enfocado en costo (Novatek NT98321) vs. un SoC de alto rendimiento (Ambarella CV2) en cámaras de Vídeo telemática. Ambarella sobresale en IA y capacidades 4K, mientras que Novatek prioriza varios canales de 1080p a bajo costo. Funciones y datos resumidos a partir de información del fabricante y despieces de dispositivos.* Como ilustra la tabla, un Ambarella CV2 ofrece muchísima más capacidad que un Novatek NT98321, pero no todos los camiones necesitan el mismo nivel. Muchas flotas combinan un MDVR asequible basado en NT98321 para la cobertura con una unidad frontal basada en CV2 para capacitación y prevención. Con Navixy como backend agnóstico al dispositivo, no tiene que tomar una decisión de un solo SoC para toda la flota; usted estandariza en la plataforma y deja que el caso de uso dicte la cámara. Cuando la prioridad es la seguridad proactiva, como con detección de fatiga, alertas de salida de carril y de colisión frontal, o detalle a nivel de placa, una unidad de clase CV2 destaca y Navixy lleva sus eventos más ricos a los mismos flujos de trabajo que usted usa para el resto de la flota. #### Cómo elegir la opción correcta para su flota Al elegir una cámara de Vídeo telemática, es tentador comparar especificaciones obvias como megapíxeles, campo de visión, tamaño de almacenamiento, etc. Sin duda, esas son importantes, pero como hemos comentado, las especificaciones menos obvias, como el **SoC y sus capacidades** son lo que realmente diferencia a una cámara «inteligente» de una básica. Aquí hay algunas consideraciones y conclusiones clave para gestores de flotas y proveedores de soluciones telemáticas: * **Ajuste la inteligencia de la cámara a sus necesidades.** Si solo necesita grabación de video confiable (como evidencia después de incidentes) y quizá cargas automáticas de eventos de frenado brusco, una cámara de gama media o básica puede ser suficiente. Pero si quiere funciones de seguridad preventiva (alertas de salida de carril, monitoreo del estado del conductor, alertas para evitar colisiones), busque cámaras con un SoC capaz de IA que admita explícitamente funciones ADAS y DMS. El costo adicional inicial puede rendir frutos al evitar accidentes y mejorar el comportamiento del conductor. Recuerde: esa inteligencia extra no viene de la carcasa o del sensor de la cámara, sino del procesador y el software internos. * **No se base solo en la resolución.** Una etiqueta de 1080p o 4K no cuenta toda la historia. Una cámara de gama baja puede tener la misma resolución de sensor que una de gama alta, pero la calidad del procesamiento de imagen podría diferir. Los SoC de gama alta tienen ISP más avanzados, lo que significa imágenes más nítidas, mejor desempeño con poca luz y colores y exposición más precisos. Eso puede ser crucial para obtener grabaciones útiles (por ejemplo, capturar los números de placas por la noche). Así que considere el procesador de imagen, no solo el sensor de imagen, especialmente si la calidad de la evidencia en video es importante para usted. * **Considere la expansión multicanal y el margen de la plataforma.** Elija un backend agnóstico al dispositivo (por ejemplo, Navixy) que admita tanto cámaras de clase MDVR como de clase ADAS/DMS, para que agregar vistas orientadas al conductor o pasar a resoluciones más altas no obligue a cambiar de plataforma. * **Revise las funciones de IA declaradas y las actualizaciones.** Los fabricantes a menudo enumeran funciones ADAS (salida de carril, advertencia de colisión frontal, etc.) si la cámara las admite. Sin embargo, tenga en cuenta que hay una diferencia entre las implementaciones básicas y las avanzadas. Trate de averiguar *cómo* logra la cámara esas funciones. ¿Tiene un chip de IA dedicado (NPU)? ¿Qué tan «inteligente» afirma ser? Además, considere si el dispositivo admite actualizaciones de firmware para sus modelos de IA: una buena plataforma podría mejorar con el tiempo mediante software, mientras que una realmente de gama baja quizá nunca reciba actualizaciones ni funciones nuevas. * **Planifique los datos auxiliares (más allá del video).** Si las cámaras reenvían datos de sensores CAN, BLE o RS-485, use una plataforma con decodificación del lado de la nube como Navixy IoT Logic. Mantiene alineadas las etiquetas de IA y el estado de los sensores, lo que permite políticas basadas en combinaciones (por ejemplo, somnolencia + exceso de velocidad o sobretemperatura + giro brusco). * **Equilibre presupuesto y beneficio.** En última instancia, todo se reduce al ROI. Una cámara con un SoC de última generación costará más, pero si evita un accidente grave o proporciona evidencia clara que ahorra un reclamo de seguro, puede pagarse sola fácilmente. Por otro lado, si las operaciones de su flota tienen relativamente poco riesgo y usted principalmente quiere cámaras para documentación, podría optar por la solución más simple y ahorrar presupuesto. La clave es entender por qué está pagando usted: *«comprando inteligencia, no una caja.»* La caja por sí sola no hace gran cosa. Es la inteligencia (el SoC y el software integrado) la que aporta el valor. El mundo de Vídeo telemática demuestra la regla: obtiene lo que paga. Las especificaciones externas rara vez revelan cuánto permite realmente el SoC (el cerebro de silicio). Mire más allá de los píxeles y el almacenamiento, y verá por qué importa elegir el chip correcto. Desde unidades básicas de evidencia hasta cámaras ADAS avanzadas, la verdadera prueba es cómo funcionan juntas. Un piloto con cámaras mixtas en un backend agnóstico al dispositivo como Navixy muestra la diferencia al instante: capacitación, reclamos y ancho de banda gestionados en un solo lugar sin dependencia de proveedor. En el mercado actual, la inteligencia dentro de la cámara es lo que impulsa la seguridad y el ROI. Las flotas más inteligentes compran el cerebro, no solo la caja. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://navixy.com/docs/expert-center/es/vehicle-telematics-technology/video-telematics/video-telematics-101/inside-the-dashcam-what-really-powers-video-telematics.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.