Page 4 of 5
Posted: Sat Aug 28, 2010 5:50 am
by alanrichey
OK, that's odd. It shows that Rob's no-repeat works but does anyone know why changing to NEC2 (that was the only change in V2010) or using Rob's NEC1 (No-repeat) should screw up just the Custom button codes ?
For vicky: There is nothing special about the cusotm codes, they are just buttons that are not available on the virtual remote but can be accessed via a menu.
Posted: Sat Aug 28, 2010 6:27 am
by vickyg2003
alanrichey wrote:OK, that's odd. It shows that Rob's no-repeat works but does anyone know why changing to NEC2 (that was the only change in V2010) or using Rob's NEC1 (No-repeat) should screw up just the Custom button codes ?
That often happens when you change remotes. The buttons get reassigned. I'd look at the RDMU to make sure the buttons are assigned correctly.
RDF errors, or RM version might also have to be considered if the RDMU looks right.
For vicky: There is nothing special about the cusotm codes, they are just buttons that are not available on the virtual remote but can be accessed via a menu.
Yes, I've been reading and looking at the pictures and see all sorts of buttons like c12 and c13, but I can't find them when looking at the RDMU.
Posted: Sat Aug 28, 2010 6:38 am
by alanrichey
vickyg2003 wrote:The buttons get reassigned. I'd look at the RDMU to make sure the buttons are assigned correctly. RDF errors, or RM version might also have to be considered if the RDMU looks right.
Afraid not. We didn't change Remotes and we didn't change any button assignments. The ONLY thing we did was change the IR Protocol in the Setup Tab from NEC1 to Rob's 'special'.
Posted: Sat Aug 28, 2010 7:10 am
by vickyg2003
alanrichey wrote:vickyg2003 wrote:The buttons get reassigned. I'd look at the RDMU to make sure the buttons are assigned correctly. RDF errors, or RM version might also have to be considered if the RDMU looks right.
Afraid not. We didn't change Remotes and we didn't change any button assignments. The ONLY thing we did was change the IR Protocol in the Setup Tab from NEC1 to Rob's 'special'.
But your user also said that things had changed for the NEC2 protocol. So if that is true, then the protocol upgrade shouldn't be the source of the problem.
An RDF problem or a version change in RM needs to be explored too.
Posted: Sat Aug 28, 2010 7:41 am
by alanrichey
OK, I don't understand the NEC2 as I did that, but I now see that Rob used a different RMDU file than me.
So let's try some consistency
https://www.hifi-remote.com/forums/dload ... le_id=8846
Now has what I think is the fully working V2010 from the File section, but with repeats and V2011 with the 'no repeat' Protocol but everything else identical.
Rodge: What does that give you ?
Posted: Sat Aug 28, 2010 8:07 am
by vickyg2003
One more thing to consider. Have Rodge check out to see if there is a signal coming out of the IR Blaster when using the custom codes buttons. It could be that those particular functions NEED a repeat.
Posted: Sat Aug 28, 2010 11:07 am
by Rodge
V2010, still does the repeats.
The new V2011 seems to be working perfectly now!! Unless you guys want me to try anything else, I think we're golden.
Thanks for all your help.
Rodge
Posted: Sat Aug 28, 2010 2:05 pm
by alanrichey
OK, glad we are there now. That 2nd V2011 used Rob's 'no repeat' IR Protocol and I made sure all the button assignments were identical. So the previous one was just finger trouble.
Right, obviously I am happy as I can use that RMDU file as a template if other people get the 'double skipping', but it would be nice if we could formalise it in PROTOCOLS.INI as a new protocol, maybe just called NEC1 (Slingbox), explaining in the notes that it does not repeat ?
Or is that a step too far ?
Al
Posted: Sat Aug 28, 2010 3:00 pm
by eferz
alanrichey wrote:Right, obviously I am happy as I can use that RMDU file as a template if other people get the 'double skipping', but it would be nice if we could formalise it in PROTOCOLS.INI as a new protocol, maybe just called NEC1 (Slingbox), explaining in the notes that it does not repeat
What would be super fantastic awesome, is if RM was updated in a way that it did those calculations internally, as opposed to having to use protocol builder. Maybe including a [Repeat] subsection with the RDFs, so that RM can present a protocol parameter option.
That way we wouldn't need a separate RDF for every protocol just for the Slingbox. And other remote users may be able to benefit from it as well.
Just my 2 copper anyhow.
Posted: Tue Aug 31, 2010 3:50 am
by alanrichey
The new protocol proved itself again at
http://answers.slingbox.com/message/18783#18783
Be nice if it was formalised
Posted: Tue Aug 31, 2010 6:23 pm
by eferz
vickyg2003 wrote:Yes, I've been reading and looking at the pictures and see all sorts of buttons like c12 and c13, but I can't find them when looking at the RDMU.
I believe you're probably looking at is Alan's custom skin for SlingRemote. In his skin the remote buttons C10 through C17, correspond with "Custom 10" through "Custom 17" in the Slingbox's RDF's (BINJU, BINPK, BINRV, and BINPL) which is used to build the default buttons of the RMDU file. We've documented 106 realistic skins provided by Sling Media on this wiki page (
http://slingbox.wikia.com/wiki/Skin.toc).
Here is an excerpt of the xml files which define the keymaps on three remote skins; default, alan, and sa8300.
Code: Select all
Default Remote:
<map key="062" cmd="id.remote.custom.10" name="Custom10" category="Custom"/>
Alan's Remote:
<map key="062" cmd="id.remote.custom.10" name="Custom10" category="Custom"/>
SA8300 Remote:
<map key="062" cmd="id.remote.a" name="A" category="Misc" shortcut="Ctrl+Shift+A"/>
And this is how they appear in each skin.
Uploaded with
ImageShack.us
In the default skin, the button isn't represent on the skin's graphic. So, the user has to go through the menu options to initiate key "062"
On Alan's Custom Skin, remote key "062" is represented as "C10" button.
With the SA8300 skin, Key "062" is represented as "A" button.
eferz wrote:alanrichey wrote:Right, obviously I am happy as I can use that RMDU file as a template if other people get the 'double skipping', but it would be nice if we could formalise it in PROTOCOLS.INI as a new protocol, maybe just called NEC1 (Slingbox), explaining in the notes that it does not repeat
What would be super fantastic awesome, is if RM was updated in a way that it did those calculations internally, as opposed to having to use protocol builder. Maybe including a [Repeat] subsection with the RDFs, so that RM can present a protocol parameter option.
That way we wouldn't need a separate RDF for every protocol just for the Slingbox. And other remote users may be able to benefit from it as well.
Just my 2 copper anyhow.
I just realized after answering Vicki, that I was confusing RDF's with the "protocol.ini" files. How come nobody corrected me?
Posted: Tue Aug 31, 2010 8:03 pm
by vickyg2003
Well there is a lot to correct. Even the protocols.ini can't control the repeats. Sure it can serve up a non prepeating NEC1 protocol, if someone writes one, but that requires someone go in to PB and create a non repeating protocol and and add it to the protocols.ini. Somehow you got the idea that we could bypass PB, and as far as I know that's not going to happen. Each protocol is different. Some have a piece of code that sets the ROD register to the minimum number of repeats, but more often than not, there are complex workings that control the number of repeats.
Posted: Tue Aug 31, 2010 8:18 pm
by alanrichey
Accepting all of that, but when I look at my statistics of the Remotes I have built, 150 of the 250 or so of the proven remotes I have produced have used the NEC1 protocol, and apart from my Sky Box, all the 'double skips' have been NEC1. So just adding a single new protocol of NEC1 (Slingbox) would seem to be a useful addition.
Meanwhile I will continue using Rob's template
Posted: Tue Aug 31, 2010 11:46 pm
by eferz
vickyg2003 wrote:Well there is a lot to correct. Even the protocols.ini can't control the repeats. Sure it can serve up a non prepeating NEC1 protocol, if someone writes one, but that requires someone go in to PB and create a non repeating protocol and and add it to the protocols.ini. Somehow you got the idea that we could bypass PB, and as far as I know that's not going to happen. Each protocol is different. Some have a piece of code that sets the ROD register to the minimum number of repeats, but more often than not, there are complex workings that control the number of repeats.
I do appreciate being corrected. While learning this stuff as I go, I need to be kicked in the tookus from time to time when I'm wrong. If not I'm just going to continue thinking otherwise.
My only excuse is letting the simplicity of disabling repeats get head of me from the process which was taught in the
Repeat function in Protocols thread. The tools which make it possible lead me to believe it would be an simple request for RM to be able to turn off the "
RptHeld" bit if its represented within
FF06 address. After all, subtracting a single bit from two bytes doesn't seem difficult.
However, that's where my own ignorance got the best of me. Probably why I got the functionality of the protocol.ini and RDFs a bit mixed up in my head. I should have reviewed the NEC protocols before opening my big mouth. Then I would have realized that the Protocol Upgrade Code doesn't even show up in RM for any NEC protocol.
My one question earlier in this thread remains unanswered though. Since Rob created the Protocol Upgrade Code, is there a way to save it into my own protocol.ini file or do I have to always use that RMDU template to avoid NEC1 repeats.
Code: Select all
Upgrade protocol 0 = 01 FF (S3C80) Manual Settings (RM v1.98)
44 8C 11 8B 12 E5 4C 08 08 01 21 01 06 01 21 03
31 D4 FD 11 A7 08 B7 8D 01 46
End
Orginally, I thought maybe I could just copy "
[pid: 01 FF]" section then rename it to
[NEC1 NR] and just append the hexcodes above to "
Code.S3C80=". However,
[pid: 01 FF] doesn't seem to be in the protocol.ini file.
On another note, I've been trying to field your questions about Slingbox to help you understand it better. I'm not sure if I've been helpful in clarifying, unhelpful in confusing, or if I'm just outright annoying you. Alan has warned me in multiple occasions that my explanations are way too complicated. So, I'm starting to fear because you haven't respond to any of those posts that its either the middle or latter option. I apologize if that's the case.
Posted: Wed Sep 01, 2010 6:19 am
by The Robman
You certainly can add my non-repeating NEC protocol to protocols.ini if you like.
