MXPA00002742A - Aparato de television digital para controlar un dispositivo periferico por medio de una barra colectora digital - Google Patents

Aparato de television digital para controlar un dispositivo periferico por medio de una barra colectora digital

Info

Publication number
MXPA00002742A
MXPA00002742A MXPA/A/2000/002742A MXPA00002742A MXPA00002742A MX PA00002742 A MXPA00002742 A MX PA00002742A MX PA00002742 A MXPA00002742 A MX PA00002742A MX PA00002742 A MXPA00002742 A MX PA00002742A
Authority
MX
Mexico
Prior art keywords
peripheral device
digital
control
digital television
bus
Prior art date
Application number
MXPA/A/2000/002742A
Other languages
English (en)
Inventor
Thomas Anthony Stahl
Steven Charles Rhoads
Mike Arthur Derrenberger
Izzat Hekmat Izzat
Saban Kurucay
Amit Kumar Chatterjee
Sanjeev Nagpal
Original Assignee
Amit Kumar Chatterjee
Mike Arthur Derrenberger
Izzat Hekmat Izzat
Saban Kurucay
Sanjeev Nagpal
Steven Charles Rhoads
Thomas Anthony Stahl
Thomson Consumer Electronics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Amit Kumar Chatterjee, Mike Arthur Derrenberger, Izzat Hekmat Izzat, Saban Kurucay, Sanjeev Nagpal, Steven Charles Rhoads, Thomas Anthony Stahl, Thomson Consumer Electronics Inc filed Critical Amit Kumar Chatterjee
Publication of MXPA00002742A publication Critical patent/MXPA00002742A/es

Links

Abstract

Se define un nivel mínimo de interoperabilidad para intercambiar contenido de audio/video (A/V), y un control asociado entre los dispositivos electrónicos comunes del consumidor (CE).Esta interperabilidad se base en la barra colectora en serie IEEE.1394 para las capas física y de enlace, y hace uso de AV/CóCAL como el lenguaje de control. Esta invención proporciona la reducción del número de controles remotos que el usuario podría necesitar, permitiendo que los comandos de control remoto siempre sean recibidos por un dispositivo de control (por ejemplo, un televisor digital), y luego encaminados al dispositivo periférico apropiado (por ejemplo, una VCR digital), después de traducirse a un formato universal.

Description

APARATO DE TELEVISIÓN DIGITAL PARA CONTROLAR UN DISPOSITIVO PERIFÉRICO POR MEDIO DE UNA BARRA COLECTORA DIGITAL Campo de la Invención La invención involucra un sistema para controlar múltiples dispositivos electrónicos, tales como dispositivos electrónicos del consumidor o similares, por medio de interconexiones, tales como barras colectoras de datos digitales. De una manera más particular, esta invención se refiere a una configuración para administrar la interoperabilidad de estos dispositivos.
Antecedentes de la Invención Una barra colectora de datos se puede utilizar para interconectar dispositivos electrónicos, tales como receptores de televisión, dispositivos de despliegue visual, grabadoras de video-casete (VCR) , receptores de satélite de transmisión directa (DBS) , y dispositivos de control del hogar (por ejemplo, un sistema de seguridad o un dispositivo de control de temperatura) . La comunicación utilizando una barra colectora de datos se presenta de acuerdo con un protocolo de la barra colectora. Los ejemplos de los protocolos de barras colectoras incluyen la Barra Colectora Electrónica del Consumidor (CEBus) , y la Barra Colectora en Serie de Alto Rendimiento IEEE-1394.
Un protocolo de barra colectora normalmente proporciona comunicación tanto de información de control como de datos. Por ejemplo, la información de control de CEBus se comunica sobre un "canal de control" que tiene un protocolo definido en la especificación IS-60 de la Electronics Industries Association (EIA) . En una barra colectora en serie IEEE-1394, la información de control generalmente se pasa utilizando los servicios asincrónicos de la barra colectora en serie. La información de control para una aplicación particular se puede definir utilizando, por ejemplo, el Lenguaje de Aplicación Común (CAL), o AV/C. En la actualidad, la mayoría de los dispositivos A/V se controlan con una unidad a control remoto (RC) . El enlace directo o físico real se puede implementar con transmisión infrarroja (IR), de ultrasonido (US), o de radiofrecuencia (RF) . El protocolo entre el dispositivo periférico y la unidad a control remoto es un dispositivo específico, de tal manera que cada dispositivo viene con su propia unidad de control remoto. Cada dispositivo periférico interpreta los tecleos que recibe por medio de su enlace directo, y realiza las acciones correspondientes. Por consiguiente, en el caso del infrarrojo, el control de un dispositivo periférico u objetivo está limitado a una línea de visión directa entre la unidad de control remoto y el dispositivo periférico.
En el grupo de audio/video (A/V) analógico de la actualidad, los dispositivos periféricos de control pueden incluir, pero no requerir, la activación de un mecanismo de Despliegue Visual en Pantalla (OSD) , en un dispositivo de despliegue visual (es decir, un televisor) . El despliegue visual en pantalla de estos dispositivos de audio/video se genera en el dispositivo periférico u objetivo (por ejemplo, la VCR digital) , y se produce sobre la salida NTSC de estos dispositivos de la misma manera que cualquier otra señal de video. Por consiguiente, no se necesita hardware o software adicional en el dispositivo periférico o en el dispositivo de despliegue visual. La Figura 1 ilustra un sistema A/V actual 10 que tiene una VCR 12 y un dispositivo de despliegue visual 14 (por ejemplo, un televisor) , que emplea esta metodología de control. Los menúes asociados con la VCR de control 12, son generados por la VCR 12, y se proporcionan al dispositivo de despliegue visual 14 por medio de la salida NTSC de la VCR 12 como un video compuesto. Desafortunadamente, el utilizar el mismo planteamiento (ver la Figura 2) con un televisor digital (DTV) , como un dispositivo de despliegue visual 14', no es práctico, debido a que se requeriría que los menúes fueran transportados como corrientes de transporte MPEG-2. La generación de estas corrientes necesita de la integración de un codificador MPEG 15' en todos los dispositivos periféricos, lo cual incrementa mucho el costo y la complejidad de estos dispositivos electrónicos del consumidor. Compendio de la Invención La presente invención proporciona un nivel mínimo de interoperabilidad para intercambiar contenido de audio/video (A/V) , y el control asociado entre los dispositivos electrónicos del consumidor comunes (CE) . La interfase se basa en la barra colectora en serie IEEE-1394 para las capas físicas y de enlace, y hace uso de un ^lenguaje de control, tal como AV/C ó CAL, para administrar los OSDs, y controlar la conectividad de los dispositivos interconectados por medio de una barra colectora en serie digital. De una manera particular, esta invención proporciona la reducción del número de controles remotos que podría necesitar el usuario, al permitir que siempre se reciban comandos de control remoto mediante un dispositivo de control (por ejemplo, un televisor digital o DTV) , y luego encaminarlos al dispositivo periférico apropiado después de traducirse a un formato universal. Un mensaje remoto universal se lleva a través de la barra colectora en serie, y permite aplicaciones complejas, tales como permitir al usuario seleccionar un programa para grabar utilizando la EPG del DTV, Aunque será posible controlar cada dispositivo CE a través de su propio tablero frontal o su propio control remoto, se reconoce que es altamente deseable controlar todos los dispositivos del grupo con un control remoto. Una manera de alcanzar esta meta de un modo que amplíe la interoperabilidad, es utilizar un lenguaje de control estándar (por ejemplo, CAL o AV/C) , para llevar mensajes de control remoto universales a través de la barra colectora. Esto también permitiría el control de los dispositivos que no estén directamente en la línea de visión (por ejemplo, los dispositivos en un cuarto diferente u ocultos, por ejemplo detrás de una puerta de un gabinete) , siempre que estén en la barra colectora en serie IEEE-1394. Una vez que el usuario ha exhibido el menú del dispositivo periférico en un dispositivo de despliegue visual, el dispositivo de despliegue visual puede relevar los comandos iniciados por el usuario (es decir, los tecleos en el control remoto (RC) ) pretendidos para el dispositivo periférico, recibidos por cualquier enlace apropiado (por ejemplo, enlace IR) . Las teclas de control remoto se mapearían en un lenguaje de comando común, con el que cumplirían todos los dispositivos electrónicos de consumidor de cualquier fabricante, antes de transferirse .
Breve Descripción de los Dibujos La invención se puede entender mejor haciendo referencia al dibujo adjunto, en el cual: La Figura 1 muestra, en una forma de diagrama de bloques simplificada, la interoperabilidad de un sistema de audio/video de la técnica anterior. La Figura 2 muestra, en una forma de diagrama de bloques simplificada, la extensión de la interoperabilidad de la técnica anterior entre una VCR digital y un televisor digital . La Figura 3 es un diagrama de bloques esquemático simplificado que ilustra el protocolo de la barra colectora en serie IEEE-1394. La Figura 4 muestra, en una forma de diagrama pictórico simplificado, un grupo de dispositivos electrónicos digitales del consumidor, que ilustra la trayectoria de los comandos iniciados por el usuario. La Figura 5 muestra, en una forma de diagrama de bloques esquemático simplificado, la interoperabilidad de los dispositivos digitales que emplea la presente invención. En el dibujo, los numerales de referencia que sean idénticos en las diferentes figuras, indican características que son iguales o similares.
Descripción Detallada de los Dibujos El uso de la barra colectora en serie IEEE-1394 se ha sugerido para muchas aplicaciones dentro de un medio ambiente de Red del Hogar. Se está discutiendo dentro de la Video Electronics Standards Association (VESA) , el uso como una "red total del hogar". Se está construyendo en las PCs de la siguiente generación, y se utilizará para muchos periféricos locales, incluyendo unidades de disco. Además, los dispositivos electrónicos de audio/video digitales del consumidor, tales como televisores digitales (DTVs) y grabadoras de video-casete digitales (DVHS) pueden utilizar una barra colectora en serie para interconectar estos dispositivos . La IEEE-1394 es una barra colectora en serie digital de alta velocidad y bajo costo desarrollada para utilizarse como un periférico o una barra colectora de plano posterior. Algunos de los puntos sobresalientes de la barra colectora incluyen: asignaciones de dirección de nodo dinámico, velocidades de datos de 100, 200, y 400 Mbits/segundo, modos asincrónico e isocrónico, arbitraje justo de la barra colectora, y consistencia con ISO/IEC 13213. La Figura 3 ilustra el protocolo de la barra colectora en serie para la barra colectora en serie IEEE-1394, 16, como un conjunto de tres capas apiladas. La capa física 18 consiste en los circuitos de señalización físicos, y la lógica, que son responsables de la inicialización de energización, arbitraje, detección de restablecimiento de barra colectora, y señalización de datos. Se definen dos pares de señal diferencial de bajo voltaje protegidos, más un par de energía para el cable en serie de la IEEE-1394. La señalización se hace utilizando un nivel de bits de estrobe de datos que codifica con tolerancia de dobles saltos. Los datos se formatean en paquetes en la capa de enlace 20. Se soportan dos clases de comunicación de datos entre los dispositivos: asincrónicos e isocrónicos. La comunicación asincrónica se puede caracterizar como "permite el reconocimiento", mientras que la comunicación isocrónica se puede caracterizar como "siempre a tiempo" . El servicio asincrónico se utilizará primordialmente para controlar los mensajes de estado, mientras que la comunicación isocrónica se utilizará para las corrientes de datos, tales como video MPEG. La naturaleza oportuna de la comunicación isocrónica se logra proporcionando un ciclo cada 125 microsegundos. Los ciclos isocrónicos tienen prioridad sobre la comunicación asincrónica . La transferencia asincrónica puede tener lugar en cualquier tiempo en que esté libre la barra colectora. Se reserva un mínimo de 25 microsegundos de cada ciclo de 125 microsegundos para la transferencia de datos asincrónicos. La transferencia isocrónica proporciona un mecanismo de transferencia de datos en tiempo real. Una comunicación isocrónica continua entre uno o más dispositivos, es referida como un canal. El canal tiene que establecerse primero, y luego se garantiza que el dispositivo solicitante tenga la cantidad solicitada de tiempo de barra colectora cada ciclo. La capa de transacción 22 define un protocolo de petición-respuesta completo para realizar transacciones de la barra colectora. Aunque la capa de transacción 22 no agrega servicios para la transferencia de datos isocrónicos, sí proporciona una trayectoria para la administración de los recursos necesarios para los servicios isocrónicos. Esto se hace a través de lecturas y escrituras en el registro de estado de control (CSR) . La capa de transacción 22 también define un mecanismo de reintento para manejar situaciones en donde los recursos estén ocupados y no puedan responder. Los datos asincrónicos se transfieren entre los nodos de IEEE-1394, utilizando una de tres transacciones: "leer datos", para recuperar los datos desde un nodo diferente; "escribir datos", para transferir datos hacia un nodo diferente, y "asegurar datos", para transferir datos hacia un nodo diferente para procesarse, y luego los datos se regresan al nodo original . La administración de la barra colectora en serie 24 describe los protocolos, servicios, y procedimientos operativos, en donde se selecciona un nodo, y luego puede ejercer el control al nivel de la administración sobre la operación de los nodos restantes sobre la barra colectora. Hay dos entidades administrativas definidas para la barra colectora en serie IEEE-1394; el administrador de recursos isocrónico 26, y el administrador de barra colectora 28. Estas dos entidades pueden residir en dos nodos diferentes, o en el mismo nodo. Un administrador de barra colectora separado 28 puede estar ausente de la barra colectora. En esta circunstancia, el administrador de recursos isocrónicos 26 ejerce un subconjunto de las responsabilidades administrativas normalmente asumidas por el administrador de la barra colectora 28. El administrador de la barra colectora 28 proporciona un número de servicios, incluyendo, mantenimiento de la velocidad y del mapa topológico, y optimización de la barra colectora. El administrador de recursos isocrónicos 26 proporciona facilidades para asignar amplitud de banda isocrónica, asignación de números de canal, y la selección del ciclo maestro. Se requiere un control de nodos en todos los nodos; el controlador de nodos 30 implementa los" CSRs requeridos por todos los nodos de la barra colectora en serie, y se comunica con las capas física 18, de enlace 20, y de transacción 22, y con cualquier aplicación presente en el dispositivo. El componente controlador de nodos 30, así como el CSR, y las facilidades de ROM de configuración, se utilizan para configurar y administrar las actividades en un nodo individual . Para que la barra colectora en serie IEEE- 1394 funcione de una manera apropiada, se necesitarán un administrador de recursos isocrónicos (IRM), y un administrador de la barra colectora (BM) . Debido a que la *jH| mayoría de los grupos (es decir, los dispositivos interconectados por medio de una barra colectora digital) incluirán un dispositivo de despliegue visual de alguna clase, se debe requerir que una Caja de Establecimiento Superior con Despliegue Visual Analógico y DTV, deba ser capaz de tener IRM y BM. En algunos casos, tales como en un grupo todo de audio, puede no estar presente un dispositivo ^ de despliegue visual. En este caso, también se debe requerir que un Amplificador de Audio Digital sea capaz de tener IRM y BM. El IRM 26 proporciona los recursos necesarios para que la barra colectora en serie asigne y desasigne de una manera cooperativa los recursos isocrónicos (canales y amplitud de banda) , requeridos para operaciones ordenadamente isocrónicas. El IRM 26 proporciona una localización común para que los otros nodos verifiquen la disponibilidad de canales y amplitud de banda, y para registrar sus nuevas asignaciones. En IRM 26, cuya localización se conoce inmediatamente al completarse el proceso de auto- identificación, también proporciona una localización común en donde los nodos de la barra colectora en serie pueden determinar la identidad del BM 28, si hay uno presente.
El BM 28, si está presente, proporciona servicios administrativos a otros nodos en la barra colectora en serie. Estos incluyen activación de un ciclo maestro, optimización de desempeño, administración de energía, administración de velocidad, y administración de topología. El Protocolo de Control Funcional (FCP) está diseñado para controlar los dispositivos conectados a través de una barra colectora IEEE-1394. El FCP utiliza el paquete de escritura asincrónico de la IEEE-1394, para enviar comandos y respuestas. El paquete asincrónico de la IEEE-1394 se estructura con el FCP empotrado en el campo de datos mostrado más adelante. El Aparato de Comando/Transacción (CTS) especifica el grupo de comandos (por ejemplo, AV/C, CAL) . También permite encapsular un conjunto único del vendedor en el paquete . Marco FCP en la carga útil de una escritura asincrónica Los marcos FCP se clasifican como marcos de comando, y marcos de respuesta. El marco de comandos se escribe en un registro de comando de un periférico, y el marco de respuesta se escribe en un registro de respuesta de un dispositivo de control. El estándar especifica dos direcciones para el comando y la respuesta. La estructura del paquete isocrónico en la IEC-61883 se muestra más adelante. El encabezado del paquete se compone de dos quadlets de un paquete isocrónico IEEE-1394. (Un quadlet es cuatro bytes de 8 bits) . El encabezado del Paquete Isocrónico Común (CIP) se coloca al principio del campo de datos de un paquete isocrónico de IEEE-1394, inmediatamente seguido por los datos de tiempo real.
Longitud Rótulo Canal Código T Si de Datos Encabezado CRC CIP Encabezado Datos en Tiempo Real Datos CRC La longitud de datos es la longitud del campo de datos en bytes, Rótulo indica si existe CIP (01) ó no (00), Canal especifica el número de canal isocrónico, Código T = 1010, y Si es un campo de control específico de la aplicación. El estándar 61883 definió un formato genérico para la transmisión A/V del consumidor. Este formato tiene un encabezado de dos quadlet como se muestra más adelante. En la Tabla, SID es la identificación del nodo fuente, DBS es el tamaño del bloque de datos en quadlets, Número de Fracción (FN) se permite dividir los paquetes de la fuente para la utilización del tiempo de la barra colectora; Cuenta de Cojín de Quadlet (QPC) indica la cuenta del número de quadlets; Encabezado de Paquete de Fuente (SPH) es un indicador para indicar si el paquete tiene un encabezado de paquete de fuente; rsv indica reservado para el futuro; Contador de Bloque de Datos (DBC) es un contador de continuidad; FMT indica la identificación del formato, tal como MPEG2 , DVCR; y el Campo Dependiente del Formato (FDF) es específico de la identificación del formato.
El concepto de clavijas y de registradores de control de clavijas se utiliza para iniciar y detener los flujos de datos isocrónicos en la barra colectora, y para controlar sus atributos. Los registros de control de clavija son registros CSR para propósitos especiales. El conjunto de procedimientos que utilizan los registros de control de clavija para controlar un flujo de datos isocrónicos se denomina Procedimiento de Administración de Conexión (CMP) .
Los datos isocrónicos fluyen desde un dispositivo transmisor hasta cero o más dispositivos receptores, enviando los datos sobre un canal isocrónico en la barra colectora IEEE-1394. Cada flujo de datos isocrónicos se transmite hasta un canal isocrónico a través de una clavija de salida en el dispositivo transmisor, y es recibido desde el canal isocrónico a través de una clavija de entrada en cada uno de los dispositivos receptores. La transmisión de un flujo de datos isocrónicos a través de una clavija de salida se controla mediante un Registro de Control de Clavija de salida (oPCR) , y un Registro de Clavija Maestro de salida (oMPR) localizados en el dispositivo transmisor. oMPR controla todos los atributos del flujo de datos isocrónicos comunes, mientras que oPCR controla todos los demás atributos. Existen registros similares (iPCR, y iMPR) para la recepción de datos isocrónicos. Solamente hay un oMPR (iMPR) para todas las clavijas de salida (clavijas de entrada) . El contenido de oMPR (iMPR) incluye: capacidad de velocidad de datos y número de clavijas, entre otros. oMPR (iMPR) contiene un contador de conexión, número de canal, y velocidad de datos, entre otros . Existen un número de procedimientos administrativos para cada tipo de conexión, que permiten que una aplicación establezca una conexión, sobreponga una conexión, e interrumpa una conexión. Estos procedimientos involucran la asignación de recursos de la IEEE-1394, el establecimiento de valores apropiados en los registros de control de clavija, el reporte de posibles condiciones de falla a la aplicación, y conexiones administrativas después de un restablecimiento de la barra colectora. Sigue uno de estos CMP . Para transportar datos isocrónicos entre dos dispositivos A/V en una barra colectora en serie IEEE-1394, es necesario conectar una clavija de salida en el dispositivo transmisor, con una clavija de entrada en el dispositivo receptor, utilizando un canal isocrónico. La relación entre una clavija de entrada, una clavija de salida, y un canal isocrónico, se denomina una conexión de punto a punto. De una manera similar, existen conexiones de transmisión externa (una clavija de salida y un canal isocrónico) , y conexiones de transmisión interna (una clavija de entrada, y un canal isocrónico) . El flujo de datos isocrónicos se controla mediante un registro de control de clavija de salida (oPCR) , y un registro de clavija maestra de salida (oMRP) , localizados en el lado de transmisión. oMPR controla todos los atributos, (por ejemplo, capacidad de velocidad de datos, base del canal de transmisión, etcétera) que son comunes a todos los flujos isocrónicos transmitidos por el dispositivo A/V correspondiente.
La recepción de un flujo de datos isocrónico a través de una clavija de entrada se controla mediante un registro de control de clavija de entrada (iPCR) , y un registro de clavija maestra de entrada (iMPR) localizados en el dispositivo receptor. iMPR controla todos los atributos (por ejemplo, capacidad de velocidad de datos, etcétera) que son comunes a todos los flujos de datos isocrónicos recibidos por el dispositivo correspondiente. Los principales pasos involucrados en el establecimiento de una conexión son asignación de recursos de IEEE-1394 (por ejemplo, amplitud de banda), y establecimiento de canal, velocidad de datos, identificación de excedente, y contador de conexión, en oPCR e iPCR. Un flujo de datos isocrónico se puede controlar mediante cualquier dispositivo conectado con la barra colectora en serie IEEE-1394, mediante la modificación de los registros de control de clavija correspondientes. Aunque los registros de control de clavija se pueden modificar mediante transacciones asincrónicas en la barra colectora en serie IEEE-1394, el método preferido de administración de conexiones a través del uso de AV/C. Está completamente dentro del alcance de esta invención emplear cal para la administración de conexión. Lenguajes de Control de Aplicación Con el objeto de que un dispositivo electrónico del consumidor interactúe con otros dispositivos interconectados por medio de una barra colectora en serie IEEE-1394, se debe definir un modo de producto común, y un conjunto de comandos común. Tres planteamientos convencionales para la modelación y control del dispositivo son CAL, AV/C, y el planteamiento adoptado para la Barra Colectora en Serie Universal (USB) . CAL y AV/C son lenguajes de control que distinguen entre las. entidades lógicas y físicas. Por ejemplo, un televisor (es decir, una entidad física) puede tener un número de componentes funcionales (es decir, entidades lógicas) , tales como un sintonizador, amplificador de audio, etcétera. Estos lenguajes de control proporcionan dos funciones principales: asignación de recursos y control. La asignación de recursos se refiere a la solicitud, utilización, y liberación de recursos de la Red Genérica. Los mensajes y el control se transportan mediante el FCP, como se define en IEC-61883, y como se discutió anteriormente. Por ejemplo, CAL ha adoptado una metodología base objeto para su sintaxis de comandos. Un objeto contiene y tiene un acceso único a un número establecido de valores internos conocidos como variables de instancia (IV) . Cada objeto guarda una lista interna de métodos. Un método es una acción que toma un objeto como resultado de recibir un mensaje. Cuando se invoca un método, normalmente se actualizan una o más IVs . Un mensaje consiste en un identificador de método, seguido por cero o más parámetros. Cuando un objeto recibe un método, busca a través de su lista de métodos, uno que concuerde con el método identificado en el mensaje. Si se encuentra, se ejecutará el método. Los parámetros suministrados con el mensaje determinan la ejecución exacta del método. El diseño de lenguajes de control se basa en la suposición de que todos los productos electrónicos del consumidor tienen una estructura jerárquica de partes o funciones comunes. Por ejemplo, CAL trata cada producto como una colección de una o más de estas partes comunes, denominadas Contextos. Estos contextos están diseñados para permitir el acceso a la funcionalidad del producto de una manera uniforme. La estructura de datos de contexto es un modelo de software definido en cada dispositivo, que modela la operación de todas las funciones del dispositivo. Un contexto consiste en uno o más objetos agrupados juntos para formar una subunidad funcional específica de un dispositivo. Como un objeto, el contexto es un modelo de una subunidad funcional. Los dispositivos son definidos por uno o más contextos. CAL ha definido un gran conjunto de contextos para modelar diferentes tipos de dispositivos electrónicos del consumidor. Cada contexto, independientemente de en qué producto esté, opera de la misma manera.
Los objetos son definidos por un conjunto de IVs, por ejemplo, las IVs para un contenido de objeto de conmutación binaria requerido, e IVs opcionales. Las IVs requeridas incluyen una variable (posición_actual) que indica si el conmutador está activado o desactivado, y la posición por omisión (posición omisión) del conmutador. Las IVs opcionales incluyen función de posiciones; reporte de condiciones; destino_dirección; valor_anterior, y encabezado reporte. La IVs son como variables en cualquier programa de software, y son soportadas en CAL, como datos Booleanos, Numéricos, de Caracteres, y de Información (arreglo) . Las IVs en un objeto se pueden categorizar en tres grupos generales: IVs de soporte, IVs de reporte, e IVs activas. Las IVs de soporte normalmente son variables de sólo lectura que definen el uso de instalación del objeto, y la operación de las IVs activas. Las IVs activas de un objeto son las variables que se establecen o se lee primariamente para operar el objeto. La interacción entre un dispositivo de control (por ejemplo, DTV) , y un dispositivo periférico (por ejemplo, DVHS) , se puede dividir principalmente en dos categorías principales : i) Un interacción de máquina-máquina, en donde tanto el dispositivo de control como el periférico son máquinas. Es importante observar que, para este tipo de interacción, no hay inicio del usuario en el momento de la interacción real. Sin embargo, es posible que el usuario preprogramará el dispositivo de control para realizar una acción específica en un punto del tiempo específico. ii) Una interacción de usuario-máquina, en donde un ser humano está iniciando acciones en el dispositivo de control . El elemento primario de la entrada de usuario-máquina para los dispositivos de audio/video analógicos (A/V) en la actualidad, es el uso de una unidad a control remoto (RC) , o el tablero frontal. Algo de la interacción también puede hacer uso de un mecanismo de despliegue visual en pantalla (OSD) . En esta clase de interacción, el usuario interactúa directamente con el periférico. En el caso de los controles remotos de la actualidad, el protocolo de mensaje utilizado en específico del dispositivo y/o del fabricante. El dispositivo periférico procesa los comandos recibidos, y realiza las acciones requeridas. Si se utiliza un despliegue visual en pantalla, este incluye mantener el rastro de los tecleos del control remoto procesados, y actualizar el despliegue visual en pantalla exhibido de conformidad con lo mismo, después de cada tecleo. Actualmente, no hay un protocolo de mensajes estándar. Esto conduce al uso de múltiples unidades de control remoto (es decir, diferentes unidades RC para TV, VCR, etcétera) . Los controladores remotos universales disponibles en el mercado tienen una capacidad limitada. Estos dispositivos normalmente cambian su formato de mensaje dependiendo de cuál botón de "foco de dispositivo" se haya oprimido. La presente invención da a los usuarios la capacidad para interactuar con los dispositivos A/V interconectados por medio de una barra colectora en serie IEEE-1394, de una manera en la que están acostumbrados (es decir, utilizando una unidad RC posiblemente en conexión con un OSD) . Es decir, se establece un nivel base de interoperabilidad entre los dispositivos de diferentes fabricantes a un costo mínimo. El definir un mecanismo de mensajes estándar para permitir el transporte de los tecleos del control remoto a otras unidades por medio de la barra colectora en serie IEEE- 1394, para el uso de la unidad de control remoto asociada con el dispositivo de control (por ejemplo, DTV) , como una verdadera unidad de control remoto universal . En la operación, el usuario elegirá, por medio del DTV, un dispositivo de fuente de video (es decir, periférico) , tal como una DVCR. Una vez que se selecciona el dispositivo periférico, el DTV establece una conexión para recibir un programa A/V digital (normalmente sobre un canal isocrónico) , y un OSD (normalmente sobre el enlace asincrónico) . Luego el usuario puede "enfocar" la unidad de control remoto (RC) en la DVCR, oprimiendo el botón de VCR. Ahora, para las siguientes presiones del botón del control remoto, el DTV recibirá los tecleos del control remoto, debido a que el DTV entiende el formato de la modulación del control remoto y el formato de datos . El DTV sabe que el tecleo del control remoto se pretende para la DVCR y no para el DTV. El DTV entonces traducirá el tecleo del control remoto a un código clave universal estandarizado previamente determinado, y lo transportará a través de la barra colectora en serie hasta la DVCR. La DVCR recibirá el código clave universal estandarizado, y luego realizará la acción deseada. Por ejemplo, en la situación de un RCA DTV 14", y un Sony DVCR 12", como se ilustra en la Figura 4, se recibe un comando RC desde un controlador remoto RCA de 13" sobre el enlace IR, y por lo tanto, estará en el formato RCA. El RCA de 14" traducirá esto al formato universal, y lo transferirá a través de la barra colectora en serie de 16". La Sony DVCR 12" recibirá el comando universal, y tal vez lo traducirá al formato Sony, y luego tomará la acción. La traducción de los comandos se puede pensar como una traducción de un idioma a otro. Como un ejemplo de un tecleo de RC, este sería "REPRODUCIR" . Este comando comúnmente está disponible en muchas unidades RC, inclusive cuando el formato del mensaje sea diferente de fabricante a fabricante. Más adelante se definen diferentes métodos para transferir un menú de despliegue visual en pantalla desde un dispositivo periférico hasta un dispositivo de control, por ejemplo, un televisor digital. Para simplificar la transferencia de información del OSD, se puede utilizar un método de "Jalar" para transferir la información del OSD desde el dispositivo periférico hasta el dispositivo de control. Con este método, el volumen de los datos OSD se transfiere desde el periférico hasta un dispositivo con capacidad de despliegue visual, mediante peticiones de lectura asincrónicas emitidas por el dispositivo con capacidad de despliegue visual. Es decir, el dispositivo de control lee la información OSD desde la memoria del periférico, haciendo uso de cuando menos una transacción de lectura en bloque de la IEEE-1394. El dispositivo de control se informa de la localización y del tamaño de los datos OSD por medio de un comando "disparador", que se envía desde el periférico hasta el dispositivo de despliegue visual, cuando el periférico está listo para iniciar la transferencia de datos. Debido a que la información OSD en el dispositivo periférico se actualiza en respuesta a los tecleos del RC, el dispositivo de control (o el DTV) se alerta de la disponibilidad de datos recién actualizados. Esto se puede lograr enviando un mensaje corto (es decir, "disparador") al objeto OSD del dispositivo de control. Se debe observar que este mensaje necesita informar al dispositivo de control de la localización inicial, así como de la longitud de los datos OSD que se van a leer. La longitud es necesaria debido a que la aplicación del dispositivo de control va a hacer uso de transacciones de lectura asincrónicas de la IEEE-1394. Si la longitud es mayor de la que se ajustaría en la máxima longitud posible del paquete para una red de IEEE-1394 particular, el dispositivo de control puede iniciar múltiples transacciones de lectura en bloque, hasta que se haya leído toda la información OSD. En adición a la localización de inicio y a la longitud de los datos OSD actuales que se van a transferir a un dispositivo de despliegue visual, es útil un campo que indica el tipo de datos OSD. Esto es especialmente útil, debido a que, en este caso, también se puede utilizar el mismo mecanismo para disparar el mecanismo OSD de un dispositivo de despliegue visual, pera exhibir cosas tales como mensajes de error, advertencia, y/o estado. La diferenciación del tipo de datos OSD es útil para que el dispositivo de despliegue visual y/o el usuario decidan si realmente quieren que se exhiba (por ejemplo, un usuario que esté viendo una película puede querer ignorar cosas tales como mensajes de estado) . Un método de empuje asincrónico utiliza primariamente transacciones de escritura asincrónica de la barra colectora en serie IEEE-1394, iniciadas por el dispositivo periférico, para escribir los datos OSD en el dispositivo de control. Este planteamiento permite que un dispositivo periférico escriba el contenido de su menú en un dispositivo de control. Debido a que se espera que los menúes sean más grandes que la MTU (Unidad de Máxima Transferencia) de la barra colectora, se puede agregar un encabezado de fragmentación. La capa de transporte de menú debe agregar este encabezado. En el lado receptor, esta capa reensambla el menú, y lo pasa a las capas superiores. Un método de transporte isocrónico proporciona "transmisión" de los datos OSD sobre uno de los canales isocrónicos proporcionados por la barra colectora en serie IEEE-1394. Se necesitaría amplitud de banda, y mantenerse siempre que el dispositivo periférico esté siendo controlado utilizando el OSD. Un método de corriente asincrónica utiliza una corriente asincrónica para llevar la información OSD. Una corriente asincrónica es esencialmente la misma que una corriente isocrónica, con la excepción de que no hay reservación de amplitud de banda, y la corriente se envía en la porción asincrónica del ciclo de la barra colectora. La navegación a través del menú del dispositivo periférico se logra relevando todos los tecleos del RS sobre la barra colectora en serie IEEE-1394 en la forma de comandos universales hasta el dispositivo periférico. Este método de navegación es compatible con cualquier método de representación de OSD. Solamente se necesita un software mínimo tanto en el dispositivo periférico como en el dispositivo de control. El dispositivo de control solamente necesita tener una manera bien definida para enviar la información de tecleos al periférico. De una manera similar, el dispositivo periférico solamente necesita poder actualizar la información OSD de una manera bien definida. Los datos OSD no necesitan contener información alguna para identificar la función y/o los parámetros. El dispositivo periférico simplemente mantiene el rastro de la entrada en la forma de tecleos, y actualiza su OSD como lo vea adecuado. En un grupo A/V interconectado mediante una barra colectora en serie IEEE-1394, es posible relevar los tecleos del RC hasta el periférico por medio de la barra colectora, en lugar de hacerlo a través de un enlace directo (por ejemplo, IR), como se ilustra en la Figura 5. Esto es posible mediante la definición de un formato de mensaje estándar que proporcione información acerca del tecleo del RC al dispositivo periférico. Con este sistema 10", (1) se pueden relevar comandos del RC desde un controlador remoto 13" hasta dispositivos que no estén en la línea de visión directa (es decir, en otro cuarto, etcétera) , y (2) la unidad de RC 13" asociada con el dispositivo de control (por ejemplo, DTV) 14" puede actuar efectivamente como un RC universal (por ejemplo, aun cuando el controlador remoto de marca RCA para el televisor RCA pueda no operar directamente con la VCR Sony, el TV RCA puede relevar los tecleos del RC por medio de mensajes estandarizados sobre la barra colectora en serie IEEE-1394 hasta la VCR) . Los mensajes estándares se pueden definir de tal manera que puedan relevar también conjuntos de caracteres completos en múltiples lenguajes de acuerdo con el estándar de código único (un subconjunto de ISO 10646, como es definido por el Unicode Consortium) , además de poder relevar todas las teclas de función especiales posibles encontradas en una unidad de RC. Esto permite relevar tecleos en un teclado IR, así como en el RC. El relevo de los tecleos de la unidad de control remoto (RC) hasta el dispositivo periférico, se define más completamente más adelante. Sin embargo, este método se puede extender hasta dispositivos tales como teclados de computadoras, tableros de control, etcétera. El control de un dispositivo periférico (por ejemplo, DVCR 12") puede empezar seleccionando ese dispositivo como la fuente en el DTV 14". En este contexto, la selección de la fuente se refiere a que el dispositivo de control adquiere todos los parámetros necesarios, de tal manera que los tecleos de RC subsecuentes se relevan al periférico pretendido. Estos parámetros incluyen la identificación del nodo del dispositivo periférico, EUI etcétera, y se pueden obtener de la tabla de registro. La operación de selección de la fuente puede ser iniciada por el usuario haciendo clic en un icono de una interfase gráfica del usuario (GUI) del dispositivo de control, o en una tecla de RC, tal como VCR1 en una unidad RC. Los títulos de selección de fuente producen mensajes de RC (tales como "subir canal" y "bajar canal"), como se aplican a la DVCR 12" . Una vez que se ha seleccionado un dispositivo periférico, todos los tecleos de RC subsecuentes pretendidos para el dispositivo periférico, se relevan al objeto de Entrada de Teclado Universal de ese periférico. Un formato típico del paquete enviado se muestra más adelante. El paquete se envía al dispositivo periférico haciendo uso de la transacción de escritura en bloque asincrónica de la barra colectora en serie IEEE-1394. Encapsulación de Mensaje Remoto Infrarrojo Universal < 1 byte X 1 byte X 1 byte X 1 byte > -1 Quadlet- La variable de información_tecleo de 24 bits se define como sigue: Formato de Mensaje Remoto Infrarrojo Universal Código_tipo (8 bits) Código_valor (16 bits) La variable de código_tipo define la semántica de los siguientes 16 bits contenidos en el código_valor . Campos de Mensaje Remoto Infrarrojo Universal El dispositivo periférico que recibe la información del tecleo de RC mediante su módulo de software de Entrada de Teclado Universal (UKI) , realiza la acción correspondiente. No todas las acciones necesariamente requieren del uso de un OSD. Un ejemplo es el comando REPRODUCIR, que se releva a la DVCR 12". Es suficiente que se inicie la acción de reproducción, y no se requiere retroalimentación al usuario en la forma de un OSD.
Por otra parte, algunas funciones de control pueden tener lugar a través de un mecanismo de despliegue visual OSD. Para estos dispositivos, después de recibir la información de tecleo a través de su objeto UKI , se actualiza la información OSD si es necesario, y se envía al dispositivo de control un mensaje corto, indicando la disponibilidad de información OSD actualizada (en el caso del Método de Jalón Asincrónico) . Por consiguiente, la aplicación del dispositivo de control puede leer la información OSD desde el periférico, y exhibirla. Es importante observar que un dispositivo periférico en espera (que no esté siendo controlado por nadie en ese momento) que reciba un comando RC a través del enlace indirecto, necesita un mecanismo para evitar tomar una acción dos veces cuando reciba el mismo mensaje por medio de trayectorias múltiples. Esto puede suceder cuando el dispositivo periférico sea fabricado por la misma compañía que el dispositivo de control. En esa situación, es posible que el dispositivo periférico reciba el comando RC como un mensaje RC universal sobre la barra colectora en serie, y también puede recibir el mensaje por medio del enlace infrarrojo directo. Otra posibilidad puede ser si un usuario está controlando un dispositivo periférico sobre la barra colectora en serie desde una localización remota, y otra persona está tratando de controlar el mismo dispositivo periférico por medio de un enlace infrarrojo directo utilizando el controlador remoto asociado. Una manera de hacer la resolución de múltiples trayectorias, es que el periférico active un cronómetro después de recibir los comandos RC a través del enlace indirecto. Este cronómetro se restablece cada vez que se recibe un nuevo comando RC a través del enlace indirecto. Cualesquiera tecleos de RC recibidos sobre el enlace directo son ignorados durante el período en que está activo este cronómetro. El cronómetro, por definición, llega a inactivarse después de un período de inactividad, y el dispositivo regresa a su estado en espera, en donde responde a los tecleos relevados ya sea a través del enlace directo o del indirecto. En adición, una vez que se inicia el control a través del enlace indirecto mediante un nodo particular, el periférico ignorará cualesquiera mensajes adicionales de tecleo del RC que vengan desde otros nodos. Además, puede ser deseable impedir el acceso en general a un dispositivo. En tal caso, se " desarrolla una relación especial denominada de "seguro", por una duración corta o larga de tiempo, entre dos dispositivos. El seguro permite que un dispositivo controle el acceso a algunas o todas las partes del dispositivo asegurado. El dispositivo de control es el "dispositivo de seguro", y el objeto de la relación de seguro es el "dispositivo asegurado". La relación de seguro permite que un dispositivo se enlace con otro dispositivo. Existen diferentes niveles de seguro deseados . En muchos casos, una aplicación requiere solamente de un seguro al nivel del dispositivo. Sin embargo, existen casos en que es deseable asegurar a un nivel de objeto. Una vez que esta situación es una aplicación VCR, en donde podría ser deseable asegurar el mecanismo de transporte, mientras que se permita que otros dispositivos editen o agreguen eventos del cronómetro. De la misma manera, aunque es deseable asegurar el objeto de despliegue visual en un televisor para garantizar un despliegue visual apropiado, no es deseable asegurar la capacidad del dispositivo para responder a otras comunicaciones . El siguiente esquema de seguro permite que un dispositivo, contexto, u objeto sea tratado como un recurso de la red. El recurso puede obtenerse o adquirirse directamente de otros dispositivos que residan en la red. Hay dos planteamientos de seguro discutidos. Se hace directamente una petición de asegurar el dispositivo, y el dispositivo debe determinar si puede acomodar el seguro, o si tiene precedencia un seguro anterior. Si hay un impedimento para hacer un nuevo seguro, un corredor de seguro solicita que se disuelvan los seguros de impedimento anteriores . Una vez que se disuelven los seguros anteriores, el corredor otorga la solicitud de seguro. El dispositivo asegurado debe asegurar que se disuelvan todos los seguros de impedimento antes de permitir el nuevo seguro. El segundo tipo de seguro es el seguro de recursos. En el seguro de recursos, el dispositivo de seguro transmite una solicitud de que todos los dispositivos disuelvan los seguros que impedirían que se presente el nuevo seguro . Una vez que haya pasado tiempo suficiente para asegurar que se resuelvan todos los conflictos anteriores, el dispositivo establece el seguro. Durante la operación a través del enlace directo, un dispositivo periférico simplemente recibe entradas desde su unidad RC o desde el tablero frontal, y realiza las acciones correspondientes. Sin embargo, hay una ligera complicación cuando, como un resultado de estas acciones, se supone que se genera un OSD en un dispositivo de despliegue visual. Debido a que está en este caso, las acciones del periférico se iniciaron a través de su propio enlace directo, y el periférico no tiene conocimiento sobre cuál nodo de la red exhibir su OSD. Por consiguiente, un dispositivo que detecte el inicio del control a través de su enlace directo, puede-: enviar mensajes a cada dispositivo con capacidad de OSD. Es hasta que el dispositivo de despliegue visual decide si actuar sobre este mensaje o no. Por ejemplo, si el enfoque en ese dispositivo de despliegue visual se ha dado a la VCR1, y recibe un mensaje desde la VCR1, es muy natural que el dispositivo de despliegue visual actúe sobre ella. Si el dispositivo de despliegue visual no se enfoca en el dispositivo particular, se puede alertar al usuario sobre la presencia de una petición de despliegue visual OSD mediante una unidad remota, pero puede elegir ignorarla dependiendo del tipo de datos en el mensaje recibido. Debido a que el control real es a través del enlace directo, no tiene absolutamente ningún efecto sobre el periférico si cualquiera o múltiples dispositivos de despliegue visual eligen exhibir el OSD. Por otra parte, este mecanismo también se puede utilizar para informar al usuario de las condiciones de error, advertencias, etcétera, que el usuario puede o no querer tener exhibidas en ese momento. Por consiguiente, el mensaje incluye un campo para que el tipo de datos indique si los datos OSD presentados al dispositivo de despliegue visual son de un mensaje de advertencia, un mensaje de error, datos OSD normales, etcétera. De una manera similar, se puede implementar un mecanismo de cronómetro para el enlace directo, de tal manera que, durante el tiempo en que esté activo, se ignore cualquier información de tecleo del RC recibida a través del enlace indirecto. Todos los dispositivos que son capaces de utilizar comandos de control remoto debe implementar el módulo dei software de Entrada de Teclado Universal. En el dispositivo periférico, el receptor para el tecleo RC se implementa, por ejemplo, mediante un objeto CAL denominado "Entrada de Teclado Universal". Este es un objeto muy simple, de tal manera que el comando CAL enviado es extremadamente simple, corto, y fácil de distribuir. Esta simplicidad es importante, debido a que este nivel de interoperabilidad no debe requerir de un lenguaje de aplicación de control de implementación completa. Se muestra (más adelante) la sintaxis exacta que forma el marco del protocolo de control funcional (FCP), como es definido por IEC 61883. La sintaxis de todo el paquete es consistente con la estructura/sintaxis general de CAL. Sin embargo, a este nivel de interoperabilidad, un dispositivo que releve los tecleos RC puede simplemente juntar el paquete más adelante, en lugar de implementar todo el mecanismo CAL. En seguida se define una muestra de algunos códigos de la Clave Remota Universal; se pueden definir códigos adicionales según sean necesarios .
Proceso de Descubrimiento El proceso de descubrimiento permite que el dispositivo de control descubra otros dispositivos en la red. Este proceso se activa mediante un restablecimiento de barra colectora, y sirve para buscar y descubrir los dispositivos existentes en la red. Se puede ocasionar un restablecimiento de la barra colectora mediante la conexión/desconexión de un dispositivo, restablecimiento iniciado por el software, etcétera. Este módulo del software se apoya en alguna información almacenada en cada ROM de configuración del dispositivo. Esta información es referida como Tabla de Dispositivo de Auto-Descripción (SDDT) , y contiene información tal como Número de Modelo, Localización del Menú, URL, Identificación del Vendedor EUI , etcétera. La SDDT del dispositivo de control o de despliegue visual, contiene un señalador hacia un bloque de información que contiene información acerca de las capacidades de despliegue visual del dispositivo. El bloque de información puede incluir el tipo de despliegue visual (entrelazado o progresivo) , los máximos bytes por línea, los modos de resolución soportados (completo, 1/2, 1/3), los pesos mixtos soportados, máximos bits/pixeles soportados para el modo de paleta (2, 4, 8), y máximo tamaño de bloque soportado. También se pueden utilizar otros métodos de descubrimiento para obtener esta información, tales como la Clavija de Hogar, y Reproducir, definidos para CAL, o los descriptores de subunidad definidos para AV/C. Después de que se terminar la inicialización de la barra colectora, el administrador de descubrimiento del dispositivo de control lee la SDDT localizada en la ROM de cada dispositivo conectado. Esta información se construye en una tabla de registro. Cada dispositivo en la barra colectora en serie IEEE-1394 tendrá una tabla de registro que se utilizará para mantener el rastro de otros dispositivos en la barra colectora y sus capacidades. Para todos los dispositivos en la barra colectora, esta tabla de registro (o registro) se actualizará durante el proceso de descubrimiento. El registro proporciona servicios a la aplicación para mapear las características volátiles, (por ejemplo, identificación de nodo 1394, dirección IP etcétera) , un EUI no volátil de 64 bits ( Identificador Único Extendido) para identificar cualquier nodo en la barra colectora 1394. La tabla de registro es mantenida por el administrador de registro adentro de cada dispositivo, y contiene la información para cada nodo, con el fin de proporcionar el servicio previamente especificado. Esta tabla de registro se actualiza constantemente mediante el administrador de 'descubrimiento en los restablecimientos de la barra colectora. En seguida tenemos un ejemplo de la construcción de esta tabla de registro: EUI de 64 ID_nodo Dirección Fabricante/No . Tipo de bits 1394 IP de modelo Dispositivo Los campos de la Tabla de registro se definen como: • EU de 64 bits es un número de 64 bits que identifica de una manera exclusiva un nodo entre todos los nodos de la Barra Colectora en Serie fabricados en todo el mundo . 1 quadlet = 32 bits- • ID nodo 1394 es un número de 16 bits que identifica de una manera única un nodo de la barra colectora en serie adentro de una subred de la barra colectora en serie IEEE-1394. Los 10 bits más significativos son la identificación de la barra colectora, y los bits menos significativos son la identificación física. La identificación de la barra colectora identifica de una manera exclusiva una barra colectora particular adentro de un grupo de barras colectoras puenteadas. La identificación física se asigna dinámicamente durante el proceso de auto-identificación .
• Dirección IP es una dirección IP privada de 32 bits asignada dinámicamente. • Fabricante/No. de modelo se obtiene de la SDDT del dispositivo, y se utiliza para informar al cliente de las posibilidades para seleccionar una fuente. • Tipo de Dispositivo también se obtiene de la SDDT del dispositivo, y se utiliza para informar al cliente de las posibilidades para seleccionar una fuente. Este campo también puede ser útil para determinar cuál formato de corriente se debe utilizar. Por ejemplo, una máquina de juego no puede utilizar MPEG 2 como un formato de salida. El registro se puede utilizar para determinar la dirección de la barra colectora en serie IEEE-1394 para cualquier nodo en la red del hogar, basándose en la EUI de 64 bits de ese nodo. La correlación con un identificador estable, tal como EUI, es importante, debido a que las direcciones de nodos pueden cambiar durante un restablecimiento de la barra colectora. En cada uno de los dispositivos CE, ocurre algún establecimiento en el momento de la instalación (a través del uso de la Administrador de Establecimiento del Dispositivo) , como se describió anteriormente para mapear otros dispositivos en el grupo, para los canales de salida o entrada de esos dispositivos. Esto no necesariamente significa que se asignen canales isocrónicos de la IEEE-1394 en este momento. Otra posibilidad es que cada dispositivo meramente cargue un menú de selección con dispositivos encontrados en la red, viendo la SDDT. La interacción puede empezar dirigiendo primero el dispositivo de despliegue visual (asumido como digital en este ejemplo) , y seleccionando el dispositivo que desee controlar el usuario (por ejemplo, VCR digital) . Cuando sucede esto, se establece un canal isocrónico entre la DVHS y el dispositivo de despliegue visual. Muchos controles remotos tienen funciones especiales que solamente tienen significado para el dispositivo periférico. Estas funciones especiales pueden no estar integradas en el RC asociado con el dispositivo de control (por ejemplo, DTV) . Por consiguiente, la función de estas teclas se puede poner a disposición en un menú desde el periférico. Además, la presente invención permite el control de dispositivos que no sean de video, mediante la utilización de una interfase gráfica del usuario. Como se mencionó anteriormente, el dispositivo de despliegue visual (es decir, DTV) sería una buena elección para un dispositivo de control, debido a que casi siempre estará presente en el grupo. Un dispositivo que no sea de video, proporcionaría menúes de la misma manera que los dispositivos de video (descritos anteriormente) . Sin embargo, el dispositivo necesitaría almacenar sus propios menúes . En algunos casos, es mejor tener un control coordinado de varios dispositivos a la vez, por ejemplo, esto puede ser útil en el caso de la duplicación. Esta coordinación es difícil de hacer utilizando solamente comandos que mapeen en un control remoto infrarrojo. Adicionalmente, será deseable tener la capacidad para controlar algunos dispositivos CE desde una PC. Esto es en donde podría ser útil un lenguaje de control completo con modelos de dispositivos, tales como CAL AV/C. Aunque la invención se ha descrito con detalle con respecto a numerosas modalidades de la misma, podrá ser visto que, después de una lectura y entendimiento de lo anterior, los expertos en la materia pensarán en numerosas alteraciones a la modalidad descrita, y se pretende incluir estas alteraciones dentro del alcance de las reivindicaciones adjuntas .

Claims (10)

REIVINDICACIONES
1. Un aparato de televisión digital, el cual comprende : (a) un elemento para comunicarse por medio de una barra colectora digital con un dispositivo periférico; (b) un elemento para recibir, desde un elemento de entrada de datos asociado con el aparato de televisión digital, un comando iniciado por el usuario asociado con el control del dispositivo periférico, siendo este comando iniciado por el usuario reconocido por el aparato de televisión digital, y que comprende información de encabezado e información de control para controlar un modo operativo del dispositivo periférico; (c) un elemento para mapear la información de control en un comando universal capaz de ser interpretado por el dispositivo periférico, no respondiendo este dispositivo periférico al comando iniciado por el usuario; y (d) un elemento para transferir la información de control traducida sobre la barra colectora digital al dispositivo periférico.
2. El aparato de televisión digital de la reivindicación 1, el cual comprende además: (a) un elemento para recibir, desde el dispositivo periférico, datos digitales asociados con un despliegue visual en pantalla del dispositivo periférico; y (b) un elemento, acoplado con el elemento receptor, para exhibir los datos del menú.
3. El aparato de televisión digital de la reivindicación 2, en donde el elemento receptor recibe los datos digitales correspondientes a la información de control traducida; y que además comprende: un elemento para actualizar una porción del despliegue visual en pantalla en respuesta a los datos del menú recibidos .
4. El aparato de televisión digital de la reivindicación 2, en donde los datos digitales definen funciones seleccionables por el usuario asociadas con el dispositivo periférico.
5. El aparato de televisión digital de la reivindicación 4, en donde el dispositivo periférico es un dispositivo que no es de video.
6. Un método para controlar un dispositivo electrónico periférico del consumidor interconectado por medio de una barra colectora en serie IEEE-1394 con un aparato de televisión digital, comprendiendo este método: (a) determinar, en respuesta a un restablecimiento de la barra colectora, los dispositivos periféricos interconectados por medio de la barra colectora en serie. (b) comunicarse, por medio de la barra colectora en serie, con el dispositivo periférico; (c) recibir, desde un elemento de entrada de datos asociado con el aparato de televisión digital, un comando iniciado por el usuario asociado con el control del dispositivo periférico, teniendo este comando un formato reconocido por el aparato de televisión digital, y que comprende información de control; (d) mapear la información de control en un formato capaz de ser interpretado por el dispositivo periférico, no respondiendo este dispositivo periférico a dicho comando; y (e) transferir la información de control traducida sobre la barra colectora digital al dispositivo periférico.
7. Un método para controlar un dispositivo electrónico periférico del consumidor interconectado por medio de una barra colectora en serie IEEE-1394 con un televisor digital, el cual comprende: (a) recibir, por medio de la barra colectora en serie, una señal de control a partir del televisor digital, siendo esta señal de control traducida desde un formato solamente reconocido por el televisor digital; y (b) iniciar un cronómetro para generar un período de tiempo en respuesta a la señal de control recibida por medio de la barra colectora en serie, respondiendo solamente el dispositivo periférico a comandos adicionales recibidos por medio de la barra colectora en serie durante este período de tiempo.
8. El método de la reivindicación 7, en donde el dispositivo periférico se selecciona a partir de un menú asociado con el televisor digital, enlistando este menú los dispositivos periféricos disponibles.
9. El método de la reivindicación 8, en donde el dispositivo periférico recibe la señal de control por medio de un enlace directo, y el dispositivo periférico realiza los pasos de: (a) enviar un mensaje al televisor digital, indicando este mensaje la disponibilidad de datos digitales asociados con un despliegue visual en pantalla del dispositivo periférico; (b) recibir un reconocimiento desde el dispositivo de control; y (c) transportar los datos digitales sobre la barra colectora en serie hasta el televisor digital;
10. El método de la reivindicación 9, en donde el paso de iniciar un cronómetro comprende: iniciar un cronómetro para generar un período de tiempo en respuesta a la señal de control recibida por medio del enlace directo, respondiendo solamente el dispositivo periférico a comandos adicionales recibidos por medio del enlace directo durante dicho período de tiempo.
MXPA/A/2000/002742A 1997-09-18 2000-03-17 Aparato de television digital para controlar un dispositivo periferico por medio de una barra colectora digital MXPA00002742A (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US60/059,507 1997-09-18
US60/066,782 1997-11-25
US60/071,341 1998-01-14

Publications (1)

Publication Number Publication Date
MXPA00002742A true MXPA00002742A (es) 2001-06-26

Family

ID=

Similar Documents

Publication Publication Date Title
US6665020B1 (en) Digital television apparatus for controlling a peripheral device via a digital bus
US7659940B2 (en) Apparatus and method for improved device interoperability
US7131135B1 (en) Method for automatically determining the configuration of a multi-input video processing apparatus
EP1112650B1 (en) A method and system for electronic communication
JP2001007861A (ja) ゲートウェイ装置
JP4663119B2 (ja) 多重入力ビデオ処理装置の構成を自動的に判定する方法
EP1345424B1 (en) Method for controlling a peripheral consumer electronic device
MXPA00002742A (es) Aparato de television digital para controlar un dispositivo periferico por medio de una barra colectora digital
JP2000332801A (ja) 仮想avネットワーク構築装置、及び仮想avネットワーク構築方法、並びに仮想avネットワーク構築方法に関するプログラムを記載した記録媒体
JP2000174782A (ja) 機器制御装置及び機器被制御装置
JP2000253463A (ja) ネットワーク制御システム及びこのネットワーク制御システムに用いるターゲット、コントローラ、並びにコンシューマ
MXPA00002741A (es) Dispositivo electronico periferico y sistemas para controlar este dispositivo por medio de una barra colectora digital
JP2003110561A (ja) ホームネットワーク上のストリーム管理装置
WO2000062176A1 (en) System for establishing and maintaining connections and confirming format compatibility between units, subunits and content