Arduino IRremote
Support for ESP 3.0 core
Una biblioteca que permite el envío y recepción de señales infrarrojas.
Disponible como biblioteca Arduino "IRremote".
? Google Translate
Protocolos IR compatibles
Características
Nuevas funciones con la versión 4.x
Nuevas funciones con la versión 3.x
Convirtiendo su programa 2.x a la versión 4.x
Cómo convertir los antiguos códigos de datos IR de 32 bits de los primeros MSB a los nuevos códigos de datos IR de 32 bits de los primeros LSB
Errores al usar las versiones 3.x para tutoriales antiguos
Permanecer en 2.x
¿Por qué *.hpp en lugar de *.cpp?
Usando los nuevos archivos *.hpp
Tutoriales
3 formas de especificar un código IR
Distribución de pines del receptor IR
Recibir códigos IR
Descargo de responsabilidad
Otras bibliotecas, que pueden cubrir estos protocolos
Protocolo=PULSE_DISTANCE
Protocolo=DESCONOCIDO
Cómo lidiar con protocolos no compatibles con IRremote
decodificadoIREstructura de datos
Protocolos ambiguos
Uso de RAM de diferentes protocolos
Manejo de protocolos desconocidos
Envío de códigos IR
Lista de bases de datos públicas de códigos IR
Envío de códigos IR IRDB
Enviar PIN
Pequeño receptor y emisor NEC
El protocolo RÁPIDO
Preguntas frecuentes y sugerencias
La recepción se detiene después de analogWrite() o tone() o después de hacer funcionar un motor
Bandera de desbordamiento de conjuntos receptores
Problemas con Neopixels, FastLed, etc.
No funciona/no se compila con otra biblioteca
Múltiples instancias de receptor y remitente de IR
Aumentar la fuerza de la señal de salida enviada
Frecuencia de reloj mínima de la CPU
Protocolo Bang & Olufsen
Ejemplos para esta biblioteca
Ejemplos en línea de WOKWI
Control por infrarrojos de un coche robot
Problemas y discusiones
Opciones de compilación/macros para esta biblioteca
Cambiar archivos de inclusión (*.h) con Arduino IDE
Modificando las opciones de compilación con Sloeber IDE
Tableros compatibles
Uso de temporizador y pin
Incompatibilidades con otras bibliotecas y comandos de Arduino como tone() y analogWrite()
Generación de señal Hardware-PWM para envío
¿Por qué utilizamos un ciclo de trabajo del 30% para enviar?
Cómo decodificamos señales
Diagramas de codificación NEC
Comparación rápida de 5 bibliotecas receptoras de IR de Arduino
Historia
Enlaces útiles
Colaboradores
Licencia
Derechos de autor
NEC / Onkyo / Apple Denon / Sharp Panasonic / Kaseikyo
JVC LG RC5 RC6 Samsung Sony
Universal Pulse Distance Universal Pulse Width Universal Pulse Distance Width
Hash Pronto
BoseWave Bang & Olufsen Lego FAST Whynter MagiQuest
Los protocolos se pueden activar y desactivar definiendo macros antes de la línea #include <IRremote.hpp> como aquí:
#definir DECODE_NEC//#definir DECODE_DENON#incluir <IRremote.hpp>
Muchos tutoriales y ejemplos.
Mantenido activamente.
Permite recibir y enviar datos de sincronización sin procesar .
Dado que 4.3 IrSender.begin(DISABLE_LED_FEEDBACK) ya no funcionará , utilice IrSender.begin(DISABLE_LED_FEEDBACK, 0) en su lugar.
Se agregó un nuevo decodificador universal de distancia de pulso/ancho de pulso/ancho de distancia de pulso , que cubre muchos protocolos desconocidos anteriormente.
Impresión del código de cómo enviar el comando recibido mediante IrReceiver.printIRSendUsage(&Serial) .
El tipo RawData ahora es de 64 bits para plataformas de 32 bits y, por lo tanto, decodedIRData.decodedRawData puede contener información de trama completa para más protocolos que con 32 bits como antes.
Devolución de llamada después de recibir un comando: llama a su código tan pronto como se recibe un mensaje.
Manejo mejorado de los protocolos PULSE_DISTANCE + PULSE_WIDTH .
Nuevo protocolo FAST.
Impresión automática de la función de envío correspondiente con printIRSendUsage() .
Debes reemplazar #define DECODE_DISTANCE por #define DECODE_DISTANCE_WIDTH (solo si habilitaste explícitamente este decodificador).
El parámetro bool hasStopBit ya no es necesario y se elimina, por ejemplo, para la función sendPulseDistanceWidth() .
Se puede utilizar cualquier pin para recibir y, si SEND_PWM_BY_TIMER no está definido, también para enviar.
El LED de retroalimentación se puede activar para enviar/recibir.
Para la decodificación se proporciona un valor nominal ** de 8/16 bits, así como una dirección de 16 bits y un número de protocolo (en lugar del antiguo valor de 32 bits).
Los valores del protocolo cumplen con los estándares del protocolo .
NEC, Panasonic, Sony, Samsung y JVC decodifican y envían LSB primero.
Admite el protocolo Universal Distance , que cubre muchos protocolos desconocidos anteriormente.
Compatible con la biblioteca tone() . Vea el ejemplo de recepción de demostración.
Envío y recepción simultáneos. Vea el ejemplo de SendAndReceive.
Soporta más plataformas .
Permite la generación de señales no PWM para simular simplemente una señal de receptor baja activa para conexión directa a dispositivos receptores existentes sin usar IR.
Fácil configuración del protocolo, directamente en su código fuente .
Reduce la huella de memoria y disminuye el tiempo de decodificación.
Contiene un decodificador exclusivo NEC muy pequeño, que no requiere ningún recurso de temporizador .
-> Comparación de funciones de 5 bibliotecas IR de Arduino.
A partir de la versión 3.1, la generación de PWM para el envío se realiza mediante software , ahorrando así el temporizador del hardware y habilitando pines de salida arbitrarios para el envío .
Si usa un núcleo Arduino (antiguo) que no usa el indicador -flto para compilar, puede activar la línea #define SUPPRESS_ERROR_MESSAGE_FOR_BEGIN en IRRemote.h, si recibe mensajes de error falsos con respecto a begin() durante la compilación.
Se han agregado los objetos IRreceiver e IRsender y se pueden usar sin definirlos, como el conocido objeto Arduino Serial .
Simplemente elimine la línea IRrecv IrReceiver(IR_RECEIVE_PIN); y/o IRsend IrSender; en su programa y reemplace todas las apariciones de IRrecv. o irrecv. con IrReceiver y reemplace todos IRsend o irsend con IrSender .
Dado que los valores decodificados ahora están en IrReceiver.decodedIRData y ya no en results , elimine la línea decode_results results o similar.
Al igual que para el objeto Serial, llame IrReceiver.begin(IR_RECEIVE_PIN, ENABLE_LED_FEEDBACK) o IrReceiver.begin(IR_RECEIVE_PIN, DISABLE_LED_FEEDBACK) en lugar de IrReceiver.enableIRIn() o irrecv.enableIRIn() en setup().
Para enviar, llame IrSender.begin(); en configuración().
Si IR_SEND_PIN no está definido (antes de la línea #include <IRremote.hpp> ), debe utilizar, por ejemplo, IrSender.begin(3, ENABLE_LED_FEEDBACK, USE_DEFAULT_FEEDBACK_LED_PIN);
La antigua función decode(decode_results *aResults) se reemplaza por simple decode() . Entonces, si tiene una declaración if(irrecv.decode(&results)) reemplácela con if (IrReceiver.decode()) .
El resultado decodificado ahora está en IrReceiver.decodedIRData y ya no en results ; por lo tanto, reemplace cualquier aparición de results.value y results.decode_type (y similares) por IrReceiver.decodedIRData.decodedRawData e IrReceiver.decodedIRData.protocol .
Los indicadores de desbordamiento, repetición y otros se encuentran ahora en IrReceiver.receivedIRData.flags .
Rara vez se usa: results.rawbuf y results.rawlen deben reemplazarse por IrReceiver.decodedIRData.rawDataPtr->rawbuf y IrReceiver.decodedIRData.rawDataPtr->rawlen .
Los 5 protocolos NEC, Panasonic, Sony, Samsung y JVC se convirtieron primero a LSB. Las funciones de envío para enviar datos MSB antiguos pasaron a llamarse sendNECMSB , sendSamsungMSB() , sendSonyMSB() y sendJVCMSB() . Las antiguas funciones MSB sendSAMSUNG() y sendSony() todavía están disponibles. La antigua versión MSB de la función sendPanasonic() fue eliminada, ya que tenía errores que nadie reconocía y por lo tanto se suponía que nunca se usaría.
Para convertir códigos MSB a LSB, consulte a continuación.
#incluye <IRremote.h>#define RECV_PIN 2IRrecv irrecv(RECV_PIN);
resultados decode_results; configuración nula()
{
...
Serie.begin(115200); // Establecer comunicación en serie
irrecv.enableIRIn(); // Inicia el receptor}void loop() { if (irrecv.decode(&results)) {
Serial.println(resultados.valor, HEX);
...
irrecv.resume(); // Recibe el siguiente valor
}
...
} #incluir <IRremote.hpp>#definir IR_RECEIVE_PIN 2void setup()
{
...
Serie.begin(115200); // // Establecer comunicación en serie
IrReceiver.begin(IR_RECEIVE_PIN, ENABLE_LED_FEEDBACK); // Inicia el receptor}void loop() { if (IrReceiver.decode()) {
Serial.println(IrReceiver.decodedIRData.decodedRawData, HEX); // Imprime datos sin procesar "antiguos"
IrReceiver.printIRResultShort(&Serial); // Imprime los datos recibidos completos en una línea
IrReceiver.printIRSendUsage(&Serial); // Imprime el extracto requerido para enviar estos datos
...
IrReceiver.resume(); // Habilitar la recepción del siguiente valor
}
...
} Para los nuevos decodificadores de NEC, Panasonic, Sony, Samsung y JVC , el resultado IrReceiver.decodedIRData.decodedRawData ahora es LSB-first , como sugiere la definición de estos protocolos.
Para convertir uno en otro, debe invertir las posiciones del byte/nibble y luego invertir todas las posiciones de los bits de cada byte/nibble o escribirlo como una cadena binaria e invertirlo/duplicarlo.
Ejemplo: 0xCB 34 01 02
0x20 10 43 BC después del mordisco inverso
0x40 80 2C D3 después de invertir el bit de cada mordisco
0->0 1->8 2->4 3->C 4->2 5->A 6->6 7->E 8->1 9->9 A->5 B->D C->3 D->B E->7 F->F
0xCB340102 es binario 1100 1011 0011 0100 0000 0001 0000 0010 .
0x40802CD3 es binario 0100 0000 1000 0000 0010 1100 1101 0011 .
Si lees la primera secuencia binaria al revés (de derecha a izquierda), obtienes la segunda secuencia. Puedes usar bitreverseOneByte() o bitreverse32Bit() para esto.
El envío de códigos MSB antiguos sin conversión se puede realizar utilizando sendNECMSB() , sendSonyMSB() , sendSamsungMSB() , sendJVCMSB() .
Si sufre errores con el código del tutorial antiguo, incluido IRremote.h en lugar de IRremote.hpp , intente retroceder a la versión 2.4.0.
Lo más probable es que su código se ejecute y no se pierda las nuevas funciones.
Considere utilizar la versión 2.4 original de 2017 o la última versión 2.8 compatible con versiones anteriores para su proyecto.
Puede ser suficiente y maneja perfectamente códigos IR de 32 bits.
Si esto no se ajusta a su caso, tenga la seguridad de que 4.x al menos intenta ser compatible con versiones anteriores, por lo que sus ejemplos antiguos aún deberían funcionar bien.
Sólo están disponibles los siguientes decodificadores:
NEC Denon Panasonic JVC LG
RC5 RC6 Samsung Sony
La llamada de irrecv.decode(&results) utiliza los primeros decodificadores MSB antiguos como en 2.x y establece los códigos de 32 bits en results.value .
Sin decodificación a una dirección de 8/16 bits más significativa (constante) y un comando de 8 bits.
Cada archivo *.cpp se compila por separado mediante una llamada del compilador exclusivamente para este archivo cpp. Estas llamadas son gestionadas por el sistema IDE/make. En el IDE de Arduino las llamadas se ejecutan al hacer clic en Verificar o Cargar .
Y ahora nuestro problema con Arduino es:
¿Cómo configurar las opciones de compilación para todos los archivos *.cpp, especialmente para las bibliotecas utilizadas?
Los IDE como Sloeber o PlatformIO admiten esto al permitir especificar un conjunto de opciones por proyecto. Agregan estas opciones en cada llamada del compilador, por ejemplo, -DTRACE .
Pero Arduino carece de esta característica. Por lo tanto, la solución no es compilar todas las fuentes por separado, sino concatenarlas en un archivo fuente enorme incluyéndolas en su fuente.
Esto se hace, por ejemplo, #include "IRremote.hpp" .
Pero ¿por qué no #include "IRremote.cpp" ?
Pruébelo y verá toneladas de errores, porque cada función del archivo *.cpp ahora se compila dos veces, primero compilando el archivo enorme y segundo compilando el archivo *.cpp por separado, como se describe arriba.
Por lo tanto, ya no es posible usar la extensión cpp , y una solución es usar hpp como extensión, para mostrar que es un archivo *.cpp incluido.
Cualquier otra extensión, por ejemplo, cinclude, sería suficiente, pero hpp parece tener sentido común.
Para admitir las opciones de compilación más fácilmente, debe usar la instrucción #include <IRremote.hpp> en lugar de #include <IRremote.h> en su programa principal (también conocido como archivo *.ino con setup() y loop()).
En todos los demás archivos , debe utilizar lo siguiente para evitar errores del vinculador multiple definitions :
#definir USE_IRREMOTE_HPP_AS_PLAIN_INCLUDE#incluir <IRremote.hpp>
Asegúrese de que todas las macros en su programa principal estén definidas antes de cualquier #include <IRremote.hpp> .
De lo contrario, las siguientes macros definitivamente se anularán con los valores predeterminados:
RAW_BUFFER_LENGTH
IR_SEND_PIN
SEND_PWM_BY_TIMER
Una introducción muy elaborada a los controles remotos IR y la biblioteca IRremote de DroneBot Workshop.
Hay 3 formas diferentes de especificar un código IR particular.
El tiempo de cada marca/pulso y espacio/distancia_entre_pulsos se especifica en una lista o matriz. Esto permite especificar todos los códigos IR , pero requiere mucha memoria y no es legible en absoluto . Una definición formal de dicha matriz de temporización, incluida la especificación de frecuencia y repeticiones, es el formato Pronto .
La memoria se puede guardar utilizando una resolución de tiempo más baja. Para IRremote puede utilizar una resolución de 50 µs que reduce a la mitad el requisito de memoria mediante el uso de valores de bytes en lugar de valores int16. Para fines de recepción, puede utilizar el hash de sincronización proporcionado por el decodificador decodeHash() .
Hay 3 esquemas de codificación principales que codifican un flujo de bits binario/valor hexadecimal:
PULSE_DISTANCE . La distancia entre pulsos determina el valor del bit. ¡Esto requiere siempre un poco de parada! Algunos ejemplos son los protocolos NEC y KASEIKYO. El ancho del pulso es constante para la mayoría de los protocolos.
PULSE_WIDTH . El ancho de un pulso determina el valor del bit, la distancia del pulso es constante. ¡Esto no requiere ningún bit de parada! El único ejemplo conocido es el protocolo SONY.
Codificación de fase/Manchester. El tiempo de la transición (fase) de pulso/pausa con respecto al reloj determina el valor del bit. Algunos ejemplos son los protocolos RC5 y RC6.
La codificación de fase tiene una longitud de bits constante , PULSE_DISTANCE con ancho de pulso constante y PULSE_WIDTH no tienen una longitud de bits constante .
Un ejemplo bien conocido de PULSE_DISTANCE con codificación de ancho de pulso no constante es la codificación serial RS232 . Aquí el ancho de pulso no constante se utiliza para permitir una longitud de bit constante .
La mayoría de las señales IR tienen un encabezado especial para ayudar a configurar la ganancia automática del circuito receptor. Este encabezado no forma parte de la codificación, pero suele ser importante para un protocolo especial y, por lo tanto, debe ser reproducible.
Tenga en cuenta que hay códigos que utilizan una codificación PULSE_DISTANCE donde se coloca más de un 0/1 binario en una combinación de pulso/pausa. Esto requiere más de 2 combinaciones diferentes de duración de pulso o pausa. El protocolo HobToHood utiliza dicha codificación.
El uso de esquemas de codificación reduce la especificación de un código IR a un valor de flujo de bits/hexadecimal, que es LSB de forma predeterminada y tiempos de pulso/pausa del encabezado, 0 y 1. El valor hexadecimal es bastante legible . Estos esquemas no pueden incluir ninguna semántica como dirección, comando o suma de verificación en este flujo de bits.
Existen algunos protocolos comunes que se implementan directamente en IRremote. Especifican la frecuencia, los tiempos del encabezado, 0 y 1, así como otros valores como suma de comprobación, distancia de repetición, codificación repetida, conmutación de bits, etc. También se especifica la semántica del valor hexadecimal, lo que permite el uso de solo 2 parámetros de dirección. y comando para especificar un código IR. Esto ahorra memoria y es muy legible . A menudo, la dirección también es constante, lo que reduce aún más los requisitos de memoria.
Tutorial del sensor de infrarrojos Adafruit
En su programa verifica si hay un marco IR completamente recibido con:
if (IrReceiver.decode()) {}
Esto también decodifica los datos recibidos.
Después de una decodificación exitosa, los datos IR están contenidos en la estructura IRData, disponible como IrReceiver.decodedIRData .
estructura IRData { protocolo decode_type_t; // DESCONOCIDO, NEC, SONY, RC5, PULSE_DISTANCE, ... dirección uint16_t; // Dirección decodificada comando uint16_t; // Comando decodificado uint16_t extra; // Se utiliza para el ID de proveedor desconocido de Kaseikyo. Tics utilizados para decodificar el protocolo de distancia. uint16_t númeroDeBits; // Número de bits recibidos para datos (dirección + comando + paridad): para determinar la longitud del protocolo si es posible una longitud diferente. banderas uint8_t; // IRDATA_FLAGS_IS_REPEAT, IRDATA_FLAGS_WAS_OVERFLOW, etc. Consulte las definiciones de IRDATA_FLAGS_*
IRRawDataType decodificadoRawData; // Datos sin procesar decodificados de hasta 32 bits (64 bits para arquitecturas de CPU de 32 bits), utilizados para funciones sendRaw. uint32_t decodedRawDataArray[RAW_DATA_ARRAY_SIZE]; // Datos sin procesar decodificados de 32 bits, que se utilizarán para la función de envío.
irparams_struct *rawDataPtr; // Puntero de los datos de tiempo sin procesar que se van a decodificar. Principalmente el búfer de datos que se llena al recibir ISR.}; Esta es la lista de banderas contenidas en el campo de banderas.
Compruébelo, por ejemplo, if(IrReceiver.decodedIRData.flags & IRDATA_FLAGS_IS_REPEAT) .
| Nombre de la bandera | Descripción |
|---|---|
| IRDATA_FLAGS_IS_REPEAT | El espacio entre el fotograma anterior es menor que el espacio máximo esperado para una repetición. ¡¡¡No comprobamos si hay cambios en el comando o la dirección, porque casi no es posible presionar 2 botones diferentes en el control remoto en aproximadamente 100 ms!!! |
| IRDATA_FLAGS_IS_AUTO_REPEAT | El fotograma repetido actual es una repetición que siempre se envía después de un fotograma normal y no se puede evitar. Sólo especificado para protocolos DENON y LEGO. |
| IRDATA_FLAGS_PARITY_FAILED | La trama actual (repetición automática) violó la verificación de paridad. |
| IRDATA_FLAGS_TOGGLE_BIT | Se establece si el bit de conmutación RC5 o RC6 está configurado. |
| IRDATA_FLAGS_EXTRA_INFO | Hay información adicional que no está contenida en la dirección ni en los datos (por ejemplo, ID de proveedor desconocido de Kaseikyo o en decodedRawDataArray). |
| IRDATA_FLAGS_WAS_OVERFLOW | Demasiadas marcas y espacios para el RAW_BUFFER_LENGTH especificado. Para evitar señales interminables de desbordamiento, irparams.rawlen se establece en 0 en este caso. |
| IRDATA_FLAGS_IS_MSB_FIRST | Este valor está determinado principalmente por el protocolo (conocido). |
auto myRawdata= IrReceiver.decodedIRData.decodedRawData;
Las definiciones de IrReceiver.decodedIRData.flags se describen aquí.
IrReceiver.printIRResultShort(&Serial);
IrReceiver.printIRResultRawFormatted(&Serial, verdadero);`
Los datos sin procesar dependen del estado interno del temporizador Arduino en relación con la señal recibida y, por lo tanto, pueden ser ligeramente diferentes cada vez. (problema de resolución). ¡Los valores decodificados son los interpretados que toleran diferencias tan pequeñas!
IrReceiver.printIRSendUsage(&Serial);
El protocolo NEC se define como dirección de 8 bits y comando de 8 bits. Pero los campos de datos y de dirección física tienen cada uno un ancho de 16 bits. Los 8 bits adicionales se utilizan para enviar la dirección invertida o el comando para verificar la paridad.
El protocolo NEC extendido utiliza los 8 bits de paridad adicionales de la dirección para una dirección de 16 bits, deshabilitando así la verificación de paridad de la dirección.
El protocolo ONKYO, a su vez, utiliza los 8 bits de paridad adicionales de dirección y comando para una dirección y comando de 16 bits.
El decodificador reduce los valores de 16 bits a 8 bits si la paridad es correcta. Si la paridad no es correcta, no asume ningún error de paridad, pero toma los valores como valores de 16 bits sin paridad, asumiendo NEC extendido o protocolo de protocolo NEC extendido.
¡Pero ahora tenemos un problema cuando queremos recibir, por ejemplo, la dirección de 16 bits 0x00FF o 0x32CD! El decodificador interpreta esto como una dirección NEC de 8 bits 0x00/0x32 con paridad correcta de 0xFF/0xCD y la reduce a 0x00/0x32.
Una forma de manejar esto es forzar a la biblioteca a usar siempre la interpretación del protocolo ONKYO usando #define DECODE_ONKYO . Otra forma es comprobar si IrReceiver.decodedIRData.protocol es NEC y no ONKYO y revertir la reducción de paridad manualmente.
Con una pulsación larga, el protocolo NEC no repite su trama, sino que envía una trama corta repetida especial. Esto permite distinguir fácilmente entre pulsaciones largas y pulsaciones repetidas y ahorra un poco de energía de la batería. Este comportamiento es bastante exclusivo de NEC y sus protocolos derivados como LG y Samsung.
Pero, por supuesto, también hay sistemas de control remoto que utilizan el protocolo NEC pero solo repiten el primer cuadro cuando se realiza una pulsación larga en lugar de enviar el cuadro especial de repetición corta. A esto lo llamamos protocolo NEC2 y se envía con sendNEC2() .
Pero tenga cuidado, el protocolo NEC2 solo puede ser detectado por el decodificador de la biblioteca NEC después del primer cuadro y si realiza una pulsación prolongada.
Con una pulsación larga, el protocolo SamsungLG no repite su fotograma, envía un fotograma repetido corto especial.
RAW_BUFFER_LENGTH determina la longitud del búfer de bytes donde se almacenan los datos de sincronización IR recibidos antes de la decodificación.
100 es suficiente para protocolos estándar de hasta 48 bits , donde 1 bit consta de una marca y un espacio. Siempre requerimos 4 bytes adicionales, 1 byte para el espacio inicial, 2 bytes para el encabezado y 1 byte para el bit de parada.
Los protocolos de 48 bits son PANASONIC, KASEIKYO, SAMSUNG48, RC6.
Los protocolos de 32 bits como NEC, SAMSUNG, WHYNTER, SONY(20), LG(28) requieren una longitud de búfer de 68 .
Los protocolos de 16 bits como BOSEWAVE, DENON, FAST, JVC, LEGO_PF, RC5, SONY(12 o 15) requieren una longitud de búfer de 36 .
MAGIQUEST requiere una longitud de búfer de 112 .
Los acondicionadores de aire suelen enviar un flujo de datos de protocolo más largo, de hasta 750 bits .
Si el intervalo de registros determinado por RECORD_GAP_MICROS se cambia de los 8 ms predeterminados a más de 20 ms, el búfer ya no es un byte sino un búfer uint16_t, que requiere el doble de RAM.
Esta biblioteca fue diseñada para caber dentro de MCU con niveles relativamente bajos de recursos y estaba destinada a funcionar como una biblioteca junto con otras aplicaciones que también requieren algunos recursos de la MCU para funcionar.
Utilice el ejemplo de ReceiverDemo para imprimir toda la información sobre su protocolo IR.
El ejemplo de ReceiverDump le brinda más información pero tiene una mala detección de repetición debido al tiempo requerido para imprimir la información.
Si su protocolo parece no ser compatible con esta biblioteca, puede probar la biblioteca IRMP, que admite especialmente los protocolos de Manchester mucho mejor.
Para acondicionadores de aire , puede probar la biblioteca IRremoteESP8266, que admite un impresionante conjunto de protocolos y muchos acondicionadores de aire y también funciona en ESP32.
Raw-IR-decoder-for-Arduino no es una biblioteca, sino un boceto de ejemplo de arduino, que proporciona muchos métodos de decodificación, especialmente protocolos de aire acondicionado . El envío de estos protocolos se puede realizar mediante la biblioteca Arduino HeatpumpIR.
Si obtienes algo como esto:
PULSE_DISTANCE: HeaderMarkMicros=8900 HeaderSpaceMicros=4450 MarkMicros=550 OneSpaceMicros=1700 ZeroSpaceMicros=600 NumberOfBits=56 0x43D8613C 0x3BC3BC
entonces tienes un código que consta de 56 bits , que probablemente proviene de un control remoto del aire acondicionado.
Puedes enviarlo con sendPulseDistanceWidth() .
uint32_t tRawData[] = { 0xB02002, 0xA010 };
IrSender.sendPulseDistance(38, 3450, 1700, 450, 1250, 450, 400, &tRawData[0], 48, falso, 0, 0); Puede enviarlo llamando sendPulseDistanceWidthData() dos veces, una para los primeros 32 bits y la siguiente para los 24 bits restantes.
El decodificador PULSE_DISTANCE / PULSE_WIDTH simplemente decodifica un flujo de tiempo en un flujo de bits almacenado como valores hexadecimales. Estos decodificadores no pueden incluir ninguna semántica como dirección, comando o suma de verificación en este flujo de bits. Pero el flujo de bits es mucho más legible que un flujo de tiempo. Este flujo de bits se lee primero en LSB de forma predeterminada . Si LSB no es adecuado para futuras investigaciones, puede cambiarlo aquí.
Si la RAM no supera los 2k, el decodificador solo acepta duraciones de marca o espacio de hasta 2500 microsegundos para ahorrar espacio en la RAM; de lo contrario, acepta duraciones de hasta 10 ms.
Si ve algo como Protocol=UNKNOWN Hash=0x13BD886C 35 bits received como salida de, por ejemplo, el ejemplo de ReceiverDemo, tiene un problema con la decodificación de un protocolo o un protocolo no compatible.
Si recibe una cantidad impar de bits , su circuito receptor probablemente tenga problemas. Quizás porque la señal IR es demasiado débil.
Si ve tiempos como + 600,- 600 + 550,- 150 + 200,- 100 + 750,- 550 entonces un espacio de 450 µs se dividió en dos espacios de 150 y 100 µs con una señal de pico/error de 200 µs entre ellos. Quizás debido a un receptor defectuoso o una señal débil junto con otra fuente emisora de luz cercana.
Si ve tiempos como + 500,- 550 + 450,- 550 + 450,- 500 + 500,-1550 , entonces las marcas son generalmente más cortas que los espacios y, por lo tanto, MARK_EXCESS_MICROS (especificado en su archivo ino) debe ser negativo para compensar esto. en la decodificación.
Si ve Protocol=UNKNOWN Hash=0x0 1 bits received puede ser que el espacio después de la marca inicial sea más largo que RECORD_GAP_MICROS . Esto se observó en algunos protocolos de aire acondicionado LG. Inténtelo de nuevo con una línea, por ejemplo, #define RECORD_GAP_MICROS 12000 antes de la línea #include <IRremote.hpp> en su archivo .ino.
Para ver más información que le ayude a encontrar el motivo de su protocolo DESCONOCIDO, debe habilitar la línea //#define DEBUG en IRremoteInt.h.
Si no sabe qué protocolo utiliza su transmisor de infrarrojos, tiene varias opciones.
Simplemente use el valor hash para decidir qué comando se recibió. Vea el ejemplo de SimpleReceiverForHashCodes.
Utilice el ejemplo IRreceiveDemo o IRreceiveDump para descartar la temporización de IR. Luego puede reproducir/enviar este tiempo con el ejemplo SendRawDemo.
El ejemplo IRMP AllProtocol imprime el protocolo y los datos de uno de los 40 protocolos admitidos . Se puede utilizar la misma biblioteca para enviar estos códigos.
Si tiene a mano una placa Arduino más grande (> 100 kBytes de memoria de programa), puede probar el ejemplo IRremoteDecode de la biblioteca Arduino DecodeIR.
Utilice IrScrutinizer. Puede generar automáticamente un boceto de envío para su protocolo exportándolo como "Arduino Raw". Es compatible con IRremote, el antiguo IRLib e Infrarrojo4Arduino.
Si tiene un dispositivo a mano que puede generar los códigos IR con los que desea trabajar (también conocido como control remoto IR), se recomienda recibir los códigos con el ejemplo de ReceiverDemo, que le indicará en la salida serie cómo enviarlos.
Protocol=LG Address=0x2 Command=0x3434 Raw-Data=0x23434E 28 bits MSB first Send with: IrSender.sendLG(0x2, 0x3434, <numberOfRepeats>);
Descubrirá que la dirección es una constante y que los comandos a veces están agrupados de forma sensata.
Si no está seguro del número de repeticiones que debe utilizar para el envío, 3 es un buen punto de partida. Si esto funciona, puedes comprobar los valores más bajos después.
Si ha habilitado DECODE_DISTANCE_WIDTH , el código impreso por printIRSendUsage() difiere entre plataformas de 8 y 32 bits , por lo que es mejor ejecutar el programa receptor en la misma plataforma que el programa emisor.
Todas las funciones de envío admiten el envío de repeticiones si es conveniente. Las tramas repetidas se envían en un período fijo determinado por el protocolo. por ejemplo, 110 ms de principio a fin para NEC.
Tenga en cuenta que no hay ningún retraso después de la última marca enviada . Si maneja el envío de fotogramas repetidos usted mismo, debe insertar retrasos razonables antes de los fotogramas repetidos para permitir la decodificación correcta.
El envío de códigos MSB antiguos sin conversión se puede realizar utilizando sendNECMSB() , sendSonyMSB() , sendSamsungMSB() , sendJVCMSB() .
Los códigos que se encuentran en la base de datos Flipper-IRDB son bastante sencillos de convertir, porque también utilizan el esquema de dirección/comando.
La coincidencia de protocolo es NECext -> NECext (u Onkyo), Samsung32 -> Samsung, SIRC20 -> Sony con 20 bits, etc.
Los códigos que se encuentran en la base de datos irdb especifican un dispositivo , un subdispositivo y una función . La mayoría de las veces, el dispositivo y el subdispositivo se pueden tomar como byte superior e inferior del parámetro de dirección y la función es el parámetro de comando para las nuevas funciones estructuradas con parámetros de dirección, comando y recuento de repeticiones como, por ejemplo, IrSender.sendNEC((device << 8) | subdevice, 0x19, 2) .
Se puede encontrar una asignación exacta en los archivos de definición de IRP para protocolos IR. "D" y "S" indican dispositivo y subdispositivo y "F" indica la función.
Se puede elegir cualquier pin como pin de envío, porque la señal PWM se genera de forma predeterminada con la activación de bits del software, ya que SEND_PWM_BY_TIMER no está activo.
En ESP32, el canal LEDC 0 se utiliza para generar el IR PWM.
Si se especifica IR_SEND_PIN (como macro c), reduce el tamaño del programa y mejora el tiempo de envío para AVR. Si desea utilizar una variable para especificar el pin de envío, por ejemplo, con setSendPin(uint8_t aSendPinNumber) , debe desactivar esta macro IR_SEND_PIN . Luego puede cambiar el pin de envío en cualquier momento antes de enviar una trama IR. Consulte también Opciones de compilación/macros para esta biblioteca.
http://www.harctoolbox.org/IR-resources.html
Base de datos IRDB de Flipper
| decodificación de aleta | Decodificación remota IR |
|---|---|
| Samsung32 | Samsung |
| Comité ejecutivo nacional | Comité ejecutivo nacional |
| NECext | ONKYO |
| <bit de inicio><VendorID:16><VendorID paridad:4><Género1:4><Género2:4><Comando:10><ID:2><Paridad:8><bit de parada> y el ID es el MSB de la dirección. dirección: 8A 02 20 00 comando: 56 03 00 00 -> IRremoto: Dirección 0x6A8, sendPanasonic (para 02 20) y Comando 0x35 | <bit de inicio><ID de proveedor:16><paridad de ID de proveedor:4><Dirección:12><Comando:8><Paridad de paridad de ID de proveedor, dirección y comando:8><bit de parada> |
Para aplicaciones que solo requieren protocolo NEC, variantes NEC o FAST (ver más abajo), se incluye un receptor/remitente especial, que tiene un tamaño de código muy pequeño de 500 bytes y NO requiere ningún temporizador .
En lugar de muestrear la entrada cada 50 µs como lo hace IRremote, el receptor TinyReceiver utiliza una interrupción de cambio de pin para la decodificación sobre la marcha, lo que limita la elección de protocolos.
En cada cambio de nivel, el nivel y el tiempo transcurrido desde el último cambio se utilizan para decodificar incrementalmente el protocolo.
Con este principio operativo, no podemos esperar un tiempo de espera y luego decodificar el protocolo como lo hace IRremote.
En cambio, necesitamos saber cuál es el último bit (cambio de nivel) de un protocolo para realizar la decodificación final y la llamada de la función de devolución de llamada opcional proporcionada por el usuario handleTinyReceivedIRData() .
Es decir, necesitamos saber el número de bits de un protocolo y por tanto el protocolo (familia).
Consulte los ejemplos de TinyReceiver e IRDispatcherDemo.
Tenga cuidado de incluir TinyIRReceiver.hpp o TinyIRSender.hpp en lugar de IRremote.hpp .
//#define USE_ONKYO_PROTOCOL // Como NEC, pero toma la dirección de 16 bits y el comando cada uno como un valor de 16 bits y no como un valor normal de 8 bits y un valor invertido de 8 bits.//#define USE_FAST_PROTOCOL // Usa el protocolo FAST en lugar de NEC / ONKYO#include "TinyIRReceiver.hpp"void setup() { initPCIInterruptForTinyReceiver(); // Habilita la generación de interrupciones al cambiar la señal de entrada IR}void loop() { if (TinyReceiverDecode()) { printTinyReceiverResultMinimal(&Serial);
} // No se requiere currículum() :-)} #incluye "TinyIRSender.hpp" void setup() { sendNEC(3, 0, 11, 2); // Envía la dirección 0 y el comando 11 en el pin 3 con 2 repeticiones.}void loop() {}Aquí se puede encontrar otro pequeño receptor y remitente que admite más protocolos .
El protocolo FAST es un protocolo propietario de JVC modificado sin dirección, con paridad y con una cabecera más corta . Está destinado a tener una respuesta rápida al evento que envió la trama de protocolo a otra placa. FAST tarda 21 ms en enviarse y se envía en un período de 50 ms . Tiene paridad total de 8 bits para la detección de errores.
La sincronización de bits es como JVC
El encabezado es más corto, 3156 µs frente a 12500 µs
Sin dirección y datos de 16 bits, interpretados como comando de 8 bits y comando invertido de 8 bits, lo que lleva a una longitud de protocolo fija de (6 + (16 * 3) + 1) * 526 = 55 * 526 = 28930 microsegundos o 29 ms.
Las repeticiones se envían como tramas completas pero en un período de 50 ms / con una distancia de 21 ms.
#definir IR_SEND_PIN 3#incluir <IRremote.hpp>void setup() { sendFAST(11, 2); // Envía el comando 11 al pin 3 con 2 repeticiones.}void loop() {} #define USE_FAST_PROTOCOL // Utilice el protocolo FAST. Sin dirección y datos de 16 bits, interpretados como comando de 8 bits y comando invertido de 8 bits#include "TinyIRSender.hpp"void setup() { sendFAST(3, 11, 2); // Envía el comando 11 al pin 3 con 2 repeticiones.}void loop() {}El protocolo FAST puede recibirse mediante IRremote y TinyIRReceiver.
El intervalo de muestreo del receptor de 50 µs se genera mediante un temporizador. En muchas placas este debe ser un temporizador de hardware. En algunos tableros donde hay un temporizador de software disponible, se utiliza el temporizador de software.
Tenga en cuenta que el temporizador de hardware utilizado para recibir no debe usarse para analogWrite() .
Especialmente el control del motor a menudo usa la función analogWrite() y, por lo tanto, detendrá la recepción si se usa en los pines indicados aquí.
En las tablas de la UNO y otras AVR, el temporizador del receptor es lo mismo que el temporizador de tono. Por lo tanto, recibir se detendrá después de un comando tone() . Consulte el ejemplo de recibo de cómo lidiar con él, es decir, cómo usar IrReceiver.restartTimer() .
El indicador IRDATA_FLAGS_WAS_OVERFLOW está configurado, si RAW_BUFFER_LENGTH es demasiado pequeño para todas las marcas y espacios del protocolo. Esto puede suceder en marcos de protocolo largos como los del aire acondicionado. También puede suceder, si RECORD_GAP_MICROS es más pequeño que la brecha real entre un marco y el marco de repetición de THR, interpretando así ambos como un marco consecutivo. Lo mejor es volcar el tiempo entonces, para ver qué razón es de esperar.
Irremote no funcionará bien cuando use Neopixels (también conocido como WS2811/WS2812/WS2812B) u otras bibliotecas que bloquean las interrupciones durante más tiempo (> 50 µs).
Ya sea que use la Lib de AdaFruit Neopixel, o las interrupciones rápidas, se desactivan en muchas CPU de extremo inferior como los Arduinos básicos por más de 50 µs. A su vez, esto impide que el controlador de interrupción IR se ejecute cuando sea necesario. Ver también este video.
Una solución es esperar a que el receptor IR esté inactivo antes de enviar los datos de Neopixel con if (IrReceiver.isIdle()) { strip.show();} .
Esto evita que al menos la ruptura de una transmisión IR en funcionamiento y la dependencia de la tasa de actualización del Neopixel- puedan funcionar bastante bien.
Hay algunas otras soluciones para esto en procesadores más potentes, vea esta página de Marc Merlin
Otra biblioteca solo está funcionando/compilando si desactiva la línea IrReceiver.begin(IR_RECEIVE_PIN, ENABLE_LED_FEEDBACK); .
Esto a menudo se debe a los conflictos de recursos del temporizador con la otra biblioteca. Por favor vea a continuación.
Esta biblioteca admite solo un receptor IR y un objeto de remitente IR (Irrecv e Irsend) por CPU.
Sin embargo, dado que el envío es una tarea en serie, puede usar setSendPin() para cambiar el PIN para enviar, emulando así múltiples remitentes.
El receptor utiliza una función activada por temporizador especial, que lee el valor de señal IR digital de un pin cada 50 µs.
Por lo tanto, varios receptores IR solo se pueden usar conectando los pasadores de salida de varios receptores IR juntos. Los módulos del receptor IR usan internamente un transistor NPN como dispositivo de salida con solo una resistencia de 30k a VCC. Esto es básicamente un "colector abierto" y permite que se conecten múltiples pines de salida a un pin de entrada Arduino.
Sin embargo, tenga en cuenta que cualquier señal débil / perturbada de uno de los receptores también interferirá con una buena señal de otro receptor.
La mejor manera de aumentar la potencia IR de forma gratuita es usar 2 o 3 diodos IR en serie. Un diodo requiere 1.2 voltios a 20 mA o 1.5 voltios a 100 mA, por lo que puede suministrar hasta 3 diodos con una salida de 5 voltios.
Para alimentar 2 diodos con 1.2 V y 20 mA y un suministro de 5 V, configure la resistencia a: (5 V - 2.4 V) -> 2.6 V / 20 MA = 130 Ω .
Para 3 diodos requiere 1.4 V / 20 MA = 70 Ω .
La corriente real podría ser menor desde la pérdida en el pin AVR . Por ejemplo, 0.3 V a 20 mA.
Si no requiere más de 20 mA, no es necesario usar un transistor externo (al menos para chips AVR).
En mi arduino nanos, siempre uso una resistencia de la serie de 100 Ω y un LED de IR?
Para recibir, la frecuencia mínima del reloj de la CPU es de 4 MHz , ya que el temporizador de 50 µs ISR (rutina de servicio de interrupción) toma alrededor de 12 µs en un ATMEGA de 16 MHz.
El TinyrreCeiver, que no requiere encuestas, funciona con 1 MHz.
Para el envío, el software predeterminado generado PWM tiene problemas en AVR en ejecución con 8 MHz . La frecuencia PWM es de alrededor de 30 en lugar de 38 kHz y RC6 no es confiable. Puede cambiar a la generación PWM de temporizador por #define SEND_PWM_BY_TIMER .
El decodificador de protocolo Bang & Olufsen no está habilitado de forma predeterminada, es decir, si no se habilita explícitamente el protocolo explícitamente por #define DECODE_<XYZ> . Siempre debe ser habilitado explícitamente por #define DECODE_BEO . Esto se debe a que tiene una frecuencia de transmisión IR de 455 kHz y, por lo tanto, requiere un hardware receptor diferente (TSOP7000).
Y debido a que la generación de una señal PWM de 455 kHz actualmente solo se implementa para SEND_PWM_BY_TIMER , enviar solo funciona si se define SEND_PWM_BY_TIMER o USE_NO_SEND_PWM .
Para obtener más información, consulte IR_BANGOLUFSEN.HPP.
Los ejemplos están disponibles en Archivo> Ejemplos> Ejemplos de bibliotecas personalizadas / Irremote.
Para adaptarse a los ejemplos al flash 8K de Attiny85 y Attiny88, se requiere la biblioteca Arduino AttinySerialut para esta CPU.
Ver también Taller Dronebot SimpleReiver y SimplePleSender.
Los ejemplos SimpleReiver y SimplePleSender son un buen punto de partida. Un ejemplo simple se puede probar en línea con Wokwi.
SimpleReceiverforhashcodes usa solo el decodificador hash. Convierte todos los marcos IR de más de 6 en un código hash de 32 bits, lo que permite la recepción de protocolos desconocidos.
Ver: http://www.romo.com/2010/01/using-arbitrary-remotes-with-arduino.html
Si el tamaño del código o el uso del temporizador son importantes, mire estos ejemplos.
El ejemplo de TinyReceiver utiliza la biblioteca TinyirRreceiver que solo puede recibir NEC, NEC extendidos, Onkyo y protocolos rápidos, pero no requiere ningún temporizador . Utilizan la interrupción del cambio de pin para la decodificación de la mosca, que es la razón de la elección del protocolo restringido.
TinyReceiver se puede probar en línea con Wokwi.
El ejemplo de Tinysender utiliza la biblioteca TinyIrsender que solo puede enviar protocolos NEC, Onkyo y rápidos .
Envía códigos de protocolo NEC en formato estándar con una dirección de 8 bits y comando de 8 bits como en el ejemplo de SimplePleSender. Tiene opciones para enviar usando protocolos NEC, Onkyo y rápidos extendidos. Guarda 780 bytes de memoria del programa y 26 bytes RAM en comparación con SimplePleSender, que hace lo mismo, pero usa la biblioteca Irremote (y, por lo tanto, es mucho más flexible).
Si el protocolo no es NEC y el tamaño del código es importante, mire este ejemplo.
Recibido recibe todos los protocolos y genera un pitido con la función Arduino Tone () en cada paquete recibido.
Se detecta presionar un botón IR (recepción de múltiples repeticiones para un comando).
AllProtocolsonLCD también muestra el corto resultado en una LCD 1602 . La pantalla LCD se puede conectar paralelo o serie (I2C).
Al conectar el pin de depuración a tierra, puede forzar la impresión de los valores sin procesar para cada cuadro. El número PIN del PIN de depuración se imprime durante la configuración, porque depende de la placa y el tipo de conexión LCD.
Este ejemplo también sirve como ejemplo de cómo usar irremote y tono () juntos .
Recibe todos los protocolos y descarta la señal recibida en diferentes sabores, incluido el formato Pronto. Dado que la impresión lleva mucho tiempo, las señales de repetición pueden omitirse o interpretar como desconocidas.
Envía todos los protocolos disponibles al menos una vez.
Demuestra recibir mientras envía .
Registre y reproduce la última señal recibida de IR en el botón Presione. Los marcos IR de protocolos conocidos son enviados por el codificador de protocolo apropiado. Los marcos de protocolo UNKNOWN se almacenan como datos sin procesar y se envían con sendRaw() .
Intente decodificar cada marco IR con el decodificador de ancho de distancia universal , almacenar los datos y enviarlos al botón Presione con sendPulseDistanceWidthFromArray() .
Si la RAM no es más de 2K, el decodificador solo acepta duraciones de marca o espacio de hasta 2500 microsegundos para ahorrar espacio RAM, de lo contrario acepta duraciones de hasta 10 ms.
El almacenamiento de datos para el protocolo de ancho de distancia requiere 17 bytes. El ejemplo de ANCIVEAndsend requiere 16 bytes para datos de protocolo conocidos y 37 bytes para datos sin procesar del protocolo EGNEC.
Sirve como un expansor macro remoto IR. Recibe el protocolo SAMSung32 y al recibir un marco de entrada especificado, envía múltiples marcos SAMSUNG32 con retrasos apropiados en el medio. Esto sirve como una emulación de teclas de Netflix para mi antiguo televisor Samsung H5273.
Marco para llamar a diferentes funciones de su programa para diferentes códigos IR.
Controle un relé (conectado a un pin de salida) con su control remoto.
Ejemplo para una clase definida por el usuario, que usa la clase Irrecv de Irremote.
Ejemplo para enviar códigos IR de aire acondicionado LG controlados por entrada en serie.
Simplemente utilizando la función bool Aircondition_LG::sendCommandAndParameter(char aCommand, int aParameter) Puede controlar el aire acondicionado por cualquier otra fuente de comando.
El archivo aclg.h contiene la documentación de comando del protocolo IR de aire acondicionado LG. Basado en la ingeniería inversa del control remoto LG AKB73315611.
IRECEIVERTIMINGANALISE se puede probar en línea con Wokwi Haga clic en el receptor mientras la simulación se ejecuta para especificar códigos IR individuales.
Ejemplo para recibir y enviar el protocolo AEG / Elektrolux Hob2hood.
Este ejemplo analiza la señal entregada por su módulo receptor IR. Los valores se pueden usar para determinar la estabilidad de la señal recibida, así como una pista para determinar el protocolo.
También calcula el valor MARK_EXCESS_MICROS , que es la extensión de la duración de la marca (pulso) introducida por el módulo del receptor IR.
Se puede probar en línea con Wokwi. Haga clic en el receptor mientras se ejecuta la simulación para especificar códigos NEC IR individuales.
Recibido + SendDemo en un programa. Demuestra recibir mientras envía . Aquí ve el retraso de la salida del receptor (azul) de la entrada del diodo IR (amarillo). 
Receptor simple
Simple Toggle by IR Key 5
Tinirreador
Análisis de receptiTiming
Receptor con salida LCD y instrucción Switch
Este ejemplo de la biblioteca Arduino PwmmotorrControl controla las funciones básicas de un automóvil robot utilizando la biblioteca Irremote.
Controla 2 canales de motor PWM, 2 motores en cada canal.
Aquí puede encontrar el instructable para el ensamblaje y el código del automóvil.
IR_ROBOTCAR con receptor TL1838 IR conectado a la placa de expansión. 
¡No abra un problema sin probar primero algunos de los ejemplos!
Si tiene un problema, publique la MCVE (ejemplo verificable completo mínimo) que muestra este problema. Mi experiencia es que la mayoría de las veces encontrarás el problema mientras creas esta mcVe?
Usar bloques de código; ¡Nos ayuda a ayudarlo cuando podemos leer su código!
Para personalizar la biblioteca a diferentes requisitos, hay algunas opciones de compilación / macros disponibles.
Estas macros deben definirse en su programa antes de la línea #include <IRremote.hpp> para entrar en vigencia.
Modifíquelos habilitándolos / deshabilitándolos, o cambie los valores si corresponde.
| Nombre | Valor predeterminado | Descripción |
|---|---|---|
RAW_BUFFER_LENGTH | 200 | Tamaño del búfer de la entrada RAW UINT16_T Buffer. ¡Debe ser uniforme! Si es demasiado pequeño, se establecerá la bandera de desbordamiento. 100 es suficiente para protocolos regulares de hasta 48 bits, pero para la mayoría de los protocolos de aire acondicionado se requiere un valor de hasta 750. Use el ejemplo recibido para encontrar el valor más pequeño para sus requisitos. Un valor de 200 requiere 200 bytes RAM. |
EXCLUDE_UNIVERSAL_PROTOCOLS | desactivado | Excluye el decodificador universal para los protocolos de ancho de distancia de pulso y Decodehash (decodificador especial para todos los protocolos) desde decode() . Guarda hasta 1000 bytes de memoria del programa. |
DECODE_<Protocol name> | todo | Selección de protocolo individual para ser decodificados. Puede especificar múltiples protocolos. ver aquí |
DECODE_STRICT_CHECKS | desactivado | Verifique las características adicionales requeridas de la sincronización del protocolo como la longitud de la marca para un protocolo de marca constante, donde la longitud del espacio determina el valor de bit. Requiere hasta 194 bytes adicionales de memoria del programa. |
IR_REMOTE_DISABLE_RECEIVE_COMPLETE_CALLBACK | desactivado | Guarda hasta 60 bytes de memoria del programa y 2 bytes RAM. |
MARK_EXCESS_MICROS | 20 | Mark_EXCESS_MICROS se resta de todas las marcas y se agrega a todos los espacios antes de decodificar, para compensar la señal de formación de la señal de diferentes módulos del receptor IR. |
RECORD_GAP_MICROS | 5000 | Brecha mínima entre las transmisiones IR, para detectar el final de un protocolo. Debe ser mayor que cualquier espacio de un protocolo, por ejemplo, el espacio de encabezado NEC de 4500 µs. Debe ser más pequeño que cualquier brecha entre un comando y una repetición; Por ejemplo, la brecha de retransmisión para Sony es de alrededor de 24 ms. Tenga en cuenta que este es el retraso entre el final del comando recibido y el comienzo de la decodificación. |
DISTANCE_WIDTH_DECODER_DURATION_ARRAY_SIZE | 50 si Ram <= 2k, de lo contrario 200 | Un valor de 200 permite decodificar marcas o duraciones de espacio hasta 10 ms. |
IR_INPUT_IS_ACTIVE_HIGH | desactivado | Habilitarlo si usa un receptor de RF, que tiene una señal de salida alta activa. |
IR_SEND_PIN | desactivado | Si se especifica, reduce el tamaño del programa y mejora el tiempo de envío para AVR. Si desea usar una variable para especificar el PIN de envío, por ejemplo, con setSendPin(uint8_t aSendPinNumber) , no debe usar / deshabilitar esta macro en su fuente. |
SEND_PWM_BY_TIMER | desactivado | Desactiva la generación PWM de operador en software y use hardware PWM (por temporizador). Tiene la ventaja de una generación de PWM más exacta, especialmente el deber cyc
Expandir
Información adicional
Aplicaciones relacionadas
Recomendado para ti
Información relacionada
Todo
|
