What TwistedMelon said...

You don't see the latency? Fine. As I said it could be a bad batch of remotes.

The latency is coming from the remote and has nothing to do with the base station. When set to IR/RF or RF only, the remote sends the codes using that hardware protocol.

As TwistedMelon stated this latency issue is less than 1 second. Most people wouldn't even notice it. But to someone who is sensitive to slight anomalies/delays like this issue, will definitely see it. Like me, TwistedMelon, and several others. Including URC.

Same theory as to why some people aren't sensitive to the rainbow effect on DLP TVs. Also some people never notice the refresh rate flicker seen on CRT monitors when it's set to 60 Hz or less. Those effects drive me nuts.

So you don't see the latency. URC technicians can see it. They tested it and confirmed that there was an issue. It must just be us...

Not trying to argue with you here Mitch...more trying to see if I can replicate the issue both in-house (literally) and in the field. I'd say we have a far greater sampling than most as the MX-980 is the only remote we've sold from URC for the past 3 years. We also use this remote with Crestron RF gateways in Crestron systems.

Now granted our systems never utilize IR via line of site for any device and IMO having the programming set to IR/RF is bad juju...and why bother.

That being said you surely will see a bit of latency when using RF via a gateway/processor or base station due to the processing time involved and the time it takes to convert back to IR and send over the emitter. That will always be a longer response time than IR line of sight.

To your point though I'm wondering if when set to IR/RF the remote processes the RF output first and then IR...that could be creating some latency that you are seeing. It's possible the remote can't handle outputting both simultaneously.

Just curious...In your system, are you set to IR/RF but the devices are visible too?

Yes. My equipment is all line of site. As I stated here and in other posts I noticed this when I switched from using an MX-900 to MX-980. On the MX-900 there is no latency at all and all the devices are set to both IR/RF.

On the MX-980 if I set the devices to anything other than IR I get the latency on all devices. As one would expect, I thought it might be RF interference on the MRF-350. That's what led me to take the MRF-350 out of the picture and see if the problem persisted. And indeed, it did.

When the 980 is set to both IR/RF and the MRF-350's power is unplugged, I get the latency. If I plug power back into the MRF-350 and set the devices to RF only I get the latency. I've verified that there is no RF interference on the MRF-350. No solid red LED lights or flickering LED lights on the MRF-350. I've also tried setting the MRF-350 to several different IDs.

If I set the 980 to IR only the problem goes away. Regardless whether or not the MRF-350 is plugged in or not. Again, I want to emphasize that I see none of these issues with the MX-900 controlling the exact same equipment.

If you do a search on remotecentral you will see that several other people are experiencing this same issue. One poster stated that on his 980 everything was fine until he updated his CCP and downloaded it to his remote. He can't recall exactly which update caused the problem but he thinks it was one of the last two.

It's also possible that this issue is related only to a certain batch of remotes. Which would explain why you're not seeing the issue on any of your remotes.

How old is the remote that you're using in house? For reference purposes I purchased mine on 4/19/12. We could compare serial numbers as a method of determining the manufacture date.

Mine is B580112 0100937

There's also another set of numbers under the "Win CE .NET 4.2 Core" label. They are:

00039-496-641-966
X11-15297

Again, URC has escalated this to their engineers so there must be an issue. At least with some of the remotes. Maybe the newer ones.

having the programming set to IR/RF is bad juju...and why bother.

I would agree in the case of a real device, where you don't want to transmit the exact same command via both RF and IR on the same button press.

But URC remote are not in fact device nor activity specific. Their layouts are made of of generic pages which can be used for literally anything you want, limited only by your imagination and within the constraints of the options available within the CCP software.

So take for example a set of pages that one sets up as an activity where multiple devices are being controlled, some via RF and some via IR. You must declare that set of pages in the RF panel as being either IR or RF or both.

The problem of latency will be especially pronounced on devices that otherwise react especially quickly and where the reaction is immediately visible. For example something like a tuner/DVR where switching screens or jumping channels would otherwise be very quick. With the SagetTV setup I described originally (using RC5 codes), setting the MX-980 up for RF, whether it's transmitting the encoded IR strings or firing a simple trigger to the MSC-400, the latency is pretty much unbearable for navigation and transport controls. The default short skip on this device is 10 seconds, so when you introduce close to a half a second of latency per button press, this gets to be incredibly annoying. The same goes for navigating through its menus.

The other troublesome effect is that button repeating can be problematic via RF for some devices. I'm currently having some troubles with my DVDO Edge scaler, though I haven't spent any amount of time trying to diagnose/correct that particular issue yet.

The URC remote unfortunately have these latency issues plus other more basic IR issues such as the inability to dissect protocols, including repeats. It means a lot of fiddling with the setup.programming that should not have to be done.

For my TV/Media Wtaching activity, I'm currently using RF routing for all devices except the SageTV extender since the other devices don't reflect the latency in an appreciable manner. That includes TV, Pre-amp, scaler/switcher, roller motor and three separate sets of lights. The pre-amp is a combination of RF to RS-232 and IR while all the others are RF to IR.

TwistedMelon,

You might want to try an MX-900 in your system as a test. I see no latency when I use mine in my system. On my MX-900 all of my devices are set to IR/RF. I am controlling the exact same components with the exact same configurations on both devices. With the exception of graphics and screen layouts of course.

Any idea why there would be such a difference between these two? I would think the 980 would be able to handle this more capably then the 900.

URC really needs to do better in this regard. This is a pretty fundamental requirement for an RF capable remote I would think.

The one I have at home was first put in service Feb. 2011 according to my records. Serial number is B620308 0002966.




Regarding controlling multiple devices from within a single device page. There's still no reason to be setting anything to IR/RF, that's just asking for trouble. If you are referencing commands for a device that is line of sight IR via a page for a device that is hidden from view and controlled via RF you should be aliasing the IR device (and that device's setting will follow)...you shouldn't be copy/pasting a command in this instance. You need to alias it...the commands will follow properly via IR or RF. I stand by my statement that having the control set to IR/RF is bad juju and even worse juju if you have a device visible to the controller.

To be clear, I was simply giving an example. I don't have any groups of pages set to IR/RF and all activity pages use aliases and smart macros, only specific "device" pages contain database and learned IR.

To suggest that a configuration be put together in a certain way is fine, but if it doesn't behave when created a different way, it's because of URC bugs and implementation issues, not because someone is configuring the remote incorrectly.

The RF/IR option exists for a reason,so if someone were using it, that's fair game IMO, and it should also work.

I observe latency issues with any and all methods of transmitting RF.

Just to echo Twistedmelon, I've been observing the same behavior in my MX-980 for a number of weeks now. Prior to that, RF signals from the MX-980 were transmitted without a substantial delay. Now I'm guessing there is a 500-700 ms delay between pressing a button, and the MRF-350 transmitting it. There is no interference observed on the unit.

I hadn't made any changes to my remote or updated CCP in probably close to a year. A couple of weeks ago I added a single button to one of my devices, and at the same time allowed CCP to update.

After I uploaded the changes, I observed the problem.

I tried again last night to switch everything to RF, and I still observe the problem.

It's strange that Tweeterguy has not been able to reproduce the latency issue on his remotes. This does make me think that it might be isolated to a certain batch of remotes AND one of the latest CCP updates.

I'll be giving URC another call this week. Hopefully they will have made some progress on this problem.

Does the MX980 have the same latency problems with used with a MRF260 or a MSC400? The 260 has it's RF receiver built into the case and the MSC400 uses the same antenna as the MRF350.

The reason I ask this is because the firmware in the remote may currently be written to insert a 500ms - 700ms delay after the button press to let the RF gateway of the base station open before it receives the command and then closes. If it is in the remote then the 260 will behave the same way when passing RF>IR and the MSC400 will behave the same way when receiving a trigger from the handset before executing the command.

The serial numbers indicate the manufacture date of any URC product:
Tweeterguy's sn is B620308 0002966 which indicates manufacturing code "B62" which is a 418mhz MX980 "0308" which is March 2008 build date and "0002966" which is the actual serial number in that batch.

Mitch57's sn is B580112 0100937 where B58 is either a 433mhz 980 OR a different hardware revision of the 418mhz because his manufacture date is January 2012, 4 years after Tweeterguy, and this could mean anything: different board components, new WinCE framework version, different factory.

I'm using MSC-400 with a single RFX-250 receiver.

Date-code on my MX-980: B580810 - it's a 418MHz model, not the 433MHz "i" model.

Update!

I called URC twice this week. Once on Thursday and again on Friday.

On Thursday I gave the escalation case number to the tech who answered the phone. I had him read it back to me and low and behold, it wasn't even the same issue I had described to them almost two months ago. I gave him the name of the original tech I talked to and he said he would talk to him and call me back. Of course, as usual, that return phone call never came.

I called again on Friday and this time asked for Joe Salvatore who is the tech support manager. I got his voice mail so I left him a message. He got right back to me within an hour.

I explained the problem with the MX-980 latency issue and he was fully aware of the problem and said that there were others who had also called in with the same problem. He told me that the Engineers were in fact working on a fix and indicated he thought a resolution would be available soon.

Joe is a great guy and when I explained my frustration with not getting other techs to address the problem or return my phone calls, he said he would definitely address those issues with his department. He assured me that he would call me as soon as the fix was available. He also stated that I would probably see it via a CCP update before he could call me to notify me of the fix. But he said he would call me either way.

I was very impressed with Joe's professionalism and above board performance in trying to get to the bottom of the issue.

Job well done Joe! Let's just hope the Engineers find a fix soon.

Let us know when you hear back from URC because if the update comes out there's no way I'll know about it since I'm currently using direct IR for the devices I need real-time control of.

I will post an update on the situation as soon as I hear from Joe.

There was a CCP update today.

I think it's fixed. It feels faster to me.