Repeat function in Protocols

[alanrichey]

Once again the subject of double-skipping has come up on the official Slingbox support forum, and I feel for these people as I suffer this problem myself with double-skipping on the Up arrow on my Sky box.

I know I should get into Protocol Builder to figure it out myself, but I just haven't had the time recently. In the forum 'eferz' has suggested we might be able to manually edit our own copy of protocol.ini to change the number of repeats for a specific protocol.

My own interest as a test case is the RC6-m-20n protocol which is the one used by my Sky box. Is there a manual edit I could do, changing a byte or two, to reduce the number of repeats ?

[The Robman]

I think there's a Slingbox control file that actually controls this.

When the Slingbox calls an executor, it calls it in the same fashion as when a macro calls it, which means the repeat count is set to 2. You can override this in the executor by setting R0D to 1 (ie, LD R0D,#02h).

[alanrichey]

Sorry Rob, I have no idea what an executor is so your second sentence means nothing to me I'm afraid.

And do you mean that there is a control file on each PC ? I am not sure how that would work as this problem is the identical on the Slingplayer program and also on the web-based player and all the files for those are in totally different places, there is no common ground.

[The Robman]

If you don't know what an executor is, I don't think you'll be able to tweak the executor in Protocol Builder.

[alanrichey]

Fair enough. As I said in the post, I was hoping I could just alter a byte in the protocols.ini entry.

Never mind.

[The Robman]

You would ultimately alter some of the code in protocols.ini, but the question is knowing which code to change and what to change it to, that's what I was trying to describe, and your previous post gave me the impression that you knew what a protocol executor was, because you mentioned Protocol Builder. After all, that's Protocol Builder's only purpose.

In other words, you would need to have the executor in question loaded into PB, then you would add the command that I gave you. Actually, now that I think about it, there's an even simpler way. As the Slingplayer remotes don't try to simulate holding a button down, there's no need for Slingbox executors to repeat at all, so we could just turn off the repeat feature. There is a single bit in the data block of most executors that controls this, but for some of the more complicated executors, it would still need to be changed in the code.

Perhaps if you give an example of a protocol that you want to stop repeating, I can make the change for you and show you how I did it, so you could do it in future.

[alanrichey]

...your previous post gave me the impression that you knew what a protocol executor was, because you mentioned Protocol Builder.

I actually said I hadn't got into Protocol Builder

Perhaps if you give an example of a protocol that you want to stop repeating, I can make the change for you and show you how I did it, so you could do it in future.

As I said on the original post: "My own interest as a test case is the RC6-m-20n protocol "

Al

[The Robman]

...your previous post gave me the impression that you knew what a protocol executor was, because you mentioned Protocol Builder.

I actually said I hadn't got into Protocol Builder

Right, but you at least knew what it was. What threw me was your next post where you said you didn't know what an executor is, as an executor is what you create using Protocol Builder. I was getting mixed messages as to your knowledge level on this, which was making it hard to pitch my responses at the right level.

[alanrichey]

Assume no knowledge beyond Remotemaster

[eferz]

I thought I'd play around with it after reading some older threads.

https://www.hifi-remote.com/forums/viewtopic.php?t=12302

Except that this one has gone past my personal knowledge base I keep telling people that with RM-produced Custom Remotes we have no control over the repeat function as this is fixed. So they (and me) have to live with 'double skipping'.

But I know you have 'tweaked' protocols to change the repeat settings, is it something I could learn how to do ?

Sometimes its as simple as changing a number, in a box labeled Repeats, other times it takes assembly language work.

https://www.hifi-remote.com/forums/viewtopic.php?t=11061

Did you use protocol builder ? Could you please explain ? I didn't see any reference to custom protocols from any Slingbox tutorials so far.

This isn't in the tutorials because it's not something a regular user should be expected to do.

Basically, I cut and paste the protocol (which I wrote, btw) from your RM file into PB (protocol builder) and then switched off the repeating feature. Then, I had to re-create the entire upgrade in KM because I don't think there's a way to start a "manual settings" upgrade in RM. Then I imported it back into RM.

The OBCs are different but the EFCs and the hex codes are the same, which is all that's important.

So, I opened up Remote Master, selected "RC6-M-20n" then clicked on the "Output" tab and pushed on the "Copy to Clipboard" button in the Upgrade Protocol Code section



Uploaded with ImageShack.us

Then I went into protocol builder and pasted the Protocol Code into the Decode box, clicked on Decode. I see there's a few options available to me in the Repeat subsection.



Uploaded with ImageShack.us

However at this point I'm not sure what to do. Should I make changes in the repeat section, save the project, open the file it inside of Keymap Master, copy the clipboard, then open Remote Master to Import from Clipboard?

I'm even less knowledgeable about this stuff but I'm at least I'm willing to tinker. My daddy always used to say, "You can't get answer to questions that you don't ask. And you don't know which questions to ask until you get involved."

[The Robman]

You need to also look at the Disassembly tab to see what assembler code is being used. This protocol executor's an odd one because as far as I can tell, it doesn't repeat. The first thing I look for is the rightmost bit of pf1, if it's set it repeats, if it's clear (which it is in this case) it doesn't repeat. Next I look in the code to see if it gets set there (the pf1 register is R29) and in this case it isn't. I also look to see if the signal is created in the normal way (ie, by calling $0133 or $0146) or if it's hand crafted, and in this case it's sent in the normal way.

So, bottom line, as far as I can see this signal doesn't repeat, so I must be missing something.

[eferz]

Okay, I took the liberty of taking a screenshot of the disassembly tab.



Uploaded with ImageShack.us

I circled in green the line which I believe you're referring. However, looking at the byte in the comment "0000 0101" it looks like the last bit is on. Or am I looking at the wrong values?

[The Robman]

No, you're right, in your version of the executor it is indeed turned on. Which remote did you have selected in RM when you selected "RC6-M-20n"?

So, if you change that byte so that the right most bit is clear, you will have a non-repeating protocol.

Now normally, you would just have to copy the new executor to your remote, but as you're looking to program the Slingbox, you would need to make the change to the data in protocols.ini instead.

Here's the code in protocols.ini:

Code.S3C80=47 93 61 8B 12 87 05 08 04 00 DE 00 00 00 00 00 \
CA D4 44 05 35 01 A8 0C 0A 18 07 02 11 10 08 10 \
07 10 09 10 C1 1E 10 08 10 07 0A EF 19 09 8D 01 \
46

The byte colored red needs to change to 04.

[eferz]

I selected "Slingbox with UEI PL Chip" for the remote in RM. (top most screenshot for clarification)

[eferz]

Now normally, you would just have to copy the new executor to your remote, but as you're looking to program the Slingbox, you would need to make the change to the data in protocols.ini instead.

Here's the code in protocols.ini:

Code.S3C80=47 93 61 8B 12 87 05 08 04 00 DE 00 00 00 00 00 \
CA D4 44 05 35 01 A8 0C 0A 18 07 02 11 10 08 10 \
07 10 09 10 C1 1E 10 08 10 07 0A EF 19 09 8D 01 \
46

The byte colored red needs to change to 04.

Well, thank you, Rob! That makes perfect sense. I honestly, don't see what the big fuss was all about. It certainly did seem more frightening than it actually is. Though that's just one of many protocols isn't it? I'm sure there's others that aren't quite as friendly.

Now that I juxtapose the "Disassembly" tab of Protocol Builder with the code in the "protocols.ini" file, I see that each line of code in protocol builder is just concatenated in the "protocols.ini". And since I know how to add and subtract in binary, I understand that clearing the last bit in 05h = 101b = 4+0+1(-1) = 100b = 04h.

Thanks again, I appreciate the walk through.