Sending and receiving IR commands don't match

0

I have two Arduino boards. One is connected to an IR transmitter and the other is connected to an IR receiver.

I have the IRremoteESP8266: IRrecvDumpV3 application running on the receiver board which seems to work ok, as when i press one of my IR remote controls, it prints out consistent data based on each button press.

However, I am trying to a create an application on the transmitter end which for a start has hard-coded hex string as commands there to test in a loop, which get converted to uint64 values and sent to the sendElitescreens() function and transmitter as below. The uint64 values are correct before sending.

#include <ESP8266WiFi.h>
#include <ESP8266WebServer.h>
#include <ESP8266SSDP.h>
#include <uri/UriBraces.h>
#include <IRremoteESP8266.h>
#include <IRsend.h>
#include <OneWire.h>
#include <DallasTemperature.h>

const uint16_t kIrLed = 5;  // ESP8266 GPIO pin to use. Recommended: 4 (D2).

int LED = 4; // Assign LED pin i.e: D2 on NodeMCU

// GPIO where the DS18B20 is connected to
const int oneWireBus = 2;     

// Setup a oneWire instance to communicate with any OneWire devices
OneWire oneWire(oneWireBus);

// Pass our oneWire reference to Dallas Temperature sensor 
DallasTemperature sensors(&oneWire);

IRsend irsend(kIrLed);

void setup() {
  sensors.begin();
  pinMode(LED, OUTPUT);
  irsend.begin();
  Serial.begin(115200);
}

uint64_t stringToUint_64(String value) {
  int stringLenght = value.length();

  uint64_t uint64Value = 0x0;
  for(int i = 0; i<=stringLenght-1; i++) {
    char charValue = value.charAt(i);

    uint64Value = 0x10 * uint64Value;
    uint64Value += stringToHexInt(charValue);
  }

  Serial.print("string to int is");
  Serial.println(uint64Value);
  return uint64Value;
}

int stringToHexInt(char value) {
  switch(value) {
    case '0':
      return 0;
    break;
    case '1':
      return 0x1;
    break;
    case '2':
      return 0x2;
    break;
    case '3':
      return 0x3;
    break;
    case '4':
      return 0x4;
    break;
    case '5':
      return 0x5;
    break;
    case '6':
      return 0x6;
    break;
    case '7':
      return 0x7;
    break;
    case '8':
      return 0x8;
    break;
    case '9':
      return 0x9;
    break;
    case 'A':
    case 'a':
      return 0xA;
    break;
    case 'B':
    case 'b':
      return 0xB;
    break;
    case 'C':
    case 'c':
      return 0xC;
    break;
    case 'D':
    case 'd':
      return 0xD;
    break;
    case 'E':
    case 'e':
      return 0xE;
    break;
    case 'F':
    case 'f':
      return 0xF;
    break;
  }
  return 0;
}

void loop() {

  String up_command = "FDA2256";
  String down_command = "FBA1136";
  String stop_command = "FEA3387";
  
  Serial.println("In loop - sending commands ..");

  // Send each screen command and wait for 4 seconds
  digitalWrite(LED, HIGH); // turn the LED on
  //Serial.println("Up");
  //Serial.println(up_command);
  irsend.sendElitescreens(stringToUint_64(up_command));
  digitalWrite(LED, LOW); // turn the LED off
  delay(4000);

  digitalWrite(LED, HIGH); // turn the LED on
  //Serial.println("Down");
  //Serial.println(down_command);
  irsend.sendElitescreens(stringToUint_64(down_command));
  digitalWrite(LED, LOW); // turn the LED off
  delay(4000);

  digitalWrite(LED, HIGH); // turn the LED on
  //Serial.println("Stop");
  //Serial.println(stop_command);
  irsend.sendElitescreens(stringToUint_64(stop_command));
  digitalWrite(LED, LOW); // turn the LED off
  delay(4000);
}

The dump received on the IRrecvDumpV3 doesn't make any sense unfortunately. The hex values don't match and are changing all the time as below.

Am I doing something fundamentally wrong here? Thanks in advance for any support.

Timestamp : 000065.309
Library   : v2.8.6

Protocol  : UNKNOWN
Code      : 0xC7BEF4CD (24 Bits)
uint16_t rawData[47] = {294, 13074,  278, 2678,  106, 3600,  128, 168,  182, 2812,  496, 15370,  126, 136,  478, 740,  474, 6344,  256, 9350,  470, 17040,  196, 4726,  128, 4016,  300, 2520,  232, 430,  260, 5484,  202, 9052,  528, 2536,  306, 536,  162, 4418,  232, 6456,  184, 2698,  164, 4792,  260};  // UNKNOWN C7BEF4CD


Timestamp : 000069.510
Library   : v2.8.6

Protocol  : UNKNOWN
Code      : 0xAF8A3196 (117 Bits)
uint16_t rawData[233] = {136, 490,  960, 612,  276, 124,  2650, 838,  2304, 192,  5306, 120,  440, 522,  4792, 560,  1092, 150,  440, 336,  7364, 124,  1320, 934,  1046, 356,  4644, 526,  476, 146,  2174, 324,  802, 442,  428, 208,  124, 198,  898, 388,  2552, 924,  580, 464,  2314, 446,  534, 148,  648, 370,  1426, 340,  736, 188,  2548, 550,  180, 734,  128, 328,  140, 248,  776, 1354,  180, 154,  1372, 290,  650, 128,  898, 408,  1254, 620,  618, 554,  570, 716,  182, 242,  2116, 1298,  1048, 246,  1588, 168,  266, 310,  548, 266,  1794, 180,  1228, 702,  1108, 260,  576, 116,  122, 298,  362, 408,  448, 490,  200, 690,  1066, 522,  1524, 208,  1244, 586,  280, 810,  346, 120,  256, 980,  474, 722,  570, 650,  480, 1248,  518, 158,  294, 154,  264, 1778,  980, 810,  248, 636,  292, 164,  366, 428,  126, 1148,  102, 210,  792, 968,  764, 432,  332, 566,  848, 596,  212, 904,  868, 1064,  216, 568,  106, 332,  502, 712,  194, 152,  140, 548,  208, 220,  842, 2728,  458, 802,  706, 1348,  1082, 188,  350, 566,  130, 722,  404, 158,  346, 766,  430, 2454,  196, 368,  700, 412,  328, 1388,  512, 674,  600, 794,  122, 1634,  114, 1242,  176, 268,  410, 984,  132, 294,  138, 274,  390, 252,  428, 1194,  224, 346,  324, 442,  142, 1752,  402, 838,  294, 338,  134, 870,  354, 1634,  338, 1080,  236, 234,  266, 182,  564, 610,  254};  // UNKNOWN AF8A3196


Timestamp : 000086.112
Library   : v2.8.6

Protocol  : UNKNOWN
Code      : 0xE3EA772A (37 Bits)
uint16_t rawData[73] = {2456, 156,  1922, 174,  690, 618,  1620, 258,  368, 416,  236, 1298,  312, 1320,  446, 45914,  148, 2240,  204, 1094,  210, 942,  132, 2448,  202, 654,  262, 658,  160, 518,  616, 622,  832, 142,  260, 1772,  606, 128,  234, 374,  896, 388,  1078, 984,  842, 1448,  2342, 2590,  148, 196,  1522, 1138,  1406, 124,  208, 414,  1288, 278,  198, 1188,  182, 302,  780, 680,  1048, 260,  288, 380,  274, 1398,  116, 458,  172};  

You need to show your complete sketch.

@xfpd Sorry. I updated the question now with the complete sketch.

Why not send raw or decoded IR the receiver understands?

@xfpd Because my application will eventually receive a string in that format to be converted.

How is this determined? It is not in your sketch.

@xfpd I don't know. I haven't looked into the IRrecvDumpV3 code in detail. The receiving of the hex string via HTTP is not in my sketch yet as i'm not at that point yet.

Can you post what your receive sketch produces from a single button press of the original remote control?

I don't think you should be manually turning on the IRLED before sending the code. The IRRemote library should take care of that, at the right time.

It looks to me like the codes are 32 -bit, not 64-bit.

Hi @ShermanP . Below is what I get on the receiver when I press the same button 4 times on a JVC television remote control. The data toggles between 0x40 and 0x840 which I wasn't expecting, but perhaps part of the protocol.

Regarding the turning on and off of the LED from my Arduino TX application, if I don't do that, nothing gets transmitted. Thanks in advance for your help.

Timestamp : 000484.329
Library   : v2.8.6

Protocol  : RC5
Code      : 0x40 (12 Bits)
uint16_t rawData[23] = {910, 898,  1770, 876,  908, 876,  884, 900,  884, 900,  904, 1780,  1768, 878,  882, 902,  882, 902,  882, 900,  882, 900,  882};  // RC5 40
uint32_t address = 0x1;
uint32_t command = 0x0;
uint64_t data = 0x40;


Timestamp : 000484.947
Library   : v2.8.6

Protocol  : RC5
Code      : 0x840 (12 Bits)
uint16_t rawData[23] = {906, 902,  882, 900,  1742, 904,  880, 902,  880, 904,  880, 1806,  1742, 904,  880, 904,  878, 906,  878, 904,  880, 904,  878};  // RC5 840
uint32_t address = 0x1;
uint32_t command = 0x0;
uint64_t data = 0x840;


Timestamp : 000485.061
Library   : v2.8.6

Protocol  : RC5
Code      : 0x840 (12 Bits)
uint16_t rawData[23] = {908, 902,  880, 904,  1742, 904,  880, 902,  880, 904,  878, 1806,  1740, 904,  880, 902,  880, 904,  878, 904,  880, 902,  880};  // RC5 840
uint32_t address = 0x1;
uint32_t command = 0x0;
uint64_t data = 0x840;


Timestamp : 000485.537
Library   : v2.8.6

Protocol  : RC5
Code      : 0x40 (12 Bits)
uint16_t rawData[23] = {908, 902,  1742, 904,  880, 902,  880, 902,  880, 902,  880, 1806,  1740, 904,  880, 904,  878, 904,  858, 924,  880, 904,  878};  // RC5 40
uint32_t address = 0x1;
uint32_t command = 0x0;
uint64_t data = 0x40;

I'm confused. What is the "Elitecreens" format in your original sketch? Is that different from the JVC?

@ShermanP I'm also a bit confused. The JVC remote was just to test. It has nothing to do with my end goal. I just wanted to see what data would be received when I press it.

EliteScreens is what i will be working with though, eventually. I don't have the remote. I got provided the raw hex commands for the up, down and stop commands which I am trying to send. irsend.sendElitescreens is a function part of the library : GitHub - crankyoldgit/IRremoteESP8266: Infrared remote library for ESP8266/ESP32: send and receive infrared signals with multiple protocols. Based on: https://github.com/shirriff/Arduino-IRremote/

I don't know anything about Elitescreens, but I think the first step is to see if you can get things working with the JVC. But I can't tell what protocol that remote is using. It doesn't look like RC5, but I can't tell what it is.

Do you by chance have an Arduino Uno or Nano at hand? If so, you might try running this sketch to receive the JVC IR, just to see if it's any different from what you got with the ESP8266.

https://github.com/gbhug5a/SimpleIRRaw/blob/main/IRCaptureRaw.ino

Why answer questions when you can just ask someone else?

Yes, in this case I can say some protocols add a 0x800 to the code to indicate a "key repeat" function while others use another syntax for the repeating keys. So given a specific protocol, if you need to read all the single "repeats" just use a bitwise AND to clean the "repeat" bit (e.g. "code & 0xFF"), otherwise if you want to ignore repeats just drop any code with that bit (e.g. "if ( (code & 0x100) != 0 )").

Said that, maybe I'm missing something: why are you trying to send strings representing a command instead of choosing any protocol (e.g. NEC or any physical remote you already have to test with) and "map" your commands to specific keys (e.g. up, down and stop keys from the standard TV remote keyboards)?

@xfpd What exactly do you mean by this?

@docdoc Thanks for this.

I don't have a remote yet. I've just been supplied the raw commands to send over irsend.sendElitescreens.

I've actually solved the problem since. It was a hardware issue. the wrong GPIO pin had been used:(

You're welcome. But what about my question?

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.