It appears that one needs to clarify the concept of "repeating portion", as there are two distinct usages of the term which tends to breed confusion.

In the world of IR (not Pronto Hex format), most IR protocols do not have a "repeating portion". To repeat the code they just retransmit it again. Sony is like this. Hold the button down on the remote, and if the code is allowed to repeat, it is sent again. Things like a power toggle code obviously would not be allowed to "repeat".

The original NEC codes did not have a repeat portion but that was changed sometime later. In some of the newer NEC codes (and others that are similar) there is the "One Time" pattern which is sent when you touch the button on the remote. There is also a very short pattern which just has the start and end sections of the One Time pattern but nothing in the middle. It is what is sent when the button is held down. (Note: The buttons I am referring to are on the original manufacturers remote).

Think of that pattern, the "Repeating pattern" as saying "do the last thing you did again". As long as the button was held down that same "Do it again" command is sent. This makes for a very responsive system as the "Do it again" command is generally of very short duration as it is missing all of the detail about what is to be done.

When the original Prontios were built, Philips wanted to cover all cases so they established the Pronto HEX format. Ths format consists of a four word preface that describes the remainder of the data followed by the data set(s) themselves. Philips allowed for two distinct data sets. One data set was for when the Pronto button (or screen) was touched and was called the One Time burst set or the One Time pattern; and one data set was for when the button was held down or the screen continuously touched and was called the Repeat Burst set or the Repeat pattern.

If you now think about it (just a little) you can see that the mapping of either type of IR protocol (with or without seperate and distinct repeat patterns) can be easily mapped into Philips pronto HEX.

In the Sony case where the entire pattern is to be sent to make it repeat, the two burst sets of the Pronto HEX codes are the same. If the command is not allowed to repeat then the second burst set is empty.

In the case of a seperate repeating pattern then The Pronto Hex format allows you to place the main pattern as the One Time burst set, and the repeating pattern as the Repeat Burst set.

Hope that halps explain it.

This post is in reference to last post on Page #1 of this thread.

And, when it comes to duplicating activities, you should then consider putting your main script into panel labels and using eval() to cut down on config file size as script would be duplicated in all copies, but rather evaulated from a common place (1 copy). Search this forum for eval() for more info.

Hi All, I'm new to the forums and spotted this post.
I appreciate this is an old post - but I am also suffering with slow response when trying to use the onHold function. I too am trying to integrate several activities into one and use the same volume up/down buttons to control different kit depending on which room you are in and whether you wish to control the TV or AVR volume.

My previous button code stated:

onHold = function()
{volume_up();};
onHoldInterval = 50;

The volume_up function uses executeActions for hidden buttons.

It response is acceptable when changing the volume on TVs or the multi-room amplifier but is very slow with the Yamaha AVR for the cinema room. I have read the posts and although I have a little programming experience I don't know a great deal about IR codes. I need some help...

I have captured the AVR volume codes and I believe I have the short repeat code (by capturing while already holding down the remote control button):

Volume up full code:

0000 006E 0022 0002 0154 00AA 0016 0015 0016 003F 0016 0015 0016 003F 0016 003F 0016 003F 0016 003F 0016 0015 0016 003F 0016 0015 0016 003F 0016 0015 0016 0015 0016 0015 0016 0015 0016 003F 0016 0015 0016 003F 0016 0015 0016 003F 0016 003F 0016 0015 0016 0015 0016 0015 0016 003F 0016 0015 0016 003F 0016 0015 0016 0015 0016 003F 0016 003F 0016 003F 0016 05E3 0154 0054 0016 0E2C

Short code (I think):

0000 006E 0002 0002 0154 0054 0016 0E2C

How can I use the repeat code?

Do I change the button code to:

volume_up();
onHold = function()
{volume_up2();};
onHoldInterval = 1;

Where volume_up points to a button with the full code and volume_up2 would point to a button with the repeat code?

Any help will be greatly appreciated.

Also I saw in the posts a reference to a document by Barry Gordon but I couldn't see it in the document list - could anyone post a link for me?

Code #1
0000 006E 0022 0002 0154 00AA 0016 0015 0016 003F 0016 0015 0016 003F 0016 003F 0016 003F 0016 003F 0016 0015 0016 003F 0016 0015 0016 003F 0016 0015 0016 0015 0016 0015 0016 0015 0016 003F 0016 0015 0016 003F 0016 0015 0016 003F 0016 003F 0016 0015 0016 0015 0016 0015 0016 003F 0016 0015 0016 003F 0016 0015 0016 0015 0016 003F 0016 003F 0016 003F 0016 05E3 0154 0054 0016 0E2C

Code #2
0000 006E 0002 0000 0154 0054 0016 0E2C

This might work, depending solely on timing (don't use long onHoldIntervals > 50ms and don't use scheduleAfter to execute the widget). If it does not work, then your only recourse is to remain status quo.

The yamaha learned code does have the repeat sequence built in it is the last 4 numbers which constitute a null message. That is, a message with no data just a start sequence and a stop sequence. The null message is taken to mean "repeat the last message received". The pronto should issue the repeat sequence (after sending the full message once when the button was depressed, for as long as you hold the button depressed if attached to a button.

Pronto general IR format allows for a short representation of an IR pattern as opposed to the normal Pronto HEX learned code format. These shorthand representations never begin with 0000 or 0100. The short code would be expanded by the pronto into the equivalent of the long code, and is just a reference to an algorithm supplying the necessary code numbers as parameters. In effect they generate the pattern on the fly using a general purpose algorithm. I do the same thing in many of my applications never storing the actual IR pattern, but just storing the device and key code numbers, and which algorithm (protocol) to use to develop the pattern.

I have avoided using executeActions() in cases where the sending of an IR code is needed outside the confines of a macro per the reasons already discussed. I have also gotten quite used to seeing the "Sending Icon" animate while a given IR code is being sent which doesn't happen when using an executeActions() statement instead.

There will be way to make the animation happen very soon. :)

Excellent! Most excellent indeed. :-)

Is there any plan to fix the original problem? It's a little aggravating that these guys are going to spend their time dealing with a cosmetic issue (the IR sending graphic) when there's functionality that is broken to the point of being unusable.

-RD

Not yet, but I continue to ask... Regarding unuseable, there are workarounds that may be able to be used in certain conditions but I admit that the IR transmission is not as fluidic as it could be.

As a means to free up some much need space in the remote for my XCF I'm now dynamically building the disc loading macros for my DVD Juke activity solely using ProntoScript rather than using conventional action lists (400 per changer). End result, I went from 0% memory free in the remote to 5% memory free. That being said, the only thing I don't like now is the fact that the sending icon is no longer present and animating as the disc loading macro is running and the "please wait" graphics are shown. Granted the "please wait" graphics that I have displayed indicate the progress of the macro, but I'm just so used to seeing the sending icon spinning around as well. Was wondering Lyndel if your quote above ever came to fruition perhaps.

Yes, use scheduleActions() instead of executeActions() but may require you using PEP2 or firmware suited for PEP2.

I did try that already. No joy unfortunately. Perhaps it's due to the fact I'm using PEP v1 and can't update past remote firmware version 7.1.21, i.e. the bug introduced with later firmware versions regarding PEP v1 files and the ProntoScript located on firm keys not then working. The use of PEP v2 is out of the question in my case. Guess I'll eventually get used to not seeing the sending icon spinning round.

Well clearly I was doing something wrong the other week, because scheduleActions() works just fine when downloading from PEP v1 to a remote running firmware version 7.1.21. Just finished implementing something new this evening for my "DVD Juke" activity which would only work using scheduleActions(). Performed a quick test before taking the time to implement the update and had no issues. Not sure what I was doing wrong the other week, but I'm glad I decided to give scheduleActions() another shot. Seriously pumped that I can add scheduleActions() to my PEP v1 bag of tricks now. :-)