Your Universal Remote Control Center
RemoteCentral.com
Audio, Receivers & Speakers Forum - View Post
Previous section Next section Previous page Next page Up level
Up level
The following page was printed from RemoteCentral.com:

Login:
Pass:
 
 

Page 2 of 3
Topic:
Need help converting NEC to Pronto
This thread has 32 replies. Displaying posts 16 through 30.
Post 16 made on Tuesday October 17, 2017 at 15:52
kgossen
Super Member
Joined:
Posts:
March 2008
2,853
...
"Quality isn't expensive, it's Priceless!"
OP | Post 17 made on Wednesday October 18, 2017 at 12:21
Smakodak
Junior Member
Joined:
Posts:
April 2016
16
Hej Flemming (I think we're both from Denmark, but I'll write in english anyway),

I'm no expert, but I would try to remove the two last characters from both "device" and "function".

So for the Vol+ you put the below in the "Generate" page in IrScritinizer:

Protocol: Nec1
D (Device): 0x37
S (Subdevice): Blank
F (Function): 0x19

Let me know your results :)
Post 18 made on Wednesday October 25, 2017 at 08:04
borgon
Long Time Member
Joined:
Posts:
August 2011
33
Sorry for the delay (been out of town)

I was finally able to give it a try....and no luck.

to help, when I use IrScrutinizer and do the volume command above (0x37 0x19) this is the output I get (below), but nothing registers on the Lyngdorf

0000 006C 0022 0002 015B 00AD 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 0016 0016 0016 0016 0041 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0041 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 05F7 015B 0057 0016 0E6C
OP | Post 19 made on Thursday October 26, 2017 at 07:46
Smakodak
Junior Member
Joined:
Posts:
April 2016
16
Are you certain that both the remote control you are using, and the Lyngdorf IR-receiver are both working?

Still using the Volume+ as an example, Hex 0x37CA resolves to decimal 14282, and Hex 0x19E6 to 6630. The maximum decimal value for the NEC1 protocol is 255.
If the values are right, maybe it's the protocol. But I haven't any experience with other protocol than NEC1, so I cannot tell if there is another that supports these values.

If all else fails, and you have a working remote, there's always the possibility to record the signals from that.
Post 20 made on Thursday October 26, 2017 at 10:24
borgon
Long Time Member
Joined:
Posts:
August 2011
33
the Lyngdorf receives commands from its original remote, and the URC registers on other devices so i think both are working.

how do you convert Hex to decimal?
OP | Post 21 made on Thursday October 26, 2017 at 23:18
Smakodak
Junior Member
Joined:
Posts:
April 2016
16
I use this online converter: [Link: binaryhexconverter.com]
Post 22 made on Friday October 27, 2017 at 08:01
borgon
Long Time Member
Joined:
Posts:
August 2011
33
thanks - I've been using the Hex tool in IR scrutinizer. Still can't get it to work.

For instance, Power toggle

Power Togle 0x37CA, 0x0CF3

37 --> 55
CA --> 202
OC --> 12
F3 --> 246

pretty sure 37ca is the device and ocf3 is the function. Puttin combinations of all in IRscrutinizer results in HEX codes that just don't work. I did conform with Lyngdorf thats its NEC1 proptocol

Not sure what I'm doing wrong

Any adivce?
OP | Post 23 made on Friday October 27, 2017 at 08:32
Smakodak
Junior Member
Joined:
Posts:
April 2016
16
Your assumption regarding device and function seems correct to me, since 0x37CA is the same for every command.

I cannot help you any further. As I wrote earlier, you can build an IR sender and receiver. The recipe are made by the same guy that wrote IrScrutinizer, and can be used with it. You can find it here: [Link: harctoolbox.org]
He is the user who helped me here and goes under the remotecentral alias "Barf".
You could also try and ask him directly. He probably can tell if the codes you got from Lyngdorf are valid or not.

If you are living in Denmark, I would be happy to send you the one I made. You could just return it when finished. I actually have two, and I would also gladly sell you the spare.
Post 24 made on Friday October 27, 2017 at 12:17
Barf
Regular Member
Joined:
Posts:
August 2013
161
1. This has nothing to do with IrScrutinizer. You would not ask Apple or Samsung about a "silly" phone number...
2. IrScrutinizer understands hexadecimal numbers in 0x... notation too,
3. ... and contains a hex <-> decimal converter (Tools -> Hex calculator).
4. Your options are:
* Guess how the numbers should be transformed to S, D, and F,
* Find the codes somewhere else (https://irdb.globalcache.com ?)
* Capture them yourself. For this, Smakodak make a good offer; take advantage of that.
Post 25 made on Friday October 27, 2017 at 16:57
borgon
Long Time Member
Joined:
Posts:
August 2011
33
Thanks Barf,

- I had been to globalcache and couldnt find them there
- i'd love to take Smakodak up on his offer, but unfortunately I'm in the US which (i'm guessing) makes shipping costs high

So it looks like I'm left with trying to guess.

To get a little guidance; the power toggle example above. NEC1 code given is
0x37CA, 0x0CF3

When I try to convert them to decimal, what do I input?
0x37
0x37ca
37
CA

.... or is that (sadly) going to be part of the guessing game?
OP | Post 26 made on Friday October 27, 2017 at 18:24
Smakodak
Junior Member
Joined:
Posts:
April 2016
16
Thanks Barf for clearing things up :)

Did you, Borgon, try downloading from globalcache?
I did. Try the two below.

Vol+ (DPA1/SDAI/TDA/MIllennium Preamp/Processors)
0000 006C 0022 0002 015B 00AD 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 05F7 015B 0057 0016 0E6C

Vol+ (RP1 Preamp/Processor)
0000 006C 0022 0002 015B 00AD 0016 0016 0016 0016 0016 0016 0016 0016 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 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 06A4 015B 0057 0016 0E6C
Post 27 made on Saturday October 28, 2017 at 03:32
Barf
Regular Member
Joined:
Posts:
August 2013
161
To get a little guidance; the power toggle example above. NEC1 code given is
0x37CA, 0x0CF3

When I try to convert them to decimal, what do I input?
0x37
0x37ca
37
CA

First note that the "third byte" and the "forth byte" (0C and F3) sum up to 255, which is consistent with NEC1. Good news. The same way. the first and the second byte does NOT sum up to 255, which means that S should not be blank. So the natural guess would be

D = 0x37
S = 0xCA
F = 0x0C

(you type in the four characters "0x37", forget about translation to decimal.) Next guess is to bit-reverse these number (some communities (Lirc and Arduino IRremote for example) do not "like" the least-significant-bit-first notation that e.g. NEC1 is using). Bit-reversing 0x37 = 00110111 gives 11101100 = 0xEC (reading the bits in the opposite order). A good tool for computing this is the Hex calculator in IrScrutinizer (the row marked "LSB" gives the bit-reversed result). For the example

D = 0xEC
S = 0x53
F = 0x30
Post 28 made on Saturday October 28, 2017 at 06:12
borgon
Long Time Member
Joined:
Posts:
August 2011
33
On October 28, 2017 at 03:32, Barf said...
First note that the "third byte" and the "forth byte" (0C and F3) sum up to 255, which is consistent with NEC1. Good news. The same way. the first and the second byte does NOT sum up to 255, which means that S should not be blank. So the natural guess would be

D = 0x37
S = 0xCA
F = 0x0C

Thanks!!!!!! this here works. You guys all rock. This is why I love this community!
OP | Post 29 made on Saturday October 28, 2017 at 16:06
Smakodak
Junior Member
Joined:
Posts:
April 2016
16
On October 28, 2017 at 03:32, Barf said...
First note that the "third byte" and the "forth byte" (0C and F3) sum up to 255, which is consistent with NEC1. Good news. The same way. the first and the second byte does NOT sum up to 255, which means that S should not be blank. So the natural guess would be

D = 0x37
S = 0xCA
F = 0x0C

(you type in the four characters "0x37", forget about translation to decimal.) Next guess is to bit-reverse these number (some communities (Lirc and Arduino IRremote for example) do not "like" the least-significant-bit-first notation that e.g. NEC1 is using). Bit-reversing 0x37 = 00110111 gives 11101100 = 0xEC (reading the bits in the opposite order). A good tool for computing this is the Hex calculator in IrScrutinizer (the row marked "LSB" gives the bit-reversed result). For the example

D = 0xEC
S = 0x53
F = 0x30

I'm still with you. Barf, if you got the time, I have a couple of questions.
1. Why was "the natural guess" F=0x0C and not F=0xF3?
2. Is there, in your opinion, a sane explanation to the notation Borgon was given by Lyngdorf? I mean, you figured it out, but you had to "guess". That shouldn't be necessary. Isn't the NEC1 protocol well described?
Post 30 made on Sunday October 29, 2017 at 08:57
Barf
Regular Member
Joined:
Posts:
August 2013
161
To my knowledge, the protocol we call NEC1 is specified in official documents. It is also described in a number of places on the Internet, for example [Link: sbprojects.com] . (I even think that the firm NEC (now called Renesas) asks for a license fee if you implement it in a commercial product with D != 0.)

The procotol NEC1 contains 32 "payload" bits, which can be decomposed into four bytes. First one is device address, called D by IrScrutinizer and DecodeIR. The second one was originally just the (one-) complement of the first, but as more "addresses" were sought, it aquired its owm "life" as "subdevice", S. The third byte is the command number, F. The forth byte the complement of the third, although some manufacturers (Yamaha, possibly others) has used it differently. Note that by convention AND specification, these bytes are interpreted least significant bit first.

Some projects interpret the payload bits differently. For example Arduino-IRremote [Link: github.com] considers the number of bits variable (up to 32) and lumps them all into one number, interpreted most-significant-bit-first.

Why Lyngdorf selected their format you have to ask them. Possibly the last two "numbers" of the "short pronto form"?

I have put a file in Girr format (can be directly read into IrScrutinizer, and then transformed to other formats) here:  [Link: raw.githubusercontent.com]
Page 2 of 3


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