URC-8060 Extender menu simulation

Nils_Ekberg · Post by **Nils_Ekberg** » Sun Feb 22, 2004 1:59 pm

If you are interested in simulating the unextended remotes animation for the MENU functions the following keymoves can be added to the extender IR image.

Make sure that you did not delete the DSM device and protocol (TV/1103)

TV;Menu;<N/A>;TV;1103;$94 $62 $36 $36 $36
TV;Play;<N/A>;TV;1103;$62 $B1 $36 $36 $36
VCR;Menu;<N/A>;TV;1103;$94 $69 $36 $36
SAT/CBL;Menu;<N/A>;TV;1103;$94 $5B $36 $36
SAT/CBL;Guide;<N/A>;TV;1103;$A5 $5B $36 $36 $36
SAT/CBL;Exit{PVR};<N/A>;TV;1103;$A6 $5B $36 $36 $36

If you do not use a specific device you can leave those keymoves out or you can use these to modify the actions as you like

egn · Post by **egn** » Mon Feb 23, 2004 8:57 am

Hi Nils,

the problem is that with nested menus where exit goes back only one level it jumps back on the remote even one is still in menu mode. So this works only with one level of menus or where exit always leaves menu mode.

I still have to stay on the screen with all keys in order to keep track of everything with my LinuxVDR. LinuxVDR has a multilevel menu system and it would be very hard to track everything. May be something like a level protocol would do the job where you count up and down the levels and can specify commands which are issued when counting from 0 to 1 and back von 1 to 0 or other specific values. With a function that can test against arbitrary values one could implement fairly complex operations.

May be we should define a very simple script language that is implemented with one universel protocol. It should be able to operate on bits, nibbles and bytes. You can define values and use them with simple operations like set, reset, increment, decrement, test, ... With this we would be able to run fairly complex operations with simple key presses.

Just dreaming...

Emil

Nils_Ekberg · Post by **Nils_Ekberg** » Mon Feb 23, 2004 12:25 pm

I am not sure if I am going to spend a lot of time with this capability so I was just providing these as examples of how these DSM could be used to simulate the original remote. You can tailer them anyway you like and for that matter can leave out the ones like the exit if you don't like the way they work.

I do like the idea of what you are suggesting just not sure how something like that could be implemented in limited space but I will look at it

egn · Post by **egn** » Mon Feb 23, 2004 1:05 pm

Hi Nils,

I don't want to press you to do anything. You have already spend a lot of time and made a great extender for the 8060.

This all are just ideas which came to mind and you are free to implement them or not as your time allows. I am playing around with JP1 just about two weeks and see currently two main problems:

1. The tools are all very capable but also very complex in use

2. Even for simple new functionality the extenders must be rewritten

For the 1st point a GUI Tool would be nice that can be used to assign keys and codes easily without knowing much about the hex codes. You simply specify for a key what function tree composed from ToadTog, LKP and other special functions and real key codes are necessary. RM is a first start but it mimics to much the concept behind KM and therefor has the same complexity. The tool I have in mind will reserve necessary phantom keys automatically and setup the keymoves.The final result can be a tool like ProntoEdit which is very easy to use.

The 2nd problem can be solved by implementing a generic extender that operates like a micro-kernel or interpreter. This doesn't mean that Linux should be ported onto a JP1 capable remote.

No, it should be just a simple interpreter with a core of functions allowing to build the currently available special functions and more. You get a lot of flexibility if there is enough keymove memory to hold the program. This interpreter can be ported on all remotes for which enough information is available to build an extender. The advantage would be that the programs would be portable between the different remotes and therefor there is more synergy.

I am doing low level assembler programming with all kind of processors in operating systems more than 20 years for a living. So I have a lot of experience here. My problem is that I have not much free time to spend, otherwise I would look more into implementing some functionality myself.

I don't want to offend anyone how has spend a lot of spare time into this project and with great results. I just want to throw in some ideas to improve JP1 functionality even more.

Cheers,
Emil

Nils_Ekberg · Post by **Nils_Ekberg** » Mon Feb 23, 2004 1:43 pm

egn wrote:This all are just ideas which came to mind and you are free to implement them or not as your time allows. I am playing around with JP1 just about two weeks and see currently two main problems:

egn wrote:1. The tools are all very capable but also very complex in use.

For the 1st point a GUI Tool would be nice that can be used to assign keys and codes easily without knowing much about the hex codes. You simply specify for a key what function tree composed from ToadTog, LKP and other special functions and real key codes are necessary. RM is a first start but it mimics to much the concept behind KM and therefor has the same complexity. The tool I have in mind will reserve necessary phantom keys automatically and setup the keymoves.The final result can be a tool like ProntoEdit which is very easy to use.

In the interim there is another tool that helps with DSM's, ToadTog's, and L/DKP's called ExtenderCodeCalc. This allows you to enter keynames and it generates the keycodes. It also lets you enter any existing keycodes from IR and it decodes them for you. I know, it is still one more seperate tool. There is also someone working on a GUI for special protocols in IR even as we speak.

egn wrote:2. Even for simple new functionality the extenders must be rewritten

The 2nd problem can be solved by implementing a generic extender that operates like a micro-kernel or interpreter. This doesn't mean that Linux should be ported onto a JP1 capable remote. No, it should be just a simple interpreter with a core of functions allowing to build the currently available special functions and more. You get a lot of flexibility if there is enough keymove memory to hold the program. This interpreter can be ported on all remotes for which enough information is available to build an extender. The advantage would be that the programs would be portable between the different remotes and therefor there is more synergy.

Interesting concept. At this point in time all of the extenders are starting to look alike except for the differences in the remotes internals. Adding functionality does not always require a rewrite but does require repackaging. The big issue requireing a rewrite for the Kameleons was going from a hard button remote to managing the backlight and key ilumination. Now going from one Kameleon to the next is pretty easy.

egn wrote:I don't want to offend anyone how has spend a lot of spare time into this project and with great results. I just want to throw in some ideas to improve JP1 functionality even more.

Cheers,
Emil

You will not offend anyone here just remember that all of us are in the same boat. We all have other jobs (mostly IT) and do this as a hobby in our spare time.