Which IR transceiver to get?

[jed-9]

Well I've been doing some reading but I've gotten to a point where I can't quite decide which transceiver to get.
I've narrowed it down to these four:

BC4+BCX-1 ---Bitwise Controls http://www.bitwisecontrols.com/products.php
IRTrans Ethernet http://www.irtrans.de/en/shop/lan.php
CommandIR II http://www.commandir.com/content/view/32/48/
USB-IR transceiver ---IguanaWorks http://iguanaworks.net/

Global cache is ruled out as I've seen no mention of development for Linux on their site.
Also I'm not sure the last one is really a contender because it's very light on features compared to the others...

Then again, despite having many features the IRTrans device does have one big knock against it that this one doesn't.
It's built-in transmitter only has one port....

This port can have up to 6 emitters, but you can only output the same code-set simultaneously via those emitters.
A second port can be added, but even then one cannot transmit two different code-sets from the two ports (via emitters) at the same time!

I'd love to hear peoples thoughts/experiences surrounding these devices, which you'd recommend and why!

Thanks heaps,
Jed
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

[Kyle McKay-4]

I have an IguanaWorks iguanaIR hybrid -- it's the USB stick  
configuration with one built-in IR emitter and a socket to plug in one  
or two additional IR emitters (it's available in other variations -- 2  
built-in emitters or up to 4 plug-in emitters).  All variations  
include a built-in IR receiver.

I've used it quite successfully with lirc on Mac OS X and am very  
happy with it -- the source code including the device firmware itself  
is fully open source.  I have successfully used irrecord to create a  
new profile and irsend to then control the device with that profile.

If you choose an iguanaIR, make sure you have lirc 0.8.6 or later and  
the iguanaIR-1.0pre1.tar.bz2 driver (which includes the 0306 firmware  
-- the device firmware is user-reflashable) for the most stable  
operation.  I've also found that it works best in threaded mode with  
libusb-1.0.3 (or later) together with libusb-compat-0.1.3 (or later)  
rather than using libusb-0.1.12 -- at least that's the case on Mac OS X.

I chose the iguanaIR device because it is very small, is USB bus  
powered, works with libusb, is open source and allows me to plug in an  
IR extender (I'm using a leftover TiVo IR extender I have that works  
well with it).

It does have some limitations.  You cannot simultaneously send &  
receive -- this is mostly transparent to the end user -- the receiver  
simply does not receive anything while actively transmitting.  After  
transmitting, the receiver starts picking up again.  Also, although  
you can transmit on any combination of the (up to 4) emitters  
simultaneously, you cannot transmit different codes on different  
emitters simultaneously.

Hope that helps,

Kyle

On Oct 13, 2009, at 07:41, Jed <jedi.theone@...> wrote:

> Well I've been doing some reading but I've gotten to a point where I  
> can't quite decide which transceiver to get.
> I've narrowed it down to these four:
>
> BC4+BCX-1 ---Bitwise Controls http://www.bitwisecontrols.com/products.php
> IRTrans Ethernet http://www.irtrans.de/en/shop/lan.php
> CommandIR II http://www.commandir.com/content/view/32/48/
> USB-IR transceiver ---IguanaWorks http://iguanaworks.net/
>
> Global cache is ruled out as I've seen no mention of development for  
> Linux on their site.
> Also I'm not sure the last one is really a contender because it's  
> very light on features compared to the others...
>
> Then again, despite having many features the IRTrans device does  
> have one big knock against it that this one doesn't.
> It's built-in transmitter only has one port....
>
> This port can have up to 6 emitters, but you can only output the  
> same code-set simultaneously via those emitters.
> A second port can be added, but even then one cannot transmit two  
> different code-sets from the two ports (via emitters) at the same  
> time!
>
> I'd love to hear peoples thoughts/experiences surrounding these  
> devices, which you'd recommend and why!
>
> Thanks heaps,
> Jed

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

[Michelle Dupuis]

I highly recommend the IRTrans.  Expensive but excellent.

They have an IP version (plug into network) and USB version.  Both are Lirc
compatible, and more....

-----Original Message-----
From: Kyle McKay [mailto:mackyle@...]
Sent: Tuesday, October 13, 2009 11:42 AM
To: lirc-list@...
Subject: Re: Which IR transceiver to get?

I have an IguanaWorks iguanaIR hybrid -- it's the USB stick configuration
with one built-in IR emitter and a socket to plug in one or two additional
IR emitters (it's available in other variations -- 2 built-in emitters or up
to 4 plug-in emitters).  All variations include a built-in IR receiver.

I've used it quite successfully with lirc on Mac OS X and am very happy with
it -- the source code including the device firmware itself is fully open
source.  I have successfully used irrecord to create a new profile and
irsend to then control the device with that profile.

If you choose an iguanaIR, make sure you have lirc 0.8.6 or later and the
iguanaIR-1.0pre1.tar.bz2 driver (which includes the 0306 firmware
-- the device firmware is user-reflashable) for the most stable operation.
I've also found that it works best in threaded mode with
libusb-1.0.3 (or later) together with libusb-compat-0.1.3 (or later) rather
than using libusb-0.1.12 -- at least that's the case on Mac OS X.

I chose the iguanaIR device because it is very small, is USB bus powered,
works with libusb, is open source and allows me to plug in an IR extender
(I'm using a leftover TiVo IR extender I have that works well with it).

It does have some limitations.  You cannot simultaneously send & receive --
this is mostly transparent to the end user -- the receiver simply does not
receive anything while actively transmitting.  After transmitting, the
receiver starts picking up again.  Also, although you can transmit on any
combination of the (up to 4) emitters simultaneously, you cannot transmit
different codes on different emitters simultaneously.

Hope that helps,

Kyle

On Oct 13, 2009, at 07:41, Jed <jedi.theone@...> wrote:

> Well I've been doing some reading but I've gotten to a point where I
> can't quite decide which transceiver to get.
> I've narrowed it down to these four:
>
> BC4+BCX-1 ---Bitwise Controls
> BC4+http://www.bitwisecontrols.com/products.php
> IRTrans Ethernet http://www.irtrans.de/en/shop/lan.php
> CommandIR II http://www.commandir.com/content/view/32/48/
> USB-IR transceiver ---IguanaWorks http://iguanaworks.net/
>
> Global cache is ruled out as I've seen no mention of development for
> Linux on their site.
> Also I'm not sure the last one is really a contender because it's very
> light on features compared to the others...
>
> Then again, despite having many features the IRTrans device does have
> one big knock against it that this one doesn't.
> It's built-in transmitter only has one port....
>
> This port can have up to 6 emitters, but you can only output the same
> code-set simultaneously via those emitters.
> A second port can be added, but even then one cannot transmit two
> different code-sets from the two ports (via emitters) at the same
> time!
>
> I'd love to hear peoples thoughts/experiences surrounding these
> devices, which you'd recommend and why!
>
> Thanks heaps,
> Jed

----------------------------------------------------------------------------
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the
only developer event you need to attend this year. Jumpstart your developing
skills, take BlackBerry mobile applications to market and stay ahead of the
curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

[jed-9]

I have been very impressed with their responsiveness.

Very hard to get much feedback from many of the other vendors but Marcus
has responded to my dozens & dozens of questions even though he's not
yet made a sale.

Michelle Dupuis wrote:

> I highly recommend the IRTrans.  Expensive but excellent.
>
> They have an IP version (plug into network) and USB version.  Both are Lirc
> compatible, and more....
>
> -----Original Message-----
> From: Kyle McKay [mailto:mackyle@...]
> Sent: Tuesday, October 13, 2009 11:42 AM
> To: lirc-list@...
> Subject: Re: Which IR transceiver to get?
>
> I have an IguanaWorks iguanaIR hybrid -- it's the USB stick configuration
> with one built-in IR emitter and a socket to plug in one or two additional
> IR emitters (it's available in other variations -- 2 built-in emitters or up
> to 4 plug-in emitters).  All variations include a built-in IR receiver.
>
> I've used it quite successfully with lirc on Mac OS X and am very happy with
> it -- the source code including the device firmware itself is fully open
> source.  I have successfully used irrecord to create a new profile and
> irsend to then control the device with that profile.
>
> If you choose an iguanaIR, make sure you have lirc 0.8.6 or later and the
> iguanaIR-1.0pre1.tar.bz2 driver (which includes the 0306 firmware
> -- the device firmware is user-reflashable) for the most stable operation.
> I've also found that it works best in threaded mode with
> libusb-1.0.3 (or later) together with libusb-compat-0.1.3 (or later) rather
> than using libusb-0.1.12 -- at least that's the case on Mac OS X.
>
> I chose the iguanaIR device because it is very small, is USB bus powered,
> works with libusb, is open source and allows me to plug in an IR extender
> (I'm using a leftover TiVo IR extender I have that works well with it).
>
> It does have some limitations.  You cannot simultaneously send & receive --
> this is mostly transparent to the end user -- the receiver simply does not
> receive anything while actively transmitting.  After transmitting, the
> receiver starts picking up again.  Also, although you can transmit on any
> combination of the (up to 4) emitters simultaneously, you cannot transmit
> different codes on different emitters simultaneously.
>
> Hope that helps,
>
> Kyle
>
> On Oct 13, 2009, at 07:41, Jed <jedi.theone@...> wrote:
>> Well I've been doing some reading but I've gotten to a point where I
>> can't quite decide which transceiver to get.
>> I've narrowed it down to these four:
>>
>> BC4+BCX-1 ---Bitwise Controls
>> BC4+http://www.bitwisecontrols.com/products.php
>> IRTrans Ethernet http://www.irtrans.de/en/shop/lan.php
>> CommandIR II http://www.commandir.com/content/view/32/48/
>> USB-IR transceiver ---IguanaWorks http://iguanaworks.net/
>>
>> Global cache is ruled out as I've seen no mention of development for
>> Linux on their site.
>> Also I'm not sure the last one is really a contender because it's very
>> light on features compared to the others...
>>
>> Then again, despite having many features the IRTrans device does have
>> one big knock against it that this one doesn't.
>> It's built-in transmitter only has one port....
>>
>> This port can have up to 6 emitters, but you can only output the same
>> code-set simultaneously via those emitters.
>> A second port can be added, but even then one cannot transmit two
>> different code-sets from the two ports (via emitters) at the same
>> time!
>>
>> I'd love to hear peoples thoughts/experiences surrounding these
>> devices, which you'd recommend and why!
>>
>> Thanks heaps,
>> Jed
>
>
> ----------------------------------------------------------------------------
> --
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the
> only developer event you need to attend this year. Jumpstart your developing
> skills, take BlackBerry mobile applications to market and stay ahead of the
> curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

[jed-9]

Thanks Kyle!

> I have an IguanaWorks iguanaIR hybrid -- it's the USB stick  
> configuration with one built-in IR emitter and a socket to plug in one  
> or two additional IR emitters (it's available in other variations -- 2  
> built-in emitters or up to 4 plug-in emitters).  All variations  
> include a built-in IR receiver.

I didn't realise it could power up to eight emitters via 4 transmitter
ports. Do you know if the built-in receiver it 36-40Khz or just 38Khz?

>
> I've used it quite successfully with lirc on Mac OS X and am very  
> happy with it -- the source code including the device firmware itself  
> is fully open source.  

I don't think the device firmware is open on the IRtrans, not sure about
the other devices.

> I have successfully used irrecord to create a  
> new profile and irsend to then control the device with that profile.
>
> If you choose an iguanaIR, make sure you have lirc 0.8.6 or later and  
> the iguanaIR-1.0pre1.tar.bz2 driver (which includes the 0306 firmware  
> -- the device firmware is user-reflashable)

Pretty sure the IRTrans fw is flashable & it also has a built-in webface
for config etc. Not sure how functional it is...

> for the most stable  
> operation.  I've also found that it works best in threaded mode with  
> libusb-1.0.3 (or later) together with libusb-compat-0.1.3 (or later)  
> rather than using libusb-0.1.12 -- at least that's the case on Mac OS X.
>
> I chose the iguanaIR device because it is very small, is USB bus  
> powered, works with libusb, is open source and allows me to plug in an  
> IR extender (I'm using a leftover TiVo IR extender I have that works  
> well with it).

I do like it's small size, shame I don't have any USB ports at the front
of my current PC enclosure. USB powered is a nice touch, less clutter.
What's an IR extender? Not sure if the IRTrans or others can do that.

> It does have some limitations.  You cannot simultaneously send &  
> receive -- this is mostly transparent to the end user -- the receiver  
> simply does not receive anything while actively transmitting.  After  
> transmitting, the receiver starts picking up again.  

I don't think the IRTrans has this limitation, not sure about the others.

> Also, although  
> you can transmit on any combination of the (up to 4) emitters  
> simultaneously, you cannot transmit different codes on different  
> emitters simultaneously.

The IRtrans model I'm considering is also limited in this way.
It doesn't have CommandIR's "parallels device blasting"
i.e. sending 4 diff. code-sets at once to 4 diff. devices.
I think it might be a bit of a gimmick though...

> On Oct 13, 2009, at 07:41, Jed <jedi.theone@...> wrote:
>> Well I've been doing some reading but I've gotten to a point where I  
>> can't quite decide which transceiver to get.
>> I've narrowed it down to these four:
>>
>> BC4+BCX-1 ---Bitwise Controls http://www.bitwisecontrols.com/products.php
>> IRTrans Ethernet http://www.irtrans.de/en/shop/lan.php
>> CommandIR II http://www.commandir.com/content/view/32/48/
>> USB-IR transceiver ---IguanaWorks http://iguanaworks.net/
>>
>> Global cache is ruled out as I've seen no mention of development for  
>> Linux on their site.
>> Also I'm not sure the last one is really a contender because it's  
>> very light on features compared to the others...
>>
>> Then again, despite having many features the IRTrans device does  
>> have one big knock against it that this one doesn't.
>> It's built-in transmitter only has one port....
>>
>> This port can have up to 6 emitters, but you can only output the  
>> same code-set simultaneously via those emitters.
>> A second port can be added, but even then one cannot transmit two  
>> different code-sets from the two ports (via emitters) at the same  
>> time!
>>
>> I'd love to hear peoples thoughts/experiences surrounding these  
>> devices, which you'd recommend and why!
>>
>> Thanks heaps,
>> Jed

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

[CommandIR Support]

On Wed, 2009-10-14 at 02:13 +1000, Jed wrote:
> > Also, although  
> > you can transmit on any combination of the (up to 4) emitters  
> > simultaneously, you cannot transmit different codes on different  
> > emitters simultaneously.
>
> The IRtrans model I'm considering is also limited in this way.
> It doesn't have CommandIR's "parallels device blasting"
> i.e. sending 4 diff. code-sets at once to 4 diff. devices.
> I think it might be a bit of a gimmick though...

A differentiator, not a gimmick.  I spent weeks ironing out multi-blast
with LIRC last year.

Matthew

--
CommandIR Support <commandir@...>





------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

[Kyle McKay-4]

On Oct 13, 2009, at 09:13, Jed wrote:

> Thanks Kyle!
>
>> I have an IguanaWorks iguanaIR hybrid -- it's the USB stick  
>> configuration with one built-in IR emitter and a socket to plug in  
>> one  or two additional IR emitters (it's available in other  
>> variations -- 2  built-in emitters or up to 4 plug-in emitters).  
>> All variations  include a built-in IR receiver.
>
> I didn't realise it could power up to eight emitters via 4  
> transmitter ports. Do you know if the built-in receiver it 36-40Khz  
> or just 38Khz?

Maybe I said that wrong.  It can have up to two sockets each of which  
can have 1 or 2 emitters plugged in so 4 maximum emitters.  The  
receiver is 38 kHz only, but the transmitter supports a range of  
frequencies.

>> I've used it quite successfully with lirc on Mac OS X and am very  
>> happy with it -- the source code including the device firmware  
>> itself  is fully open source.
>
> I don't think the device firmware is open on the IRtrans, not sure  
> about the other devices.
>
>> I have successfully used irrecord to create a  new profile and  
>> irsend to then control the device with that profile.
>> If you choose an iguanaIR, make sure you have lirc 0.8.6 or later  
>> and  the iguanaIR-1.0pre1.tar.bz2 driver (which includes the 0306  
>> firmware  -- the device firmware is user-reflashable)
>
> Pretty sure the IRTrans fw is flashable & it also has a built-in  
> webface for config etc. Not sure how functional it is...
>
>> for the most stable  operation.  I've also found that it works best  
>> in threaded mode with  libusb-1.0.3 (or later) together with libusb-
>> compat-0.1.3 (or later)  rather than using libusb-0.1.12 -- at  
>> least that's the case on Mac OS X.
>> I chose the iguanaIR device because it is very small, is USB bus  
>> powered, works with libusb, is open source and allows me to plug in  
>> an  IR extender (I'm using a leftover TiVo IR extender I have that  
>> works  well with it).
>
> I do like it's small size, shame I don't have any USB ports at the  
> front of my current PC enclosure. USB powered is a nice touch, less  
> clutter.
> What's an IR extender? Not sure if the IRTrans or others can do that.

Sorry, I just mean the standard IR blaster on a long cable.  Like one  
of these:

http://www3.tivo.com/assets/images/buytivo/products/tivogear/accessories/IR%20control%20cable/full_ircontrolcable.jpg

>> It does have some limitations.  You cannot simultaneously send &  
>> receive -- this is mostly transparent to the end user -- the  
>> receiver  simply does not receive anything while actively  
>> transmitting.  After  transmitting, the receiver starts picking up  
>> again.
>
> I don't think the IRTrans has this limitation, not sure about the  
> others.

It has this limitation because it just has one CPU in it and the  
receiver generates interrupts during reception.  Since the transmit  
carrier is software generated, if receiver interrupts were allowed  
during transmission, you might end up transmitting corrupted codes as  
the timing would be affected by the receiver interrupts.

Any other IR transceivers with a similar architecture likely share  
this issue -- it's worth testing if it's important to your setup.

>> Also, although  you can transmit on any combination of the (up to  
>> 4) emitters  simultaneously, you cannot transmit different codes on  
>> different  emitters simultaneously.
>
> The IRtrans model I'm considering is also limited in this way.
> It doesn't have CommandIR's "parallels device blasting"
> i.e. sending 4 diff. code-sets at once to 4 diff. devices.
> I think it might be a bit of a gimmick though...

I'm not sure this is actually an issue in reality because I believe  
that lirc effectively pipelines send requests to the same device so if  
you tried to issue two irsend commands at the same time, one would end  
up waiting for the other to complete before transmitting -- worth  
verifying though.

Kyle

>> On Oct 13, 2009, at 07:41, Jed <jedi.theone@...> wrote:
>>> Well I've been doing some reading but I've gotten to a point where  
>>> I  can't quite decide which transceiver to get.
>>> I've narrowed it down to these four:
>>>
>>> BC4+BCX-1 ---Bitwise Controls http://www.bitwisecontrols.com/products.php
>>> IRTrans Ethernet http://www.irtrans.de/en/shop/lan.php
>>> CommandIR II http://www.commandir.com/content/view/32/48/
>>> USB-IR transceiver ---IguanaWorks http://iguanaworks.net/
>>>
>>> Global cache is ruled out as I've seen no mention of development  
>>> for  Linux on their site.
>>> Also I'm not sure the last one is really a contender because it's  
>>> very light on features compared to the others...
>>>
>>> Then again, despite having many features the IRTrans device does  
>>> have one big knock against it that this one doesn't.
>>> It's built-in transmitter only has one port....
>>>
>>> This port can have up to 6 emitters, but you can only output the  
>>> same code-set simultaneously via those emitters.
>>> A second port can be added, but even then one cannot transmit two  
>>> different code-sets from the two ports (via emitters) at the same  
>>> time!
>>>
>>> I'd love to hear peoples thoughts/experiences surrounding these  
>>> devices, which you'd recommend and why!
>>>
>>> Thanks heaps,
>>> Jed

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

[jed-9]

apologies bad choice of word.

CommandIR Support wrote:

> On Wed, 2009-10-14 at 02:13 +1000, Jed wrote:
>>> Also, although  
>>> you can transmit on any combination of the (up to 4) emitters  
>>> simultaneously, you cannot transmit different codes on different  
>>> emitters simultaneously.
>> The IRtrans model I'm considering is also limited in this way.
>> It doesn't have CommandIR's "parallels device blasting"
>> i.e. sending 4 diff. code-sets at once to 4 diff. devices.
>> I think it might be a bit of a gimmick though...
>
> A differentiator, not a gimmick.  I spent weeks ironing out multi-blast
> with LIRC last year.
>
> Matthew

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

[jed-9]

>>> Also, although  you can transmit on any combination of the (up to 4)
>>> emitters  simultaneously, you cannot transmit different codes on
>>> different  emitters simultaneously.
>>
>> The IRtrans model I'm considering is also limited in this way.
>> It doesn't have CommandIR's "parallels device blasting"
>> i.e. sending 4 diff. code-sets at once to 4 diff. devices.
>> I think it might be a bit of a gimmick though...
>
> I'm not sure this is actually an issue in reality because I believe that
> lirc effectively pipelines send requests to the same device so if you
> tried to issue two irsend commands at the same time, one would end up
> waiting for the other to complete before transmitting -- worth verifying
> though.

Yeah this is what was explained to me, so I'm not sure how CIR's
parallel device blasting would actually work in that case...

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

[CommandIR Support]

On Wed, 2009-10-14 at 03:28 +1000, Jed wrote:

> >>> Also, although  you can transmit on any combination of the (up to 4)
> >>> emitters  simultaneously, you cannot transmit different codes on
> >>> different  emitters simultaneously.
> >>
> >> The IRtrans model I'm considering is also limited in this way.
> >> It doesn't have CommandIR's "parallels device blasting"
> >> i.e. sending 4 diff. code-sets at once to 4 diff. devices.
> >> I think it might be a bit of a gimmick though...
> >
> > I'm not sure this is actually an issue in reality because I believe that
> > lirc effectively pipelines send requests to the same device so if you
> > tried to issue two irsend commands at the same time, one would end up
> > waiting for the other to complete before transmitting -- worth verifying
> > though.
>
> Yeah this is what was explained to me, so I'm not sure how CIR's
> parallel device blasting would actually work in that case...

Since I'm following the thread, hopefully I can help clarify.

The CommandIR driver is different from the others in that it doesn't use
separate LIRC instances / driver instantiations for each of the IR
blasters, always just 1, so it doesn't benefit from LIRC pipelining to
the driver.  

In order to transmit different signals on each emitter at the same time,
CommandIR has it's own pipe-lining.  Has to keep all the data streams
coming so the TX doesn't get starved.  There may be a better technical
way to do it now, but at the time each hardware device was assumed to
have 1 transmitter and 1 modulator.

This design makes it real easy to officially support up to 16 IR
emitters (4 CommandIRs), since plugging in more CommandIRs is invisible
to LIRC and the user.  A couple of the well known US set-top-box
manufacturers use CommandIR arrays (and LIRC) for testing - without the
extra parallel pipelining, they'd be testing sequentially; or managing
up to like /dev/lirc255+ ...

(Aside, the hardware's a bit overboard with 4 modulators too, capable of
transmitting different frequencies on each emitter at the same time (ie
control a 56K device, and a 38K device, plus 2 more devices, while still
receiving IR commands from a remote, or an IR emitter placed over the
receiver).  So I can probably even say that not every home needs one, as
like many speciality & commercial/industrial-graded goods.)

Hope that clarifies; just wanted to keep the answer with the question on
the list.  Cheers,

Matthew

--
CommandIR Support <commandir@...>


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

[jed-9]

>>>>> Also, although  you can transmit on any combination of the (up to 4)
>>>>> emitters  simultaneously, you cannot transmit different codes on
>>>>> different  emitters simultaneously.
>>>> The IRtrans model I'm considering is also limited in this way.
>>>> It doesn't have CommandIR's "parallels device blasting"
>>>> i.e. sending 4 diff. code-sets at once to 4 diff. devices.
>>>> I think it might be a bit of a gimmick though...
>>> I'm not sure this is actually an issue in reality because I believe that
>>> lirc effectively pipelines send requests to the same device so if you
>>> tried to issue two irsend commands at the same time, one would end up
>>> waiting for the other to complete before transmitting -- worth verifying
>>> though.
>> Yeah this is what was explained to me, so I'm not sure how CIR's
>> parallel device blasting would actually work in that case...
>
> Since I'm following the thread, hopefully I can help clarify.
>
> The CommandIR driver is different from the others in that it doesn't use
> separate LIRC instances / driver instantiations for each of the IR
> blasters, always just 1, so it doesn't benefit from LIRC pipelining to
> the driver.  
>
> In order to transmit different signals on each emitter at the same time,
> CommandIR has it's own pipe-lining.  Has to keep all the data streams
> coming so the TX doesn't get starved.  There may be a better technical
> way to do it now, but at the time each hardware device was assumed to
> have 1 transmitter and 1 modulator.
>
> This design makes it real easy to officially support up to 16 IR
> emitters (4 CommandIRs), since plugging in more CommandIRs is invisible
> to LIRC and the user.  A couple of the well known US set-top-box
> manufacturers use CommandIR arrays (and LIRC) for testing - without the
> extra parallel pipelining, they'd be testing sequentially; or managing
> up to like /dev/lirc255+ ...
>
> (Aside, the hardware's a bit overboard with 4 modulators too, capable of
> transmitting different frequencies on each emitter at the same time (ie
> control a 56K device, and a 38K device, plus 2 more devices, while still
> receiving IR commands from a remote, or an IR emitter placed over the
> receiver).  So I can probably even say that not every home needs one, as
> like many speciality & commercial/industrial-graded goods.)
>
> Hope that clarifies; just wanted to keep the answer with the question on
> the list.  Cheers,
>
> Matthew

Was away for a few days, thanks for clarifying this!
Still not quite sure this would benefit me in any way...

I intend to learn all my consumer electronics IR codes using a
transceiver + LIRC. Then I hope to use a Wifi Hand-held + HTPC + LIRC +
Transceiver to issue commands to all gear within range.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

[jed-9]

>>>>>> Also, although  you can transmit on any combination of the (up to
>>>>>> 4) emitters  simultaneously, you cannot transmit different codes
>>>>>> on different  emitters simultaneously.
>>>>> The IRtrans model I'm considering is also limited in this way.
>>>>> It doesn't have CommandIR's "parallels device blasting"
>>>>> i.e. sending 4 diff. code-sets at once to 4 diff. devices.
>>>>> I think it might be a bit of a gimmick though...
>>>> I'm not sure this is actually an issue in reality because I believe
>>>> that lirc effectively pipelines send requests to the same device so
>>>> if you tried to issue two irsend commands at the same time, one
>>>> would end up waiting for the other to complete before transmitting
>>>> -- worth verifying though.
>>> Yeah this is what was explained to me, so I'm not sure how CIR's
>>> parallel device blasting would actually work in that case...
>>
>> Since I'm following the thread, hopefully I can help clarify.
>> The CommandIR driver is different from the others in that it doesn't use
>> separate LIRC instances / driver instantiations for each of the IR
>> blasters, always just 1, so it doesn't benefit from LIRC pipelining to
>> the driver.
>> In order to transmit different signals on each emitter at the same time,
>> CommandIR has it's own pipe-lining.  Has to keep all the data streams
>> coming so the TX doesn't get starved.  There may be a better technical
>> way to do it now, but at the time each hardware device was assumed to
>> have 1 transmitter and 1 modulator.
>>
>> This design makes it real easy to officially support up to 16 IR
>> emitters (4 CommandIRs), since plugging in more CommandIRs is invisible
>> to LIRC and the user.  A couple of the well known US set-top-box
>> manufacturers use CommandIR arrays (and LIRC) for testing - without the
>> extra parallel pipelining, they'd be testing sequentially; or managing
>> up to like /dev/lirc255+ ...
>>
>> (Aside, the hardware's a bit overboard with 4 modulators too, capable of
>> transmitting different frequencies on each emitter at the same time (ie
>> control a 56K device, and a 38K device, plus 2 more devices, while still
>> receiving IR commands from a remote, or an IR emitter placed over the
>> receiver).  So I can probably even say that not every home needs one, as
>> like many speciality & commercial/industrial-graded goods.)
>>
>> Hope that clarifies; just wanted to keep the answer with the question on
>> the list.  Cheers,
>>
>> Matthew
>
> Was away for a few days, thanks for clarifying this!
> Still not quite sure this would benefit me in any way...
>
> I intend to learn all my consumer electronics IR codes using a
> transceiver + LIRC. Then I hope to use a Wifi Hand-held + HTPC + LIRC +
> Transceiver to issue commands to all gear within range.

Matt, could you explain how this might be advantageous for my usage
scenario?  Thanks!

Cheers,
Jed

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

[jed-9]

>>>>>>> Also, although  you can transmit on any combination of the (up to
>>>>>>> 4) emitters  simultaneously, you cannot transmit different codes
>>>>>>> on different  emitters simultaneously.
>>>>>> The IRtrans model I'm considering is also limited in this way.
>>>>>> It doesn't have CommandIR's "parallels device blasting"
>>>>>> i.e. sending 4 diff. code-sets at once to 4 diff. devices.
>>>>>> I think it might be a bit of a gimmick though...
>>>>> I'm not sure this is actually an issue in reality because I believe
>>>>> that lirc effectively pipelines send requests to the same device so
>>>>> if you tried to issue two irsend commands at the same time, one
>>>>> would end up waiting for the other to complete before transmitting
>>>>> -- worth verifying though.
>>>> Yeah this is what was explained to me, so I'm not sure how CIR's
>>>> parallel device blasting would actually work in that case...
>>>
>>> Since I'm following the thread, hopefully I can help clarify.
>>> The CommandIR driver is different from the others in that it doesn't use
>>> separate LIRC instances / driver instantiations for each of the IR
>>> blasters, always just 1, so it doesn't benefit from LIRC pipelining to
>>> the driver. In order to transmit different signals on each emitter at
>>> the same time,
>>> CommandIR has it's own pipe-lining.  Has to keep all the data streams
>>> coming so the TX doesn't get starved.  There may be a better technical
>>> way to do it now, but at the time each hardware device was assumed to
>>> have 1 transmitter and 1 modulator.
>>>
>>> This design makes it real easy to officially support up to 16 IR
>>> emitters (4 CommandIRs), since plugging in more CommandIRs is invisible
>>> to LIRC and the user.  A couple of the well known US set-top-box
>>> manufacturers use CommandIR arrays (and LIRC) for testing - without the
>>> extra parallel pipelining, they'd be testing sequentially; or managing
>>> up to like /dev/lirc255+ ...
>>>
>>> (Aside, the hardware's a bit overboard with 4 modulators too, capable of
>>> transmitting different frequencies on each emitter at the same time (ie
>>> control a 56K device, and a 38K device, plus 2 more devices, while still
>>> receiving IR commands from a remote, or an IR emitter placed over the
>>> receiver).  So I can probably even say that not every home needs one, as
>>> like many speciality & commercial/industrial-graded goods.)
>>>
>>> Hope that clarifies; just wanted to keep the answer with the question on
>>> the list.  Cheers,
>>>
>>> Matthew
>>
>> Was away for a few days, thanks for clarifying this!
>> Still not quite sure this would benefit me in any way...
>>
>> I intend to learn all my consumer electronics IR codes using a
>> transceiver + LIRC. Then I hope to use a Wifi Hand-held + HTPC + LIRC
>> + Transceiver to issue commands to all gear within range.
>
> Matt, could you explain how this might be advantageous for my usage
> scenario?  Thanks!
>
> Cheers,
> Jed

Hi Matt,

Could I possibly get a response?

Thank-you,
Jed

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

[CommandIR Support]

On Tue, 2009-11-03 at 23:52 +1000, Jed wrote:

> >> Was away for a few days, thanks for clarifying this!
> >> Still not quite sure this would benefit me in any way...
> >>
> >> I intend to learn all my consumer electronics IR codes using a
> >> transceiver + LIRC. Then I hope to use a Wifi Hand-held + HTPC + LIRC
> >> + Transceiver to issue commands to all gear within range.
> >
> > Matt, could you explain how this might be advantageous for my usage
> > scenario?  Thanks!
> >
> > Cheers,
> > Jed
>
> Hi Matt,
>
> Could I possibly get a response?
>
> Thank-you,
> Jed

Not more than I've already sent you on and off list.  Please feel free
to make both our jobs easier and scratch CommandIR from your shortlist.
I think you could have bought and tried all 4 products for the amount of
time you're spending reaching a conclusion.

All the best,

Matthew



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference