User

20.06.2016 03:43:41

Hi,

I experience a strange and for me crucial issue with the Apple Remote (Built-in IR Receiver) connected to a Mac mini (2011) currently running Mountain Lion.

I need to control a mechanical device with a start and a stop signal: starting to press the corresponding button of the Apple Remote should send a start signal to the device, releasing the button should send a stop signal, so that the mechanical device is active as long as I press the button of the Apple Remote.

This sounds like the easiest and most natural thing in the world, but unfortunately, I just cannot get it to work.

The mechanical device is connected via Ethernet, i.e. it is controlled by network commands. There is an OS X command line utility (let’s call it mycmd) which allows to send start and stop commands to the device.

So I constructed a fitting behavior with 1 action. The action uses 2 AppleScript steps: 
Execute on button press: do shell script "/usr/local/bin/mycmd start" 
Execute on button release: do shell script "/usr/local/bin/mycmd stop" 
As I said, the simplest thing in the world.

And indeed, everything works as expected if I test this with the Script Remote Virtual Remote, with a script like this:

tell application "Remote Buddy" to scriptremote button "plus" event "press" 
delay 3 
tell application "Remote Buddy" to scriptremote button "plus" event "release"

When I run this script, "/usr/local/bin/mycmd start" is immediately invoked; 3s later, "/usr/local/bin/mycmd stop" is invoked. Just as it should be.

HOWEVER, as soon as I use the Apple Remote instead and press the Plus button for 3s, "/usr/local/bin/mycmd start" is immediately invoked (as it should be), and then, only 100ms-200ms later, "/usr/local/bin/mycmd stop" is invoked – no matter how long I actually press the button.

I tried everything I could think of to debug this, and, among many other things, replaced "/usr/local/bin/mycmd start" and "/usr/local/bin/mycmd stop" with "logger start" and "logger stop". Looking at the syslog, I found to my big surprise that in this case, the Apple Remote DOES work as expected, i.e. the "stop" appears in the syslog exactly when I release the button of the Apple Remote. (Of course, the Script Remote Virtual Remote works as well.)

So, to sum up:

Script Remote & logger WORKS (stop is sent when the button is released) 
Script Remote & mycmd WORKS (stop is sent when the button is released) 
Apple Remote & logger WORKS (stop is sent when the button is released) 
Apple Remote & mycmd DOES NOT WORK (stop is sent 100ms-200ms after start)

I.e. every combination works except the one combination I actually need. :-(

I have no idea what happens here. mycmd is a very simple command line utility that basically just sends a few bits over a network interface. Controlling something via the local network should not be anything special nowadays.

The action is assigned to the Global mapping, and Remote Buddy Preferences > General > Advanced > "Manually activated Behaviors stay active until they are explicitely deactivated" is checked, so it’s not an issue of another behavior taking over.

But what is it? From my debugging, I can only assume that it’s a deep rooted bug somewhere within the Apple Remote specific code (in contrast to the Script Remote code).

But how can I work around this? Using an IR remote to start/stop a device over the network really isn’t an exotic task, is it?

Last edited: 20.06.2016 03:44:03

Last edited: 20.06.2016 03:46:28

Last edited: 20.06.2016 03:49:44

Last edited: 20.06.2016 03:55:15 

User

20.06.2016 09:32:02

Here are a few thoughts:

1) the Apple Remote uses IR - light outside the visible spectrum - whereas Wi-Fi uses radio technology, so the two can't possibly physically interfere.

2) on the driver level, there is no connection between the driver for the Apple IR Receiver and the Wi-Fi driver, so I can't see how they'd possibly interfere with each other

3) I'd usually suggest to exchange the Apple Remote battery - and you might still give this a try just to rule this out as a possibly factor - but IF the Apple Remote works consistently (!) reliable (!) otherwise, this may not be necessary

4) looking at the big picture, the only difference between working and non-working scenarios is that the non-working scenario involves a mechanical device - which could possibly have physical effects that might interfere the IR spectrum used by the Apple Remote to transmit commands to the Mac's IR Receiver. This is what the Apple Remote sends for a single button press:

[IR command: button X pressed] 
[IR command: repeat] 
[IR command: repeat] 
... 
[IR command: repeat] 
[IR command: repeat] 
[IR command: button released]

After receiving a [button press] command, Remote Buddy expects the [repeat] commands to arrive within a certain time frame. If it does not arrive, it treats the button press as if it had ended. So if even a single one of the repeat signals gets corrupted due to IR interference - and can no longer be decoded by the Apple IR Receiver due to that - the button press will end at the end of said time frame.

Chances are the mechanical device you're using is emitting infrared radiation, thereby interferes with the Apple Remote's IR signals and leads to the premature end of the button press.

When looking for possible IR sources that might interfere, keep in mind that heat can also be a source. More here: https://en.wikipedia.org/wiki/Infrared

5) Another possibility would be that you're trying to use the Apple Remote from too far a distance or that there's not a direct line of sight when you try to control the mechanical device.

6) Other options that aren't vulnerable to IR interference would be Remote Buddy Mobile (Wi-Fi, free on the App Store) or a Sony PS3 BD Remote (Bluetooth, sells for around 20€).

Hope that helps. 

User

20.06.2016 11:27:00

Thanks for your reply!

Turns out it is indeed something like “IR interference”.

When describing the issue, I omitted one “detail” that in all my testing never occurred to me could be the root of all evil:

The mechanical device itself is controlled via IR. I.e. what actually happens when I press the Apple Remote button is that Remote Buddy sends a network signal to an IRTrans network device which in turn issues an IR signal to control the mechanical device (a motor driven volume control of a stereo amplifier).

Now, the reason that this obvious source of trouble never came to my mind before I read your reply is that when I used the original IR remote control for the amplifier, nothing at all ever got triggered on my Mac mini (and vice versa), so I always thought these two IR receivers are completely isolated from each other.

But it seems the signal the IRTrans device sends is MUCH stronger than that of the original IR remote control for the amplifier: even when I wrapped the IRTrans device in paper now to test the possible IR interference, the issue still occurred. Only when I put the IRTrans device into another room (!), it stopped. So maybe the issue is not even an identical pulse sequence, but some kind of “overdriving” or, as you put it, interference?

I have no experience with IR technology. If this was a problem with a radio controlled device, I would try different carrier frequencies, channels etc. But from what I can see, there are no comparable settings here.

Isn’t the IR receiver in the Mac mini assumed to react only to IR signals of a “paired” device (which the Apple Remote is, and the IRTrans of course is not)? Also, I use the IRTrans device for various other tasks, too, and it never triggers anything in Remote Buddy except this button release signal (but it triggers the release signal for all buttons of the Apple Remote, not just the “Plus” button in my example).

From your experience with IR devices, is there anything I could try, or do I simply have to give up on using an Apple Remote to control the volume of my stereo amplifier?

Last edited: 20.06.2016 11:29:48

Last edited: 20.06.2016 11:30:05 

User

20.06.2016 11:46:13

Sorry, my first reply to your post was probably a bit premature, too, as I was so excited to finally have found the source of the issue.

Rereading point 4 of your reply carefully, it seems clear that a simple corruption of repeat signals is most probably the issue, not a specific, coincidentally identical pulse sequence etc.

Is there, by any chance, a hidden defaults setting in Remote Buddy to control the “tolerance” for missing repeat signals? If it’s really corrupted repeat signals, I would think this is the only thing that might help.

 
Can you tell me how long this time frame is?

Thanks in advance for your reply!

Last edited: 20.06.2016 11:47:37

Last edited: 20.06.2016 11:47:53

Last edited: 20.06.2016 11:53:27 

User

20.06.2016 12:19:59

To elaborate on my thoughts:

Just as you described in point 4 of your reply for the Apple Remote, the IRTrans device ALSO sends IR [repeat] commands to the stereo amplifier until Remote Buddy tells it to stop via the command line utility.

If the time between these repeat commands is similar to the time period with which the Apple Remote sends repeat commands, it’s clear these signals will overlap rather sooner than later. (This is why I asked with which time period the Apple Remote sends repeat commands.)

BUT, assuming that e.g. the Apple Remote period is 100ms, if I chose something like 75ms for the IRTrans repeat period, there could never be an overlap on two successive signals. This means that IF I could tell Remote Buddy to tolerate 1 missing repeat command, it should work, at least theoretically. 

User

28.06.2016 09:36:01

 
 
There are, in fact, different wavelengths, but almost all consumer IR uses the same wavelength (the only company I've heard of using a different wavelength is Bang & Olufsen).

To the IR Receiver, there are pretty much just two states: pulse (where IR light is received) and space (where none is received). As soon as you have multiple devices emit IR pulses at the same time, the IR Receiver will no longer be able to decode it.

 
The Apple IR Receiver does decoding in hardware (there's no way to access pulse/space lengths) and also offers some filtering options regarding the Apple Remote IDs (0-255) sent with every button press. But this still requires that what it receives is decodable at all.

 
This is because, as the Apple IR Receiver can no longer decode what it receives, it has to assume the button on the Apple Remote is no longer pressed.

 
Unfortunately, I don't see a possibility to use two IR senders at the same time without them interfering the pulse-space-sequences of each other and subsequently make decoding them essentially impossible.

 
There are several different time frames for the various stages of an Apple Remote command - and the "release" code can be sent at any time.

 
It's a good and valid idea in theory, but in practice I'd assume it to not be possible. There are too many variables and parts to this solution for it to align perfectly on such small time frames. 

User

14.07.2016 08:10:59

Thanks a lot for your reply and your detailed explanations!

 
Yes, I see that you are most probably correct on this one. I liked the idea of using Apple’s aluminum remote control very much simply because it has such a beautiful design, which is unlike any other remote control, and fits the Mac mini perfectly.

But now that I’ve switched to Remote Buddy Mobile instead, I have to say that this app matches the beauty of the Apple Remote hardware on a software level. It is really a perfect remote control solution with everything you could wish for, so I’m really happy with this solution.

The funny thing is that I originally bought Remote Buddy just to be able to use an IR remote control …