PDA

View Full Version : GlobalCache driver bug - no repeats



jameswing
March 10th, 2005, 11:14 AM
I am just moving this thread to the right forum, now that we know the forum to which it pertains.

Bug: GlobalCache driver will not repeat codes, and it needs to have a minumum number of repeats even for 'non-repeating' codes to assure proper reception -- like NRIR Server does.

http://www.promixis.com/phpBB2/viewtopic.php?p=113345

I hope this is the correct way to 'move' a thread when there is no moderator for the forums in question. :o

--Jim

ebariaux
March 10th, 2005, 12:37 PM
You might want to try to play around with the code and the once vs repeat portion of it. I vaguely recall a discussion on this on the forums quite some time ago but did not find it back with a quick search.

So for instance, instead of:

0000 0067 0000 000D 0060 0019 0018 0019 0018 0019 0018 0019 0030 0019 0030 0019 0018 0019 0018 0019 0030 0019 0030 0019 0030 0019 0018 0018 0018 03FD

You might try

0000 0067 000D 0000 0060 0019 0018 0019 0018 0019 0018 0019 0030 0019 0030 0019 0018 0019 0018 0019 0030 0019 0030 0019 0030 0019 0018 0018 0018 03FD

This defines a code with just a once part and no repeat part. This should not work but who knows.

You could also try to combine both, like:

0000 0067 000D 000D 0060 0019 0018 0019 0018 0019 0018 0019 0030 0019 0030 0019 0018 0019 0018 0019 0030 0019 0030 0019 0030 0019 0018 0018 0018 03FD 0060 0019 0018 0019 0018 0019 0018 0019 0030 0019 0030 0019 0018 0019 0018 0019 0030 0019 0030 0019 0030 0019 0018 0018 0018 03FD

jameswing
March 10th, 2005, 05:09 PM
Thanks Eric,

I'll give those ideas a shot tonight after work, though I am not optimistic. My theory (and I am on a roll, y'know') is that the first will make NRIR operate the same way GC does currently - ie. broadcast 13 'pairs' in 40 ms and fail to operate the device. --- but at least the two would be doing the same thing! :lol: ; and the second will broadcast 26 'pairs' via GlobalCache, operating the device very infrequently, if at all; and will broadcast ((1+6)*13=) 91 'pairs' via NRIR Server, operating the device fine, and taking only slightly (1/6 = 17%) longer to complete the sequence.

I'll post back and let you know.

--Jim

jameswing
March 10th, 2005, 07:44 PM
'Learning' with 'End Timeout' set to 35 ms so that all pairs are shown for troubleshooting purposes:

For your second scenario:

0000 0068 0000 001A 0061 0018 0018 0018 0018 0018 0018 0018 0030 0019 0030 0019 0018 0018 0018 0018 0030 0019 0030 0019 0030 0019 0018 0018 0018 03F4 0061 0018 0018 0018 0018 0018 0018 0018 0030 0019 0030 0019 0018 0018 0018 0018 0030 0019 0030 0019 0030 0019 0018 0018 0018 056F
(26 pairs)
is 'learned' from the GC-100; and
0000 0065 0000 005B 0060 0018 0018 0019 0018 0019 0018 0019 0030 0019 0030 0019 0018 0019 0018 0019 0030 0019 0030 0019 0030 0019 0018 0019 0018 03FD 0060 0018 0018 0019 0018 0019 0018 0019 0030 0019 0030 0019 0018 0019 0018 0019 0030 0019 0030 0019 0030 0019 0018 0019 0018 03F7 0060 0018 0018 0019 0018 0019 0018 0019 0030 0019 0030 0019 0018 0019 0018 0019 0030 0019 0030 0019 0030 0019 0018 0019 0018 03F7 0060 0018 0018 0019 0018 0019 0018 0019 0030 0019 0030 0019 0018 0019 0018 0019 0030 0019 0030 0019 0030 0019 0018 0019 0018 03F7 0060 0018 0018 0019 0018 0019 0018 0019 0030 0019 0030 0019 0018 0019 0018 0019 0030 0019 0030 0019 0030 0019 0018 0019 0018 03F7 0060 0018 0018 0019 0018 0019 0018 0019 0030 0019 0030 0019 0018 0019 0018 0019 0030 0019 0030 0019 0030 0019 0018 0019 0018 03F7 0060 0018 0018 0019 0018 0019 0018 0019 0030 0019 0030 0019 0018 0019 0018 0019 0030 0019 0030 0019 0030 0019 0018 0019 0018 0596
(91 pairs)
is 'learned' from the USB-UIRT from NRIR Server. So I was right on the money there.


The first scenario gave me just what I expected from the GC-100:
0000 0068 0000 000D 0061 0019 0018 0018 0018 0018 0018 0018 0030 0019 0030 0019 0018 0018 0018 0018 0030 0019 0030 0019 0030 0019 0018 0018 0018 057E

but this is what came from NRIR Server:
0000 0065 0000 004E 0060 0018 0019 0019 0019 0019 0019 0019 0030 0019 0030 0019 0019 0019 0019 0019 0030 0019 0030 0019 0030 0019 0019 0019 0019 03F7 0060 0018 0019 0019 0019 0019 0019 0019 0030 0019 0030 0019 0019 0019 0019 0019 0030 0019 0030 0019 0030 0019 0019 0019 0019 03F7 0060 0018 0019 0019 0019 0019 0019 0019 0030 0019 0030 0019 0019 0019 0019 0019 0030 0019 0030 0019 0030 0019 0019 0019 0019 03F7 0060 0018 0019 0019 0019 0019 0019 0019 0030 0019 0030 0019 0019 0019 0019 0019 0030 0019 0030 0019 0030 0019 0019 0019 0019 03F7 0060 0018 0019 0019 0019 0019 0019 0019 0030 0019 0030 0019 0019 0019 0019 0019 0030 0019 0030 0019 0030 0019 0019 0019 0019 03F7 0060 0018 0019 0019 0019 0019 0019 0019 0030 0019 0030 0019 0019 0019 0019 0019 0030 0019 0030 0019 0030 0019 0019 0019 0019 0596
(78 pairs =) 6 iterations of the code! It repeated 'Part 1' of the code, even though 'Part 2' (which doesn't exist in this case) is the only part that is supposed to repeat in the scheme of the Pronto/CCF format..... :o I'm going to do a tad more testing to see if that will happen when 'Part 2' does exist and report back.

--Jim

jameswing
March 10th, 2005, 08:23 PM
I tried 13 pairs in 'part 1' and 13 pairs in 'part 2' (the repeating portion) of a code. NRIR broadcasts 'part 1' once, and 'part 2' six (6) times. The NRIR Server driver is smart enough to know that one transmission of a code in a noisy IR environment is insufficient to get the job done. That is why it works and the GlobalCache driver does not.

If the GC driver would repeat at all, I could just hold the darn button down longer to get the codes to work. :roll:

Promixis, is anybody reading this, or the bug report I logged?

--Jim

Ben S
March 10th, 2005, 09:14 PM
Yes Jim, I'm reading it, and will delve deeper into the bug repeat you've mentioned to get the GC device operating properly for you.

But first, are you absolutely certain the GlobalCache is not repeating codes? I'll need to add some logging in there, as it has repeated my codes in the past. I'll need to fire up the GC test-bed and ensure that it's still working as expected.

jameswing
March 10th, 2005, 09:56 PM
Thanks for the reply Ben. I am 100% certain that the GlobalCache is not repeating. It sends the code exactly one time. I am not 100% certain that my GlobalCache device will repeate codes if given the command to do so -- ya never know, it could be defective. So I am working on that now. I have downloaded a piece of VB to create a socket and send text commands to a port on an IP address (Socketwrench from Catalyst.com) and I will tonight create a GlobalCache-formatted command with a repeat count and send it directly to the GC-100 to confirm. Will advise.

--Jim

jameswing
March 10th, 2005, 10:33 PM
OK. 100% certain that the GlobalCache will repeat when given the command to do so. I gave it the following command:
sendir,2:1,1,40000,5,1,96,24,24,24,24,24,24,24,48, 24,48,24,24,24,24,24,48,24,48,24,48,24,24,24,24,10 20
(ie. 13 pairs, 5 iterations)
Response from GlobalCache:
"completeir,2:1,1"
code learned with 'End Timeout' turned up high for full code capture:
0000 0068 0000 0041 0061 0017 0018 0018 0018 0018 0018 0018 0030 0017 0030 0017 0018 0018 0018 0018 0030 0017 0030 0017 0030 0017 0018 0018 0018 03FF 0061 0017 0018 0018 0018 0018 0018 0018 0030 0017 0030 0017 0018 0018 0018 0018 0030 0017 0030 0017 0030 0017 0018 0018 0018 03FF 0061 0017 0018 0018 0018 0018 0018 0018 0030 0017 0030 0017 0018 0018 0018 0018 0030 0017 0030 0017 0030 0017 0018 0018 0018 03FF 0061 0017 0018 0018 0018 0018 0018 0018 0030 0017 0030 0017 0018 0018 0018 0018 0030 0017 0030 0017 0030 0017 0018 0018 0018 03FF 0061 0017 0018 0018 0018 0018 0018 0018 0030 0017 0030 0017 0018 0018 0018 0018 0030 0017 0030 0017 0030 0017 0018 0018 0018 056F
(hex 0041 = 65 pairs = 13 pairs x 5 iterations)

And I have reinstalled NetRemote and repeated the previous tests on GlobalCache.

There is no question that the 'enable repeat' and 'repeat limit' settings in the GlobalCache driver in the IR plugin for NetRemote are not working, and that when they are set to 'on', and '100' respectively, exactly one iteration of the IR code is blasted, regardless of the duration of the keypress. Further, I can see that IP packets are received by the GC-100 on button-down, as well as on button-up events.

I hope this helps. I can't wait to get this working and build myself an uber remote like jlee and company. :D Please post what you determine, I am very curious to know what went wrong.

--Jim
--now knowing more about sockets, IP/TCP protocols, and IR noise than I ever wanted to know :wink:

Ben S
March 13th, 2005, 08:30 AM
Hi James,
Nice investigations! This will definitely help me resolve the issue. I'll see if I can dig up an answer in the next few days for you.

jameswing
March 22nd, 2005, 11:33 PM
Big news!
Thanks to Wilhelm, I discovered we are not all on the same page.... or the same device in this case.

Since I am DEVELOPING my ccf, rather than USING it, I am testing NetRemote on my desktop PC, rather than my PPC. I had seen that Wilhelm was using his GC, and asked him to email his version of the IR plugin. He sent me the PPC version, not the PC version. Well, this is my first usage of a PPC, and it had not occurred to me that the plugins were different (until then) :oops: -- I’m a noob...

So, I tested the PPC. The PPC version also ignores the repeat count settings, but it repeats the code exactly eight (8 ) times, rather than one (1), resulting in a robust code, but not one that will repeat while you hold the button down. This explains why the CG driver appears to work for those using the PPC.

However, it still will not work for repeating keys. For example, a video tape player that performs fast-forward as long as you hold down the FFW button, then returns to play mode when the FFW button is released…. Or a volume-up or volume-down until button-release – and I use the volume keys about as much as all other keys combined. :cry:

Since there is a button-up event generated when releasing the button, and there is a ‘stopir’ command on the GC to stop repeating transmission, I believe when the button-down event occurs, it should send a command to the CG to repeat the code x times (where x is the maximum number of repeats set for the plugin by the user – ie, the ‘safety-stop’), then it should send a ‘stopir’ command when the button-up event occurs. Now I’m gonna go out on a limb here and make an assumption based on another observation detailed in this thread: http://www.promixis.com/phpBB2/viewtopic.php?t=10715
…that is, in the case of the NRIR Server, it doesn’t seem to ‘get’ the button-up event if it follows the button-down event too closely. Making a complete SWAG, one could suppose that the same issue might have been encountered with the GC, so the repeat-count was simply set at eight (8) in order to make the GC work (mostly) and move on to more important bugs. (Did I mention this was a SWAG theory?)

So Ben, whadayathink about a fix on the PC version of the IR driver, (now that we are both talking about the same thing)? And what about my crazy theory… is there anything to it? It would sure be nice to have repeats working on the GC. 8)

Wilhelm
March 23rd, 2005, 03:31 AM
Hi Jim,

as I said, still both versions should work the same.
I still don't understand what the problem is with your repeat 8 times. There must be something wrong with the coding of the IR.
I haven't had the time to go over all of your posts. I think it would be best if we took one particular code and make it work, to figure things out.

If your code repeats 8 times, it clearly is wrong. Try to learn a single keystroke without repeat. See if that works (without repeat and one time only) Post this code here.
Then learn the code with the repeat sequence and post it here also. Then we could see what the problem might be.

I remember problems with the GC not working properly whith code that have no preamble and only a loop sequence. I think Ben still hasn't fixed that - we'll see.

jameswing
March 23rd, 2005, 04:26 PM
Thanks Wilhelm,
I have already done exactly what you suggest. The results are posted in this thread and in the one preceding it (referenced at the beginning of this thread).

Actually, the fact that it repeats the code eight times is the reason that it does work. The term 'non-repeating code' is really a misnomer. It would be more correct to call such a code a 'non-infinitely-repeating code'. You see, the IR world is a noisy one, and sending a code just one time will almost never be sufficient for the whole thing to be received reliably. In the case of Sony, at least, 'non-repeating codes' really repeat a few times and stop, regardless of the duration of your key-press, while 'repeating codes' repeat indefinitely until you release the key.

For example, take my Sony camcorder remote that has been used for many of these tests. The 'stop' key utilizes a 13 bit code with no 'preamble'. It is a 'non-repeating' code (that is, you press the key down and it flashes for a brief instant, and stops even though you are still holding down the key). When you actually record the output from the transmitter with a modified ‘IR-learning’ tool, you can see that it transmits the 13 bit code five times, then stops. This results in a 'robust' code transmission.

Storing this 13 bit code in a CCF and using NRIR Server with USB-UIRT (with repeats disabled) to transmit it, you will find that it transmits the code six times and then stops (resulting in a robust code transmission).

Using the same CCF and switching to GlobalCache output (with repeats disabled or enabled), you will find that it transmits the code eight times and then stops (resulting in a robust code transmission) when using the PPC. But when using the real PC, (with the different IR driver,) the 13 bit code is transmitted exactly one time and then stops (resulting in a failed code transmission at least 99% of the time).

All of this is 100% reproducible. What is confusing is that you say your IR driver on your PC works fine. Have you tested sending codes out your GC from NetRemote on your desktop PC lately? Can I talk you into emailing me THAT drv_ir.dll too?

I know that some manufacturers use a ‘preamble’ that will cue the receiver to really watch closely the repeating portion of the code. In that case, I would assume that a single iteration of the repeating portion would be significantly more likely to be properly received than in the case where there is no preamble sequence. This might explain why some stuff would work fine, even from the PC version. Here is the test: find any code in your CCF whose first and third word are ‘0000’ (ie. A code that looks like 0000 xxxx 0000 xxxx ….. where x is any hex number) – Note the first word of 0000, indicates that it is a ‘learned’ code, rather than an RC5 code, and the third word is the count of bits in the preamble. Then, using your real PC, try to send that code via GC. I’d bet two dollars against a Euro that it doesn’t work.

This would verify your recollection:

I remember problems with the GC not working properly whith code that have no preamble and only a loop sequence.

--Jim

Wilhelm
March 23rd, 2005, 05:28 PM
Sorry Jim, but I think your interpretation of whats going on is flawed.
I have no code, which get sent more than one time for a single keypress.
Why are you still insisting on debugging that camcorder before checking whats going on with a device that does work?
BTW NetRemote does not support RC5 codes.

...and I cannot see that you did what I suggested. So one last try:
1. learn a code with NR and push the button for a short time.
2. learn the same code with NR and hold the button until the learning routine stops by itsself.
3. Post both codes.

And please do not use any button that you know doesn't repeat.

What you discribe with the off button is an odd thing and has nothing to do with repeat.
If you have a button that does not repeat, you don't have a loop sequence!

As I said, I know there is a bug in the GC not sending a code without preamble, unless you hold the button until it repeats, but that's another problem.

jameswing
March 23rd, 2005, 11:10 PM
Once again Wilhelm’s help is very enlightening for reasons other than what was expected. Things are becoming clearer.

I cannot learn with NR, as mine has an unsupported processor for direct IR. As such, I must learn IR codes by alternate means. I have two such means. One is IRLearner from Jon Rhees; the other is IR-Learner form GlobalCache. It all comes down to what the learner considers a single iteration of the code.

When I send the stop code from my remote, and I say that I need more than 20 milliseconds of off-time to indicate the ‘end’ of a code, the code is represented as this (65 pairs):
0000 0068 0000 0041 0060 0017 0018 0018 0018 0018 0018 0018 0030 0017 0030 0017 0018 0018 0018 0018 0030 0017 0030 0017 0030 0017 0018 0018 0018 03FA 0060 0017 0018 0018 0018 0018 0018 0018 0030 0017 0030 0017 0018 0018 0018 0018 0030 0017 0030 0017 0030 0017 0018 0018 0018 03FA 0060 0017 0018 0018 0018 0018 0018 0018 0030 0017 0030 0017 0018 0018 0018 0018 0030 0017 0030 0017 0030 0017 0018 0018 0018 03FA 0060 0017 0018 0018 0018 0018 0018 0018 0030 0017 0030 0017 0018 0018 0018 0018 0030 0017 0030 0017 0030 0017 0018 0018 0018 03FA 0060 0017 0018 0018 0018 0018 0018 0018 0030 0017 0030 0017 0018 0018 0018 0018 0030 0017 0030 0017 0030 0017 0018 0018 0018 0FB2

However, If I say 20 milliseconds of off-time represents the end of the code, what I see is five iterations of a code that would be represented as this (13 pairs):
0000 0067 0000 000D 0060 0019 0018 0019 0018 0019 0018 0019 0030 0019 0030 0019 0018 0019 0018 0019 0030 0019 0030 0019 0030 0019 0018 0019 0018 03FD
(5 x 13 = 65)

Jon’s IR Learner generates the latter, though it does not tell you how many iterations it sees. GC’s IR Learner has a user-selectable timeout setting, and will generate either of the above, depending on the setting.

Now, Since Jon also wrote the driver for his USB-UIRT plug-in, it is expecting his kind of code, and it knows that a single iteration is not enough, so if I feed Jon’s driver Jon’s short code of 13 pairs, it repeats it six times (6 x 13 = 78 pairs) cause it figures six is a reasonable number (really cause Jon figured six was a reasonable number and he hard coded it in there). If I feed Jon’s driver the long code of 65 pairs, it sends 390 (= 6 x 65) pairs. But Jon didn’t write the GC driver, so when using the GC, the long code produces exactly the same thing as the original remote, while the short code doesn’t work unless you place the emitter exactly in the right spot, and get lucky.

So which is the correct way of doing it and why did Jon pick the number six? Join me next time in the continuing Saga.

See you tomorrow.

--Jim

Wilhelm
March 24th, 2005, 03:43 AM
Jim,

I didn't know you couldn't learn with NR, sorry. What PPC are you using?

So I think we are dealing with two different problems here and the learning is a big part of them. (I think NR has the best IR learner built in - it's a shame you can't use it. I haven't had any trouble learning any code with it.)

1. The code you are trying to reproduce is a bit odd, because it has a repitition in the preamble sequence. That seems to irritate the different learners. If that device needs to see the 65 pairs, then ok. You could hold the key until it reacts or you could put the whole sequence in the preamble portion of the code. I really don't think this is about repeat at all, but a matter of timeout as you described and this is clearly a problem with the different learners.
2. The driver doesn't work well with the GC when the preamble is empty. GC doesn't send anything, if the stop code arrives early, meaning the loop hasn't started yet and the preamble is empty. That could be fixed in the IR driver of NR but since this bug is so old, I would not bet on getting it fixed. (I reported this about a year ago)

You still haven't confirmed any device working - with repeat- Is it really true that only have such odd devices? I allways thought, that my Yamaha receiver was the most difficult device to get to repeat and that works fine.....

Cheers

jameswing
March 24th, 2005, 08:25 AM
Wilhelm,
I wasn’t ignoring your questions, I just needed to get some sleep first, cause the answers are complex. So here goes:

My PPC is an iPaq RX3115. Since the direct IR doesn’t work with the processor in this unit, I must lear IR codes on my PC, then paste them into the CCF and upload the CCF to the PPC. As such, I am developing the CCF entirely on the PC. My A/V equipment (except the monitor) is in a closet, two hallways plus two rooms away from my office (where the development PC lives). For development/troubleshooting/testing purposes, I need to be able to see the telltale lights on the GC, and see the equipment responding (or not) to the IR signals. I have 100Mbps Ethernet now instead of 10Mbps plus I’m getting a tad old, fat, and slow. Thus, I can no longer outrun the TCP packets from my PC to the A/V equipment closet in order to see what is happening after I click. Plus, I can’t test the hold-down button repeats that way. :lol:

So, to answer your question
Why are you still insisting on debugging that camcorder before checking whats going on with a device that does work? A: 1) It is cordless and it weighs approximately two pounds, and is considerably easier to bring into my office than the 200 disc CD changer or the 42” Plasma monitor. 2) I have tried a number of codes from other remotes, both infinitely-repeating and non-infinitely-repeating, observing the output from the remote, the GC, and the USB-UIRT (and now the GC when driven by the PPC versus the GC when driven by the PC). I have created bogus IR codes for testing purposes to see how the different drivers render it differently. I have seen that the results are not dependent on which device I use.

And as for this one:
So one last try:
1. learn a code with NR and push the button for a short time.
2. learn the same code with NR and hold the button until the learning routine stops by itsself.
3. Post both codes.

And please do not use any button that you know doesn't repeat.

Here is the Volume-UP button from my Denon receiver remote as learned by Jon’s learner when the button is held for an infinite duration or for as short a period as I can physically operate a rubber button (same result either way) – 32 pairs:

0000 006D 0000 0020 000A 001E 000A 0046 000A 001E 000A 001E 000A 001E 000A 0046 000A 001E 000A 001E 000A 001E 000A 0046 000A 0046 000A 0046 000A 0046 000A 001E 000A 001E 000A 06BD 000A 001E 000A 0046 000A 001E 000A 001E 000A 001E 000A 001E 000A 0046 000A 0046 000A 0046 000A 001E 000A 001E 000A 001E 000A 001E 000A 0046 000A 0046 000A 06A5

Note the off period near the middle of the code (hex 06BD @ 38kHz = 45 milliseconds). The first half of the pairs is not the same as the second half of the pairs.

When using the GC Learner with the timeout set to less than 45 milliseconds, as we would expect, we get only the first half of the sequence above – 16 pairs:

0000 0070 0000 0010 000a 001d 000a 0044 000a 001d 000a 001d 000a 001d 000a 0044 000a 001d 000a 001d 000a 001d 000a 0044 000a 0044 000a 0044 000a 0044 000a 001d 000a 001d 000a 02ea
I’ll call that ‘part A’.

If I block transmission in the beginning and remove the blockage while the code is repeating, half of the time I will learn the code just above, and the other half of the time I will learn the second half of the 32 pair sequence, as expected – 16 pairs:

0000 0070 0000 0010 000a 001d 000a 0044 000a 001d 000a 001d 000a 001d 000a 001d 000a 0044 000a 0044 000a 0044 000a 001d 000a 001d 000a 001d 000a 001d 000a 0044 000a 0044 000a 02ea
I’ll call that ‘part B’.

Increasing the timeout setting on the GC Learner, the shortest code I can get is this – 48 pairs:

0000 0070 0000 0030 000A 001D 000A 0043 000A 001D 000A 001D 000A 001D 000A 0043 000A 001D 000A 001D 000A 001D 000A 0043 000A 0043 000A 0043 000A 0043 000A 001D 000A 001D 000A 0686 000A 001D 000A 0043 000A 001D 000A 001D 000A 001D 000A 001D 000A 0043 000A 0043 000A 0043 000A 001D 000A 001D 000A 001D 000A 001D 000A 0043 000A 0043 000A 0686 000A 001D 000A 0043 000A 001D 000A 001D 000A 001D 000A 0043 000A 001D 000A 001D 000A 001D 000A 0043 000A 0043 000A 0043 000A 0043 000A 001D 000A 001D 000A 0E93
Note that is part A + part B + part A.

Holding down the remote button longer, I can get however many iterations of the sequence I like, all the way until I hang the PC trying to do the conversion on too many. This learning routine does not stop by itself (this is why it has been so useful in my troubleshooting). The sequence goes A + B + A + B + A + B + A + B + ……..
It ends with part A or part B with equal probability.

I’m out of time for now, but in my next installment, I’ll show you how this is incorrect without you knowing about it (cause you don’t have an IR Learner that doesn’t stop by itself):
I have no code, which get sent more than one time for a single keypress.

And I’d like to make sure we are on the same page with our definition of terms like ‘preamble’, ‘intro burst’, ‘repeating code’, etc. I’m going to re-read these first:
http://www.giantlaser.com/tonto/?x=doc_ir
http://www.remotecentral.com/features/irdisp1.htm

Thanks again for your help Wilhelm. Maybe if we get this issue defined clearly enough we can get a fix for your bugs and mine.

--Jim
PS. Oh…
You still haven't confirmed any device working - with repeat- Is it really true that only have such odd devices? I allways thought, that my Yamaha receiver was the most difficult device to get to repeat and that works fine..... GC will not repeat when holding the button down for any code for me. The USB-UIRT will. Could you confirm that you can hold down a button for… say 10 seconds… and the telltale light on the GC will stay on the whole time?

Wilhelm
March 24th, 2005, 09:05 AM
Wilhelm,
Could you confirm that you can hold down a button for… say 10 seconds… and the telltale light on the GC will stay on the whole time?

Just in short, I can definately confirm that for all my hardware.

Wilhelm

P.S. I will get back to you later. I will try your codes and see what happens. I have a portable testing device, so I could try to learn a denon volume code in a shop on saturday and send it to you.. Perhaps this will clear things up. ;-)

jameswing
March 24th, 2005, 02:21 PM
Defining terms:
I am referring to the two ‘parts’ of an IR transmission as the ‘intro sequence’ and the ‘repeat sequence’ (per Stewart Allen). A transmission would consist of the intro sequence one time (if it exists), followed by the repeat sequence (if it exists) one or more times. Each of these sequences consists of a ‘lead-in pair’, several ‘data pairs’, and a ‘lead-out pair’.

Now for the confusing part: Barry Gordon uses the term ‘preamble’ to refer to the first four hex ‘words’ of a learned code that occur just before the first word of the intro sequence (if it exists) or just before the first word of the repeat sequence (if the intro sequence does not exist). That is, the four words which tell the Pronto that 1) it is a learned code, 2) the carrier frequency, 3) the length of the intro sequence, 4) the length of the repeat sequence. You and I have recently used the term ‘Preamble’ (I think) to refer to the intro sequence or maybe you were referring to the lead-in pair. So I am abandoning the term to avoid confusion, and I will call the first four words of a learned Pronto code the ‘pronto code parameters’.

Take as an example:
The code that GlobalCache would generate if given this command in GC format:

sendir,2:1,1,40000,5,1,96,24,24,24,24,24,24,24,48, 24,48,24,24,24,24,24,48,24,48,24,48,24,24,24,24,10 20
This IR sequence would consist of 5 repeats of the following on a 40 kHz carrier:
1 lead-in pair -- 96 cycles of ‘on’, followed by 24 cycles of ‘off’
3 ‘zero-bits’ – 24 cycles of ‘on’ followed by 24 cycles of ‘off’
2 ‘one-bits’ – 48 cycles of ‘on’ followed by 24 cycles of ‘off’
2 ‘zero-bits’
3 ‘one-bits’
1 ‘zero-bit’
1 lead-out pair that is also a ‘zero-bit’ – 24 cycles of ‘on’ followed by 1020 cycles of ‘off’ before another code is allowed to be sent.
Since we told it to repeat 5 times, it starts with the lead-in pair again immediately following that 1020 cycles of ‘off’ in the lead-out pair, repeating the 13 pairs a total of five times. That is the IR activity that is created by the actual remote control for ‘stop’ on my DV camera.

Now here is the question: How to record, store, and send something in Pronto format to create a transmission similar enough to that to properly operate the device?

The answer Jon’s Learner will give you is that the Pronto code is:

0000 0067 0000 000D 0060 0018 0018 0018 0018 0018 0018 0018 0030 0018 0030 0018 0018 0018 0018 0018 0030 0018 0030 0018 0030 0018 0018 0018 0018 03E8
It will not tell you how many times it repeated.
(I’ll call this the ‘base code’)

The answer the GC Learner will give you with a low timeout setting (25 milliseconds) is the same.

The answer the GC Learner will give you with a higher timeout setting (35 milliseconds) is:

0000 0067 0000 0041 0060 0018 0018 0018 0018 0018 0018 0018 0030 0018 0030 0018 0018 0018 0018 0018 0030 0018 0030 0018 0030 0018 0018 0018 0018 03FC 0060 0018 0018 0018 0018 0018 0018 0018 0030 0018 0030 0018 0018 0018 0018 0018 0030 0018 0030 0018 0030 0018 0018 0018 0018 03FC 0060 0018 0018 0018 0018 0018 0018 0018 0030 0018 0030 0018 0018 0018 0018 0018 0030 0018 0030 0018 0030 0018 0018 0018 0018 03FC 0060 0018 0018 0018 0018 0018 0018 0018 0030 0018 0030 0018 0018 0018 0018 0018 0030 0018 0030 0018 0030 0018 0018 0018 0018 03FC 0060 0018 0018 0018 0018 0018 0018 0018 0030 0018 0030 0018 0018 0018 0018 0018 0030 0018 0030 0018 0030 0018 0018 0018 0018 0578
(I’ll call this the ‘long code’)

Which answer is right?

Well, the base code is technically correct in that it really captured the code in its purest form. If I send that code with as few as two or three repeats, it reliably operates the device. If a button were programmed to repeat the base code as long as it was pressed, I might be hard-pressed to hold it for a short enough period of time to repeat the code fewer than 2 or 3 times (each iteration takes ~45 milliseconds, so a quarter-second press would give you five repeats). Now if you are using the NRIR Server and Jon’s USB-UIRT driver to transmit this, you are in luck, ‘cause Jon’s transmitting driver is expecting the base code that Jon’s learning driver generates. If ‘hold-down button repeats’ is disabled, his driver will repeat the code exactly six times (hard-coded), (resulting in reliable operation of the device). And if ‘hold-down button repeats’ is enabled, his driver will repeat the code for as long as you hold down the button (resulting in reliable operation of the device when you hold down the button for more than a tenth of a second, and allowing repeating buttons, like volume-up to work the way they were intended).

But, what if you are using the GC to transmit?
Well then the answer depends for now on if you are using the PC or the PPC. If you are using the PPC, it seems to be expecting the base code, and has a fixed repeat count of eight. If you are using the PC, it seems to be expecting the long code, and does not repeat.

One of the first questions that come to mind when I was reading the details about the different formats for IR codes was “Where is the repeat-count stored in Pronto format?” If you have a base code, and it repeats as long as you hold down the button, it acts very much like a real remote control – you control the repeat count with the duration of your key press. You don’t need to store a repeat-count. However, in the case of this type of remote control, we don’t have a set of contacts to open and close for reliable starting and stopping of the transmission. We have instead button-up and button-down events. These seem to sometimes be lost, have delays in arrival over the network, or sometimes even arrive at their destination in the wrong order if they are too close together in time.

So what is the workaround? I see two so far:
1) Decide on a reasonable number of repeats to ensure a robust code transmission and have your base code repeated this fixed number of times. -- Jon’s USB-UIRT and the GC when driven by the PPC.
2) Store the long code, with the repeats built-in. One code with redundant information. (The GC when driven by the PC).

I am assuming that the directIR on the PPCs that support it use the long code method for learning and transmitting.


Ben,
Would you mind sounding in here and confirming or denying?

--Jim

Wilhelm,
Do you have a digital video camera? You can see the IR transmission with it. You can use it to see the duration of a non-repeating code emitted from the GC when driven by the PPC, and compare it to the duration of the same code from the GC when driven by the PC. I think you will find the duration of the transmission to be eight times longer for the PPC driven GC emission (ie, a 0.25 second emission (~7.5 frames) vs. 2 seconds (~60 frames)). Mine is very repeatable, but then again, hold-down button repeats work for you, but not for me…Perhaps the result will be telling.

Wilhelm
March 24th, 2005, 06:09 PM
Hi Jim,

this is all very nice, but far too detailed.
I really don't want to debug the different learning methods and don't want to analyze which learner is doing what before we do a simple test.

Please try this code in your environment. Question: Does this repeat properly on your GC (and by repeat I mean repeat when holding the button).?


0000 006d 0022 0002 0155 00aa 0016 0016 0016 003f 0016 0016 0016 003f 0016 003f 0016 003f 0016 003f 0016 0016 0016 003f 0016 0016 0016 003f 0016 0016 0016 0016 0016 0016 0016 0016 0016 003f 0016 0016 0016 003f 0016 0016 0016 003f 0016 003f 0016 0016 0016 0016 0016 0016 0016 003f 0016 0016 0016 003f 0016 0016 0016 0016 0016 003f 0016 003f 0016 003f 0016 05e6 0155 0055 0016 0e3d


If that's established we can go further. If not, there is something different between your an my setup.

Wilhelm
March 24th, 2005, 06:34 PM
... and after that you may try this:

these are the 2 denon amplifier volume codes I found in my iPAQ 3970 Nevo
I learned them with an iPAQ 3870 with NetRemote.
They both rpeat properly on my GC. I hope this will get us somewhere.

Ben S
March 24th, 2005, 08:01 PM
Hi guys,
I appreciate you guys going through this exercise.

If you can wait a week or two, I'll be re-focusing back on the IR code soon.

Thanks!

jameswing
March 24th, 2005, 09:26 PM
For Wilhelm's first sample code from 3+ hrs ago: Your code with 22 pairs for the intro sequence and two pairs for the repeat sequence: Following are pictures of what I get. The GC will not repeat, regardless of settings. It no longer repeats eight times when driven by the PPC (Either I was crazy for several reproductions, or something changed :oops: :evil: ) The GC does not act differently based on whether it is driven by the PC or the PPC. :-?

BTW, That code causes the UIRT to 'stick' on A LOT when repeats are enabled.

--Jim
Will try the others in a bit.

jameswing
March 24th, 2005, 10:02 PM
Son of a *****! Thanks Wilhelm! I only needed to try the first one to find the problem. It repeats fine on my GC too :D

I compared yours and mine and found the difference. I made a slight modification to yours to test, and sure enough... it won't repeat on GC now. What did I do, you ask? I added a beep to the button (before the IR code). It has no impact on the repeats with the UIRT, but it hoses the GC! Now that we know what the problem is, I assume that will get fixed pretty soon. AND, I can work around it in the meantime. Whoot! I am back on track! :D

Now should we move on to your funky code Wilhelm? ... in a new thread...

Thanks again Wilhelm for working with me to troubleshoot this!

--Jim

Wilhelm
March 25th, 2005, 03:20 AM
Yeah!

Jim, if you add a beep to the button, then you created a macro. Macros are not supposed to repeat. (I suppose) So the UIRT part is not behaving properly.
What a simple explanation for a big problem. :-)

jameswing
March 25th, 2005, 12:13 PM
hmmmmm.....
[envisioning the code executed on button-down event and on button-up event]

I can see where having more than one IR code being sent in a macro would require some complex coding if you wanted to allow repeats on anything other than the last IR code in the macro, but I would think it should allow at least the last IR code in the macro (which would usually be the ONLY IR code in the marcro) to repeat. If not, it will be useless to me. Nearly all of my keys will need to be macros, as they need to first select a driver/device/port/etc, then send the code.

For example: A TV control page would of course include channel selection buttons (IR to satellite dish controller from port 1 on the GC), volume controls (repeating IR from port 2 on the GC to the amplifier), and the monitor power button (generic TCP driver to send ASCII text to port 4999 on GC to send serial command to Plasma monitor).

I guess it all comes down to what Promixis thinks about whether or not we should be able to have a code in a macro repeat with GC. If they think not, they ain't a-gonnna make it happen, and I am wasteing my time :cry: .

--Jim

Wilhelm
March 25th, 2005, 03:26 PM
I don't think a button as you descibe it has to repeat, at leat not normally. There might be rare circumstances where it might be desirable, but to dismiss the whole program because of it is too hard in my opinion.
I am happy, that NR is one of the few programs that allows repeat at all.
Maybe you can work on some lua code for those events where the standard function does not suit you.

Anyway, have a nice easter, everybody

jameswing
March 25th, 2005, 07:04 PM
For the non-repeating codes I suppose I could use the GC learner with the timeout set high in order to learn the 'long code', but then if I send them via the USB-UIRT, they come out six times as long. :roll:

For the repeating codes I guess I could build a Lua solution... maybe...

If I could trigger an action on button-up, I could manually convert the codes to GC format and use the generic TCP plugin to send them to the GC with a very high fixed number of repeats, then send a 'stopir' command on button-up. I assume that is what is done internally when there is no macro involved.

That just seems kinda high maintenance and .... beta ....

The whole idea of the remote control with feedback and a nice reliable WiFi connection might be enough to make me do it anyway. This thing sure is cool. If only the bugs were worked out...

I gotta do a bit more research on what is involved in selecting a driver/device/port/etc, followed by sending the IR code, but I'm certain it will require more than one 'action' per button, and thus be a macro.

Ben,
What do you think about a repeating code in a Macro? If it is the last action in the macro, can we expect it to repeat via GC in a near-term release? Or am I just dreaming that such an idea would work anyway?
Secondly, can Lua be aware of a button-up event in NetRemote?

Thanks,

--Jim

midiringtones
March 25th, 2005, 11:44 PM
oh man oh man oh man!!! For the life of me I have wondered why my volume control won't repeat to my denon (I swore it used to work). I always figured it was a big introduced and just kept installing releases hoping it would be fixed (man is it hard to change volume pressing the button each time!).

turns out you guys discovered my problem is well! because I have a GC device, and a UIRT I have code telling it to use the GC and what port to use. Apparently it is now a "macro" and the source of my problem! I would have to argue we will need repeats, or more importantly, i way to say repeat this part of a button press but not the rest.

for now i will remove the GC controlling code, just make sure the button i pressed before that set the output to the GC!

thanks for making my life happier :)

Curt

Ben S
March 26th, 2005, 08:41 AM
Okay guys - I see where the current handling of this can be a problem for you guys, but the real problem is that handling of -time-, in general.

The code says "give me a count of all actions that are delays, beeps, or IR codes (including NetRemote actions) in this action group (including all button aliases, etc.).

The fact that NRIRServer repeats here is actually a bug in NetRemote (believe it or not), as nothing should repeat when there are multiple actions.

Take, for instance, a simple action list that includes 1) A delay of 5000 milliseconds and 2) An IR code.

NetRemote will wait 5 seconds, and then blast the IR code. At this point, NetRemote will only blast the code once (without repeat). If it did otherwise, it would wait 5 seconds, start blasting the code (with repeat), and send the code for 5 seconds during the delay while the button is down.

Now you could say that a Variable set (of the global cache port) happens almost immediately, but the plugin mechanism doesn't know if you're during that or calling an action that takes 10 seconds, so it counts -all plugin actions- as "time takers".

Can you guys help think of a proper workaround? I've never had a Pronto, but does it do this differently (only call delay or beep once)?

Wilhelm
March 26th, 2005, 03:19 PM
Hi Ben,

as far as I know, the Pronto doesn't repeat macros. Frankly I don't see how this could be made usefully. I can see, that switching to another output is something that should work independant of a macro, but determining from a macro which part should be repeated and which not would be more confusing than helping.
The Pronto manages switching the output when changing the panels but that could be probably also set on panel load.
I suppose switching output within a single macro is impossible for the Pronto.

And finnaly I think, switching output in every button before sending a single IR-code is not the right way to go anyway. There must be other ways to set the output which keeps
compatibility.

jameswing
March 26th, 2005, 03:30 PM
I'm trying to envision a workaround that wouldn't break any existing functionality.

Trying to figure out the existing requirements, I experimented with the following macro:
10 ms beep
2000 ms (2 sec) delay
~270 ms IR code

I quickly press and release the button one time:

[button down][button up]
Beep for 10 ms
Pause for 2 sec
Packets delivered to GC and GC blasts IR one time (~270 ms)

I rapid-fire clicky the button 3 times:

[button down][button up] [button down][button up] [button down][button up]
Beep for 10 ms
Pause for 2 sec
Packets delivered to GC and GC blasts IR one time (~270 ms)
Beep for 10 ms
Pause for 2 sec
Packets delivered to GC and GC blasts IR one time (~270 ms)
Beep for 10 ms
Pause for 2 sec
Packets delivered to GC and GC blasts IR one time (~270 ms)

I hold the button down for ~6 seconds:

[button down]
Beep for 10 ms
Pause for 2 sec
Packets delivered to GC and GC blasts IR one time (~270 ms)
Beep for 10 ms
Pause for 2 sec
Beep for 10 ms
Pause for 2 sec
Beep for 10 ms
[button up]
Pause for 2 sec
Packets delivered to GC, no IR (presumably a stopIR command)

Now the third scenario perplexes me a bit, (everything being repeated except the IR transmission... plus the packets sent after a delay to the GC iff the button-up event occurs after the macro has completed execution at least once) Is this intended, and I am just missing the reason? or should it not even repeat the macro when holding the button down?

--Jim

jameswing
March 26th, 2005, 03:59 PM
Just saw Wilhelm's post and wanted to put in my $0.02.

This thing is way more uber than a Pronto, and it would be a real bummer to limit it to one device per panel. As long as forward compatibility from Pronto is maintained, I don't think backward compatibility should be a consideration.

--Jim

jameswing
March 26th, 2005, 05:55 PM
Ok, just some brainstorming...
Given Ben's description, I see this grossly oversimplified pseudo-code:


enable_repeats=true (this is user-selectable)
max_repeats=100 (this is user-selectable)

function onButtonDown
if count(actions)>1 then isamacro=true
if (isamacro) or not(enable_repeats) then
repeats=1
else
repeats=max_repeats
end if
sendGC(repeats, code)
end function

function onButtonUp
if not(isamacro) and (enable_repeats) then sendGC(‘stopIR’)
end function


How about telling NetRemote that we want to repeat IR codes in a macro:
Create NetRemote variable: thisbutton.repeats -- type=boolean
and replace the above code with:

function onButtonDown
if count(actions)>1 then isamacro=true
if ((isamacro) and not(thisbutton.repeats)) or not(enable_repeats) then
repeats=1
else
repeats=max_repeats
end if
sendGC(repeats, code)
end function

function onButtonUp
if (not(isamacro) or (thisbutton.repeats)) and (enable_repeats) then
set thisbutton.repeats=false
sendGC(‘stopIR’)
end if
end function

Then we set up our CCF:
Action Group


set variable thisbutton.repeats=true
set device/driver/port
IR (to repeat until button-up)


Even more complex macros would still work... This one would repeat the first IR for a period (delay), then the second IR until button-up (or once if the button-up event has occured before it starts)
Action Group


set variable thisbutton.repeats=true
beep
IR (until next IR sent (see back-to-back IR commands in GC API) or until button-up, whichever is first)
delay (however long you would like the first IR to repeat)
IR (repeat until button-up)

Now I know it is oversimplified, but without seeing the source, it is the best I can come up with.

Ben
I would sign a non-disclosure agreement if you are interested in sending me the source-code. I would be more than happy to dive into this.

--Jim

Wilhelm
March 26th, 2005, 07:18 PM
Still thinking about you macro:



beep 10ms
delay 2s
IR Code


and you want to repeat it: If this would repeat you would have your first chance to stop the IR more than 2 sec.after it began.
So if we are talking synchronous running this macro you would have to wait 2,01 sec to get your first chance to stop the repeating GC. This is NOT an option. If you want to stop the repeating macro before it finishes it's loop, it would probably leave something in an undefined state. And when would you start the repeat? After the first macro cycle is run or what.

As I said, I still see the need to be able to change the output before a code is sent, but repeating a macro doesn't make any sense at all to me.

Using DirectIR sending this IR-repeat while repeating the macro is simply not possible, because the timing is highly critical. So it would even mean inconsistency between different IR outputs.

At best we could discuss repeating the last action in a macro. But what about a macro that switches to channel 123: Should we then repeat the 3 until the button is released?

I think this discussion is highly theoretical and this wouldn't make sense in real life.

So - if not already clear - I am AGAINST repeating macros.

Promixis
March 26th, 2005, 08:02 PM
Glad to know where you stand :D

And I agree. Macros shouldn't repeat. It just doesn't make sense (at least to me :))

jameswing
March 26th, 2005, 10:54 PM
Perhaps I wasn't clear. The macro wouldn't repeat. Only the IR code would repeat. Clearly one would not want a real macro to repeat anyway. 'Tis only those codes that are a macro only by technicality that one would even want the IR code to repeat. Repeating macros is silly.

The sample I used would not be used in reality, 'twas only an easy one to see what happens.

In any case, no, it wouldn't be 2 seconds before you got a chance to stop the code.you don't save up the amount of time the key is pressed. If you released the key in this example before the code started, it would transmit one time and stop. It simply waits 2 seconds before it starts due to the sample delay. As soon as you release the key, it sends a stopIR, just like any other repeating key.


At best we could discuss repeating the last action in a macro. But what about a macro that switches to channel 123: Should we then repeat the 3 until the button is released?
Obviously in this case you would not go out of your way to send the special 'thisbutton.repeats' code.

Methinks you didn't read my post carefully and assumed I jumped off the deep end.

So - if not already clear - I am not talking about repeating macros.

Oh, BTW... As it currently stands, the macro does repeat -- see the third test. It all repeats except the IR code. I agree that it probably should not.

Wilhelm
March 27th, 2005, 03:56 AM
Yes, I have seen that

Oh, BTW... As it currently stands, the macro does repeat -- see the third test. It all repeats except the IR code. I agree that it probably should not.
and I think it's a bug.

As I said, I can see what you are trying to do, but in my opinion it's far too complicated. Due to the compatibility issue with the Pronto, I think many things in NR are far too complicated to do.

If I understand you correctly, you are trying to do something before -or after- the IR codes gets sent and you only want the IR to repeat.

Many people seem to want a "keyclick" when a button is pushed, some people want to switch IR output and maybe something we can't think of yet.
If there is something changed, I would like it to be outside of the actions code of the button.

And remember Direct-IR isn't something hat can be started or stopped asynchonously, I know, Jim, you can't use it with your PPC but I suppose many people do.

Perhaps a lua interface on ButtonPush and ButtonRelease would be a way to go?

BTW. Beep is still not working on the PPC or is it?

jameswing
March 27th, 2005, 08:34 AM
And remember Direct-IR isn't something [t]hat can be started or stopped asynch[r]onously, I know, Jim, you can't use it with your PPC but I suppose many people do.

Yeah, it occurred to me this morning that directIR might not work the same way as the GC, (instead requiring actual intervention and synchronous timing from NetRemote,) and that if such were the case, the whole idea would be pooched. :(


If I understand you correctly, you are trying to do something before -or after- the IR codes gets sent and you only want the IR to repeat. Yup. This is easy with GC. You can tell it 'Repeat this code until I tell you to stop, or until I give you another code to send, while I go about my business,' and it will dutifully execute. But since I have exactly zero experience with directIR on the PPC, I'll certainly take your word for it that it isn't feasible with directIR.

I was approaching this from exactly the opposite angle of yours, Wilhelm. I was figuring the only way to keep compatibility with the CCF format was to do it inside the actions code of the button, the same way we currently select a driver/device/port, or set other NetRemote variables. I don't see how you could associate a device/driver/port/etc with a button outside of the buttons 'actions'. Got any ideas?

I think I like the Lua option, but I am not sure if Lua is 'aware' of button-up events, and if it uses triggers and such. Anybody want to weigh-in on that? or point me to some good samples of Lua for me to start my studies... :)

--Jim

jameswing
March 27th, 2005, 08:38 AM
oh... yeah... beep does not work on my PPC.
(The beep isn't in my macro for a beep, it is just a placeholder for now for the command to set the driver/device/port)
--Jim

Ben S
March 28th, 2005, 10:14 PM
Hi James-
Perhaps the new designer will allow such things in the future, but for now it's not possible to designate certain parts of the macro as repeating.

Additionally, only IR actions are disabled for repeating, all other actions will repeat appropriately during a macro.

If this is unexpected, I can disable repeat for all "macros" where more than one action is undefined. I'll need to see how people are currently using this to see if that's possible/warranted, however.

Regarding beep: It should work, but at a (possibly incorrect) timing. This doesn't work for either of you guys?

Wilhelm
March 29th, 2005, 02:01 AM
Regarding beep: It should work, but at a (possibly incorrect) timing. This doesn't work for either of you guys?

nope, doesn't do anything on 3850 PPC2002, haven't tested with others for a long long time.

Concerning the repeat of macros, it doesn't bother me at the moment, but I find it illogical that they repeat at all. What good should it do to repeat "part" of a macro?

jameswing
March 29th, 2005, 10:57 PM
Thanks Ben.

I have not tested the beep over a wide range of pitch and duration so I cannot say for certain, but no worky so far. Will try some more later.

As for the repeating of the macro, I gotta agree with Wilhelm that it doesn't make sense to repeat a macro. (Though I don't see a 'repeating' IR code as 'repeating' in the same sense of the word, but that is another debate.) In any case, I hardly see it ever being an issue anyway. You got way more important issues to deal with. :wink:

As a workaround for the 'No repeating IR codes in a button with more than one action' rule, I will try to build a lua script to execute on button-down (sendir....), and another to execute on button-up (stopir) and see if I can make that work for selecting a device/port/etc, followed by a repeating code. Volume buttons, here I come!

--Jim