JP1 Remotes

mdavej · Expert Joined: 08 Oct 2003 Posts: 4501

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 · Joined: 05 Jul 2012 Posts: 86

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!

3FG · Expert Joined: 19 May 2009 Posts: 3367

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.

The Robman · 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!

Zibri · Joined: 05 Jul 2012 Posts: 86

This is the protocol executor.

The Robman · Posted: Mon Jul 09, 2012 10:07 pm Post subject:

Here's the executor code with some commentary

3FG · Expert Joined: 19 May 2009 Posts: 3367

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.

mathdon · 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

The Robman · 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!

mdavej · Expert Joined: 08 Oct 2003 Posts: 4501

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

The Robman · 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!

3FG · Expert Joined: 19 May 2009 Posts: 3367

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.

The Robman · 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!

mathdon · Posted: Tue Dec 15, 2015 6:36 pm Post subject:

The Robman · Posted: Tue Dec 15, 2015 7:26 pm Post subject: