JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

NRC16 protocol

 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - General Forum
View previous topic :: View next topic  
Author Message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Sun Jun 20, 2010 12:59 pm    Post subject: NRC16 protocol Reply with quote

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:

http://www.hifi-remote.com/forums/viewtopic.php?p=7618#7618

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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Tue Jun 22, 2010 2:16 pm    Post subject: Reply with quote

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:
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:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=8560

Here's an extract of the data produced by CCF2EFC which shows the raw pronto hex:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=8561

I have also created an IR file, by importing the pronto hex, here:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=8562

Here's a PB file for $00BD, the official NRC17 executor:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=8563
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!


Last edited by The Robman on Wed Jun 23, 2010 8:55 am; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Tue Jun 22, 2010 5:00 pm    Post subject: Reply with quote

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:
Once:   +500 -2500; 1 01111111 1111111 -14500   
Repeat: +500 -2500; 1 10000000 0110110 -112000

_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Wed Jun 23, 2010 8:52 am    Post subject: Reply with quote

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:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=8564

And here's a KM upgrade that I just created using it for the Hirschmann CSR 1500B:
http://www.hifi-remote.com/forums/dload.php?action=file&file_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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Tue Dec 22, 2015 10:51 am    Post subject: Reply with quote

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:
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.
_________________
Graham
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - General Forum All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control