Hi

I'm a bit confused on how I should transmit IR code via android devices.
I have this pronto hex for example:
9000, 4500, 560, 565, 560, 565, 560, 565, 560, 565, 560, 565, 560, 565, 560, 565, 560, 565, 560, 1690, 560, 1690, 560, 1690, 560, 1690, 560, 1690, 560, 1690, 560, 1690, 560, 1690, 560, 1690, 560, 1690, 560, 565, 560, 1690, 560, 565, 560, 565, 560, 565, 560, 565, 560, 565, 560, 565, 560, 1690, 560, 565, 560, 1690, 560, 1690, 560, 1690, 560, 1690, 560

which I know it should be sent with frequency of 38hz, as is.

on the other hand, I see this example in here:
[Link: stackoverflow.com]

which basically says that with the above IR code.
I need to manipulate the data and turn it into pulses or duration and only then to transmit the IR code.

can someone please help me to understand when I need to manipulate the pronto code and when I can send it as is?

in this project:
[Link: github.com]

they even do some more manipulation to get the frequency from the pronto hex code

and after running their algorithm on my pronto code I get something like this:
1376 5776 1376 1381 1376 1381 1376 5776...
which I try to send through the consumerIrManager which I guess is wrong...

question num 2:
should I treat differently pronto codes one looks like this:
(1#)
9000, 4500, 560, 565, 560, 565, 560, 565, 560, 565, 560, 565, 560, 565, 560, 565, 560, 565, 560, 1690, 560, 1690, 560, 1690, 560, 1690, 560, 1690, 560, 1690, 560, 1690, 560, 1690, 560, 1690, 560, 1690, 560, 565, 560, 1690, 560, 565, 560, 565, 560, 565, 560, 565, 560, 565, 560, 565, 560, 1690, 560, 565, 560, 1690, 560, 1690, 560, 1690, 560, 1690, 560

and the other like this:
(#2)
0000 006C 0022 0002 015B 00AD 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0016 0016 0016 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0016 0016 0016 0016 0041 0016 0016 0016 0041 0016 05F7 015B 0057 0016 0E6C

because if I run the algorithm on the second pronto here (#2) I get somethinglike this that looks valid:
frequency turns out to be 36044~
and the pattern: 432 432 432 432 864 ...

First question: To send a certain signal, you should send a number of durations that are "close" to the one the receiver expects. It will be recognized if (and only if) it differs from the expected one "just a little". If you send a "dirty" signal (i.e. one that deviates from the perfect one, for example since it is a physical measurement), it will often work "most of the time", but not as reliable as with a perfect one. For example, it amount of allowable disturbances that can be tolerated without breaking the recognition is less. So "cleaning" your signal is desirable, however strictly speaking not always a necessity.

Best tool for cleaning signals is IrScrutinizer. It identifies the signal (assuming that the "dirtyness" is not too large), and then replaces it with the ideal, computed signal.

I would strongly recommend taking some time to "play around" with IrScrutinizer.

Second question: There are two different "forms" of IR signals in your message; first and second consists of the durations expressed in micro seconds, the even ones (first, third, fifth, ...) being on-periods ("flashes", "marks",...) , the other ones being off-periods ("gaps", "spaces", "pauses",...). The third one is however a true Pronto hex, my description [Link: harctoolbox.org] contain just what you need to know (or actually a bit more than you need to know right now). Note that all numbers are four digit hexadecimals, with no comma in between.

I understand.

So, after reading some in google and trying to understand the protocols and the way android sends IR codes ([Link: developer.android.com]))

Let's try to send this code (this is a code for skyQ remote that someone postd on this forum):
0000 0073 0000 001E 0060 0020 0010 0010 0010 0010 0010 0020 0010 0020 0020 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0020 0020 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0020 0010 0010 0020 0020 0020 0020 0020 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0E10

I first grab the frequency. because of the '0000' at the start I know it is denotes a raw IR signal with modulation.
now, '0073' is the frequency, so lets extract it out of it like so:
frequency = Integer.parseInt("0073", 16);
frequency = (int) (1000000 / (frequency * 0.241246));

so freq is: 36044

then I generate the new pronto hex:
1. first convert all the values from the forth element (0060) from hexadecimal to decimal:
96 32 16 16 16 16 16 32 16 32 ...

2. next, I run this method on the values I got [96 32 16 16 16 16 16 32 16 32 ...] :
cycles = [96 32 16 16 16 16 16 32 16 32 ...]
int[] intervals = new int[cycles.length];
int k = 1000000 / frequency;
for (int i = 0; i < intervals.length; i++) {
intervals[i] = cycles[i] * k;
}
return intervals

3. which gives me now the new values:
2592 864 432 432 432 432 432 864 432 864 864 432 432 432 ...

so I finally sends the new pronto hex above with the freq of 36044
transmit (36044, [2592 864 432 432 432 432 432 864 432 864 864 432 432 432 ...])
by android API, the array I send should be pattern in microseconds to transmit.

IS IT OK? SHOULD IT WORK?

and, for the other IR code, this one:
9000 4500 560 565 560 1690 560 565 560 565 560 1690 560 1690 560 1690 560 565 560 1690 560 565 560 1690 560 1690 560 1690 560 565 560 1690 560 1690 560 565 560 1690 560 1690 560 1690 560 565 560 565 560 565 560 565 560 1690 560 565 560 565 560 565 560 1690 560 1690 560 1690 560 1690 560

I don't do this algorithm because the frequency turns to be 536 which is wrong.
so, I send this code with frequency of 38KHz, and do you think I need to also change the pronto code or I can send it as is through the android consumerIrManager as is, like so:
transmit (38000, [9000 4500 560 565 560 1690 560 565 560 565 560 1690 ...])

Yes. Possibly you would like to add commas between the numbers to make it into valid Java ;-).


Not sure what you mean here. The signal is already a number of durations in micro seconds, and there is no information on modulation frequency.

If the modulation frequency is off by, say, 2kHz, it is in general not a big deal, unless you try to maximize the range.