|
|
|
The following page was printed from RemoteCentral.com:
Topic: | Need help converting NEC to Pronto This thread has 39 replies. Displaying posts 16 through 30. |
|
Post 16 made on Tuesday October 17, 2017 at 15:52 |
kgossen Super Member |
Joined: Posts: | March 2008 3,026 |
|
|
...
|
"Quality isn't expensive, it's Priceless!" |
|
OP | Post 17 made on Wednesday October 18, 2017 at 12:21 |
Smakodak Long Time 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 44 |
|
|
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 Long Time 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 44 |
|
|
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 Long Time Member |
Joined: Posts: | April 2016 16 |
|
|
|
Post 22 made on Friday October 27, 2017 at 08:01 |
borgon Long Time Member |
Joined: Posts: | August 2011 44 |
|
|
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 Long Time 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 Long Time Member |
Joined: Posts: | August 2013 362 |
|
|
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 44 |
|
|
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 Long Time 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 Long Time Member |
Joined: Posts: | August 2013 362 |
|
|
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 44 |
|
|
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 Long Time 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 Long Time Member |
Joined: Posts: | August 2013 362 |
|
|
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]
|
|
|
|
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.
|
|