Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Scott Baily <baily@us...> - 2002-07-05 05:24:36
>> The behavior I want is this:
currently there's no way to tell LIRC to behave like this.
> (. . . there's
no data sent with a repeat signal).
oops, my mistake. . . If I hadn't
temporarily forgotten that, then it would've made more sense why repeat_gap
is the way it is.
>If you want the latter behaviour you'll have to at
least add a new flag.
I originally thought this would be useful. But now
I think it's probably better handled externally.
I had noticed that my JVC
remote had a gap of about 27ms, but when a button is pressed twice or a
second button is pressed it leaves a gap of about 60ms between the two
signals. When transmitting to the device, one needs to leave a gap of at
least 100 ms between different codes or else the 2nd code is ignored
(probably treated as a repeat if it's the same code). In fact this behavior
can be observed with the remote, if you press two codes in a row very
quickly, then WinLIRC will detect both codes, but the CD player will only
respond to the first code. I guess they didn't plan on anyone using two
thumbs on the remote. ;)
On the other hand, my Proscan VCR will accept two
codes separated by only its 8 ms gap. I haven't tried shorter intervals.
This could cause problems if the same code is sent twice, since there are
no special repeat codes.
It seemed like it might be a good idea for lirc
to keep track of this sort of thing except:
It's not necessary for IR
detection. There's no reason to behave EXACTLY the way the device does,
LIRC can simply check if the gap is significantly greater than the normal
gap to decide if it's from a separate press. (This is essentially what it
It doesn't solve the whole problem for IR transmission.
After sending "clear" to clear the title information for a disc, the CD
player needs a little extra time because it's busy erasing the
After some menu selections the VCR needs a little extra time or it
will behave strangely or ignore the next code. If it was recently powered
on, then it may need some additional time at a certain point that it
doesn't need if it was already on when the same sequence of codes is sent.
(e.g., after pressing "menu" "2" should select menu item 2. Once I send
"menu" "2" "1" and the selection bar on the display moved to menu item 2,
but then moved back and selected item 1 instead.)
Because the situation is
complicated by these sorts of problems, IMHO, it is better to handle the
necessary delays in whatever program is telling LIRC to transmit a sequence
of signals. If the application is on the same computer as WinLIRC, this is
not a problem, because it can use WM_COPYDATA to send the instructions to
WinLIRC. The SendMessage function won't return until the code is sent. I'm
not sure about Linux. The TCP interface to WinLIRC may present a problem
especially, since it currently doesn't acknowledge the commands. Does LIRC
acknowledge the SEND_ONCE command before or after transmitting the IR
signal? At any rate, one can probably work around this, by defining a
remote that has only a gap and no header or data bits. Then LIRC or
WinLIRC can be told to send a "signal" from that remote as many times as is
needed to create the necessary delay.
Well, this email has gotten much
longer than I intended, but I thought this might be useful to whoever wants
to send rapid sequences of IR commands to devices.