I've been using my pronto for a couple of years now. So far so good. But one thing I still haven't figured out is the following:

I have a light dimmer which I control with my Pronto. I can either press the button once to turn the lights on or off, or press and hold the button to dim the lights.

I'd like to program a button so that I only have to press it once and my Pronto will send the signal for several seconds to dim the lights.

Can anyone help me with this? I've tried the FAQ's and several other options, but no succes.

Here is the code that my Pronto learned from the original dimmer remote:

0000 006f 0000 0001 0013 0083

sometimes, when I learn the code again, it is slightly different. I also get:

0000 006f 0000 0001 0010 0084

and

0000 006c 0000 0001 0011 0086

How can I edit this code so my pronto will simulate a "press and hold" function?

Best regards,

Ivo

Do those learned signals actually work? I guess a device could use IR signaling that crude. But I'm surprised a device which does something so different for a short press vs. long would use that crude a signal.

Assuming it's correct, you can extend it, but it's harder than most signals to extend because it has no large values.

There are two ways to extend a signal and to get this one up to several seconds, you'll need both methods effectively multiplied together.

1) The first four 4-digit numbers are a header. The last two are the data. To extend, you must make multiple copies of the data and you must change the header to be consistent with that number of copies. Here is an example:
0000 006f 0000 0020 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083
I made the data be 32 copies of the orriginal and adjusted the header accordingly.

2) To get up to a decent length that way, you would need an absurdly long command and probably exceed some limit. Instead you want to bind onto a key a sequence of the same command over and over.

In other remotes we call those "Macros" but I think ProntoEdit uses the word "Macro" for a specialized way of doing that which you don't want here. You just want a sequence of commands.

Maybe you can just extend the original as I did above and then issue a moderate sequence of those and it will work. But since the ending data value (the 83) is still small, you may need to compensate for processing latency.

Within each signal the values will go out exactly as specified. But on each boundary in the sequence the last value is slightly increased by latency effects in the Pronto (probably model specific). A small fraction increase won't bother the receiving device, just as the tiny difference between your learned signals (83 to 86) wouldn't bother it. But the increase may be too big a fraction, in which case you'd need to compensate by changing the last value something like this:

0000 006f 0000 0020 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0060

so the latency induced increase just reverses the change made manually to the last number.

I don't remember the timescale (I'd need to look it up in Barry Gordon's document again) but I expect you need over a thousand copies of the data. If you use a signal like the one I showed with 32 copies inside, you'd need a sequence of 32 of the signal in order to get 32*32 = 1024 copies of the raw data.

Hey John,

Thanks for your help! Now at least I know a little bit more about the structure of these codes.

I've tried extending the code and I got up to 100 repeats:

0000 006f 0000 0100 0013 0083 0013 0083 0013 0083(...)

This seems to work (I can actually dim my lights a bit with this code) but you were right about having to repeat the original code about a 1000 times to get it right. Unfortunatelly it seems that 100 repeats is the maximum.
I've tried 0000 006f 0000 0101 0013 0083 (...) but then I get the message "invalid IR code"
When I copy this code several times into the same button I get stuck because the pause between the individual codes is picked up by my light dimmer and as a result the lights go down a bit, then up a bit, then down a bit, etc.

It looks like I won't be able to turn my lights all the way up or down because I can't make the IR code long enough.
If you have another suggestion for me, please let me know. If not, thank you anyway very much for your help so far!

Best regards,

Ivo

It's amazing what you can find by simply typing in 'holding' in the 'search this forum section'

I found this in a matter of seconds.

[Link: remotecentral.com]

BTW, I used the above method only today for my m8.
He needed the 1 or 2 key held down for about 10 secs to change the Region code on his DVD system (DAVS 300).
I had to add the 'repeat' line about 30 times to achieve this. Worked a treat!
Might be easier than messing around with the actual code.

HTH

I think you missed the fact that all these numbers are base 16. When you put 0100 in that 4'th value, you make it expect 256 copies of the data. If you only gave it 100 copies that will cause problems (though I'm not sure exactly what problems). Maybe it will use you 100 copies followed by random garbage.



I don't know ProntoEdit very well and I might be misunderstanding what you mean by "copy". I thought the right method was to copy the code once onto a key on some hidden panel somewhere and then alias it multiple times onto the key where you want to use it.

Maybe someone who knows how to use ProntoEdit will jump in and clear that up.


No. I have the SAME suggestion again. It can be made to work. I'll try to be clearer this time.

Maybe the symptoms you describe are just because the actual amount of data mismatched the header, which put garbage at the end of each signal, which the device saw as a break between the parts. So maybe you just take base 16 into account and it will work. BTW 100 decimal is 0064 in base 16.

Maybe it is the latency I tried to describe before. To fix that you must guess the latency amount and subtract approximately that much from the very last number of the extended hex sequence, so all the other 0083 would stay 0083 but the very last one would be something like 0060 instead. By "very last" I mean the last one in the key defined elsewhere that you alias multiple times for the real key, so the 0060 ends up being used once per alias boundary.

You're right, I wrote it wrong. I had in fact 256 copies of the data with 0100 in the 4th value. I found out that ProntoEdit will not accept a number of copies that doesn't match the 4th value.


I've just tried that, but without succes. When trying the IR code on my light dimmer, it still breaks up after every repeat of the code, resulting in my lights going up and down, so putting the same code (with either 0083 or 0060 or something else at the end) several times under one button doesn't do the trick because of the delay in between.

Wouldn't their be a way of editing the CCF-file without ProntoEdit, and so forcing the IR-code to be longer than 256 times the original data?

Thanks. I found that one too, but it didn't work. I keep getting stuck with the pause between the separate codes, even when learning them the way it was described, with a 'beginning' code and a 'repeat' code.

I haven't heard of anyone measuring the minimum delay between commands on a button. We would need to know that to be sure of what's going on with that symptom and whether there's a work around.

I expect you don't have a second Pronto or a JP1 remote or other tool to capture IR signals for analysis and I don't have a Pronto at all.


My guess is that ProntoEdit is just enforcing a limit which is actually in the firmware of the Pronto. If the limit were just in ProntoEdit and not in the firmware then your idea is good.

One approach to test that would be the CCF compiler/decompiler in the CCF tools zip at
[Link: remotecentral.com]

I'm not an IR code expert so I'm not exactly sure if this is what your asking. But, ProntoEdit has a limit of 256 (approx) steps in a macro. This limit extends to aliases as well. So if you had a macro with 100 steps in it, but two of the steps were aliases to other 100 step macros, you'd be over the limit. Don't know if this "256" limit extends to internal stucture of code.

Jim L

I'm not sure if there is a minimum, but when looking at the indicator on the pronto screen I can see that there is a very short pause between every signal. The light dimmer picks up this pause and so recognizes the second signal (the second 256x code) as a second buttonpress, in stead of one long buttonpress.


No, I wish I had :-)


Maybe I don't have enough experience on this subject, but the last 2 hours I've tried about every program there is in this section. The only thing usefull to me was CCFTools. I could edit the CCF-file with notepad and convert it back again, but ProntoEdit won't accept it when I make the code any longer than 256 repeats in one IR-code. It will either say the CCF is invalid or give a system error and close the program.

This message was edited by Ivo1977 on 06/12/03 06:38.

That's exactly what I was trying to suggest you try. Sorry I didn't make that clear.


I assume that means you can't even transmit the CCF to the Pronto for testing. I didn't expect you could edit the CCF further in ProntoEdit after making a change it doesn't like, but I hoped you could transmit the CCF to the Pronto.

We still don't know whether ProntoEdit causes this limit or whether it reflects a firmware limit. To chase that question, I think the next thing to try would be Tonto (which I know even less about than I know ProntoEdit).

How short can the signal be and not be treated as ON/OFF? Can you make a signal that is just long enough to not be ON/OFF and alternate that signal with the 256 length one to slowly adjust in the desired direction?

No, I can't transmit the CCF to the Pronto. When I try to open the CCF file in ProntoEdit it says the file is incorrect or even shuts down, without loading the file.


I think ProntoEdit itself causes the limit, but this doesn't answer the question if the firmware sets the same limit.


What does Tonto do? I'm not familiar with it.
Oh, by the way, maybe it's useful to know I have the Pronto type 940 (so it's quite an older model).


I've just tried this. I made a signal with 96 repeats of the original code:

0000 006f 0000 0060 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 (...)

This was still recognized as an ON/OFF switch, not a "press and hold" to dim the lights.

When I made a signal with 128 repeats...

0000 006f 0000 0080 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 0083 0013 (...)

This was recognized as a "press and hold", but the lights were only dimmed just a small fraction, as if the original button was only hold for maybe half a second (it takes about 4 seconds to dim the lights completely)

Also, now I see a little miscalculation of mine (here's my inexperience with hexagonal numbers)... I said the maximum repeats was 256, but of course the number 0100 represents only 160 repeats (am I right?)

So the minimum length of the code to recognize a dim-function rather than an ON/OFF-function (128 repeats) is almost the maximum length that ProntoEdit will accept.

---

A little edit to my message...

I was trying some more just now and I found out the following:

When I let the Pronto learn the signal from the original remote and I press the button and hold it for just about half a second or longer, I always get the short IR-code (sometimes a little different, like 0013 0083 in stead of 0010 0084):

0000 006f 0000 0001 0010 0084

But when I press and release the original remote real short (so just enough to turn the lights on/off) I get different codes all the time. Here are some examples:

0000 006f 0028 0000 0014 0084 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0084 0010 0089 000d 007b 0010 0084

0000 007d 0033 0000 0002 000c 0012 0074 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 0075 0010 000c

0000 006f 0013 0000 0004 0084 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0083 0010 0084 0010 0084

0000 006e 001c 0000 0004 0085 0010 0085 0010 0085 0010 0085 0010 0084 0010 0085 0010 0085 0010 0085 0010 0085 0010 0085 0010 0084 0010 0085 0010 0085 0010 0085 0010 0085 0010 0085 0010 0085 0010 0085 0010 0085 0010 0085 0010 0085 0010 0085 0010 0085 0010 0085 0010 0085 0010 0085 000f 0084 0010 0085

I don't know if this means anything...

This message was edited by Ivo1977 on 06/12/03 11:09.

I don't know either, but if you look at the following thread you might find out.

[Link: remotecentral.com]


Hexadecimal = base 16 number
Hexagonal = six sided shape :)


I don't think so. 100 in base 16 equals 16 squared, which equals 256.


It doesn't. The Pronto is just trying too hard to find a higher level encoding where none exists. It's always tricky for an IR learning system to decide which fluctuations are random noise and which are the signal structure.

Allright, thanks. I have to go to work now so I won't be able to try this until tomorrownight, but I'm gonna take a look. Hopefully this will help.


Oops... Well, maybe I can use my translation from Dutch to English as an excuse then? ;-)


You're right again. But I'm learning a lot here :-)


That makes sense. Well, I'm gonna take a look at Tonto tomorrow. In the meanwhile, thanks again for your great help!!

Well, gave Tonto a try, but no succes I'm afraid. While Tonto does give the option of extending the code much further then ProntoEdit will allow, and so making the signal last longer, the Pronto seems to have problems with this. When I try a longer code, downloaded from Tonto, the light dimmer doesn't respond at all and my Pronto will shut down and restart a few seconds after I pushed the button.

I'm starting to get a feeling it just won't be possible to use a press and hold function on my Pronto... :-(