|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
mdavej Expert
Joined: 08 Oct 2003 Posts: 4523
|
Posted: Mon Jul 09, 2012 2:20 pm Post subject: |
|
|
Sorry for the confusion.
1195 is: 0C 58 00 device = 48 subdevice = 26 e = 0
0199 is: 04 00 E0 device= 32 subdevice = 0 e = 7
Most of our samsung upgrades have E = 7 which corresponds to E0 in the fixed data. That parameter seems to just be a nybble. So E1 doesn't make any sense. If you are really seeing E1, then perhaps the lower nybble is ignored.
I got them by trial and error. RM calculates the fixed data from the device/subdevice/e parameters. RM has an algorithm, but I don't know what it is. It's documented in the DeviceTranslator line in the second post of this thread. I don't know what it means, but I'm sure several others here could explain it. |
|
Back to top |
|
|
Zibri
Joined: 05 Jul 2012 Posts: 86
|
Posted: Mon Jul 09, 2012 2:29 pm Post subject: |
|
|
No need to go trial and error
0x0c inverted is 0x30 which is 48
0x58 inverted is 0x1a which is 26
got it now?
now, E0 inverted is 7, but E1 inverted is: 0x87 which is 135! |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3371
|
Posted: Mon Jul 09, 2012 3:24 pm Post subject: |
|
|
The translation given in protocols.ini reverses the bits for the first two fixed bytes, but only translates one nibble of the the E parameter. I'm not sure why it was setup that way, but it will ignore the 1 in E1.
I'll try to understand this better, and perhaps modify protocols.ini. There's also a small chance that 2 variants of the executor exist.
Zibri, would you mind uploading the WAV file? That may help me understand better. |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21279 Location: Chicago, IL |
Posted: Mon Jul 09, 2012 4:14 pm Post subject: |
|
|
If you know how to read S3C8 assembler, checking the protocol executor should tell you how it works. _________________ 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 |
|
|
Zibri
Joined: 05 Jul 2012 Posts: 86
|
Posted: Mon Jul 09, 2012 6:57 pm Post subject: |
|
|
This is the protocol executor. Code: | 43 8C 31 8B 12 8F 45 08 04 00 FA 02 CD 00 FA 00
E5 77 6F 08 CF 08 B4 E4 06 07 60 07 F0 05 0C 04
10 07 10 06 10 05 0A F8 20 10 E6 25 11 8D 01 61
FF00: 43 8C DB 43H, 8CH
FF02: 31 DB 31H
FF03: 8B 12 JR FF17H
FF05: 8F 45 DB 8FH, 45H
FF07: 08 04 DB 08H, 04H
FF09: 00 FA DW 00FAH
FF0B: 02 CD DW 02CDH
FF0D: 00 FA DW 00FAH
FF0F: 00 E5 DW 00E5H
FF11: 77 6F DW 776FH
FF13: 08 CF DW 08CFH
FF15: 08 B4 DW 08B4H
FF17: E4 06 07 LD R07, R06
FF1A: 60 07 COM R07
FF1C: F0 05 SWAP R05
FF1E: 0C 04 LD RC0, #04H
FF20: 10 07 RLC R07
FF22: 10 06 RLC R06
FF24: 10 05 RLC R05
FF26: 0A F8 DJNZ RC0, FF20H
FF28: 20 10 INC R10
FF2A: E6 25 11 LD R25, #11H
FF2D: 8D 01 61 JP 0161H |
I see no differences with other executors for 01b5.
And this is the wav upgrade file for 0199 and 1195 and with 01b5: https://cdn.anonfiles.com/1341878275596.zip
By the way I cross checked 0199 generated a "pronto hex code" and set it up as a macro and it worked as supposed to.
I'll try with 1195 tomorrow but I don't feel positive about it. |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21279 Location: Chicago, IL |
Posted: Mon Jul 09, 2012 10:07 pm Post subject: |
|
|
Here's the executor code with some commentary Code: | Upgrade protocol 0 = 01 B5 (S3C8+)
43 8C 31 8B 12 8F 45 08 04 00 FA 02 CD 00 FA 00
E5 77 6F 08 CF 08 B4 E4 06 07 60 07 F0 05 0C 04
10 07 10 06 10 05 0A F8 20 10 E6 25 11 8D 01 61
End
FF00: 43 8C DB 43H, 8CH - 38kHz
FF02: 31 DB 31H - 3 fixed, 1 variable
FF03: 8B 12 JR FF17H - jump to start
FF05: 8F DB 8FH - ;pf0: 10001111=devs,cmds,dev-cmd
FF06: 45 DB 45H - ;pf1: 01000101=RptHeld,LI-same,1on-LO
FF07: 08 DB 08H - ;pd00: DevBits1=8
FF08: 04 DB 04H - ;pd01: CmdBits1=4
FF09: 00 FA DW 00FAh - ;pd02/03: 1-burst on=500 uS
FF0B: 02 CD DW 02CDh - ;pd04/05: 1-burst off=1474 uS
FF0D: 00 FA DW 00FAh - ;pd06/07: 0-burst on=500 uS
FF0F: 00 E5 DW 00E5h - ;pd08/09: 0-burst off=498 uS
FF11: 77 6F DW 776Fh - ;pd0A/0B: Leadout off=61150 uS
FF13: 08 CF DW 08CFh - ;pd0C/0D: Leadin on=4510 uS
FF15: 08 B4 DW 08B4h - ;pd0E/0F: Leadin off=4496 uS
FF17: E4 06 07 LD R07, R06 - load var1 to var2
FF1A: 60 07 COM R07 - complement var2
FF1C: F0 05 SWAP R05 - swap nibbles in fix3
FF1E: 0C 04 LD W0, #04H - set W0 index to 4
FF20: 10 07 RLC R07 - rotate var2 left thru carry
FF22: 10 06 RLC R06 - rotate var1 left thru carry
FF24: 10 05 RLC R05 - rotate fix3 left thru carry
FF26: 0A F8 DJNZ W0, FF20H - loop back until W0 is zero
FF28: 20 10 INC R10 - increase fixed bytes to 4
FF2A: E6 25 11 LD R25, #11H - position of middle burst
FF2D: 8D 01 61 JP 0161H - send signal with extra burst in middle of sequence (One ON, Lead In OFF) |
Here's the IRP format of this protocol:
{38k,500}<1,-1|1,-3>(9,-9,D:8,S:8,1,-9,E:4,F:8,-68u,~F:8,1,-118)+
So, we have an 8-bit Device code, an 8-bit Sub-device code, a 4-bit Extra code, an 8-bit Function code and it's complement. Plus, there's an extra burst between the sub-device code and the extra code.
The executor code starts off supporting three fixed 8-bit bytes and one 4-bit variable byte, but it increases the fixed bytes to 4 in the code.
The device code is the first fixed byte and the sub-device code is the second fixed byte. The extra code is the first nibble of the third fixed byte. The executor code generates the function code complement and then rotates both bytes into position. The second nibble of the 3rd fixed byte serves n purpose. _________________ 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 |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3371
|
Posted: Tue Jul 10, 2012 12:31 am Post subject: |
|
|
Zibri,
Thanks for the WAV upgrade. As you say, it confirms that the executor is unchanged. So the 1 in E1 is not significant, and no change to protocols.ini is needed. |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4531 Location: Cambridge, UK |
Posted: Tue Dec 15, 2015 12:34 pm Post subject: |
|
|
I see this is an old thread, but I hope this post is still noticed. Rob says the IRP of the Samsung36 protocol is
Code: | {38k,500}<1,-1|1,-3>(9,-9,D:8,S:8,1,-9,E:4,F:8,-68u,~F:8,1,-118)+ |
This is reproduced in DecodeIR.html and in a comment in the source code for DecodeIR.dll. But is that -68u between the OBC and its complement really a misprint? I can't read S3C80 code but I can't see such a value in Rob's executor and experiment with my URC-6440 and a Widget doesn't show it occurring in the MAXQ executor. _________________ Graham |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21279 Location: Chicago, IL |
Posted: Tue Dec 15, 2015 2:02 pm Post subject: |
|
|
Good question. I don't see any mention of it in my commentary of how the signal works either. Do you have any learned captures of a Samsung36 signal? If so, I can examine them. _________________ 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 |
|
|
mdavej Expert
Joined: 08 Oct 2003 Posts: 4523
|
Posted: Tue Dec 15, 2015 3:50 pm Post subject: |
|
|
You could just shoot DVD 0199 from one remote to another. |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21279 Location: Chicago, IL |
Posted: Tue Dec 15, 2015 3:51 pm Post subject: |
|
|
I won't have access to a remote and cable until I get home this evening, so if anyone has the ability to capture the signal before then, go for it. _________________ 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 |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3371
|
Posted: Tue Dec 15, 2015 4:07 pm Post subject: |
|
|
Well, there isn't any point to looking at Setup code 0199; we can look at the S3F80 executor code and see that it doesn't add in the 68uSec.
Searching the forum gives this thread, which I believe is the origin of the IRP as determined by John Fine. It is based on one set of learns which do show the extra 68 uS. However, I see no reason to base the IRP on one set of learns, and I can't imagine that the actual protocol is intended to have this minor difference in off time (566uS versus 498uS). I'd be inclined to doubt either the learns or the OEM remote.
BTW, finding this kind of difference isn't easy. A widget counts the number of IR modulation edges in 100uS time bins, so it will take many captures to build up the statistics to measure the off time interval. A learning remote can measure times more precisely, but they have DC restore issues which make it difficult to measure the timing accurately also. In addition, a learning remote processes and tries to categorize the data into a few discrete intervals before we see it, so the actual distribution of off times is unknown. The OEM remote may have actually had only a minor difference in off time.
If I were trying to really measure this, I'd want several OEM remotes, and an oscilliscope. My recommendation is to just change the IRP. |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21279 Location: Chicago, IL |
Posted: Tue Dec 15, 2015 4:43 pm Post subject: |
|
|
If you follow the posts by KenL there are several more sets of learns and they all show the extra gap, so it's definitely there. However, I looked at the original executor that I created for this, before UEI issued one, and I didn't include it, so I obviously assumed that the signals would work without it. And I even said in my first post that I assumed that it wasn't really needed.
So I guess the question goes back to Graham, what are you looking to do here? I believe the IRP is correct as the learns posted by KenL definitely show the extra gap being present, but our executors don't recreate it, so it's evidently not needed. _________________ 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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4531 Location: Cambridge, UK |
Posted: Tue Dec 15, 2015 6:36 pm Post subject: |
|
|
The Robman wrote: | So I guess the question goes back to Graham, what are you looking to do here? |
Basically I am checking my program, still under development, that aims to convert MAXQ protocols into an easily readable form, consisting of an IRP and a readable set of algorithms for checksums and any other manipulation that is performed by code before passing the data to the IR engine. I am doing so by working through the 100+ executors the program can currently handle and checking them against protocols.ini and DecodeIR.html.
In doing so I have discovered errors not only in my program but also in UEI protocols, in protocols.ini and in DecodeIR.html. The Samsung36 protocol does not have this 68u delay in the MAXQ executor. I asked the question to try to find whether the error was in the executor or in DecodeIR.html.
The conclusion appears to be that we don't know the answer but that it is immaterial whether or not this delay is implemented in an executor. My inclination, therefore, is to make DecodeIR.html consistent with the UEI executors by removing this delay. _________________ Graham |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21279 Location: Chicago, IL |
Posted: Tue Dec 15, 2015 7:26 pm Post subject: |
|
|
mathdon wrote: | In doing so I have discovered errors not only in my program but also in UEI protocols, in protocols.ini and in DecodeIR.html. The Samsung36 protocol does not have this 68u delay in the MAXQ executor. I asked the question to try to find whether the error was in the executor or in DecodeIR.html. |
It sounds like you are performing a very worthy task. I'd like to see your error report, and I'd be happy to let UEI know about their mistakes too, if you like.
mathdon wrote: | The conclusion appears to be that we don't know the answer but that it is immaterial whether or not this delay is implemented in an executor. My inclination, therefore, is to make DecodeIR.html consistent with the UEI executors by removing this delay. |
Yeah, basically, I think the original IRP is technically correct, but it doesn't really matter, so I think modifying everything to not account for the extra delay is the right approach, especially as that's what the executors are doing. _________________ 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 |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|