On November 12, 2012 at 18:35, Lowhz said...
For IR commands that do not need to have immediate response like 10-key, cursor, channel, menu, etc. the advantage is that the RF gateway is open a fraction of the time for the MSC trigger than it would be for the RF signal from the remote. The remote's RF signal includes the preamble and the command at least once (sometimes 3 or more times) and the entire time that RF command is being received the gateway is open. The longer the gateway is open the more chance there is for local RF noise to cause the command to fail.
For commands that need high performance and response time like volume up, down and mute then that can be passed directly through as the MSC will impart a slight but perceptible latency that is kind of annoying. The chance that you will have RF noise and failure is greater because the gateway is open during the entire time that button is pressed, but to have failure on every command (like number pad) is more annoying.
^^^ this is the reasoning I was looking for, thank you for that. This is the first I've heard this despite being present in about a dozen URC trainings over the years.
Besides, why would you double your work and build macros inside the MSC and build macros from the remote? That seems like a lot of extra work and program management when almost everything you need to do with the system can be executed by the MSC.
That's what I do, macros are always on the MSC side activated by triggers commands on the remote. I was merely confused about the reasoning for single IR commands to exist as trigger commands...your explanation makes sense. Thanks again.
