On 08/31/2009 01:05 AM, Calhoun, Sean P. wrote:
>> Okay, so I get slightly better results using output #2, but something
>> still isn't quite right. I'm looping the transmitter back to the device
>> itself, and at least with #2, the receiver lights up on every transmit
>> attempt, so its always seeing *something*, but irw only registers a
>> correct key every once in a while. So we're inching closer, but still
>> not quite there yet... I haven't yet looked at debug spew to try to
>> make heads or tails of what's going on.
> Hrm. I was able to reproduce your problem looping transmitter back to receiver on the mceusb gen1. I noticed that if I tried doing irsend -#3 SEND_ONCE<remote> <key>, then 1 or 2 out of 4 transmissions usually arrived at the irw end of the setup.
> When I did my initial testing before I submitted the patch, I used a second mceusb gen1 device: one for transmitting, and one for receiving. This setup ran better than the feedback setup. I had the receiver end listening using mode2, and I piped that into a little perl script to parse the protocol for the particular remote I was using. I'd say I got 100% transmission success, and the few times a code was not recognized, I blame the perl program (and it's equivalent to too strict eps/aeps values).
Okay, yeah, using a second receiver (a later mceusb model), it behaves
> As far as irw goes, it looks like things work pretty well using the two-transceiver setup:
> # lircd -d /dev/lirc0 --output=/dev/lircd0 --pidfile=/var/run/lirc/lircd0.pid
> # lircd -d /dev/lirc1 --output=/dev/lircd1 --pidfile=/var/run/lirc/lircd1.pid
> # irw /dev/lircd1& irsend -#3 -d /dev/lircd0 SEND_ONCE viera KEY_POWER
> 000040040100bcbd 00 KEY_POWER viera
> 000040040100bcbd 01 KEY_POWER viera
> 000040040100bcbd 02 KEY_POWER viera
> 000040040100bcbd 03 KEY_POWER viera
> Given these observations, it looks to me like the device enjoys transmitting XOR receiving; not both at once.
Yeah, looks like it. Probably part of why there are tons of different
gen2 models, and only the one gen1... :)
> I will defer to your experience since you have been working with these devices and drivers a bit more than I have. I noticed when I was doing some snooping, that the device can operate in BULK mode rather than INTERRUPT mode. Do you think there is a chance that changing to bulk mode could remedy this situation (if xmit& receive are competing for clock cycles, and only one interrupt service routine can run at a time)?
I believe the original driver operated in bulk mode instead of
interrupt, but that relied on polling the device incessantly. I prefer
interrupt-driven, which at least for IR reception, seems to work better.
Heavy-duty simultaneous transmit and receive shouldn't be typical
either, and changing modes from what the later transceivers do means
extra burden supporting different code, which is what the merge was
supposed to eliminate (plus, hopefully get us xmit support).
> (as an aside, although the viera codes seem to get received just fine by an mceusb, the transmissions still won't control my viera TV. I've had great results with other appliances and the mceusb gen1, though.)
Try adding a 'min_repeat 2' (or more) to your lircd.conf, see if that helps.
After screwing around a little bit to see what init stuff is actually
needed (hoping to possibly accidentally enable xmit on port 1 too), I
went ahead and committed a slightly different patch based on yours to my
git tree. No dice still with port 1, will have to do some more snooping
to figure that one out, most likely. I'll get this into lirc cvs in the
morning too. Transmit on port 2 only is definitely better than no
transmit at all, good progress here.