how to do Hex counting

Using Arduino Programming Questions
#1

I wonder if someone can help me I’m attempting to find all valid codes for my device.
I have a few codes but was hoping someone might be able to say

int = hex 0x659A9966 +1

Here is my code

#include <IRremote.h>

char receivedChar;
boolean newData = false;

IRsend irsend;


void setup() {
  Serial.begin(115200);
  Serial.println("<Arduino is ready>");
}

void loop() {
  recvOneChar();
  showNewData();
}

void recvOneChar() {
  if (Serial.available() > 0) {
    receivedChar = Serial.read();
    newData = true;
  }
}

void showNewData() {
  if (newData == true) {

    Serial.print("Sending IR");
    irsend.sendNEC(0x659A9966, 32);
//    irsend.sendNEC(0x659A9966, 32);



    Serial.println(receivedChar);
    newData = false;
  }
}

I am trying to find IR codes for and old Pioneer amp. so far ive got
all val are HEX so 0x…
source switch
659A9966

Vol up
659A50AF

vol dwn
659AD02F

mute
659A7887

power
659A38C7

#2

0x659A9966 is 1,704,630,630

Do you see a problem here?

#3

SteveMann:
0x659A9966 is 1,704,630,630

Do you see a problem here?

I don't. It's probably me.

sparkie37:
I wonder if someone can help me I'm attempting to find all valid codes for my device.
I have a few codes but was hoping someone might be able to say

int = hex 0x659A9966 +1

0x659A9966 is just a number; if you want to go through all of them, you can just add 1. The basics:

unsigned long code = 0x659A9966;
...
...

void setup()
{
  ...
  ...
}

void loop()
{
  code += 1;
}
#4

You don’t need to “try all of them”, and it will be a very long search if you do.

You need to identify the pattern…
659A9966
99+66=FF

659A50AF
50+AF=FF

659AD02F
D0+2F=FF

659A7887
78+87=FF

659A38C7
38+C7=FF

So the first 659A is the “address” of the device. Although some devices do sometimes respond to multiple addresses. If for example the require more than 256 keys, or are a hybrid device. That’s fairly unusual however.

The second two hex bytes are the key code (00-FF) and the inverse of the key code for error detection purposes. Unless the 3rd and 4th bytes are the exact inverse of each other the device will ignore the code.

So it is pointless adding just one. You will be testing 255 invalid codes for every 1 valid one.

Start at…
659A00FF
659A01FE
659A02FD
…
…
…
659AFE01
659AFF00

Only 256 codes that need testing by adding 256 and subtracting 1 each time (I.e. add 255) and you probably do not need to test anything outside range 659A00FF through 659AFF00.

Also note that a code may need to be sent and received more than once, or with a certain delay from the previous one to be considered valid. Do not know if the library does that for you, but it’s worth considering if you are just going to belt out each code with no gap in between in loop().

Edit: also note that the address corresponds to the same pattern 65+9A=FF
But that is not always the case. This allowed for 256 different devices, but when NEC “ran out” of unique devices they started issuing/using a 16 bit address, instead of 8 bit address and sending non-inverted and inverted error checking versions. The theory is that an error in the address would be very unlikely to mutate into an address for a different device, given people have a very limited number of devices almost certainly with very different addresses (not just one or two bits different). That’s not the case with key codes though, where it would be very easy to mutate the code for key ‘0’ into ‘1’ as usually they use consecutive codes.

#5

I don’t. It’s probably me.

I do; it’s “int”

#6 
0x659A9966

Variable types

#7

TheMemberFormerlyKnownAsAWOL:
I do; it's "int"

..., the size of which is platform dependent.

#8

The NEC IR protocol corresponds with that identified by @pcbbc, where a transmitted digit is followed by its complement:

#9

TheMemberFormerlyKnownAsAWOL:
I do; it's "int"

It wasn't used in the code that OP presented; so no problem :smiley:

#10

6v6gt:
..., the size of which is platform dependent.

Which is one of the reasons I much prefer to use, for example, int16_t as it makes it clear exactly what is being used.

#11

sterretje:
It wasn’t used in the code that OP presented; so no problem :smiley:

…but it was presented in their “hopes”, however syntactically incorrect

#12

pcbbc:
You don’t need to “try all of them”, and it will be a very long search if you do.

You need to identify the pattern...
659A9966
99+66=FF

659A50AF
50+AF=FF

659AD02F
D0+2F=FF

659A7887
78+87=FF

659A38C7
38+C7=FF

So the first 659A is the “address” of the device. Although some devices do sometimes respond to multiple addresses. If for example the require more than 256 keys, or are a hybrid device. That’s fairly unusual however.

The second two hex bytes are the key code (00-FF) and the inverse of the key code for error detection purposes. Unless the 3rd and 4th bytes are the exact inverse of each other the device will ignore the code.

So it is pointless adding just one. You will be testing 255 invalid codes for every 1 valid one.

Start at...
659A00FF
659A01FE
659A02FD
..
..
..
659AFE01
659AFF00

Only 256 codes that need testing by adding 256 and subtracting 1 each time (I.e. add 255) and you probably do not need to test anything outside range 659A00FF through 659AFF00.

Also note that a code may need to be sent and received more than once, or with a certain delay from the previous one to be considered valid. Do not know if the library does that for you, but it’s worth considering if you are just going to belt out each code with no gap in between in loop().

Edit: also note that the address corresponds to the same pattern 65+9A=FF
But that is not always the case. This allowed for 256 different devices, but when NEC “ran out” of unique devices they started issuing/using a 16 bit address, instead of 8 bit address and sending non-inverted and inverted error checking versions. The theory is that an error in the address would be very unlikely to mutate into an address for a different device, given people have a very limited number of devices almost certainly with very different addresses (not just one or two bits different). That’s not the case with key codes though, where it would be very easy to mutate the code for key ‘0’ into ‘1’ as usually they use consecutive codes.

ok thanks how do i put that into code that starts from keyboard press in serial terminal and steps through each code???

#13

Repeatedly add 255 to the first possibly valid code, 0x659A00FF, will give you the next valid code.
Use at least uint32_t (unsigned long) data type for your variable, as stated earlier.
You have most of the code for processing the keyboard input, although you are not handling line endings correctly.

#14

Here is a simple example to step through the valid codes which you can adapt

uint32_t initCode  = 0x659A0000 ;
uint32_t code = 0 ;
uint8_t i = 0 ;

void setup() {
  Serial.begin( 115200 ) ;
}

void loop() {
    code = initCode + (i * 0x100) + (0xFF - i) ;
    Serial.println( code  , HEX ) ;
    i++ ;
    delay(2000) ;
}
#15

So with the help of everyone I’ve managed to find some more codes. Its interesting there are different codes that do the same thing.

source switch 
659A9966 
Vol up
659A50AF
vol dwn
659AD02F
mute
659A7887
power
659A38C7
-------------------new-uno
EQ
659A33CC
power
659A38C7

cd?
659A39C6
dat?
659A59A6
mute
659A7887
power
659AD827



power
659A38C7
mute
659A7887
vol+
659A50AF
vol -
659AD02F
source
659A9966

Did it using this code but couldn’t get it to stop or continue on its own through the range

#include <IRremote.h>

char receivedChar;
boolean newData = false;

unsigned long code = 0x659A00FF;

IRsend irsend;

void setup() {
  Serial.begin(115200);
  
  Serial.println("<Arduino is ready>");
}

void loop() {
  recvOneChar();
  showNewData();
}

void recvOneChar() {
  if (Serial.available() > 0) {
    receivedChar = Serial.read();
    newData = true;
  }
}

void showNewData() {
  if (newData == true) {
    //    Serial.print("This just in ... ");
    Serial.print("Sending IR");
    Serial.println(); 
    Serial.print(code, HEX);
    Serial.println(); 
//    irsend.sendNEC(0x659A9966, 32);
    irsend.sendNEC(code, 32);
    Serial.print("Done");

    //    irsend.sendNEC(0x659A9966, 32);


    //    irsend.sendSony(0xa90, 12);
    Serial.println(receivedChar);
    
    delay(500);
    code += 255;
  }
    if (code == '0x659AFF00', HEX);{
    newData = false;
    }
  }
#16

6v6gt:
Here is a simple example to step through the valid codes which you can adapt

uint32_t initCode  = 0x659A0000 ;

uint32_t code = 0 ;
uint8_t i = 0 ;

void setup() {
  Serial.begin( 115200 ) ;
}

void loop() {
    code = initCode + (i * 0x100) + (0xFF - i) ;
    Serial.println( code  , HEX ) ;
    i++ ;
    delay(2000) ;
}

What are the two variables?

 uint32_t code = 0 ;
uint8_t i = 0 ;
#17

Are you asking why “code” is a global?
I can’t think of a good reason.

#18

TheMemberFormerlyKnownAsAWOL:
Are you asking why "code" is a global?
I can't think of a good reason.

I was asking what do i put in the two ?

#19

You don’t touch those variables.

The sketch simply generates this series from post #3 which identified the relationship between the third and fourth hex digit pair. One entry is printed every 2 seconds:

Start at…
659A00FF
659A01FE
659A02FD
…
…
…
659AFE01
659AFF00

The variable i is simply a representation of the third hex digit pair in the number series above, running from hex 00 to FF (decimal 0 to 255)
The variable code is the full number above running from 659A00FF to 659AFF00. Yes, it need not have been global.

#20