JP1 Remotes

[gfb107]

Here's the list of protocols that RM doesn't currently support:

Echostar 2200
NEC1 2DEV Combo
NECx1
NECx2
Pioneer DVD2
Pioneer MIX
Pioneer 2CMD
Pioneer 3DEV
RC-5x
RC-5/5x Combo
RCA Combo (w/Duration)
ReplayTV (Simple)
ReplayTV (Advanced)
Zenith

I'm fairly certain it is just a matter of making the proper entries in protocols.ini, there should be no need for new code in RM.

I would appreciate any help we can get to finish this up.

The protocols.ini format is documented within the file, or you can just use existing entries as a guide.

If that is too crytpic, you could just post the details needed here, such as device parameters w/ default values, how the fixed data is calculated. Also the command parameters and how the hex command is computed, then John or I could make the protocols.ini entries.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[gfb107]

I'm still looking for help with this!
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[mr_d_p_gumby]

I've recently been working with Mark to get these protocols added to the next version of KM:

[gfb107]

All we need to do is to pick names for the 2 types of processors.
I suggest we stick with "6805" for the currently supported processor (so we don't have to go back and fix all the RDFs), and then 6805-C9 or 6805-RC16/18 for the other (I can't remember which is the new one).
Then I need to update my protocols.ini parser to recognize the new processor name. Then we can add protocol code to protocols.ini.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[gfb107]

We have to consider whether or not changing the processor name will have an impact on IR. If it makes a difference, we should maybe use a new attribute, such as

Processor.variant=

The we could have C9 and RC16/18 as values when Processor=6805.

From my point of view there is no significant difference in the effort involved with making the change.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[gfb107]

I went back and re-read the FYI: 6805 protocols thread, and have made an executive decision.

Let's have
Processor=6805

and

ProcessorVersion={C9|RC16/18}

Now we just need to tell Nils which RDFS need which value for ProcessorVersion.

I won't release the version of RM that makes use of the ProcessorVersion until Nils has releases updated RDFs.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[gfb107]

I'll add code to make the ProcessorVersion default to the older-style, once someone reminds me which that is. This should make it easier to release, as the RDF changes and RM changes won't have to be simultaneous.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[mr_d_p_gumby]

[gfb107]

I've finally figured out how to read the hidden/protected sheets and formulas in KM so that I can fairly easily add support for the missing protocols.

I've already done NECx1 and NECx2, but when I got to "NEC1 2DEV Combo" I discovered an oversight in the definition of the protocols.ini syntax. There are some protocols that have different fixed data for different processors. In general there is one that is different from the rest. I'm going to add the abilty to override the fixed data on a per processor basis, as follows (I'm using the values from "NEC1 2DEv Combo here ):

FixedData=FF 00 FF 00
FixedData.S3C80=FF 00 FF 00 00 00
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)