...

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 :)

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

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.

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?

I use this online converter: [Link: binaryhexconverter.com]

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?

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.

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.

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?

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

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

Thanks!!!!!! this here works. You guys all rock. This is why I love this community!

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?

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]