Add protocol 01 B5 (Samsung36?) to RM/KM?

mdavej · Post by **mdavej** » Mon Jul 09, 2012 1:20 pm

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.

Zibri · Post by **Zibri** » Mon Jul 09, 2012 1:29 pm

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!

3FG · Post by **3FG** » Mon Jul 09, 2012 2:24 pm

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.

Post by **The Robman** » Mon Jul 09, 2012 3:14 pm

If you know how to read S3C8 assembler, checking the protocol executor should tell you how it works.

Zibri · Post by **Zibri** » Mon Jul 09, 2012 5:57 pm

This is the protocol executor.

Code: Select all

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.

Post by **The Robman** » Mon Jul 09, 2012 9:07 pm

Here's the executor code with some commentary

Code: Select all

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.

3FG · Post by **3FG** » Mon Jul 09, 2012 11:31 pm

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.

Post by **mathdon** » Tue Dec 15, 2015 11:34 am

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: Select all

{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.

Post by **The Robman** » Tue Dec 15, 2015 1:02 pm

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.

mdavej · Post by **mdavej** » Tue Dec 15, 2015 2:50 pm

You could just shoot DVD 0199 from one remote to another.

Post by **The Robman** » Tue Dec 15, 2015 2:51 pm

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.

3FG · Post by **3FG** » Tue Dec 15, 2015 3:07 pm

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.

Post by **The Robman** » Tue Dec 15, 2015 3:43 pm

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.

Post by **mathdon** » Tue Dec 15, 2015 5:36 pm

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.

Post by **The Robman** » Tue Dec 15, 2015 6:26 pm

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.