JP1 Remotes

Posted: **Sun Jan 23, 2005 9:28 pm**

Is there a guide on setting up new protocols for remote master? I have a KM Foxtel/sky upgrade that works (which is why I'm not posting to code search) that I would prefer to use in RM. Because it uses manual settings it fails to load in RM, and I can't add the protocol manually, probably because I have no idea what the settings under manual do. When I add what I think is right (using the params from the KM file) I can never save it - it just disappears. I don't seem to be able to add anything in the Command Parameters field. There are no docs online at sourceforge, and I can't find any here via search.

decodeir tells me it's Nokia32, so maybe a master can just add that straight to RM.

Posted: **Sun Jan 23, 2005 10:36 pm**

Support for entering Manual Settings in RM is still incomplete.

However, RM is supposed to be able to import KM upgrades that use Manual Settings correctly. However, the format of this upgrade file isn't consistent with what RM expects for upgrades with Manual Settings. RM expects the custom protocol to be present in the Notes for the upgrade, but that isn't the case here. I need to get some clarification from the KM experts about this, so I can correctly import these types of upgrades in RM.

Since I know this about RM, I was able to manually insert the upgrade protocol code into the Notes section of the KM upgrade file and then successfully import it into RM. The resulting file is Foxtel Digital.rmdu.

Posted: **Mon Jan 24, 2005 12:39 am**

Thanks, Greg - looks about right...

So do you just paste the KM generated protocol code to the notes in KM?

What do you need to know about Nokia32 to put it in protocol.ini?

Posted: **Mon Jan 24, 2005 4:40 am**

gfb107 wrote:RM expects the custom protocol to be present in the Notes for the upgrade

KM can create Manual Settings without any protocol code in the Notes section, so relying on it being there is not wise. The only time KM should have p-code in Notes would be when using a 3rd-party protocol.

Posted: **Mon Jan 24, 2005 6:37 am**

Mark Pierson wrote:KM can create Manual Settings without any protocol code in the Notes section, so relying on it being there is not wise. The only time KM should have p-code in Notes would be when using a 3rd-party protocol.

It looks to me like this upgrade uses a custom protocol. I assumed this was the same thing as a 3rd-party protocol. Where does KM get the protocol code for this case?

OK, so then RM could parse it out from the Procotol Code: section of the upgrade? Can this section include protocol code for other processor types?

Posted: **Mon Jan 24, 2005 6:42 am**

harley wrote:Thanks, Greg - looks about right...

So do you just paste the KM generated protocol code to the notes in KM?

That's what I did.

What do you need to know about Nokia32 to put it in protocol.ini?

There's a bunch of information I need:

Is there a known PID used for this protocol in any remotes?
How many bytes of fixed data is there?
What are the device parameters, and what are the rules for storing them in the fixed data?
How many bytes is the hex command?
What are the command parameters, and what are the rules for storing them in the hex command?
What is the protocol code for the various processor types?

Posted: **Mon Jan 24, 2005 7:40 am**

In KM, Manual Settings can be used for any of the unnamed (PID: ####) built-in protocols that a given remote contains, in which case no 3rd party code is used (in theory, Manual Settings can be used for just about any protocol, but that would be impractical).

The code in the Protocol section of the upgrade file is KM's best guess as to what it really is and is processor specific. Since it's built-in, there's no need for a protocol upgrade by the user, and this is not what KM calls 3rd party code. That is p-code supplied to KM (via the Notes section) in cases where the remote doesn't contain it, or it's a unique special case.

Posted: **Mon Jan 24, 2005 8:41 am**

Oh. OK. So the PID used for Manual Settings isn't just an arbitrary number.
It is actually used to look up a protocol and retrieve protocol code if one is found. Of course, any protocol code entered in the Notes overrides the protocol code for that PID.

Posted: **Mon Jan 24, 2005 9:22 am**

you guys have gone way over my head.

1. Is there a known PID used for this protocol in any remotes?
2. How many bytes of fixed data is there?
3. What are the device parameters, and what are the rules for storing them in the fixed data?
4. How many bytes is the hex command?
5. What are the command parameters, and what are the rules for storing them in the hex command?
6. What is the protocol code for the various processor types?

AFAIK the code is usually 20, and I don't know what #6 means...

KM lists :

Code: Select all

Protocol ID: 	00 20
Fixed Data: 	E0 00 
	Manual Settings
PID: 	20
2nd Cmd Byte: 	None
Signal Style: 	MSB
Bits/Dev: 	8
Bits/Cmd: 	8

And my Australian URC-7544 has it built in (But not the 8810 and 8910 I got from Rob). If there's a back door to get it out I'd love to know...

Posted: **Mon Jan 24, 2005 11:55 am**

I've never looked at the Manual Settings support in RM, because I thought protocols.ini entries are easy enough to write that other experts (the people who originally deduce the right fixed data for these manual settings upgrades) would find it easier to write the protocols.ini entries for those protocols than to provide and support upgrades with manual settings.

Protocols.ini has commented out sections for most of the pid's for which it lacks clean support. Those sections include the protocol code, and the RDFs include the info about which models need that code.

The Protocol code includes a byte that tells the correct length of the fixed data and the hex command. I assume RM doesn't yet use that byte, because Protocol code was added later than the code for getting fixed data and hex command length from protocols.ini.

If you just uncomment those entries you have nearly all the required support. It would be nice to have RM check fixed data length and hex cmd length against that byte in the supplied code (when available) because no one has seriously investigated varient questions in those protocols and a wrong fixed data length indicates the imported upgrade is not compatible with the entry in protocols.ini.

Posted: **Mon Jan 24, 2005 12:04 pm**

PID 0020 is the RC6-M-20n protocol, which is already defined in protocols.ini. Fixed data "E0 00" matches setup code SAT/0847.

Just FYI, according to my files, this protocol only gets pre-loaded into certain European remotes, it's not present in any US remotes that I know of.

Posted: **Mon Jan 24, 2005 12:24 pm**

johnsfine wrote:The Protocol code includes a byte that tells the correct length of the fixed data and the hex command. I assume RM doesn't yet use that byte, because Protocol code was added later than the code for getting fixed data and hex command length from protocols.ini.

Where can I find out which bytes of the protocol code tell the length of the fixed data and hex command?

Posted: **Mon Jan 24, 2005 12:30 pm**

For S3C80:

The first two bytes always encode the frequency (by their sum) and duty cycle (by their ratio), which I assume RM won't care about.

The third byte always encodes both the fixed data length and the hex command length. It is read as two nibbles. The high nibble is the fixed data length and the low nibble is the hex command length.

I haven't checked whether non S3C80 follow the same rules. I think they do.

For example, the pid-20 entry inprotocols.ini now is shown below Notice both versions have a third byte saying 2 byte fixed data and 1 byte hex cmd.

# [pid: 00 20]
# PID=00 20
# DefaultCmd=00
# Code.S3C80=40 9A 21 8B 13 87 85 00 08 04 00 DE 00 00 00 00 00 CA F1 38 05 35 01 A8 E4 03 2D E4 04 2E E4 05 2F 08 2D F6 FF 62 19 03 E6 04 03 08 2E F6 FF 62 19 05 F6 FF 62 19 06 08 2D F0 C0 F6 FF 62 19 07 08 2F F6 FF 62 19 08 F6 FF 62 19 09 2C 04 10 09 10 08 10 07 10 06 10 05 10 04 2A F2 E6 10 06 8D 01 46 2C 04 CF 10 C1 DF 10 C1 90 C0 FB 03 B6 C1 03 2A F1 AF
# Code.740=0C 1C 21 A9 60 20 DB 00 A2 16 A0 02 22 44 22 1F 20 74 01 A2 1B A0 02 22 44 A9 20 20 DB 00 22 23 20 79 01 22 1F 06 54 06 54 06 54 06 54 20 74 01 A5 5F 85 54 20 79 01 A2 2A A0 A1 22 44 22 06 90 C2 60 3C 04 55 80 03 3C 08 55 26 54 B0 0D A2 86 A0 01 22 44 A9 10 20 DB 00 80 0B A9 10 20 DB 00 A2 86 A0 01 22 44 C6 55 D0 E0 60

Posted: **Mon Jan 24, 2005 12:41 pm**

The Robman wrote:PID 0020 is the RC6-M-20n protocol, which is already defined in protocols.ini. Fixed data "E0 00" matches setup code SAT/0847.

Just FYI, according to my files, this protocol only gets pre-loaded into certain European remotes, it's not present in any US remotes that I know of.

The variant of RC6-M-20n in protocols.ini that includes protocol code, and can therefore be used in remotes that don't have it built in, uses 6 bytes of fixed data.

The variant that doesn't have protocol code, and can therefore only be used in remotes that have it builtin, has 2 bytes of fixed data.

Posted: **Mon Jan 24, 2005 12:43 pm**

harley wrote: decodeir tells me it's Nokia32, so maybe a master can just add that straight to RM.

The Robman wrote:PID 0020 is the RC6-M-20n protocol, which is already defined in protocols.ini. Fixed data "E0 00" matches setup code SAT/0847.

That one sure confused ME. Maybe I'm still confused.

I just assumed this was a not_yet_supported protocol in the .ini file. But it sure looks like Rob is right that it's RC6-M-20n, which would be quite easy to set up in RM (and probably matches and .rmdu file already posted).

So what is the Nokia32 decode about?

JP1 Remotes

Remote Master - Manual Settings

Remote Master - Manual Settings

Re: Remote Master - Manual Settings