DecodeIR, RM and KM request: Yamaha extended NEC gap signals

[3FG]

Rob,
Thanks,
I'll spend some time (tonight, I hope) seeing if we can add a UI to this in RM just by adding an entry to protocols.ini.

[The Robman]

The tricky part will be importing KM files, I suspect that you'll need a new class for that.

[3FG]

It will probably be some time before I get to this. The popping noise I heard when I "sprained my ankle" actually means that I'll be having my fibula put back together with screws. Hard to work at a computer with one leg elevated!

[vickyg2003]

It will probably be some time before I get to this. The popping noise I heard when I "sprained my ankle" actually means that I'll be having my fibula put back together with screws. Hard to work at a computer with one leg elevated!

Oh no! Dave you've got to be more careful. Good luck with your surgery, when is that happening?

[The Robman]

It will probably be some time before I get to this. The popping noise I heard when I "sprained my ankle" actually means that I'll be having my fibula put back together with screws. Hard to work at a computer with one leg elevated!

Ouch! Airport security is gonna be fun for you!

[3FG]

Here is an entry for protocols.ini which will allow one to build an upgrade in RemoteMaster employing the Yamaha protocol executor that Rob wrote.
It does not yet support reading in a KM file for the this executor. I have adapted NECStyleImporter.java to a new class YamahaStyleImporter, but I haven't been able to test it yet-- the directory structure in RM and RMIR has changed since I last added a class.....

The protocol.ini entry refers to YamahaStyleImporter, but runs in spite of not finding the class.

Interestingly, RM does not now correctly read in standard NEC 4DEV Combo files due to an error in protocols.ini. I have fixed that in the NEC 4DEV Yamaha Combo entry.

[NEC 4DEV Yamaha Combo]
PID=01 1A
#VariantName=2
DevParms=Device 1,Sub Device 1=[-0],Device 2,Sub Device 2=[-2],Device3,Sub Device 3=[-4],Device 4,Sub Device 4=[-6]
DeviceTranslator=Translator(lsb,comp,0,8,0) Translator(lsb,comp,1,8,8) \
Translator(lsb,comp,2,8,16) Translator(lsb,comp,3,8,24) \
Translator(lsb,comp,4,8,32) Translator(lsb,comp,5,8,40) \
Translator(lsb,comp,6,8,48) Translator(lsb,comp,7,8,56)
FixedData=ff 00 ff 00 ff 00 ff 00
CmdParms=OBC:8=0,Dev.Sub:0|1|2|3,NStyle :NEC1|NEC2|NECx1|NECx2=0,YStyle :NEC*|Y1|Y2|Y3=1
CmdTranslator=Translator(lsb,comp,0,8,0) Translator(1,2,8) Translator(2,1,11,1) Translator(2,1,15) \
Translator(3,1,13,1) Translator(3,1,14)
CmdParmInit=PickInitializer(1,N0.1,N2.3,N4.5,N6.7)
ImportCmdTranslator=Translator(0,2,8,0,-1) NECStyleImporter(1) YamahaStyleImporter(2)
DefaultCmd=00 20
CmdIndex=0
Notes=Similar to NEC 4 DEV Combo, but can send Yamaha signals with 16 bits of data.\n\
NStyle selects among NEC1, NEC2, NECx1, and NECx2.\n\
YStyle selects among the following:\n\
NEC* sends the ordinary NEC signals (specified by NStyle) in which the second byte of data is the complement of the first byte.\n\
The two bytes of data always add to 255, which is standard for NEC signals. Normally only the first byte is specified.\n\
Y1: sends NEC signals except the sum of the two bytes is 127. Yamaha specifes both bytes. \n\
Y2: sum is 254 or 256.\n\
Y3: sum is 126 or 128.
Code.S3C80=43 8B 82 8B 14 CF 44 08 08 01 18 01 06 01 18 03 39 D2 DC 11 94 08 B6 08 CA E6 10 02 08 0C 18 C0 \
56 C1 C0 F0 C1 E0 C1 06 C1 03 93 C1 03 E5 C1 04 E4 0B 05 E4 0B 06 60 06 37 02 03 B6 06 01 37 04 03 B6 06 80 \
37 06 05 F6 01 04 7B 09 37 09 0C 37 01 03 46 29 0D 46 29 01 8D 01 49 C4 22 1E 37 01 EE F6 01 49 E6 28 C1 60 \
03 E6 12 01 8B E7
Code.HCS08=20 17 22 47 82 CF 44 08 08 01 17 01 1A 01 17 03 4D D2 F0 11 93 08 CA 08 C9 B6 69 B7 56 A4 C0 62 44 \
97 8C 9E CE 60 35 60 6E 02 A9 B6 68 B7 62 43 B7 63 03 56 04 A8 01 B7 63 07 56 05 CD FF 8F 25 0A 08 56 0C 00 56 \
04 14 A3 16 A3 10 A3 CC FF 5C 55 7A 35 76 00 56 ED CD FF 5C 6E C1 A2 33 60 6E 01 6A 20 E7


The NEC 4 DEV Combo correct line is ImportCmdTranslator=Translator(0,2,8,0,-1) NECStyleImporter(1). The added part is bolded. (KM uses 1 based indices, and RM uses 0 based.)

[3FG]

I have added NEC-Yamaha.zip to the RM protocols file section.

It includes the add-in for protocols.ini and YamahaStyleImporter.class. The class file is necessary to import KM files using the NEC 4DEV Yamaha protocol executor.

[mathdon]

I have posted here, for testing, a zip file containing

(1) a revised version of RemoteMaster.jar, v2.00 preview 8a, which adds to preview 8 the YahamaStyleImporter class and the correction to DeviceUpgrade.java described here, and

(2) a revised protocols.ini containing the NEC 4DEV Yamaha Combo entry (and correction to the NEC 4DEV Combo entry itself).

I have not yet posted these changes/additions to SourceForge as I think they should be tested first. Also, I wonder if there is a naming issue. YamahaStyleImporter has the structure of a translator, not an importer. Would it be better to re-name it YamahaStyleTranslator (with a corresponding change in protocols.ini, of course)?

Edit: Forget the last part about the name. I see that NECStyleImporter is also a translator.

[The Robman]

Thanks Dave and Graham, I just loaded the files to test them. I notice that the YStyle column defaults to Y1, I think it would be much better if it defaults to the standard NEC format as, even for a Yamaha receiver, most signals are still going to use the NEC format. So I would propose making the following change to protocols.ini:

I would change this...
YStyle :none|Y1|Y2|Y3=1

to this...
YStyle :NEC|Y1|Y2|Y3=0

Any thoughts?

[3FG]

Rob, that's OK with me. I vacillated about it, and if you look at my earlier post in this thread, instead of "none" I had put "NEC*".

I agree that the default choice should be 0.

I still prefer "none" to "NEC", because it seems to me that a NEC style column with typically "NEC1" displayed followed by a repeated "NEC" is confusing. In my early use of these tools I found the usage NEC1 versus NEC2 versus the generic term NEC to be quite confusing.

[mathdon]

Dave, could you please test my upload with a KM import with a full 4 devices in the NEC 4DEV Combo or the Yamaha variant, as in this post of yours it seems to be just a supposition that your suggested correction will resolve the issue. I am concerned in case there is some other place that the number is hard-wired and also needs changing, so don't want to post it to SourceForge until it is tested.

[3FG]

Yes, that was a supposition on my part. Anyway, your upload does work to import all 4 devices from a KM file.

We do need to change the behavior in the Yamaha variant executor so that YStyle defaults to 0. I found that KM allows the user to not specify byte 2, in which case the KM flle has an empty entry for device index and Style. Both KM and RM interpret that empty entry to mean the first device and NEC1. RM will also assign the default index for YStyle. Using 1 as the default means KM and RM would give different results.

So defaulting to 0 is not only better from a UI point of view, it is necessary to avoid a bug.

[mathdon]

We do need to change the behavior in the Yamaha variant executor so that YStyle defaults to 0.

Does that mean go ahead with Rob's suggestion of

YStyle :NEC|Y1|Y2|Y3=0

or is it still open as to whether that "NEC" should be "none" or "NEC*"? It would be nice to have the issue settled quickly, as it seems to be the only remaining issue concerning RMIR 2.00.

[The Robman]

My vote would be to use NEC over None, but I'll go along with the majority if the consensus is otherwise.

[3FG]

YStyle :NEC|Y1|Y2|Y3=0 is fine.