JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Add protocol 01 B5 (Samsung36?) to RM/KM?
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - General Forum
View previous topic :: View next topic  
Author Message
mdavej
Expert


Joined: 08 Oct 2003
Posts: 3751

PostPosted: Mon Jul 09, 2012 2:20 pm    Post subject: Reply with quote

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
View user's profile Send private message
Zibri



Joined: 05 Jul 2012
Posts: 86

PostPosted: Mon Jul 09, 2012 2:29 pm    Post subject: Reply with quote

No need to go trial and error Smile

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
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3240

PostPosted: Mon Jul 09, 2012 3:24 pm    Post subject: Reply with quote

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
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18406
Location: Chicago, IL

PostPosted: Mon Jul 09, 2012 4:14 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Zibri



Joined: 05 Jul 2012
Posts: 86

PostPosted: Mon Jul 09, 2012 6:57 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18406
Location: Chicago, IL

PostPosted: Mon Jul 09, 2012 10:07 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3240

PostPosted: Tue Jul 10, 2012 12:31 am    Post subject: Reply with quote

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
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 2948
Location: Cambridge, UK

PostPosted: Tue Dec 15, 2015 12:34 pm    Post subject: Reply with quote

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
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18406
Location: Chicago, IL

PostPosted: Tue Dec 15, 2015 2:02 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
mdavej
Expert


Joined: 08 Oct 2003
Posts: 3751

PostPosted: Tue Dec 15, 2015 3:50 pm    Post subject: Reply with quote

You could just shoot DVD 0199 from one remote to another.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18406
Location: Chicago, IL

PostPosted: Tue Dec 15, 2015 3:51 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3240

PostPosted: Tue Dec 15, 2015 4:07 pm    Post subject: Reply with quote

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
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18406
Location: Chicago, IL

PostPosted: Tue Dec 15, 2015 4:43 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 2948
Location: Cambridge, UK

PostPosted: Tue Dec 15, 2015 6:36 pm    Post subject: Reply with quote

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
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18406
Location: Chicago, IL

PostPosted: Tue Dec 15, 2015 7:26 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - General Forum All times are GMT - 5 Hours
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
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
Get Smart! the band's official homepage Rockabilly Central