Multiple IR devices on one port

jez

Hi,

What issues (if any) are there with having more than one IR file associated with a given IR port? I am running out of IR and would like to double up on some ports. I think this should work but what happens with things like where file1.irl and file2.irl have codes in exclusive slots so, for example, if a code in file1.irl sits in slot 10 but there is no ir code in slot 10 in file2.irl, then will the IR fire? I guess the same applies if you have two IR files each with their own codes in the same slot - I expect both codes get fired to both emitters at the same time.

What issues are there if you start playing with timing, using send_command instead of pulse etc?

Is the best strategy to make a combined IR file that is a mutually exclusive combination of the codes for each device?

Many thanks in advance

Jez

Jimweir192

I don't think you can load multiple files to the same port, the second write will overwrite the first.

If you want to do this you'll have to paste the commands into one master file and load this, you can put the commands in any available slots in the file, although obviously it will no longer match the standard template.

You can double up the emitters on 1 port, but watch out as firing the wrong IR at a device can sometimes cause wierd behaviour...

Much better to buy the extra IR ports you need - look for an old Accent3 Pro and use that in slave mode...

DHawthorne

You can combine IR files; I used to do it all the time. Use IREdit to cut the codes from one file, then paste them to the other in unused channels ... you just have to keep track of what channels are used for what devices.

A few warnings :

1) Make good and sure they are completely incompatible devices, because both emitters are going to output for either device and you don't want one being changed when you wanted the other.
2) Only do this with fairly short emitter runs. You've just cut the output in half per emitter. Better yet, use something like a Xantec or Niles emitter block to make sure both have high enough output.

I really try hard not to do this if I can at all help it; it just gets confusing having custom IR files for different customers, and I would rather have my files generic and reusable. However, in a pinch and on a tight budget, it does work.

Spire_Jeff

DHawthorne wrote: »

I really try hard not to do this if I can at all help it; it just gets confusing having custom IR files for different customers, and I would rather have my files generic and reusable. However, in a pinch and on a tight budget, it does work.

I agree, we almost never do this any more. It just creates extra work for us and any changes that happen in the future are all the more difficult. The client never appreciates the effort, and most likely never pays for the extra programming required. If you take into account all of the extra time spent combining IR files, and then figuring out how to handle things all over again when the client gets a new cable box 6 months later, most of the time everyone is better off just purchasing the extra IR ports necessary. Be this with an expansion hub/card, a second processor, or upgrading an NI-3100 to an NI-4100 and adding a couple of IR cards. Think of it this way: Either the client pays for additional hardware, or they pay for additional programming and troubleshooting. In the end, the only one that will likely suffer for this attempt to save the customer money is you and your business. (At least in my experience )

Jeff

Darkside

jez wrote: »

Hi,

What issues are there if you start playing with timing, using send_command instead of pulse etc?

Is the best strategy to make a combined IR file that is a mutually exclusive combination of the codes for each device?

Jez

Depending on what's going on, your code potentially might try to talk to both devices at once, or a couple of users could force this same condition, so, you must deal with this 'probable' timing issue and I would recommend using the SP command to do so.

In the event that two codes are output at once and you haven't 'dealt' with the issue, one or the other - sometimes both commands won't work.

ericmedley

Stephen Bolton wrote: »

Depending on what's going on, your code potentially might try to talk to both devices at once, or a couple of users could force this same condition, so, you must deal with this 'probable' timing issue and I would recommend using the SP command to do so.

In the event that two codes are output at once and you haven't 'dealt' with the issue, one or the other - sometimes both commands won't work.

Actually, the incoming new channel pulse cancels out the existing one, I think.

I've combined IR files on many occasions too. It seems designers run to the control system first whenever they need to trim out some money. So, being able to control an entire TV setup with one IR emmiter saves them some bucks on the bottom line.

I kinda built my own queue to handle collisions at the IR port. It generally works since we never use the TV's built in audio. We either use a surround processor or use the Distributed House Audio System. So, you never get a continuously held volume and channel +- or whatever trying to happen at the same time. The only time collisions can occur is at power up/down. So, I control the traffic for the power sequence and then give it back to the user once the tubes are warmed up.

jez

Thanks for the replys. I have found the most reliable thing to do (save get more IR ports) is to combine the IR file but the comments that this takes more programming time and can introduce hardware issues are taken 100%.

So far it seems to be working fine but it's not an ideal - some extra ports are on the cards I think!

Many thanks again!

jez