I'm only using a single RFX-250. The second one was only used for testing purposes and in the end picked up far too much interference itself - but didn't cause interference to be received by the first unit.

As FP Crazy mentions, when there is any interferences that's likely to affect the RFX-250, its second LED will light up - dimmly or brightly. I am currently getting solid RF performance, but the lack of interference has not improved the latency issues. And I have managed to decisively prove that the latency is on the remote end at least in some situations by watching both talk-balk LEDs on other devices and listening for audio feedback on my pre-amp, which I've mentioned is picking up any cable talk on the MSC-400.

I did find another MSC-400 issue however.

Any time you trigger a Smart Macro on the MSC-400 from the MX-980, an IR burst goes out to *ALL* attached IR emitters, regardless of your port settings on the MSC-400 or MX-980.

The IR burst is short and is not the full sequence being processed in the smart macro. I've tested it with a repeating sequence and it doesn't continue to blast IR to all ports.

What I haven't done yet is connect a learner to one of the emitters to capture what is being blasted.

Sure a little might show up here and there when connected to an MSC. Trust me, put a 350 base station behind the RFX and you will get a completely different result when checking for interference on channel zero.

Unfortunately I sold the 350 I had, so I can't test that scenario.

I'd expect the MSC-400 to work correctly, not send out random bits of IR on ports it's not supposed to be using.

I think there's one additional caveat to what I previously wrote, but I can't recall what it is right now - it was late when I tested this originally. Will update once I look at it again.

From 2008:
[Link: remotecentral.com]
This has been wrong for a long time...

I don't get it! It's a documented URC issue! Escalation report number ESC-911.

Those CI's that claim it doesn't exist haven't updated their CCP and downloaded it to the remotes in the field. It's also been documented in at least one thread here on remote central that this problem started happening consistently with one of the latest CCP updates.

Before you claim this "Latency" issue is not a problem with the MX-980 check the facts. I would like to challenge those who have a 980 and equipment to test with, to update their CCP software to the latest version and then download to MX-980. Take any/all base stations out of the picture. Set the 980 to either IR/RF or just RF.

I'm betting you will see the latency. You can further test this by changing the 980 back to "IR" only and you will see that the remote has very little to no latency what so ever. Again, take all base stations completely out of the picture when you're doing these tests.

If any of you determine that there is no issue then it's a hardware issue on a specific batch of remotes.

That's funny. "Your escalation number is (hmm let me pull this out of thin air and make it sound really important so this guy will shut up)...yep here it is, ESC-911". Almost sounds legit lol

Yah. I thought the same thing when URC gave me the number. Believe it or not, that IS the number URC gave me. Is it a legit escalation case number? Who knows. I'm going to give them another week or two and then try contacting some other people at URC that might be able to provide more input on the issue.

For you CIs out there, does URC blow smoke up your butt when complain about problems with their products and support?

Of course. They are all the same; there are a few exceptions.

BTW, here is (most of) my install. At least what's visible when you're looking away from the sectional in the room. The video was shot before any/much decor was put onto the shelves:

[Link: twistedmelon.com]

Some pendants behind the camera are also connected to the MSC-400, plus LED lighting inside the glass cabinets (white and RGB) and on the top shelf above the entire setup (RGB) which can't be seen.

Not true. As I've stated we have dozens and dozens of MX-980s in the field and believe me if there was in issue, I'd hear about it. SO, just out of curiosity...and since you are calling us CI's out I have an MX-980 at home with me to test your theories.


What good does it do to have the remote set to RF only...if you want us to


?


What's the bet? Because I see no latency when the remote is set to IR/RF with no base station.


Done. Still not sure what you're expecting to see if you take the base station out but have the remote set only to RF.

I've had this at home for a week, using it on my daily use system. Works just fine. Programmed via CCP with latest update on a Mac via VMWare Fusion in case you're wondering that too.

Must be new to electronics! If I had a dime for every time a supplier said "never heard of that before" or "you're the only one having that problem" I'd be a rich, rich man!

If you have the capability to analyze what's coming out of the remote with a scope or other instrument, then you don't need a base station, and it may be possible, depending on how you're testing, to observe the latency differences between IR and RF output. Even in a perfect situation without any software/hardware issues, RF will never (can never) be as fast as straight IR. There's an additional translation layer (transmit AND receive) introduced, which inherently adds some, even if minimal, latency to the entire process.

There are a lot of variables at play here, but in any case, regardless of how many MX-980's one has in the field, I would not expect that many, perhaps even most consumers would notice the difference one way or the other. Most people aren't going to notice problems that aren't extremely obvious. ie. Most people have no eye for small details. And as CI, I would expect that these installs were finished so that glaring issues would not be present.

None of this changes the fact that the remotes and base stations/master controllers have these issues. I was a professional software and hardware tester for years, now I design and develop the same. If I mention an issue like this, especially in public, and it is confirmed by historical data and current observation by third parties, you can be sure, 100% sure, it exists and able to be reproduced as outlined.

OK so post up your results from using your scope and RF analyzer.
Test one, IR only. Test two, RF only. Test three, remote set to IR/RF but testing the IR output.

I'll get right on that. Probably sometime after I get back from cashing the fat check URC is no doubt sending me for my time.