full duplex

[nbd]

The device is not able to send IR commands while it's receiving them.

I can reproduce this easily every time. I have igdaemon running and I can successfully send IR commands with 'igclient --send=./volup.txt' and it says 'send: success' and my amplifier reacts to that. But if I take any remote control (any but the amplifier's one) and point it at the receiver and hold a button down, then the IR command I send, does not get transmitted, although igclient still says 'send: success'.

I have another igclient running with --receiver-on --sleep 100 which displays this when I execute the send command:

received 3 signal(s):

space: 21845 pulse: 170 space: 109226

whether I hold the remote button down or not. (I'm not sure where those come from, but to my understanding it is not the command that is sent)

Compiled against libusb-1.0, driver 1.0pre2, device version 0x0306.

To me, this is critical issue, because I was hoping to use this device as IR translator (like IR repeater, but it changes the signal to be sent to another signal) but it cannot operate with continuous sequences (holding the button down). Single commands work most of the time (since the received signal sequence has ended before one is sent out)

[nbd]

The volume up command that I used for sending

[nbd]

igdaemon debug log, first sent the volup, then held down remote and sent volup again

[jdunn]

First of all, our devices are not truly "full duplex" due to memory and bandwidth limitations. Many signals require 100 transitions to send them. We cannot receive part of the signal from the PC while emitting the first part and keep the tight timings needed to get the proper carrier signals. A signal at 38kHz (the most common by far) means code on the device has to actually turn the LED on and off 38000 times per second which does not leave time to handle USB interrupts to receive additional data. This means we buffer the signals before they go out. Since the chip we use has a grand total of 256 bytes of RAM even if we tried to operate the receiver while sending the signal we would have at most 30-50 bytes to store the received signal in, which would not accommodate anywhere near a full signal.

I've written most of the above just to make sure it is recorded somewhere that someone else could find it again, and to give you some idea of the hardware limitations. From the sound of things I believe the device may still be able to do what you want because it does not sound like you actually need true full duplex operation. First off, 3 verboses is enough, the 4th throws in some lines that get a bit confusing, but I see nothing wrong with the logs.

Attempting to receive the signal that you are also sending is not possible for the reasons outlined above. You don't actually need that functionality, but looking at the value of the receiver during a send is basically meaningless. When the device says send success, it probably was successful, and if you watch the LED through a digital camera viewfinder I expect you would see a flash of similar duration and brightness whether you were pressing a button on a remote or not. However, I suspect that your amplifier can see the signal you are sending from the remote control and cannot recognize the signal from the iguanaworks device because of the interference from the remote control. If you block the amplifier's IR receiver such that the iguanaworks device can send it signals, but its remote control cannot and then send the signal while pressing a button on the remote I suspect it will work. Our device is designed to make transmission take precedence because we cannot predict what stray IR noise it may be seeing that would not allow it to transmit otherwise.

[nbd]

Ok, thanks for the info. I'll try how the amplifier reacts when I interfere its own remote with the TV's one. And then I'll try to block the amplifier's IR receiver to see only iguana's signals.

[bluey]

We haven't seen any feedback on this ticket in 2 months. Please respond with an update or we will close the ticket.

Thank you,

Ben

[nbd]

Can be closed. I can confirm that while the device is sending, it cannot receive. I changed the severity to wishlist to reflect the nature of this issue, but also the resolution as wontfix as I guess this can't be fixed on current hardware.