JP1 Remotes

Hi,

today I found out that my two URC-7541 OFAs both are JP1 capable and I directly builded a JP1 interface for them and am amazed at the possibilities this small cable can do.

My hopes were high that I now might be able to finally get a working remote profile for my Bellagio AD-2020 for my OFAs but I was not able to find any ccf, rmdu, ecf, hex, rti or pronto information on that remote (searching 3 hours - finding some interesting stuff, but nothing on the remote).

As my remotes have no learning capabilities the only way of getting some infos on the remote is lirc which is running on my vdr.

So I created a lirc conf-file for the remote in the hope that someone is able to give me the neccessary hints on how to convert this into a working upgrade for my OFAs.

As most people posting with problems get asked to upload the file I did this directly. The lirc-config can be found here :https://www.hifi-remote.com/forums/dload ... le_id=2259

Many thanks in advance for helping,

Egalus

I don't know how to tell the difference between NEC1 and NEC2 in a lirc file, but I think you're file translates to NEC1 device code 4.

I have built an upgrade file based on that assumption here...
https://www.hifi-remote.com/forums/dload ... le_id=2262

If any of the buttons are supposed to repeat when held (like the volume buttons) and they don't with this upgrade, try changing the protocol to NEC2.

Thank you very much, I never would have thought that someone would do all the work for me

This upgrade works great, all left to do was changing some keyarrangements to my personal taste.

Just for my curiosity I opened the upgrade file and the lirc file and compared them and have some findings I don't understand and some that I do

I found out that the Hex-code for the functions are the last 2 digits of the lirc file, that was easyly understood, but I didn't understand two other parts

a) Lircconfig says "Predata 0x20DF" and with devicenumber 4 this gets to Fixed Data 00 DF DF in RM

b) why does the OFA not need to care about the 2 digits infront of the 2 digits taken for the hexnumber for the update (in other words, what happens to the 3rd and 4th last digits of the lircfile)

As always I try to understand what's going on to get to a base of "dangerous half-knowings" (sorry, but english is not my native tongue and this is a word by word translation from german to english)

egalus wrote: As always I try to understand what's going on to get to a base of "dangerous half-knowings" (sorry, but english is not my native tongue and this is a word by word translation from german to english)

Your English is much better than MOST of our German , I would wager, and your literal translation is almost spot-on. In English, we frequently say that one knows "enough to be dangerous" so your meaning is crystal clear .

The Robman wrote: If any of the buttons are supposed to repeat when held (like the volume buttons) and they don't with this upgrade, try changing the protocol to NEC2.

egalus wrote:This upgrade works great, all left to do was changing some keyarrangements to my personal taste.

Did you understand what Rob said about keys that repeat while held? Did you test that?

I'm not certain, but I think that lirc file showed NEC2, not NEC1.

egalus wrote: a) Lircconfig says "Predata 0x20DF" and with devicenumber 4 this gets to Fixed Data 00 DF DF in RM

In most protocols, NEC included, the bits within each byte are transmitted in the opposite sequence from the left to right sequence you might expect when looking at the value. So the number 4 is transmitted as eight bits in sequence: 0 0 1 0 0 0 0 0

Both lirc and UEI ignore the official sequence of each protocol and use left to right. So device 4 is represented as 0x20

egalus wrote: b) why does the OFA not need to care about the 2 digits infront of the 2 digits taken for the hexnumber for the update (in other words, what happens to the 3rd and 4th last digits of the lircfile)

NEC protocol follows each byte with its inverse (0xFF minus the beyte) as a check, so the 0x20 is followed by 0xDF which is FF minus 20.

UEI protocol executors "know" that about protocols, but lirc doesn't. So UEI needs only the first byte while lirc shows both.

But here it looks like UEI has just the second byte, not the first. That's because UEI usually gets the definitions of the '1' and '0' bursts inverted, which has the same effect as subtracting from 0xFF, so they represent the value 0x20 as 0xDF, which happens to equal the second byte.

Lirc is less consistent about '1' and '0' bursts. For the exact same code set you may find one lirc file (like your file) that gets '1' and '0' correct and another that gets it backwards. So you can't rely on the rule that the backwards value UEI needs will match the second byte of the lirc data. But it will be consistent within one lirc file, so if a few functions match that way, the rest will too.

Finally, you may wonder why the UEI has the DF stored twice. That is to take up space for conistency with another form of NEC where only the function numbers have a check byte and the device check byte is replaced by a subdevice number.

johnsfine wrote:I'm not certain, but I think that lirc file showed NEC2, not NEC1.

I was thinking that too, but to try and make certain, I checked out some of the Toshiba codes found here as I'm pretty confident that all Toshiba signals are NEC1 and I couldn't see the difference to the file posted. I was looking for something describing the 2-word repeating postion and I couldn't see it.

Can you see something in there that we can use to definitively differentiate between NEC1 and NEC2?

Hey, I see an opening for a new DecodeLIRC program here!!!

I don't know why I missed it when I looked at that file.

It is NEC1.

The line that says tells you that it is NEC1. I looked for that line, didn't see it and then said it was NEC2. But the line is right there where I thought I looked.

I must admit that despite the fact that OFAs exist for such a long time this forum is really active with people that have knowledge and still share it with newbs

Just for me, if I again find a "repeat 9072 2227 " in a lircfile it's nec1 protocol and hex for RM is either the last 2 digits from lirc or 4th and 3rd last digit from lirc with devicenumber constructed like said before?

As my DVD-Player loved to interact with remotes from other equipment I have I guess chances are good that I have more Nec1 stuff around

To answer the question about nec2:
No, I did not test Nec2 as everything worked as it did with the original remote when testing. This includes no repeats for volume keys which I don't really care about as the dvd is digitally connected to my amp.

egalus wrote: Just for me, if I again find a "repeat 9072 2227 " in a lircfile it's nec1 protocol and hex for RM is either the last 2 digits from lirc or 4th and 3rd last digit from lirc with devicenumber constructed like said before?

The repeat would be approximately that in a different file, not exactly that. And a line like that is consistent with NEC1 and rules out most other protocols including NEC2. But it doesn't rule out all other protocols. My comment earlier that it "tells you that it is NEC1" was in the context of an NEC1 vs. NEC2 question, not in the context of first thing to look at when you have no idea about protocol.

Also, a few lirc files misguess the boundary between the device part and the command part so they might have more or less than 16 bits of "pre data", which completely misaligns the function data, so you need to convert hex to binary, regroup the bits and convert back.

egalus wrote:Just for me, if I again find a "repeat 9072 2227 " in a lircfile it's nec1 protocol and hex for RM is either the last 2 digits from lirc or 4th and 3rd last digit from lirc with devicenumber constructed like said before?

At this point, I would recommend that, when the "next time" comes, you post the LIRC file as you did here and ask one of us to look at it. Even we are not experts with this format yet, but we generally know enough about protocols to make an educated guess as to what the protocol being learned is. As John mentioned is his post, there are other factors that can throw things off, like in this thread where the bits were all shifted by 1.

Hopefully, John will write a program that will decode these files for you in much the same way that DecodeCCF decodes Pronto files.

egalus wrote:To answer the question about nec2:
No, I did not test Nec2 as everything worked as it did with the original remote when testing. This includes no repeats for volume keys which I don't really care about as the dvd is digitally connected to my amp.

Even though we have confirmed that these are NEC1 signals, you've thrown me a bit with this statement. Do any of the buttons on the original remote repeat (ie, when you hold the button down the player continues to respond). Volume buttons are an easy example of buttons that usually repeat but another example might be the arrow buttons.

If some of the original buttons do repeat, the same buttons in the upgrade that I created should also repeat.