Your Universal Remote Control Center
RemoteCentral.com
Discrete Code Hunter Forum - View Post
Previous section Next section Up level
Up level
The following page was printed from RemoteCentral.com:

Login:
Pass:
 
 

Topic:
Should I manipulate this IR code?
This thread has 3 replies. Displaying all posts.
Post 1 made on Wednesday March 4, 2020 at 12:24
theremoteman
New Member
Joined:
Posts:
January 2020
17
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 ...

Last edited by theremoteman on March 4, 2020 13:36.
Post 2 made on Wednesday March 4, 2020 at 15:31
Barf
Long Time Member
Joined:
Posts:
August 2013
233
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.
OP | Post 3 made on Thursday March 5, 2020 at 11:40
theremoteman
New Member
Joined:
Posts:
January 2020
17
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 ...])
Post 4 made on Thursday March 5, 2020 at 14:16
Barf
Long Time Member
Joined:
Posts:
August 2013
233
IS IT OK? SHOULD IT WORK?

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

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

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.


Jump to


Protected Feature Before you can reply to a message...
You must first register for a Remote Central user account - it's fast and free! Or, if you already have an account, please login now.

Please read the following: Unsolicited commercial advertisements are absolutely not permitted on this forum. Other private buy & sell messages should be posted to our Marketplace. For information on how to advertise your service or product click here. Remote Central reserves the right to remove or modify any post that is deemed inappropriate.

Hosting Services by ipHouse