JP1 Remotes

DecodeIR source code can be found here:
http://www.hifi-remote.com/forums/dload ... le_id=8458

DLL file is here:
http://www.hifi-remote.com/forums/dload ... le_id=8625

1) Amino vs. Zaptor protocols

It appears that we need to change the tolerances between the Amino and Zaptor protocols in DecodeIR because some Amino learns are showing up as Zaptor. The learns in question have a much lower carrier frequency than we would normally expect for Amino signals (41.4kHz rather than 55.6 kHz) which is obviously why they decoded as Zaptor as it's a lot closer to the Zaptor frequency of 36.3 kHz.

The new learns were for an Amino 125 set top box. I don't know why these learns showed up with a 41.4 carrier frequency, but the user tried a conventional Amino upgrade (with the 55.6 freq) and it worked.

Therefore, I would like to see a much wider tolerance given to the carrier frequency.

As to the question of how to differentiate between Zaptor and Amino, I think you can use the following:

• The high nibble of the checksum for Amino signals is always all ONEs.
• Amino signals toggle bit2 of byte1 with each frame.
• Zaptor signals toggle bit7 of byte2, but only on the final frame

Here's the thread where the Amino protocol was discussed:
http://www.hifi-remote.com/forums/viewtopic.php?t=5512

Here's the thread where the Zaptor protocol was discussed:
http://www.hifi-remote.com/forums/viewtopic.php?t=12520

And here's the thread where the Amino 125 STB was discussed:
http://www.hifi-remote.com/forums/viewtopic.php?t=12503

Here's a sample of the 36 kHz Zaptor signal:

0 = -330 +330
1 = +330 -330

+2640 -1980; +660; 00010000 00000000 01111000 01010101 -73920; (repeats)
+2640 -1980; +660; 00010000 10000000 01111000 01011101 -73920; (sent at end)

Here's a sample of the 55.6 kHz Amino protocol:

0 = -270 +270
1 = +270 -270

+1890; -1620 +810; 00001101 00000000 00000010 11111110 -77760
+1890; -1620 +810; 00001001 00000000 00000010 11111010 -77760

Here's a sample of the 41.5 kHz Amino signal:

0 = -270 +270
1 = +270 -270

+1890; -1620 +810; 00001101 00000000 00000001 11111101 -78300;
+1890; -1620 +810; 00001001 00000000 00000001 11111001 -78300;

2) Streamzap protocol
It appears that we have the bit breakdown wrong for this one. Details here:
http://www.hifi-remote.com/forums/viewt ... 2000#92000

3) Thomson protocol
I would like to re-define this protocol to use a 5-7 split. I will fix all the upgrades, KM and RM if DecodeIR is updated.

Recent example of the problem:
http://www.hifi-remote.com/forums/viewt ... 1076#91076

Original thread where this was discussed:
http://www.hifi-remote.com/forums/viewtopic.php?t=10540

4) NEC Yamaha signals
Original request here:
http://www.hifi-remote.com/forums/viewtopic.php?t=12428

For Thomson and StreamZap, in order to implement a different division of bits between device and OBC, don't we need a revised executor? Seems to me that the executor would use the wrong number of bits from the fixed data and the OBC data. I guess it depends on how the executor combines the two bytes of data into 12 or 13 bits of IR stream, but I would have probably explicitly masked the unused bits.

My general thinking at this point is to define two new protocol entries in protocols.ini called Thomson-7F and RC5-8F. I think this would avoid confusion. It probably wouldn't be necessary to retain the old entries. One concern I have is if a person used an old version of Thomson.irp in MakeHex to make Pronto Hex. Not too important to JP1 users but the names and conventions we use for IR protocols do get spread around.

However, I notice that the StreamZap upgrades don't load into RM, because it is spelled Streamzap in the current version of protocols.ini. I'm guessing that there's not a lot of call for StreamZap or Thomson....

3FG wrote:For Thomson and StreamZap, in order to implement a different division of bits between device and OBC, don't we need a revised executor?

The current versions of both executors already use a 5-7 split, but the original versions used a 6-6 split, which is why the JP1 tools were set up that way.