NI4100 IR Problem

elytronic

We just got a call from a customer that said that 2 tvs do not respond from their corresponding R4 remotes. Here is how the system is designed: NI4100 with 2 x NXC-IRS4 controlling 8 tvs and various BD players around the house and also some more IR devices in the rack. Other systems are connected by IP and RS232 but not relevant to this problem.

The customer called and said two tvs do not work. He then told us that the two emitters on the tvs have stayed red i.e there is constant voltage going to them. We told him to reboot the NI and the problem was fixed.

I do not know if these ports are the native IR ones and all of them had constant voltage or if they are on one of the cards and only those two had problems or the whole card.

Have you ever seen this? Constant voltage going to the emitters? What could have cause this?

P.S. Thank god we use blinking emitters otherwise we might needed much more time to diagnose this.

vining

That could also be code related such as th e R4 sending a push and the master never seeing a release. With R4's it's a good idea to put something in the hold event handler to timeout any holds.

Something like:

     HOLD[2, REPEAT]:
	  {
	  STACK_VAR INTEGER nBtn ;
        
	  nBtn = BUTTON.INPUT.CHANNEL ;
	  SELECT
	       {
	       ACTIVE(nBtn == 46 || nBtn == 47):
		    {
		    if(BUTTON.HOLDTIME <= 5000)  
			 {
			 SWITCH(nBtn)
			      {
			      CASE 46:  {fnQueue_QCmd("CMD_MVOL,PARAM_MVOL[MV_UP]") 	}// Volume +
			      CASE 47:  {fnQueue_QCmd("CMD_MVOL,PARAM_MVOL[MV_DOWN]") 	}// Volume -
			      }
			 }
		    else
			 {
			 DO_RELEASE(vTPcom,nBtn) ; //nBtnArry[nBtn]) ;
			 }
		    }
	       ACTIVE(1):
		    {
		    //
		    }
	       }
	  }

This isn't exactly what I mean but you can get the idea. If the button is held longer than the button.holdtime number the code forces a release to prevent runaway code caused by missed releases from the R4 device which can happen when the gateway buffer overflows for what ever reason.

DHawthorne

You may be grateful for blinking emitters now, but I have found them to be unreliable for AMX use. Maybe it's just the brand I use, but they seem to draw a touch more current than the IR port likes to provide. Short runs are less of a problem, but anything not in the same cabinet/rack space and I flat out refuse to use them. I would even go as far as to suggest the blinking emitter may have caused the trouble in the first place.

It's also entirely possible I had a few bad experiences and let it color my actions past the point where it was needed, and such emitters are not really an issue anymore. Take it for what it's worth: a caution and heads-up.

yanbin

I have the same problem in an Ni2100, after reboot the controller, problem fixed, but still could not find out what cause this problem.

John Nagy

We've used visible XANTECH emitters for many years, and never had a STUCK ON event such as this, nor problems with long (200+ ft) runs. Not saying that our experience makes it work everywhere.

Auser

vining wrote: »

That could also be code related such as th e R4 sending a push and the master never seeing a release. With R4's it's a good idea to put something in the hold event handler to timeout any holds.

[...]

This isn't exactly what I mean but you can get the idea. If the button is held longer than the button.holdtime number the code forces a release to prevent runaway code caused by missed releases from the R4 device which can happen when the gateway buffer overflows for what ever reason.

+1. I use R4's at home and suspect that this is the most likely scenario in your case. Every couple of weeks I'll get a runaway volume ramp as the master hasn't seen the button release from the R4 as mentioned.

If it's a volume up/down code, you'll likely have a fair idea what's going on. If the master misses a release from a different (non-repeating) code like a digit then what you've described is exactly what I'd expect to see.

There is a certain case under which an IR port will remain high after sending an IR code, but this is almost entirely unlikely in this case and sending a different IR code clears that condition.

the8thst

I posted this at IP for you, but I will reiterate here:

I have had a few instances where an IR file somehow became corrupted during transfer to the IR device. In my case it was a directv file and the power off code was corrupted so the output stayed on after the code was emitted.

Rebooting fixed the issue until the power off command was sent again, but resending the IR file did not fix it. Finally I sent a blank IR file to the device and then resent the directv file and everything has been perfect since.

I think the IR device was a built in port on a 3100, but there is a small possibility it might have been an IRS4 card in a ICS shell (this was about a year ago).

elytronic

Just an update on this which we have still not solved and we still have problems:

After the reboot last week the system came back normal and everything has been ok since today ok but we do not really know how much it is being used. The problem is we got a call today and the problem is still there.

We checked all our R4 files and we do not have any commands where we use "push and hold" so the NI not seeing a release is not the problem. I was actually hoping this was the problem since this is the easiest to troubleshoot.

The only thing we can do now is what my friend the8thst suggested and I really hope that my programmer has not done this yet and this will solve it one and for good. If we have already done this also and we still have problems then I really do not know how to tackle the troubleshooting.

I am thinking the only way to continue - if the above fails or has already failed - is to go on site when the problem occurs and get the logs from the processor when the ports are high. From what I know everytime you reboot the processor you loose the logs so in order to see the problem we have to visit when the prblem is happening. Is there anything we can do with logging so that we help with the troubleshooting and finally undertand where the problem comes from and solve it?

Thanks for the help so far - all advice has been very valuable and is helping with the troubleshooting.

elytronic

Auser wrote: »

If the master misses a release from a different (non-repeating) code like a digit then what you've described is exactly what I'd expect to see.

Can you please expand more on this? How can the master miss a release from a non repeating code? Isn't the code just a pulse? From what I understand the master is not expecting a release in this case.

There is a certain case under which an IR port will remain high after sending an IR code, but this is almost entirely unlikely in this case and sending a different IR code clears that condition.

Can you explain more on this? Maybe we are unlucky and we got this. How do we solve it?

vining

You may not be using "HOLD" but are you using any "TO"s? That would create the same affect if no release is received by the master.

Yeah, pulse is just a .5sec push/release.