JP1 Remotes

I am currently using "8780 8800 9800 extender v2a" posted by gjarboni on a URC-8800B01. I have the extender successfully installed with the following exception. In nested macros (such as the example below), the parent macro exits after completion of the child.

Key Name /Keys
MACRO2 /LightOn;Virtual_TV;DiscreteON;Virtual_TUNER; POWER
TV /MACRO2;3;Virtual_TV;Phantom2;LightOff

For this example, the macro assigned to the TV button exits after MACRO2 completes (missing the underlined commands).

Being a relatively sporatic dabbler with JP1, I am probably missing something pretty basic since it has been a while since I have played with this.

------Some background on why I am nesting (in case other options exist)

The keymove/macro memory available is very low on my remote so I have opted to use nesting in a typical subroutine fashion in an attempt to efficiently use my memory (In this case MACRO2 is a sequence common to several of my macros).

I am aware of the possibility of setting up new device codes to limit the number of keymoves that I have setup; however, I am hoping to get the nesting to work since I see it as the path of least resistance.

Any help is greatly appreciated!

Hello,

Unfortunately, none of the extenders I have written allow for nested macros. They do allow for concatenated macros, but as you've discovered, when the called macro is finished it doesn't return to the parent. The only extenders that support nested macros are those written by Nicola for the 7560 remote. And there might be one version of the 7800 extender that supports this as well. But most do not.

However, there is an easy way around this. The 740 based remotes (e.g. your producer 8) allow you to change the amount of memory allocated for keymoves vs. upgrades. I've uploaded a sample RDF to the RDF folder. It will give you twice the keymove space while eliminating the device specific memory area. Here's a link:

http://groups.yahoo.com/group/jp1/files ... ory%29.rdf

The easiest way to move to the new RDF with the new memory sizes is as follows.

Drop the RDF in the directory where you have IR.EXE
Open IR and create a file with the new RDF. Save it. This will be your new remote image.
Take your existing saved file and cut the memory from 003A to 00FF and paste it into the new file.
Open two versions of IR, one with the new image, one with the old image. Cut and paste your devices from the old to the new.
Upload your new image to the remote. You'll get an error message that the signatures are different. Hit okay. (if the remote doesn't say "MEM ERROR" when the upload is finished then you are good to go).

Let me know how it goes.

Jason M.

It works great .... Thanks!

One question though ... since I am still using device codes, what is the "device specific memory area"?

Thanks again

gjarboni wrote:The only extenders that support nested macros are those written by Nicola for the 7560 remote. And there might be one version of the 7800 extender that supports this as well. But most do not.

I have no comment on the 8800 issues here, and this isn't a criticism of Jason for not knowing details of extenders he didn't write (I barely remember details of the ones I did write), but to set the record straight, many of the S3C80 extenders support nested macros; Look in the documentation of the individual extender to find out. I'm pretty sure I wrote the first extender that supported nested macros (Nicola's older extenders didn't. I'm not sure about his newest 7560 extender). My urc6012 extender that supported nested macros has been the most popular starting point for porting or enhancing extender design. I believe most of the extenders that were derived from that one still support nested macros.

I guess that's what happens when you don't look up the details Thanks for setting the record straight.

broc wrote:It works great .... Thanks!

One question though ... since I am still using device codes, what is the "device specific memory area"?

Thanks again

The device specific memory area is for upgrades that can only be used with one mode. For example, UEI created some upgrades for satellite receivers that can only be used on the SAT button (or something like that). We don't know why they added this limitation, but it's in all the 740 remotes. Anyway, since this region is less flexible than the standard device upgrade region, there's no point to use it.

gjarboni wrote:

broc wrote:It works great .... Thanks!

One question though ... since I am still using device codes, what is the "device specific memory area"?

Thanks again

The device specific memory area is for upgrades that can only be used with one mode. For example, UEI created some upgrades for satellite receivers that can only be used on the SAT button (or something like that). We don't know why they added this limitation, but it's in all the 740 remotes. Anyway, since this region is less flexible than the standard device upgrade region, there's no point to use it.

I can add a little detail to this.

My best guess as to the reason this feature was added is so these remotes could be used as OEM remotes (ie, remotes that are supplied with your original equipment). In these cases, one device button would be labelled for the OEM device and would be "locked" so that the user cannot change the code assigned to this device button. Furthermore, the code assigned to that button would not be available for use on any of the other device buttons.

That being said, the next obvious question is, is this feature of any use to us, and the answer is "yes, but just for certain remotes".

The older Producer 8's (specifically, the URC-8080/8090 B00 and B01 remotes) have a bug in them that prevents protocol upgrades from working properly. The workaround is to create upgrades that use protocol upgrades as "device specific upgrades".

For the newer remotes (ie, the B02 versions of the old URC-8080/8090 and all of the URC-8800/9800/8780 series) this bug has been fixed and the device specific feature serves no purpose.

Thanks for the clarification guys!

(Now to dive head first into TOADTOG)

broc wrote:Thanks for the clarification guys!

(Now to dive head first into TOADTOG)

Well, I think I can save you some time. I've never written any Toad Tog protocol for any of the 740 remotes, so unfortunately you are out of luck there. Sorry.

gjarboni wrote:

broc wrote:Thanks for the clarification guys!

(Now to dive head first into TOADTOG)

Well, I think I can save you some time. I've never written any Toad Tog protocol for any of the 740 remotes, so unfortunately you are out of luck there. Sorry.

I opened another thread in the general forum which you partially answered above. The part that is left unanswered is where I should start, since this resource doesn't exist, to create this protocol.

I am guessing that this will be a combination of crash courses in the existing TOADTOG protocols and the language used by the 740 (given that I know little to nothing about either).

I've uploaded a sample RDF to the RDF folder. It will give you twice the keymove space while eliminating the device specific memory area.

Will this allow upgrades that are larger than the 50 byte limit for 740 remotes?

jetstar52 wrote:

I've uploaded a sample RDF to the RDF folder. It will give you twice the keymove space while eliminating the device specific memory area.

Will this allow upgrades that are larger than the 50 byte limit for 740 remotes?

Unfortunately, No.

Hal

jetstar52 wrote:Will this allow upgrades that are larger than the 50 byte limit for 740 remotes?

The upgrade limit is a functional restriction of the remote itself. I don't think that even an extender can override that.