View previous topic :: View next topic |
Author |
Message |
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21211 Location: Chicago, IL |
Posted: Tue Sep 07, 2010 1:13 pm Post subject: DecodeIR update requests |
|
|
DecodeIR source code can be found here:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=8458
DLL file is here:
http://www.hifi-remote.com/forums/dload.php?action=file&file_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; _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Last edited by The Robman on Fri Oct 08, 2010 9:35 am; edited 1 time in total |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21211 Location: Chicago, IL |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21211 Location: Chicago, IL |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21211 Location: Chicago, IL |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3365
|
Posted: Sat Dec 11, 2010 5:40 am Post subject: |
|
|
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.... |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21211 Location: Chicago, IL |
Posted: Sat Dec 11, 2010 6:07 am Post subject: |
|
|
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. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
|