JP1 Remotes

Posted: **Sun Jun 20, 2010 11:59 am**

I just ran a ccf file through DecodeCCF and it reported one of the devices as using the NRC16 protocol.

I tried looking up NRC16 on John's page but it's not documented yet. I didn't get any hits looking for it in the forums either, the closest I could find was some talk about NRC17 here:

https://www.hifi-remote.com/forums/viewt ... =7618#p7618

So, I decoded it by hand. It appears to be a 2-part signal where the first part is fixed and the second part is variable. Each part is 16 bits and the obc is the first half of the second 16-bit part.

What confuses me is how DecodeIR choses to convert the parts to decimal. It doesn't decode anything from the first 2 bytes, so I assume they're fixed for this protocol (is that correct?). For the second part, it decodes the OBCs (3rd byte) in LSB format and the device code (4th byte) as MSB. I would have assumed that the OBC would dictate LSB vs. MSB and we would then use that format to derive the device code.

So, John or Graham (or anyone else), can you shed any light on this protocol?

The only UEI executor that comes close to matching the profile is $00BD, which has already been labeled as NRC17, though I haven't checked it's assembler to see what it really does.

Posted: **Tue Jun 22, 2010 1:16 pm**

I think I've figured out the MSB vs. LSB thing. The only sample of NRC16 data I have has a device code of 54, which in binary is 00110110. That just happens to match the binary found in the 2nd variable byte.

However, I believe that both the OBC and the device code are really just 7-bits long, with the OBC being preceded with a "1" and the device code preceded with a "0". The 7-bit version of device code 54 is 0110110 (which is a palindrome).

So, the structure of the signal for the "1" button (OBC 1, dev 54) is as follows:

Code: Select all

Once:   +500 -2500; 10111111 11111111 -14500	
Repeat: +500 -2500; 11000000 00110110 -112000

The OBC byte is 11000000, which is really 1_1000000
The dev byte is 00110110, which is really 0_0110110

Here's a spreadsheet showing the learned signals for a Hirschmann Satellite Receiver CSR 1500 B:
https://www.hifi-remote.com/forums/dload ... le_id=8560

Here's an extract of the data produced by CCF2EFC which shows the raw pronto hex:
https://www.hifi-remote.com/forums/dload ... le_id=8561

I have also created an IR file, by importing the pronto hex, here:
https://www.hifi-remote.com/forums/dload ... le_id=8562

Here's a PB file for $00BD, the official NRC17 executor:
https://www.hifi-remote.com/forums/dload ... le_id=8563

Posted: **Tue Jun 22, 2010 4:00 pm**

I just figured out that the zero that I thought was added in front of the device code is really the last bit of the OBC. So the format is really:

Code: Select all

Once:   +500 -2500; 1 01111111 1111111 -14500   
Repeat: +500 -2500; 1 10000000 0110110 -112000

Posted: **Wed Jun 23, 2010 7:52 am**

Here's my attempt at doing the IRP for each of these protocols (with a lot of help from the automated feature in IR):

NRC16
{38k,500,lsb}<-1,1|1,-1>(1,-5,1:1,127:8,127:7,-15m,(1,-5,1:1,F:8,D:7,-110m)+)

NRC17
{38k,500,lsb}<-1,1|1,-1>(1,-5,1:1,127:8,255:8,-20m,(1,-5,1:1,F:8,D:8,-80m)+)

Here's a PB file that I just created for NRC16:
https://www.hifi-remote.com/forums/dload ... le_id=8564

And here's a KM upgrade that I just created using it for the Hirschmann CSR 1500B:
https://www.hifi-remote.com/forums/dload ... le_id=8565

The upgrade is untested, so if anyone has the time and ability to capture the signals to see if they show up as NRC16, dev 54, I would appreciate it.

Posted: **Tue Dec 22, 2015 9:51 am**

In my investigation of MAXQ protocols, I have discovered that protocols.ini already contains official UEI executors for NRC16. They must have been around for a long time, since they include code for the 740 and 6805-RC16/18 processors as well as the HCS08, S3C80 and MAXQ610, it is just that they haven't been recognised as they are languishing simply under the name [pid: 00 B0]. If you insert

Code: Select all

CmdParms=OBC:8=0
CmdTranslator=TranslatorWithDevBool(lsb,1,0,7,1)
DefaultCmd=80
DevParms=Device:7=0,OBC>127:bool
DeviceTranslator=Translator(lsb,0,7,1) Translator(1,1,0)
FixedData=00

into the entry for [pid: 00 B0], and change that name if you wish, it becomes a fully functional entry that has the device and function values in the form of Rob's IRP in the post above. Well, almost. The IRP from the MAXQ executor is actually

{37.3k,513}<-1,1|1,-1>(1,-5,1:1,127:8,127:7,-26,(1,-5,1:1,F:8,D:7,-110m)*,(1,-5,1:1,127:8,127:7,-110m))

whose only significant difference is that it repeats the prefix frame also as a final frame when the key is released. The NRC17 executor, PID 00BD:2, similarly repeats its prefix frame in this way. At least, the MAXQ executor does, which is all I can vouch for. The NRC16 and NRC17 protocols are also similar to Blaupunkt, which again has a final frame, see this post.

There is a variant of this NRC16 protocol under [pid: 00 75] which differs only in its frequency, which is 30.9k.

I realise I am replying to posts from five years ago, but hope this is still of interest. It is a first discovery from my investigation, through their MAXQ executors, of the large number of entries in protocols.ini that are identified only by their PIDs. More will follow, in other threads.

Edit: There is a minor error both in this post and in Rob's post above. The fixed bit sequence 01111111, which has been written as 127:8 in the IRPs, should actually be written as 254:8 (or 127:-8) since the values are sent lsb.